2012年最後の記事です。 今年の振り返りということで、会社の開発忘年会で発表したネタを軽くご紹介したいと思います。（軽く来年への抱負も含まれています。）
こちらが開発忘年会で使った発表資料です。
タイトルの通りですが、今年は本当に多種多様なプロジェクトに関わらせていただいて、その度に何か特定の技術・アーキテクチャ・設計手法等に夢中になりながらここまでまいりました。
ここではこの記事を読んでいる方へのご紹介も兼ねて、忘年会では時間の都合上話せなかったことも少し述べたいと思います。
キャッシュ厨
今年初期、パフォーマンス要件の非常に厳しいプロジェクトにアサインされた際に発症した症状です。
WebサービスにおいてパフォーマンスのボトルネックになりやすいのはDBサーバであるという言葉を信じ続けた*1結果、何でもかんでもキャッシュしてしまい、極力DBサーバにアクセスしないようにしようと心がけた結果、何か病的な実装になってしましました。
これが後になって、SQLチューニング厨の原因になるとは、この頃は知る由もありませんでした。
JS厨
あらゆる処理をJavaScript（以下、JS）でやりたがるという症状です。
サーバーサイドスクリプト言語で実装されたテンプレートエンジンのタグを極力使わず、JSON/XMLのAPIやHTML5のdata拡張属性を最大限駆使してサーバからクライアントへ必要なデータを渡そうとしていました。
弊社は数年前までモバイル（スマートフォンでなく、いわゆる「ガラケー」）向けサイトの開発を得意としており、JSをガッツリと使うプロジェクトはいままでありませんでした。
JS厨を発症するきっかけとなったプロジェクトは、このような意味で僕にとって非常に学びになったプロジェクトで、クライアントサイドでどれだけのことができるかを教えてくれたとともに、サーバサイドとクライアントサイドでどういう風に役割分担するべきかという設計の方法論を考えるきっかけを与えてくれました。
当時は麻疹といっていいくらいやり過ぎだった感じは否めないですが、モダンなWebサービスの設計/実装を知るうえで必要なフェーズだったと今では思っています。
Ruby/Rails信仰
弊社ではPHPを使っているプロジェクトが多いのですが、今年入社して初めてRuby on Railsのプロジェクトに関わることができました。 Rubyが持つ表現力や徹底したオブジェクト指向的思想は、コードを書いていて気持ちよく、あらためてその良さを実感しました。また、そのデファクトスタンダードのフレームワークであるRuby on Railsでは大抵の要件はそれを満たすためのgemが提供されており、しっかりとメンテナンスされているため、自前で実装しなければいけないコードは減りましたし、それを駆動するテストコードも、バグの発生件数も減ったと思っています。
来年、もっと多くのプロジェクトでRubyを導入できれば嬉しいと思いますし、プログラミング言語にはそれぞれに長所があるので、ある言語に傾倒することなく、いろいろな言語を引き続き学んでいきたいと思っています。今はScalaを勉強中なので、来年使いこなせるようになるといいかと。
SQLチューニング厨
年初にかかったキャッシュ厨の反動で、キャッシュに頼らずSQLのチューニングで高負荷なサービスを支えることはできないものかと考えた時期がありました。
弊社ではほとんどのプロジェクトでMySQLを用いていますが、この時期には本当に多くのMySQLの設定やクエリの最適化について勉強しました。これ自体は非常によかったと思いますし、今後も活用していきたいと思っています。
ただし、テーブルのレコード数や実際のトラフィックを考慮しない、いきすぎたチューニング*2をしていたかもしれないという感覚もあり、それについては反省の余地があるかと思います。
同じ年にキャッシュ厨の時期とSQLチューニング厨の時期を経験したのは今後の僕にとって大きな学びになったと思っています。
高負荷のサービスをきちんと運営するために、データに基づいたトラフィック分析をし、データ件数の伸びを予測し、キャッシュを用いた場合のヒット率を試算し、もっと合理的に意思決定ができるようになりたいと思います。
テスト厨
今年一番の大きな変化はテストコードへの興味を持つようになったことだと思っています。
仕様を明確にするためにテストを書くという設計手法に興味を持ち、よいテストコードを書けるようになることがよいプログラマになることだと考えるようになりました。その過程で、「何にでもテストを書きたい」という状態（いわゆる「テスト厨」）になるに至りましたが、これはTDDをきちんと理解するうえで必要なことだったと思っています。TDDに関しては書籍を読んで独学で学びましたが、それなりに実践できるようになったと思います。
今後もテストを軸に、保守性の高いシステムの設計・実装をできるように精進していきたいところです。
リーダブルコード厨
テストに興味を持ち始めたのとほぼ同時期、書籍「リーダブルコード」に感銘を受け、「すべてのコードはリーダブルでなければならない」という時期がありました。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
- 作者: Dustin Boswell,Trevor Foucher,須藤功平,角征典
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/06/23
- メディア: 単行本（ソフトカバー）
- 購入: 55人 クリック: 1,593回
- この商品を含むブログ (79件) を見る
変数名、メソッド名の命名に時間をかけ、どこで改行するかを長時間考え、メソッドが長くなるとその一部を別メソッドにするまでコミットしないということをやっておりました。
これは今でも間違ったことだったとは思ってないですが、先日のDevLove2012で「技術的負債を戦略的に負うのは間違いではない」という話を聞き、そういう意味では当時の自分は病的だったと考えています。
技術的負債は、それを負債だとチームで共有し、その返済計画をきちんと立てることができれば、ひとつの選択肢になり得ます。コードがリーダブルであることを犠牲にし、リファクタリングにかけるコストをカットする代わりに本来より早くプロダクトオーナーにシステムを実際に使ってもらう、ということが戦略オプションとしてとれるようになれると今より柔軟な開発ができると考えています。
オブジェクト指向厨
テストを自動化するためにはそれに適した設計というのがあります。一般に、テストをしやすい設計は、すなわち拡張しやすい設計と同義だと言われており、TDD関連の書籍では「テストの声を聞く」と表現されるほど、設計の不備はテストが教えてくれるものだと言われています。
しかし、テスト厨を発症しているときには、テストコードを書くのが楽しいあまりどんなにテストを書くのが難しくてもがんばってテストを書いていました。しかし、テスト厨がやわらぐと、自分たちが今使っているアプリケーションフレームワークやライブラリの構造そのものに疑問を感じるようになりました。そこで次に発症したのがオブジェクト指向厨です。もはや定番すぎるプログラマの麻疹ですが、僕が感染したのはまさかの今年の後半です。
弊社ではPHPで動いているプロジェクトが多く、パフォーマンスの壁がある*3ため、厳密には「厨」というほどオブジェクト指向設計をしていない（できない）ですが、隙あらばJavaを使う機会がないかとうかがっています*4。
まとめ
上述した資料にも書いていますが、麻疹はプログラマの職業病で、誰でもいつか発症します。
来年も麻疹を恐れず、いろいろなことを学び（おそらくそれに熱中し）、ますます成長していこうという所存ですので、引き続きよろしくお願いいたします。
