データベースエンジニアが行く

稼働中のシステムの修正が必要になった。
急ぎなのですぐにとりかかったが、7時間もかかってしまった。

そんなに難しい修正ではないので、3時間半か4時間で済ませることができたように思う。
時間がかかった理由を検証してみる。



急いでいたため、じっくりと修正方針を考える前にPCの前に座り、
ソースコードの修正にとりかってしまった。

修正方針が確定しないまま、ソースをあれこれ修正した。
午後10時を過ぎていて眠く、効率は良くなかったと思う。
２時間半かけて一通りの修正が終わった。

修正が終わったソースを見直していて、別の修正方法を思いつき、方針を変更。
1時間かけて再修正を終え、その日は就寝。

朝が目が覚めて、布団の中でソースの修正内容を考え直し、
さらに第三の方法があることに気付いた。

起床、朝食の後、ソースコード修正に着手し、2時間かけて
第三案でのコーディングを終了。

第二案と第三案を比較しながら、動作テストを行い、第三案を採用することに決定。
動作テストに1時間半かけたので、作業時間は合計7時間となった。
朝、布団の中で考えた時間は含めていない。

三つの案を通じて時間をとられたのが日時の比較部分。
１日前から、１時間前からと言った条件でデータを抽出するのだが
日付と時刻を別々の項目で保存していたため、日をまたいだ場合の取扱いが
複雑になり、その対応に時間をとられた。

最初の案のコーディング中にその部分の取り扱いを確定せず、あいまいなままにしたため、
第二案、第三案のコーディング中にも検討を余儀なくされた。
同じことを延々と考えていたような印象が残っている。

その他、第三案でのコーディング中にWebで検索して調べたSQL構文が
実環境では動作しないということも起きた。


三つの案のすべてについてコードを作成しているのが最大の無駄。
一日目は何もせず、二日目の朝、布団の中で考えることから始めればよかった。

次に無駄だったのが、日時の比較に費やした時間。
日付と時刻を別項目にすると、日をまたぐ場合の条件指定がややこしくなるのは明らか。
日時を連結したデータを変数で持つか、またはテーブルに項目を追加するかして、
単純化するべきだった。

今回の事例は以下の手順で行えば、4時間以内で完了できたはず。
�@データ抽出に使用するSQLコマンドを記述して、コマンドベースで実行して正常動作を確認する。
�A日時の条件指定方法をいくつか試してみて、取り扱いを決める。
�Bにコード作成にとりかかる。
�C動作テストを行う。


やみくもにPCに向かうのではなく、最初に全体の方針を決めること。
コーディングが難しそうな部分を予想し、その部分は初めに対策すること。

ソーソコードを作成したからこそ、別の案を思い浮かんだという意見もあるが、
それでは時間がかかりすぎて採算割れとなる。

手を動かしてコードを書かなくても、集中力を高めて取り組めば複数のプランを思い浮かぶはず。
急ぐときほど、落ち着いてじっくりと考えること。