2009-12-26

初めてのメンテナンス業務

つい先日、ウェブアプリケーションのメンテナンス業務を引継ぎ、無事完了したのですが、無駄な苦労をしました。課題は3つあって、



  1. 本番環境には SSH でログインできない


  2. 本番環境と、提供された開発環境は同一の構成ではない


  3. システムやツールについて知識が不足している


だったと考えています。最初の2点は私が直接関与できませんが、最後の点について、いろいろと反省点があったので、自戒と未来の自分のために書き残しておきます。



開発環境と本番環境
プロジェクトから提供された開発環境でコードが動作することは、必ずしも本番サーバで動作することが保証されませんでした。それはそれで仕方ないとして、本番環境にできるだけ似せた開発環境を自前で用意すればよかったと思います。それができなかった原因のひとつは、技術的知識/技能の不足です。



MySQL、Apache、PHP それらが chroot された環境で動作するシステムなのですが、これらのコンフィギュレーションの知識がなかったため、自前で用意した環境が信用できませんでした。ほんとになんというか気休めな感じです。



デバッグのツール
基本的に、echo、var_dump、var_export あたりの原始的な関数を使っていました。状況によっては、これらでは足りない場合が出てくるわけです。



で、独自のロギング関数を用意しました。logging_log($obj, __FILE__, __LINE__); みたいな関数で途中記録をためておいて、logging_gethistory(); で記録を読み出すような感じです。これはなかなか便利でしたが、logging_gethistory()に到達する前に、エラーで停止すると見られないというどうしようもない展開です。



プロジェクトが終わってから「PHP デバッグ」で検索すると、いろいろとたくさんツールがあることが発覚。なぜ最初に検索しなかったのかと。



依存関係の把握
Michael Feathers の「Working Effectively With Legacy Code」(レガシーコード改善ガイド)という本を紐解きました。これは変更(デバッグを含む)が困難なコードを、いかに攻略するかについて書かれた本で、その中の依存関係を理解するというところが役立ちました。



たとえば、変数 $foo; の値がおかしい、あるいは関数 $func の動作が怪しい、と。そのときに、どこかで変更を加えていいのかどうか分からないのがレガシーコードです。そこで、この処理や値を変更するとどこに影響がでるか? あるいはどこの値や処理の副作用で、当該箇所の出力が変わるのかを、簡単な図で会ておきましょう、と。非常にシンプルなプラクティスです。



どこかの値がおかしいとき、それらを逆にたどっていくわけですが、依存関係がかなり複雑でエディタでは追えませんでした。そこで、依存関係の図をかくとずいぶんわかりやすくなりました。グローバル変数の副作用があったりして大変でしたけど。








ユニットテスト
頻繁にファイルをアップロードできなかったので、一気にいろんな変更をしてしまい、ハマることもありました。そこで、機能を追加するまえに、手間がかかっても(当たり前ですが)単体テストのコードを書いて、本番サーバで動くことを確認するようにしました。



SimpleTest を使いました。これは、どっかのフォルダに置いておけばいいので、今回のように環境を自由にいじれないような場合にうってつけです。ユニットテストをするほうが、トータルのリードタイムが短くなりました。



今後
と、いうわけで、これらの反省を生かすべく、自宅サーバで簡単なアプリを運用してみようかなぁと思い始めました。そうすればインフラや環境について詳しくはないにしても、何に疑問をもつべきか、くらいは分かるようになるかな、と。ほんとは Google App Engine みたいなのが便利ですが、学習ってことで。



みなさんは、どうやって技能をみにつけているのか気になるので、コメントくださいませ。