習慣その2　書く――とにかくコードを書きましょう

手の裏付けのない言葉はあまりに安い。人を動かしたかったら、まず自分の手を動かせ。手が塞がっていたら、手を動かした経験を語れ。口で語るな手で語れ。

――小飼 弾[6]⁠

当たり前のことですが、「⁠良いコード」が書けるようになるには、「⁠自分の手を動かして、コードを書く」必要があります。コードを書くという実践が「良いコード」を書くうえでの血肉となります。仕事でコードを書くのはもちろんですが、日々の単純作業を効率化するツールやスクリプトを書いたり、新しい言語やフレームワークを試してみたり、さまざまな場面で自分の手を動かしてコードを書きましょう。

「いったい何を書けばいいの？」という人は、コードの写経はいかがでしょうか。書籍やWebサイトに掲載されているコードを、実際に手を動かして一文字ずつ入力することを「写経」と呼びます。写経することで、元のコードが書かれた手順や、行間に潜む意図を伺い知ることができます。これは、「⁠コピペ」では得ることができません。その技術を体得したいときや初めての分野の技術に挑戦するときなどに特にお勧めです[7]⁠。

習慣その3　道具を磨く―― 自分の使う道具は常に磨いておこう

コードを書くうえで必要な道具や環境を、最高の状態に保ちましょう。作業効率を上げていくことで、無駄のないプログラミングが行えます。たとえば、APIリファレンスが必要なときに、エディタのコード上から1秒で確認できるのと、Googleで毎回検索して目的に場所にたどり着くのではまったく効率が異なります。

以下、道具ごとに見ていきましょう。

エディタ／統合開発環境

viやEmacsなどの高機能なエディタや、EclipseやNetBeansのような統合開発環境を使いこなして、効率的な作業環境を構築しましょう。これらには効率を高めるショートカットキーや機能が満載です。ショートカットキーを駆使して不要な場所でマウスやカーソルキーの利用を減らしたり、エディタをカスタマイズしていくことで、手になじむ効率の良い開発環境に育っていきます。

自動化

ビルドは自動化しましょう。DBのスキーマ作成は自動化しましょう。テストは自動化しましょう。ありとあらゆることを自動化の対象とみなして、改善していきましょう。Maven2やAnt、rakeコマンド、シェルスクリプト、バッチファイルなどを使えば、繰り返し行う単純作業を自動化できるはずです。

バージョン管理ツール

バージョン管理ツールを使って、作業を巻き戻したり効率良くチーム開発できる環境を作りましょう。

UNIX/Linux/Mac OS Xなど

UNIX/Linuxのコマンド／ツール群は、開発の細かい作業をサポートしてくれます。また、Windowsでは知ることのできない哲学がUNIXの文化にはあります。

最近では、Windows上でLinuxを動かすのも簡単ですし、UbuntuやMac OS Xで開発することも問題なくできるようになってきています。使ったことのない人はぜひ利用してみてください[8]⁠。きっと世界が広がるはずです。

習慣その4　知る ―― 良い知識を得よう

良い知識を得ることは、技術向上には欠かせない要素の1つです。以下、知識の入手先別に紹介します。

書籍―原典とHow To本の2冊買いがお勧め

正しいことは何なのか、良いコードとはどのようなものなのかを知るうえで、書籍はコストパフォーマンスに優れています。

書籍を選ぶときは良書を入手しましょう。表1のように、各言語において原典と呼ぶにふさわしい良書が存在します。原典には本質的なことが書いてあり、その分野を深く理解するためにも欠かせません。

しかし「良薬口に苦し」です。良書は、難しく見えたり、とっつきにくかったりすることが多々あります。ですので、同時にライトなHow To本も手に入れるのもいいでしょう。ただし、How To本の宿命として、最初はとっつきやすいのですが、その後伸びなくなることが多いのも事実です。

繰り返しますが、良書を入手しましょう。最初は理解できなかったものでも、後で必ず必要になってくるはずです。良書が「結構いい本だな」と思えるようになれば、かなりレベルアップしていると言えるでしょう。Amazonの評価やブログでの評判を見れば、どれが良書なのかはある程度見えてきます。最後は書店で自分の目で確認して、みなさんにとっての「良書」を見つけてください。

