4

私は現在、スクラム、TDD、ドメイン駆動設計、およびボブおじさんのレシピに従って 1 年間働いています。 . 私が間違っている場合は、私を修正してください! 問題は、TDD とスクラムが、要件が現れたらそれを実装するシステムを進化させ、事前の設計を避けるべきであると述べているところから始まります。これにより、あらゆる種類の拡張パターンを常に使用して、すべての拡張ポイントを開いたままにします。これには確かに「暗い面」があります。つまり、システム全体が複雑になります。コードの特定の部分をさらに進化させる必要があるかどうかは、前もってわかりません。

しかし、どこでも (そして JAA で実際に頻繁に) 正しく述べられているように、必要な場合にのみ複雑さを追加する必要があります。この私見は、適切な事前分析が行われるべきであるという結論に至ります...残りのレシピと矛盾しています...

したがって、ループ....ああ、私は循環依存関係が嫌いです!!!

機能が「確認」された後、複雑さを軽減するために物事をリファクタリングする必要がありますか? 許可されている最も単純な方法を使用し、必要な場合にのみ拡張する必要がありますか? たとえば、必要のない超分離されたものを作成しないでください。

（質問のスタイルと内容を改善するための提案は大歓迎です。私はstackoverflowの初心者です）

4

5 に答える 5

8

機能が「確認」された後、複雑さを軽減するために物事をリファクタリングする必要がありますか? 許可されている最も単純な方法を使用し、必要な場合にのみ拡張する必要がありますか? たとえば、必要のない超分離されたものを作成しないでください。

はい。これはかなり主観的なものですが、変更すべきことをすべて変更できる柔軟性を備えたシステムは嫌いですが、それらの柔軟性のすべてを利用することはできません。ただし、あなたの発言は矛盾しています。テスト駆動開発は、「機能する可能性のある最も単純なことを行う」ことを教えてくれました。

より多くの機能が必要な場合は、テストを追加してから、コードをリファクタリングおよび拡張して、必要なことが確実に実行されるようにすることができます。テストが実施されているため、既存のコードを壊すことはありません。

要するに、柔軟性を構築しないでください。できるからです。状況によって必要とされるため、柔軟性を構築する必要があります。「オンデマンド」のリファクタリングは、(未使用の) 柔軟性を組み込むよりもプロジェクトのビルド時間を短縮すると固く信じています。

もっと短い：Keep It Simple, Stupid. ;)

于 2012-08-30T08:16:38.703 に答える
4

物事をシンプルにすることと、システムのアーキテクチャを深く理解することの間にはバランスがあると思います。

私は短期計画を長期計画から切り離そうとしています。短期的な計画では、この機能が次の反復で拡張/変更/更新される可能性が高い場合は、その準備を整えるように努めます。でも、延長が見込めない場合は、KISS の原則に従います。

長期計画では、少なくとも半年先を考えています。インタラクションはどのようなものになるでしょうか。可能なロードマップは何ですか? これにより、どこで物事をもう少し高度にするかについての基本的なアイデアが得られます。

私見では、短期目標の計画と達成の間で情報に基づいた決定を下す必要があります。

于 2012-08-30T08:23:14.277 に答える
2

経験豊富なデザイナーは直感の要素で作業を進めるのではないかと思います。「明らかな」アーキテクチャ上の決定、レイヤー化、懸念事項の分離、「脱落」のような設計上の決定があります。秘訣は、分析麻痺とオーバーエンジニアリングを避けることです。

細分性が増し、コードに近づくにつれて、「あなたはそれを必要としない」というマントラがより重要になります。美しい柔軟性に縛られてしまうのはあまりにも簡単です。ただし、いくつかの簡単な方法で将来のフレックスを有効にすることができます。たとえば、コンポーネント間の関係を (Java で) インターフェイスで表現します。本格的な抽象的な Factory Pattrern には向かないかもしれませんが、消費者が Interface にコード化されている場合、導入するのは非常に簡単です。同様に、文字列リテラルをコードの周りに散らばるのではなく、それらを 1 か所に集めることで、文字列を外部化する必要が今のところなくても、将来の国際化や動的構成が大幅に簡素化される可能性があります。

私が見た本当に優れたデザイナーは、ほとんどチェスや囲碁のゲームのようにそれをプレイしているようです。彼らは将来の動きを予測しますが、もちろん、必要になるまで応答をプレイしません。(Go 用語の味ケシは検討する価値があるかもしれません。)

はは、これは面白いですね。用語を説明するためにアジケシのリファレンスを調べたところ、著者がこの用語をシステム設計に適用して、まさにこの問題に取り組んでいることがわかりました。

于 2012-08-30T08:40:13.397 に答える
1

間違いなく、最初に最も単純なことを行うコードを追加する必要がありますが、追加するコードはSOLIDの原則に準拠している必要があります。

将来発生する可能性のある変更を推測するだけで、複雑さ（たとえば、デザインパターン、フレームワークなど）を導入しないでください。

あなたが解決している問題の本質的な複雑さは変えることができません。これには、事前の思考とブレーンストーミングが必要ですが、偶発的な複雑さは推測によって追加されます。

定期的なピアコードレビューが役立ちます。あなたの仲間が眉を上げることなくコードを読んで理解することができれば-それならそれは問題ないと思います。

于 2012-08-30T15:28:35.570 に答える
1

これにより、すべての拡張ポイントを開いたままにして、(ab)あらゆる種類の拡張パターンを常に使用するようにします。これには確かに「暗い面」があります。つまり、システム全体が複雑になります。コードの特定の部分をさらに進化させる必要があるかどうかは、前もってわかりません。

許可されている最も単純な方法を使用し、必要な場合にのみ拡張する必要がありますか?

「単純さ」と「複雑さ」の定義を微調整することで、少なくとも難問の一部を解決できると思います。

JAA の「レシピ」や SOLIDの原則などはすべて、設計における結合と結束を管理する近道です。デザインの「シンプルさ」を最大の結束と最小の結合が達成される程度として定義する場合、それらの原則とパターンはデザインをシンプルに保つことを目的としていると言えます。

したがって、その定義によれば、「拡張ポイント」と呼ばれるものは、実際には設計をシンプルに保つことの結果であり、複雑さを追加するものではありません。さらに、単純な設計の目的は将来の変更を容易にすることであるため、それらが拡張の目的で将来使用されるかどうかは重要ではありません。

「機能する可能性のある最も単純なことを行う」というフレーズは、コードの設計ではなく、何を構築するかの選択を指します。たとえば、HTML ページを表示する必要がある場合は、Web アプリケーションではなく HTML ページを作成します。

したがって、設計を維持する方法で上記の単純さの定義に従っており、特定の問題を解決するための最小限のものだけを構築する場合、コード ベースは小さくなり、設計は複雑ではなくなり、アプリケーションは将来の機能追加に必要な変更。

最後に 1 つ:テストが設計について何を伝えているかに注意してください。カップリングと結合の問題は、扱いにくいテスト フィクスチャとして現れることがよくあります。これが表示された場合は、必要なリファクタリング手順をスキップしたことを示しています。

于 2012-09-04T12:48:34.303 に答える