キミのコードが汚い理由：The Rational Edge（3/3 ページ）

[Gary Pollice（ワーチェスター工芸研究所実務学教授），＠IT]

コードの改良

　世間が汚いコードであふれている理由は十分に分かったが、では、われわれはそれに対して何ができるのだろうか？　筆者はここで、以下の3つが可能だと提案したい。

1. クリーンなコードを書くことを自分のプロセスに取り入れる
2. クリーンなコードの書き方を教える
3. クリーンなコードを評価する

　では、ここで1つ1つ説明したい。

　クリーンなコードを書くことを自分のプロセスに取り入れる。

　Agileコミュニティーにおいては、コードをクリーンしておくことは原則の1つだと高く評価している。その1つが以下だ。

　優れた技術とデザインに常に留意することがアジリティを強化する［注5］。

［注5］http://www.agilemanifesto.org/principles.html参照。

　この原則は、eXtreme Programming（XP）の連続リファクタリングなどの手法の中で明示されている。XPのチームに参加するプログラマーは、常に時間をかけ、コードを可能な限りクリーンかつエレガントなものにすることが期待されている。近道は許されることではなく、評価されることも報われることもない。もちろん、これは期限が迫ってもチームが実際にXPの手法に従っていると仮定した場合だ。しかし、時間に追われることによって、組織が再びワニとの対決を余儀なくされる文化に戻らないとの保証は一切ない。

　もしあなたが、リファクタリングや優れたコメントの作成を自分の個人プロセスに組み入れれば、ほかの方法ではコードが書けなくなっていくだろう。見積もりが正確かつ妥当なものになるよう、コードをクリーンにし、コメントを挿入するための時間を考慮することになる［注6］。

［注6］個人プロセスについては2004年8月の記事参照：http://www-128.ibm.com/developerworks/rational/library/content/RationalEdge/aug04/5585.html。

クリーンなコードの書き方を教える

　コードを書く作業はほかのどのような作業とも同じだ。練習、批判、そして練習の繰り返しが必要だ。Richard Gabriel氏は自著『Writers' Workshops & the Work of Making Things: Patterns, Poetry……（作家のためのワークショップと物作り：パターン、詩……）』［注7］［注7］の中で、散文、詩、そしてソフトウェアコードを書くときの多くの類似点を解説している　これらのさまざまな書き方を芸術として扱い、協調テクニックを重点的に学ぶことは学校では難しいが、教師がソフトウェアのコーディング学を芸術の域にまで高めることのできる手段なら、おそらくどのようなものにも価値があるだろう。

［注7］2002年、Pearson Education刊、ISBN 020172183X。

　うまく書けるようになるためには、うまく読めなくてはならない。書き方に堪能になりたいときは、まずは特定の言語で利用される標準と成句の両方の読み方を理解する必要がある。コードの読み書きも同じだ。その言語と、それのうまい使い方を学ぶ必要がある。そして、優れたコードを書けるようになりたいなら、コードをうまく読めるようになる必要がある。学生に対し、コードを読んでよく考え、その品質やエレガンスについて議論しろという時間が不足しているのだ。筆者が一緒に働く光栄にあずかれた最も優秀なソフトウェア開発者の1人は、膨大な量のコードを読む。彼は、さまざまなプロジェクトのコードを読み、どうすればそれを改良できるか考えることで、うまくプログラミングするための方法を学んでいるのだ。

　一部の学校（その数はあまりに少ないが）では、「ソフトウェアスタジオ」のような名前の付いた課程やゼミを用意している。これらの課程では、学生がアーチストや作家のように集まり、作品を見せ合う。彼らはどんな意見でも出し合い、建設的な批判の仕方や受け方を学ぶ。大体の場合、優秀な学生には業界でよく見られる大きなエゴがあり、このような課程は彼らの多くにとって困難なものになるが、それは素晴らしい学習体験になるだろう。

　われわれは、今年のWPIから「コーディング道場」を開催している。コーディング道場は、筆者が今夏の「Agile 2006」カンファレンスで知ったものだ［注8］。毎週集まってシンプルなコーディングに挑戦している。コードをグループで書くことも多い。筆者が先に示したリスト2のコードは、先日の集まりで作成したものだ。われわれの道場で唯一問題になるのは、時間があまりに短いことだ。しかし、この道場は、クリーンなコーディングテクニックについて考え、それを自分の中に取り入れるのに最適な方法だ。道場はどこでも開くことができる。会社の昼休みのイベントとしても素晴らしい。

［注8］コーディング道場の情報はhttp://wiki.agilefinland.com/?CodingDojoを参照。

　大学の課程で出る課題の大半は短いもので、前述のようにコードのエレガンスや読みやすさはあまり重視されていない。しかし教育者としては、学生が利用できるコードベースを増やす方法を探す必要がある。例えば、学生に既存のコードベースの維持管理を行わせ、これを拡張することも考えられる。そうすれば、彼らもうまく書かれていないコードの苦痛を味わい、それが後々生産性に与える影響を感じられるようになるだろう。筆者の学生は2005年にこのようなことを経験した。2006年になってから、筆者がプロジェクトにおけるコードの品質向上の必要性を認識した次第だ。

　その結果は劇的なものだった。筆者がソフトウェアエンジニアリングを教えている学生に対し、オブジェクト指向分析や設計を教えている学生の書いたベースコードを提供したところ、1週間もたたないうちにこれを効果的に使い出したのだ。2005年の時点では見られなかったことだ。筆者が毎週課題を出すOOADプロジェクトの成績は、そのjavadocコメントとコードのスタイルで採点した。

クリーンなコードを評価する

　もしあなたがマネージャならば、部下に自分の価値を理解させる必要がある。コードの品質とエレガンスがあなたにとって重要であることを、部下である開発者が確実に理解するよう努めるのだ。期限が迫ってきたらチームをかばい、（いずれにせよテキトーなことが多い）予定日を守るためだけに粗悪なコードを出荷するよりも、スコープ管理のために戦うのだ。

　優れたコードには何らかの方法で報いたい。報いることは難しいことではない。あなたが何を重んじるのかを部下たちが認識するまでにさほど時間はかからないし、彼らは底力を発揮して、これらの価値に見合った成果を上げるだろう。大規模企業の活動はこのような価値を支持しないが、コードの保守性が将来的な作業に役立つため、長期的には部下たちができる作業は増えていくだろう。

---

　本稿がきっかけとなり、クリーンなコードを評価することを考えていただけるようになれば幸いだ。筆者は、これがきっかけでクリーンなコードを評価する手段について考えるようになった。今後の記事では評価基準について解説していきたい。

要約

粗雑なコードができるには3つの理由がある。すなわち、「時間のプレッシャー」「学習不足」「熱意」だ。これらに対し、われわれはどういう対応がとれるのだろうか。3つの対策が考えられる。「クリーンなコードを書くことを自分のプロセスに取り入れる」「クリーンなコードの書き方を教える」「クリーンなコードを評価する」の3点だ。

本記事は「The Rational Edge」に掲載された「Writing clean code」をアットマーク・アイティが翻訳したものです。