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

つい先日、ウェブアプリケーションのメンテナンス業務を引継ぎ、無事完了したのですが、無駄な苦労をしました。課題は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 みたいなのが便利ですが、学習ってことで。

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

Doing リストがパワフル

Doing リストというのが、生産性の向上に威力を発揮しそうな気がします。集中を強制するから。最初に Doing リストというコンセプトを知ったのは、おそらく「ゆっくりと動きながら高速でこなす、一流の研究者の Doing リスト」だと思います。

黄色いノートパッドはそんな彼を脱線させないための「いま、何をしているか」のリストなのだということが見て取れました。実際、彼はリストに書かれている以外のことは、いっさい実行していません。

他にも、フランクリン・プランナーのタスクでも「やっている最中」という意味で、TODO リストの□の中に、・をつけるというプラクティスがありました。なので、紙ベースでやるときなんかは、・をよく使っています。

これを Things でやってみるわけです。作業中のプロジェクトには「doing」タグを付けるようにしました。こうしておくと、doing タグを選択したらいつでも、作業中のプロジェクトに戻ってこられるわけです。

途中で他のことを思いついたらどうするか。

見つからずにいったんあきらめたファイルを「あ、あそこだったかも」と思い出した場合でも、そのコマンドを打ち込むのではなく、リストにそれが加わってゆくのです。

Things では受信箱にタスクを追加するためのキーボードショートカットがあります。これを使えば、doing プロジェクトから離れることなく、思いついた作業を使い出来ます。紙でもいいけどね。

ともかく doing タグがあると「えーっと次はなにするんだったっけ？」って考えなくていいです。doing のプロジェクトがなくなったら考えますが、それは「今日」のプロジェクトからピックアップするだけなのです。どれをピックアップするかは、それはそれで重要です。それはまた別の機会に（たんにルールが決まっていないだけ）。

Things の今日タスクの進捗をカウントする AppleScript

毎日の進捗を把握し、かつ、モチベーションを（ある程度）上げるために、その日にやるべきタスクの達成度を時系列で記録し始めたわけですが、手間がかかるんですよね。というわけで AppleScript で自動化しました。ほんとは、appscript の Python バインドでやろうとしたのですが、ビルドに失敗したので、AppleScript です。

Things の「今日」タスク総数と、達成したタスク数を表示します。けっこう処理に時間がかかります。

tell application "Things"
    tell list "Today"
        set open_tasks to 0
        set completed_tasks to 0
        repeat with task in (to dos)
            tell task
                if status is open then
                    set open_tasks to open_tasks + 1
                else if status is completed then
                    set completed_tasks to completed_tasks + 1
                end if
            end tell
        end repeat
    end tell
    display dialog "Total: " & (open_tasks + completed_tasks) & return & "Done: " & completed_tasks
end tell

アプリケーションにコンパイルしたもの

もどうぞ。

タスクをこなすペースを可視化する

終了させるのに何時間もかかるような作業は、小さなステップに分割してこなすことにしています。事前に計画を立てるクセがつきますし、進んでいってる感があるからです。

ただ、私がいまやっている仕事が、仕様をまとめる、みたいな仕事なのです。学生のときに論文を書いていたときもそうでしたが、「1章」「2章」みたいな分割のしかただと、先が見えなくて、くじけてしまいます。

そんなわけで自分のモチベーションを保つために、タスクを分割するだけでなく、その時間的な進捗を見るようにしてみました。

eXtreme Programming の本だったかに、テストの結果を時系列で記録しておけみたいなことが書かれていたのを参考にしています。ときどき、タスクの数が急激に増えるのは、作業途中で、大きなタスクを小さなタスクに分割するからです。なので完了/未完了の比率も描いて、状況を把握しやすくしています。しやすいかどうか、ちょっと微妙ですが。

で、このグラフがあると、タスクをこなすペースが分かるんですね。このままでは間に合いそうになぁとか、いいペースだとか。ちょっと厳しめの目標値を立てておいて、それに追いつくように頑張ります。

ただし、この方法は作業集約的なタスクじゃないとうまくいかないかも知れません。