README Driven Development (2010)

• README駆動開発: ソフトウェア開発時にREADMEを先に作成するアプローチ
• TDD、BDD、Extreme Programming、SCRUM などのさまざまな開発手法や技術について耳にすることが多い
  • しかし、私たちが開発するソフトウェアがユーザーのニーズを満たせなければ、すべては無意味になる
  • 実装が完璧でも、間違った仕様に従っていれば価値はなく、文書化されていない美しいライブラリもほとんど価値がない
  • ソフトウェアが間違った問題を解決していたり、使い方が分からなかったりすると、深刻な問題が発生する

解決策: READMEから書き始める

• READMEを先に書くべき理由
  • コード、テスト、ストーリーなどを書く前に、まずREADMEから書く
  • READMEを書くことは、良いソフトウェアを作るための必須ステップ
  • ソフトウェアについて文章で書くまでは、何をコーディングするのか明確にならない
  • READMEを通じてプロジェクトを体系的に考えられる
• README先行作成の利点:
  • プロジェクトを体系的に考える機会:
    • コードを変更することなく、プロジェクトを体系的に考えられる
    • コーディング前にプロジェクトの構造や含まれるAPIを検討できる
  • 優れたドキュメントの確保:
    • プロジェクト初期の高いモチベーションと興味を持った状態で文書を書ける
    • 後からREADMEを書くのは退屈で、重要な詳細を見落とす可能性がある
  • チーム作業の効率向上:
    • チームの他の開発者は、プロジェクト完成前にインターフェースに関する情報を共有されることで、別の作業を自信を持って始められる
    • 明確なインターフェースなしで作業すると、大規模なコードの手戻りが必要になる可能性がある
  • 具体的な議論の土台を提供:
    • テキストで提案された解決策を書くというシンプルな行為によって、全員が明確なアイデアを持って議論できる
• README駆動開発(RDD)の特徴:
  • RDDは Documentation Driven Development(DDD) のサブセット、または制限付きバージョンと見なせる
  • RDDは設計文書を単一ファイルに制限することで、過度な仕様作成の問題を防ぐ
  • 小さくモジュール化されたライブラリを維持するよう促す

結論

• READMEを書く過程を真の「創作行為」と考えること
• この文書にはあなたのあらゆる独創的なアイデアが表現されるべきであり、文書それ自体が創造性と表現力を証明する証拠であるべき
• READMEはコードベースで最も重要な文書であるべきであり、最初に書くのが正しいアプローチである

[princox]

ソフトウェアでも小説でも映画でも、どんな形の創作物を作るときでも、
紙を前にして設計や企画をしながら作れば、より細かな点も楽に押さえられるのではないかと思います.. :)

[markman]

一番基本的なことをこれまで忘れていましたが、これからは実践してみようと思います。

[halfenif]

私たちはそれを「基本設計」と呼ぶことにしました。

[gargoyle92]

意図せず、私の仕事の進め方や文脈と似ていますね。
その部分が README という形で成果物になっているようです。

私は仕事をするとき、What、Why、How などを明確に書いて進めつつ、進行しながらやるべきことの形を固めていくタイプなので、それと似ています。

[kandk]

README駆動開発

[dbs0829]

私は研究組織にいるので、研究した内容をコードの形でリリースすることについて悩むことが多かったのですが、README駆動開発は私たちによく合いそうだという気がします。研究を始める段階から検討してみる価値のあるやり方のようです。

[jamsya]

これと似たように、バックエンドをやるときは画面を見ながらAPIドキュメントからラフに書いてみることがあるのですが、
試行錯誤を減らすのにかなり役立ちました。

[bbulbum]

ある意味、まず解決すべき問題を正確に定義することの重要性を感じさせますね。

[xguru]

2010年の記事ですが、別の記事を見ていて見つけたので投稿してみます。