書き捨てのスクリプトにこそソフトウェアエンジニアの実力がでる、ような気がした。

まず書き捨てのスクリプトを書くということは、なにかを短時間でおわらせたいという要請があるということ。タイムリミットが短い。時間が短いことにより、いくつかの工夫をすることになる。

• 重要な要件とそうでないものを判断して集中する。
• コードも、可読性、メンテナンス性、イレギュラーのハンドリングなどを取捨選択する。
• たいてい一から書くことになるので、自分の引き出しからコードの種をひいてくる。
  • 自分の引き出しとは、システムへのコードレベルの理解、既存のどのコードをを参考にすればよいかという知識、自分がアクセスできるところにあるコードスニペットなど。あるいは、一度やったことがあることは、やはり二度目はもっと早くうまくできる。よってふだんからいろいろな読み書きをすることが活きてくる。

こうした要素はふつうの開発プロジェクトでももちろん重要なことだ。だがこうした短時間でさくっと終わらせたいタスクの場合にとくに目立ってくる。経験のあるエンジニアは捨てるところの選択がうまいし、反対に時間がないからといっても、最低限必要な要件は外さない。短い時間でかいたのに、仮に自分が書いたとしてそのコードと比較すると、読みやすいものができていることが多い。

たとえば先日のできごと。データストア障害の二次対応として、ログファイルからデータストアにデータを書き戻すリカバリスクリプトを書いた。こういうバッチ処理には、特に今回は実行時間がながいものなので、つぎの要素が外せないだろう。

• 進捗のログ出力
• イレギュラーケースのハンドリング
• 任意の地点からバッチを再開ができる機能とそのためのロギング

はじめに書いたスクリプトにはこのあたりのポイントが弱かったが、経験豊富な同僚に指摘をもらうことができた。またデータ不整合がおきるコーナーケース、さらにそれがどの程度の頻度でおこりそうかという概算まで、を指摘してもらい、たいへん有りがたかった。

裏をかえすと、必要な要件に適切な優先順位をつけること、どこまで “よい” コードにするかのバランスをとること、引き出しを豊富にしておき短時間でも最適解にたどりつくこと。あくまで一要素だが、こうしたことができるのが実力のあるエンジニアということになる。どんなタスクにも有用だとおもう。ふだんからこれらを意識しながら仕事をしたい。

短時間のタスクをこなすことは、これらの要素を伸ばすよい題材だ。そう考えると Node KO や Cookpad の開発コンテスト 24、ヤフーの HackDay といった、時間制限のなかで独自のサービスをつくるコンテスト。これらは主催側からはエンジニアの実力を見るのに、参加側からは実力を示す、または伸ばすのに、よいスタイルだといえそうだ。

さいごにポイントを繰り返しておく。

• 要件の重要度を判断する
• スケジュールを考慮してどこまで凝るかを判断する
• ふだんからコードを読み書き、勉強し、引き出しをふやす。使えそうなコードは抽象化し再利用。