Sam Gentile氏（ブログ・英語）、Oren Eini (通称 Ayende)氏（ブログ・英語）、Frans Bouma氏（ブログ・英語）とその他数名が加わり、保守性の高いコードを書く方法に関して.NETのコミュニティにて議論をしている最中である。その議論は、主にテスト駆動開発(TDD)、O/Rマッパー(ORM)、Model-View-Presenter/Controller (MVP/MVC)、その他ソフトウェアの保守性を改善するための手助けとなるベストプラクティスについて行われている。
Jdn氏（ブログ・英語）は、保守性に関する自身の考えを議論し始め（source）。具体的には、TDD、ORM、MVP/MVCが、それらを後押ししていることで、生産性や保守性の妨げとなっている可能性があるという内容である。
1つ問題があります(いや、実際は1つより多いのですが)。私は、とあるアプリケーションを他の人に引き渡しています。もはや、私がそれをメンテナンスすることはないでしょう。私は、引き渡した相手を知っており、彼らのスキルセットや、一般にどのようなコードが好きなのかも知っています。
Oren Eini氏は、”保守性、それは誰のため？（source）”という投稿に対し回答している。彼は、TDD、ORM、MVP/MVCのスキルに乏しい開発者にとって、保守性は難しい(若しくは不可能)だろうと言っている。しかし、彼は、他の人が保守してきたコードに手を加えるので(コードが)よくならないままであるというのは、単によくない言い訳にすぎないと考えている。
それを古くからのやり方で行うということは、私に敗北主義者となれと言っているに等しいです。(中略)それは、"私たちはいつもこのようにやっていた"という古いアプローチです。確かに、土地をすきで耕す頑固者を使うこともできます。しかし、トラクターの方が、その運転方法を知っている必要はありますが、ずっといい仕事をしてくれるでしょう。
Sam Gentile氏もその議論に加わり、開発者にTDD、DDD、ORMといったベストプラクティスを教えるということは、"実社会"のプロジェクトにも効果をもたらすというOren氏の発言に同意している。彼は、ブログでの議論とFrans Bourma氏の"あなたは、きちんとした形のあるドキュメントなしでは生きていけない（source）"という主張に関する回答についてまとめている（source）。Bouma氏によれば、TDDは、ソフトウェアの内部の仕組みを理解する手助けにはならないとしている。おそらく、"何故"あるコードの一部がこのように作られていて、例えば他のBやCといったアルゴリズムは採用されなかったのかといった内容の詳細な設計書が欠けていると思われる。実は、"それ"がソフトウェアをより保守性の高いものにするために必要な情報なのである。これに対し、Sam氏は次のように答えている。
ユニットテストよりも良いものがあります。それは、ペアプロで開発し、きちんとリファクタリングされたコードです。一般的に、保守性や拡張性の高いコードについて語るならば、私たちが(既に機能単位できちんと分割された)プラグインのようなものを持っているというわけではないのです。繰り返し継続的にリファクタリングしたコードの内部実装が進化し、単純かつ保守性の高いものとなります。私が強く言いたいことは、このようなやり方でコードの開発をすることで、より保守性が高まり、すべてばらばらにして最初からやり直すことなく作り続けることができます。このように表現しましょう。「ユニットテストを行い、十分にリファクタリングされたコードを、1ヶ月の間見なかったとしても、再び見たときには、どうなっているのかを瞬時に理解することができます。」
Frans Bouma氏は、そういった甘い誘惑をに対し、次のように対抗している。「人の手によって、コードを正確に解析し、何が行われているかを十分に理解するための沢山の努力が行われているのです。"コードはドキュメントである"という考えによって作られたものには、よく間違いがあります。」彼の意見は次の通りである。「コードはドキュメントの代わりにはなりません。それは、単に現在の実装を表しているだけであって、"何故"そこに代わりとなるものが無いのかということ表していないからです。さらに言えば、コードは品質のよくないドキュメントなのです。それは、どのように動いているかを最も簡単な方法で人に説明するものではありません。」Oren Eini氏が再び議論に加わり（source）、彼は「多くの時間を費やして、目的が明らかになるような名称となるようにしたり、インフラストラクチャへの関心の低下」による問題を(ドキュメントが)解決すると言っている。彼は、Bouma氏の意見に対しても次のように言っている。「ドキュメントは、書かれたコードと分かれて存在するものではありません。それは、機能について表した、ある種のDSL(即ち、人が読むことができ、理解することができる言語)であると言えます。」
ドキュメントはDSLではないので、間違いなく、多くのケースにおいて理解できるものではありません。ドキュメントは、ある意味最も狡猾な方法であいまいさを作れるものです。コードがDSLの代わりでは無いというのは、コードとドキュメントが、何かしら関係があるという前提があります。しかし、コードは実際に動作するものであり、故に、システムにおいて権威あるものと言えます。
今回の議論は、"コードはドキュメントである"という過去の議論にとてもよく似ているが、それらは熟考され、多くの新しい考えと意見が生み出されていた。さて、あなたはどのように思うだろうか？
原文はこちらです：http://www.infoq.com/news/2007/06/writing-maintainable-code
（原文は2007年6月25日にリリースされました）