partitioning - 問題をより小さな理解可能な部分に分割する方法は?

Question

このトピックについて一般的なアドバイスができるかどうかはわかりませんが、試してみてください。複雑すぎて説明できないので、私のケースを説明するのは難しいです。そして、それがまさに問題です。

プロジェクトの一部を設計しようとする状況に常に出くわすようですが、考慮すべきことが多すぎて把握できません。

システムを一度に細かく分割して見る方法に関する一般的なヒントやアドバイスはありますか? 独自に個別に設計できる小さな部分を見つける方法は?

Answer 1

用語集を作成します。

つまり、プロジェクト ドメインにとって意味のある用語を特定します。プログラマの観点からではなく、主題に精通しているユーザーの観点からです。

次に、用語をできるだけ正確かつ離散的に定義します。この形式の適切な定義は、一種の疑似コードとして機能します。

問題のドメインさえ特定していないので、ランダムに例を選びます。民間の人事システムでは、次のような用語が使用される場合があります。

• ビレット: 特定のグレードおよびステップでのサービス期間 (開始日から終了日まで)
• employee : 特定の SSN に関連付けられた一連のビレット
• grade and step : 連邦一般スケジュールの行と列

等々。これは機能単位を特定するためのものではありませんが、それを行う前の適切な準備ステップであり、機能ステップを明確に定義された用語で表現できます。

Answer 2

It's useful to approach problem decomposition both top-down and bottom-up.

If you're having trouble splitting a big problem into two or more smaller problems, try to think of the smallest possible problems that will need to be solved. Once those are handled, you may start to see ways to combine them into larger problems as you approach your original large problem.

Answer 3

コードのチャンクを最小限の調整でコピー アンド ペーストしていると、それが「パーティション」であることに気付き、クラス、メソッド、関数などを作成します。

実際には、オブジェクト指向アプローチ全体がすべてです。アプリケーションを何かを実行する具体的なものと考えてみてください。物事が何であるか、そしてそれらが何をするかを説明する疑似コードを書いてください。私はこの方法で多くの「パーティション」を見つけます。