私は現在、5,000行を超えるコードに到達しようとしているプロジェクトに取り組んでいますが、デザインを完全に考えたことはありません。コードを構造化および編成するには、どの方法を使用すればよいですか？紙とペン？UML図？他に何か？
回答:
おそらく、答えがあるのと同じくらい多くの異なる見解を得るでしょう。しかし、これが私の見方です。
手始めに、5000行以上のコードは非常に小さなプロジェクトです。では、成長するプロジェクトをどのように設計するのでしょうか。まず、コードではなくシステムを設計します。コードは実際にはアーキテクチャの副次的なものです。現在の最小要件のサポートから始めます。関連するコンポーネントの単純化された図面を入れます。私個人的にはUMLが好きですが、視覚的には何でも良いでしょう。理想的には、ここで優れた設計プラクティス（インターフェース、関心事の分離など）を遵守する必要があります。
設計で最小限の要件をサポートしたら、それをコーディングします。繰り返しになりますが、適切なコーディング慣行を遵守してください。
その後、新しい要件が発生したときに繰り返し機能を追加します。理想的には、デザインも更新する必要があります。
私の経験に基づいて重要なことは、存在しない要件を見越してシステムを設計しないことです。そうしないと、プロジェクトが急速に成長し、短時間で非常に複雑になります。繰り返しますが、適切な慣行に従い、具体的な現在の要件から始めます。
フローダイアグラム、クラスダイアグラム、ユースケースダイアグラムは、大規模プロジェクトに欠かせないダイアグラムです。必要な外部ライブラリを検索して選択し、使用できる同様のオープンソースコードを検索します（学習時間を短縮し、開発時間を短縮するため）。
ホワイトボードといくつかのカラフルなマグネットとポストイットを購入することをお勧めします。それはあなたのタスクを識別するのに役立ちます。
ただし、ps 5000+行のコードは「大きく」ありません。CMS /フォーラムソフトウェアには5000行以上のコードがあります。
パッケージ図とクラス図を作成します。パッケージ図では、クラスとインターフェースを論理的にグループ化することに関心があります。また、内部パッケージなども作成したいと思います...
しかし、最初にプログラムが何をすべきかを考える必要があります。ユースケース図を作成するか、手動で作成できます。私はコードをすぐに取得することを好み、後でクラス図をパッケージ化するために交換する方が簡単であるため、クラス図で手動で行います。クラス図を使用すると、私のJavaが得られます。気に入らない場合は、手動で変更します。新しいコードが自動的に図に更新されます。私のコードの視覚的な高レベルの更新された表現があります。たとえコードを書いても、プロジェクトがグラフィカルに進行している様子を見るのに常に数分かかることがあるため、本当に役に立ちます。エンティティを整理するために、エンティティを適切なパッケージに手動でドラッグアンドドロップするだけです。私のコードは、より高いレベルの抽象化パッケージとクラス図を使用する方が良いと思います。
（ソース：ejb3.org）
同僚の何人かは私の仕事のやり方はくだらないと言いましたが……私はそれが好きです:-)
間違いなく。私はこの種のものに使用するための小さな「タブレット」ドライイレースボードを持っていますが、使いやすいものなら何でも使用します。重要なことは、簡単に考えをまとめ、すべてがどのように組み合わさっているかの全体像を確認できることです。
UMLダイアグラムのようなより正式な計画を好む人もいますが、各メソッドの外観を細かく管理することに夢中になってしまうのは簡単すぎると私は思います。ただし、繰り返しになりますが、使い慣れたものを使用してください。
編集：文芸的プログラミングにも興味があるかもしれません。アイデアは、すべてを計画して、徐々に具体的にできるということです。たとえば、プログラムは次のもので構成されているとします。
次に、テキストを画像に変換するという考えを洗練させます。したがって、次のようになります。
次に、ランダムな色を選択するというアイデアを洗練させ、すぐに通常のコードを書くだけにします。
私にとって、ソフトウェア開発の活動は、特定の問題を解決するための、徐々に細かくなった一連の設計です。何を構築するかについての高レベルのアイデアがある場合、設計は「SQLデータベースと複数のWebサービスと通信するWebアプリケーションがある」などの非常に高レベルなものになる可能性があります。次に、各部分の詳細を掘り下げると、デザインがより細かくなります。ソリューションの複雑さに応じて、設計作業の反復回数は増減します。最後の反復には、より高いレベルのデザインを実装する実際のコードの作成が含まれます。
私にとって、アーキテクチャと設計の違いは最小限であり、それらは上記で説明したプロセスの異なる反復にすぎません。2つの間の線はあいまいで、人によって異なります。
どのレベルの設計の詳細、アプリケーションのどの部分、およびプロジェクトライフサイクルのどの時点で行うかを決定するための技術があります。リスクが高く複雑なプロジェクトの場合、コード行を記述する前に非常に詳細な設計が必要になる場合があります。小規模なプロジェクトの場合は、事前の設計をほとんど行わずに、コードを実行し、機能しない部分を確認してそれらの領域を再設計するだけで済みます。ここには1つの書き込みの回答しかありません。通常、それはこれらの2つの極端の間のどこかにあります。
アーキテクチャにアプローチするときに使用するいくつかの原則について述べたブログ投稿があります。これらの線に沿って考えるとき、それはあなたに役立つかもしれません。記事の一部は.NETに固有のものですが、そのほとんどはそうではありません。
私はいつも同じ質問を自問しました。今はテスト駆動開発を実践しているだけなので、心配する必要はありません。選択したアーキテクチャの標準に従うことを除いて、コードをまったく「計画」しません。プロジェクトを始めるとき、私は何が必要になるかについてある程度の考えを持っていますが、開発が進むにつれ、私はオープンマインドを保つように努めます。テスト駆動の開発に従い、コードを継続的にリファクタリングすることで、コードを「計画」する必要はありません。テストケースを次々に満たすだけで、デザインはリファクタリングから生まれます。これは、コーディングする前に私が作成したどの計画よりも常に優れた設計です。