rebuild.fmで話にあがっていた「Readme Driven Development」について、
原文がどんな内容なのか気になったので訳してみました。
英語力が低いのでGoogle翻訳等をフル活用していますので、
間違っているところや日本語的に怪しいところなどありましたら、ご指摘お願いいたします！
Readme駆動開発
最近TDD（テスト駆動開発）やBDD（ビヘイビア駆動開発）、エクストリームプログラミング、スクラム開発、スタンドアップミーティングなど、より良いソフトウェア開発のための様々な種類の方法論・開発手法の話題をよく耳にする。
だが、開発しているソフトウェアに対して、それらの方法論・開発手法がマッチしていない限り、全く意味は無いものになっているだろう。
別の言い方をすると、粗悪な設計書に基づいた完璧な実装のように価値がないということだ。
同じようなもので、ドキュメントの無いビューティフルな技術を用いたライブラリも似たように価値がない。
あなたのプログラムが間違った使い方をされたり、 そもそも正しい扱い方を誰も分からなければ、最悪の事態が待っているからだ。
ここまではいいでしょう。
ではどのように問題解決をしていけばいいんでしょうか？
その解決法は思ってるよりか簡単で、私の主張の上で重要なことです。
それはまず、Readmeを書くこと。
はじめに、あなたがコードやテスト、動作、全体の流れ、その他諸々を書く前にReadmeを書いて下さい。
分かってる、分かってる。「俺達はプログラマーなんだよ糞が！技術ライターじゃねーんだよ！」って言うんでしょ？
けど、それじゃダメなんだよ。
Readmeを書くってことは良いソフトウェアを書くってことの重要な肝になるんだよ。
自分のソフトウェアについて書くまでは、これから何をコーディングしていくか分からないからさ。
ウォーターフォールモデルへの反発による大きな反動と、アジャイル開発が皆に認めれれるようになった狭間でいくつか失わたものがある。
勘違いはしてほしくないが、ウォーターフォールモデルでは考え方が違いすぎる。
細かい仕様を記述している巨大システムは結局ただの細かく仕様が記述された糞なシステムになってしまうんだ。
僕らにとって仕様に従って書くことは正しいことだった。
しかし、そうやって作られるものは本来のものとは全然違う方向へ行ってしまうんだ。
今、僕たちはそんな短く、糞な書き方で、完全に欠落したドキュメンテーションなプロジェクトを抱え込んでいる。
さらにそんないくつかのプロジェクトにはReadmeすらない！
これは非常に受け入れがたいことだ。
技術仕様書が全くない状態では曖昧な点がいくつか存在してしまうし、実際存在することだってあるのだ。
その曖昧な点というのは控えめなReadmeといったところだろう。
また、ドキュメント駆動開発とReadme駆動開発とを区別することが重要になる。
RDD（Readme駆動開発）は限定的なDDD（ドキュメント駆動開発）やその一部分と考えることが出来る。
システムのイントロダクションとして読まれることを意図して、デザインドキュメンテーションを１つに制限することにより、RDDは冗長的かつ正確な仕様書のせいで疲弊させられていた「DDDウォーターフォール逆戻り症候群」から助けてくれることだろう。
また同時に、RDDによってモジュール化と小さいライブラリを保つことが期待できる。
これらの単純な補強策は正当性の確認というプロセスが少なくなり、プロジェクトを駆動させる長い道のりを正しく導いてくれるだろう。
それではReadmeファイルを書くことによって得られるいくつかの重要な利点を説明しよう。
-
まずもっとも重要なのが、プロジェクトがどんな風に組み立てられどのような公開APIが含まれるべきかを、
コードの変更というオーバーヘッドをかけずに考えられるということだ。
初めて自動化されたコードテストを書いている時や、別のコードベースを覗き見て全ての種類のエラーをキャッチしようと試した時の感覚は覚えてる？
プロジェクトでコードを書く前にReadmeを書くということはそういうことと全く同じ気持ちである。 -
何を実装するのか知るためにReadmeを書く副産物として、素晴らしいドキュメントがもう目の前にあるということだ。
また、プロジェクト開始時の興奮とモチベーションが最高潮の時にドキュメントを書くことが如何に簡単かを知ることが出来る。
さかのぼってReadmeを書くことは絶対やりにくいし、何か重要なことを見逃していないかの確認をしなくてはならない。 -
もし、開発チームで働いているのならReadmeはさらなる恩恵をもたらしてくれることだろう。
もしチームの誰しもがプロジェクトが終わる前にReadmeへの情報にアクセスできるのならば、あなたのコードとインターフェイスで繋ぐ他 のプロジェクトで自信を持って開発を始めれるだろう。
定義されたインターフェイスのソートなしには、連続的か表面的な切り分けられた巨大なコードを再実装をしなければならない。 -
基本的なことを幾つか書き留めておくことでディスカッションを非常にシンプルにします。
もし何も文章化していないと、ある問題について同じ話を延々と繰り返す羽目になってしまいます。
書き留めておくという簡単な行為の提案は、既知のことを踏まえた上で議論でき、具体的な考えを皆が持つことが出来る意味がある。
真に作るということを踏まえて、プロジェクトでReadmeを書くということを考慮してみてはどうだろうか。
Readmeはあなたの素晴らしいアイデアを全て表現できる。
Readmeはあなたの創造性と表現力を証明するためにも書くべきだろう。
あなたのコードベースにおいてReadmeは最も重要な文章の一つになる。
何をするにも最初に書こう！
原文：
http://tom.preston-werner.com/2010/08/23/readme-driven-development.html