RDDは非常に簡単な方法です。 そして、ここで「DD」とは、「マスターするための1分と、マスターするためのすべての人生」を意味します。 しかし、幸いなことに、この場合はそうではありません。
最初にReadmeを書いてください。 それは基本的にそれです。 しかし、なぜですか？
ソフトウェアプロジェクトを開始するときはいつでも、それがあなたの個人的なプロジェクトであろうと、あなたが働いている会社によって所有されていようと。 （可能な限り）再利用可能な、理解可能なサポートされたコードを書くよう努力する必要があります。
誰もが、ツール、プラクティス、およびプロセスがソフトウェアの改善にどのような貢献をするかについて独自の視点を持っています。 1日の終わりに、プログラムは引き続き機能するはずです。 仕上げに集中しすぎたり、すべての美しいソリューションを使用しすぎたりすると、忘れがちです。
プログラムの仕事はそのコードだけではありません。 方法がわからないために誰もプログラムを使用できない場合は、多数のエラーが含まれているか、エラーが含まれていないかは関係ありません。
控えめなReadme
Readmeは、プロジェクト全体で最も重要なファイルです。 これには、プロジェクトのタスクの概要（目的、作成理由）、インストール手順、既知の問題、および以前にソフトウェアを使用したことがない人のためにプログラムの使用をすぐに開始するために実行する必要があることに関する十分に詳細な説明が含まれている必要があります。
誤解しないでください、Readmeは必要なすべてのドキュメントではありません。 ただし、小さなReadmeがそれを読んだ人々の問題や問題の大部分をカバーしていることを知って驚くかもしれません。
コードの作成を開始する前にReadmeを作成すると、次のようなメリットが得られます。
- 実装する必要がある機能の完全な概要と、パブリックAPIを使用してそれを提供する方法について説明します。 この時点で、コードの記述を開始する前に、プロジェクトのアーキテクチャを簡単に変更できます。
- コードの記述を開始すると、何をどのように実装すべきかが明確にわかります。
- Readmeは、プロジェクトの開発の進捗状況を自分自身や他の人々に示す指標としても役立ちます。
- 他の開発者とチームで作業する場合、ほぼ完璧な仕様になります。 また、他の開発者は、開発プロセス中に仕様が変更されることを恐れることなく、プロジェクトに接続できます。
- 議論は非常に重要です。 そして、何が書かれているかを議論するのははるかに簡単です。 Readmeを変更する方が、いつどのように機能するかをいつまでも議論するよりも簡単です。
- 原則として、プロジェクトの最初の最もアクティブでエキサイティングな部分。 これは、後であなたや他の人々に役立つ少量のドキュメントを書くのに最適な時期です。 後で、ドキュメントの作成は常に遅れ、最終的にすべての実装の詳細と既知の問題を覚えている場合、私は非常に驚くでしょう。
- 最も思慮深いプロジェクトでさえも変化していますが、これらの変化が問題のために起こらないことを願っています。 しかし、新しい機能を追加します。 しかし、それらは依然として避けられず、通常は開発を通じて発生します。 単一のドキュメント（バージョン管理システムで私は願っています）は、変更が発生したときの変更間の通信に理想的な媒体になります。 また、変更が発生したときに記録する方が、後ですべてを思い出そうとするよりもはるかに簡単です。
RDDを既存のプロジェクトに追加するには、別の記事が必要です。 しかし、現時点では、考えてみてください。