リファレンスなどのドキュメント

APIドキュメントなどのリファレンスや、RFC（Request for Comments）やJSR（Java Speciﾞcation Request）などの仕様書は、それぞれの仕様における原典です。原典は手元に置いてすぐに確認できるようにしておきましょう。

Webサイト

言語やフレームワーク、Webの最新技術、開発プロセスなど技術情報は常に移り変わっていくので、Webサイトでの継続的な情報収集が欠かせません。

その際は、RSS/フィードリーダーなどを使って効率的に巡回するとよいでしょう。まだ使っていない人は、だまされたと思ってlivedoor Readerあたりを使ってみてください。巡回の効率が数倍になって、より多くの情報を収集できるはずです。

習慣その5　聞く――アウトプットと人からのフィードバック

上記4つの習慣は1人でできる、いわば「静的」なものでした。最後の「聞く」は、他人を巻き込んだ「動的」な習慣です。「⁠聞く」は「アウトプット」と対になっています。まず自分のコードや考えを誰かにアウトプットして、フィードバックを得られる場面を作る必要があります。

ここでは、アウトプット＆フィードバックのためのいくつかの方法をご紹介します。

コードレビュー

この記事もそうなのですが、出版業界には校正作業という「荒削りな段階の原稿」を他人がチェックをして、より良い記事にしていく、素晴らしいプロセスが用意されています（毎回、その「荒削りな原稿」が締め切りまで、なかなか書けなくて苦しんでいますが(>_）⁠。校正作業により「自分以外の誰か」に見てもらうことで、原稿はビルドアップされ「良い原稿」へと近づいていきます。

ソースコードも同じです。公式・非公式を問わず、自分の書いたコードを「自分以外の誰か」にコードレビューしてもらうことで、自分では気づかなかったフィードバックがもらえます。コードが良くなるのはもちろんですが、コードレビューを通して「自分」あるいは「レビュアー」が気づきを得ることで成長できるのがレビューの良いところです。

ブログを書く

フィードバックを得る方法の一つとして、ブログに書いてアウトプットするという方法があります。たとえば、自分の書いたコードや考えを載せてみたり、はまったポイントを書いてみたり。

最近では「キーワード」や「ソーシャルブックマーク」などで、興味対象が近い人どうしがつながる機会も多くなりました。ちょっとしたことでも発言してみることで、フィードバックや気づきを得ることができます。

コミュニティや勉強会に参加する

技術コミュニティや勉強会、読書会などが、東京、地方を問わず開催されています。これらの場には志の高いエンジニアが多数参加しています。このような場所で仲間を見つけて、直接意見を交換したり、気軽に質問したりするとよいでしょう。その出会いが、あなたのこれからの仕事をより良いものにするはずです。

発表してみる

セミナーで一番成長するのは、間違いなく講師です。社内勉強会を開催するなどして、みんなの前で話すことで、考えがまとまり、より理解を深めることができます。

「1000人スピーカープロジェクト」（⁠注9）など、発表を目的にしたプロジェクトも開催され、「⁠アウトプットによる発表者の成長」が今後ますます注目されていくでしょう。発表までいかなくても、会社の人に技術の話をしたり教えたりすることも同じような効果やフィードバックがあると思います。

おわりに

今回はウォーミングアップとして、良いコードを書くために必要な日々の習慣を紹介しました。今回紹介した習慣をすべてやらなければいけないというわけではありません。自分のペースで、必要なものから取り入れていくとよいでしょう。

次回以降は、「⁠良いコード」について具体的に掘り下げて話していきます。お楽しみに。

お勧め書籍

『ソースコードリーディングから学ぶJavaの設計と実装』

WINGSプロジェクト佐藤 匡剛 著、山田 祥寛 監修
技術評論社、2006年

Struts/Velocity/Tomcat/JUnit/Spring Frameworkなどのソースコードから、背景にある設計技法などを学ぶことができます。コードの読み方がわからない、どのコードを読んでいいかわからないという人に特にお勧めです。