オピニオン: スタイルを強制するのはプログラミング言語ではなくチームであるべき

作者 Mark Levison , 翻訳者 岡田 英久 投稿日 2008年2月19日

セクション

プロセス/プラクティス,

デベロップメント,

設計/アーキテクチャ

トピック

Delivering Quality ,

Agile ,

コード分析

タグ

Value & Metrics ,

Coding Standards

大規模なマニュアルにはプログラミングに関する問題を解決するために従うべきシンプルなルールが必ず書かれていると信じている人たちがいる。これはウォーターフォール型の開発手法ではよくある考え方だろう。XP だと、安全な構造とクリーンなスタイルを開発者に強制するプログラミング言語を求める人がいる。Reg Braithwaite 氏はこの信念(source)を批判して次のように言う。

その言語でコードを書けば、その人は書いたコードのスタイルに関するすべての責任から免れる。その人たちの管理者についても同じだ。プログラマの書いたコードがコンパイルされれば、それは悪いスタイルではないと実証されたことになるし、彼らの管理者に対しては、プログラマがその言語を使っているかどうかを注意するように要求することしかできない。

.... ここから学べるのは、個々人の選択権を奪えばそれは結果として彼らの責任を免除することになり、最終的には、彼らのスキルが客観的に見て高かったとしてもパフォーマンスは大きく劣化してしまうということだ。

自動化はよいことだし、私たちはいつもそれを利用している。コンパイラやガベージコレクタだって自動化のひとつだ。自動化は、もはや問題が起こる心配のない処理に対する責任から私たちを解放してくれると Reg 氏は言う。私たちはすでに CPU インストラクションを大量に記述したり、メモリを管理したりする責任を放棄している。私たちがスタイルを自動化するということは、スタイルに対する責任を放棄すると宣言するのと同じなのである。Reg 氏は次のように続ける(source)。

スタイルを自動化するということは、スタイルはもう誰かが責任を負わなければならないような問題ではないと判断したということだ。コンパイラを通りさえすればよいのである。

スタイルを自動化すると、個人という概念やコードの所有者という概念が希薄になり、ゲートを通過したものは良いに違いないという観念が強くなる。そして、それは次に、それ以上のコードの検査は不要だという幻想を引き起こす。コードが要求されている機能を実現しており、そしてよいスタイルを強制する言語で書かれているのなら、そのコードをレビューする必要なんてないわけだ。

よいスタイルを強制するかわりに、どのプログラミング言語ならよいスタイルでコードを記述できるかを考え、よいスタイルとはどういうものかについてチームで合意を得ることに焦点をあてるのがよいだろう。そして、責任は明確にすること。自動化によって曖昧にしてしまってはいけない。それが Reg 氏からのアドバイスである。

原文はこちらです：http://www.infoq.com/news/2008/02/code-reviews

• 次へ >