個人的な中規模のプロジェクトで作業する場合、コーディングを開始する前に何を指定しますか？
機能仕様を指定します：
- コーディングを始めたばかりの場合（「方法」）、コーディングしたい「理由」と「何」（「かなり複雑な」ソフトウェアの場合、数か月または数年にわたって）を忘れるのは簡単すぎるのではないかと心配しました。開発にかかる場合があります）。
- また、私が開発するものの「範囲」を多かれ少なかれ理解したかったのです。おおよそ（桁違いに）評価するために：
- どれくらいの大きさになりますか
- 終わらせることができるか
- 始める価値があるかどうか
- 最初に開発できるサブセット
リスク管理のために、私が開発したかったもののいくつかは、私がよく知らないいくつかのソフトウェアを使用して暗示されていることを追加します。これに関連するリスクを最小限に抑えるために、私は少し使い捨てのプロトタイピングも行いました。
どのように？
ペンと紙を使って機能仕様の概要を説明しました。私が書いたもののいくつかは高レベル（ビジネスレベルの「ビジョン」ドキュメント）であり、いくつかは低レベルで、よりデザインに似ていました（UIの詳細のいくつか）。時々私は立ち止まってそれを整理する方法について困惑しましたが、その後、各ページが各トピックについて多かれ少なかれまとまりがあり、後でページを整理する方法について困惑する可能性があると考えました（おそらくあなたのウィキのように） ）。
私は両方とも事前にソフトウェアアーキテクチャを指定しましたが、指定しませんでした。
- 基本的なアーキテクチャ（いくつかの小さなコンポーネント）を念頭に置いて開発を開始し、次にコードを追加します。そして、コードを追加するときに、コンポーネントが大きくなりすぎて複雑になった場合は、それをいくつかの小さなコンポーネントに分割します...それは進化のプロセスです... Systemanticsで述べられているように、機能する複雑なシステムは進化してきました動作した単純なシステムから。
- 私はアーキテクチャを文書化していません。または、アーキテクチャの唯一のドキュメントはコード自体です。たとえば、ソースコードをソースディレクトリ、名前空間、およびDLLに配置する方法です。
私は現在のアーキテクチャの理論的正当性を持っていますが、これらの理由を文書化していません。
- 私は唯一の開発者です
- 実際のアーキテクチャはコードによって文書化されています
- アーキテクチャの理由は私の頭の中にあり、ソースコードの命名規則やさまざまなコンポーネントの依存関係などによって[再]発見できます。
私が唯一の開発者ではなかった場合（その場合のみ）、アーキテクチャとその理論的根拠を文書化する価値があると思うかもしれません。
ソフトウェアのアーキテクチャについて上で述べたことは、ソフトウェアが処理するデータにも当てはまります。
テストに関しては、少しコーディングしてからテストします。または、テストを作成してから、そのテストに合格する機能をコーディングします。私は「ビッグバン統合」、つまりテストなしで何ヶ月も書いているわけではありません。
私のプロセスの最大の弱点の1つは、事前に作業量を見積もり、その見積もりに対して実装を追跡することです...これは、この「個人的な」プロジェクトプロセスと私が行った有料プロジェクトの違いの1つです。 d他の誰かのために商業的に行う。しかし、これが良いかどうかは疑問です。見積もりが商業的にベストプラクティスである場合、おそらく私は個人的なプロジェクトでもそれを行うべきです。