アジャイルの方法論は、物事をシンプルで無駄のないものに保ち、必要になるまで複雑さや洗練を加えないようにすることを奨励しているように思えます。しかし、テクノロジーの変化のペースと量により、ますます抽象的で複雑かつ洗練されたツールとパターンを使用して、まだ経験していない (そして決して遭遇しない可能性がある) 問題を複雑な方法で解決することが奨励されています。
9 に答える
11
KISS と YAGNI は、ますます洗練された傾向と相容れないのでしょうか...
車にはアクセルとブレーキがあり、左右に曲がるハンドルがあります。どちらをいつ使用するかはドライバー次第です。
于 2009-09-10T01:49:25.187 に答える
4
私は答えを短くし、専門家にもっとよく説明してもらいます...
KISSはあなたが挙げたすべてに当てはまると思います。あなたは、抽象化と複雑さが増していると言いましたが、それはお互いにバランスを取っていると思います。
今日開発しているシステムは複雑でなければなりません。なぜなら、複雑な問題の解決策は本質的に複雑であることがほとんどだからです。ただし、物事を単純にするために、抽象化を使用します。複雑なシステムがたとえば 8 つのレイヤーで構築されている場合でも、各レイヤーをシンプルに保つことで KISS に従うことができます。
たとえば、リストから項目を 1 つまたは 2 つ選択するには:
- サービス呼び出しをラッパー オブジェクトでラップできるため、SOA は複雑ではありません。このオブジェクトは接続を処理し、呼び出しを行います。パラメーターを渡すだけなので非常に簡単です。
- ロジックを明確に分離しているため、MVC は複雑ではありません。リクエストを送信してデータを設定するためのシンプルなコントローラー、ドメインを表すシンプルなモデル、渡されたデータを表示するシンプルなビューがあります。
ただし、どちらの場合も、全体としてのパターン (またはシステム)は複雑であり、自明ではありません。小さくて単純な部品を 1 つずつ検討し、それらを組み合わせることで、作業中にメンタル モデルを維持できます。
于 2009-09-10T01:49:12.003 に答える
3
私はChrisWの答えに同意します。
アイデアは可能な限りKISSとYAGNIに固執することですが、必要が生じて洗練された/複雑なソリューションが必要な場合は、巨人の肩の上に立ち、実績のあるパターンを使用してガイドします。これらのパターンとプラクティスは、作業を簡素化することを目的としています。それらを使用することがハックの代替手段よりも難しい場合は、ハックに固執する必要があります。保守性などを考慮してください。
例として、Webサイトの最初のバージョンを構築する場合、1つまたは2つの主要な機能とほんの数ページで構成されている場合があります。このためにMVCはおそらく必要ありません（そのように始めるのは良いかもしれませんが）が、さらにいくつかの機能を追加し、それらの間で機能を共有する方法とともに管理するページが数十あると、次のようになる可能性がありますアプリケーションをより適切に構造化するにはMVCが必要であることは明らかです。
同様に、最初から共通のデータの複数のビューを返すなどの処理が必要であることがわかっている場合、MVCは、従うべきパターンをレイアウトすることで問題を単純化します。
要約すると、YAGNIは現在ですが、後で必要になった場合は、既知のパターン/ソリューションを使用してKISSを実行します。
于 2009-09-10T02:34:12.087 に答える
3
はぁ。
ますます洗練されたソフトウェアの需要に対応するには、ますます洗練された抽象的なコンポーネントが必要です。
私たちのほとんどは限られた脳のスペースを持っています。より洗練された抽象化を使用して、限られた頭脳に対処することを学ぶ必要があります。
別の方法は、抽象化を使用せず、マシンコードに限定することです。
http://www.cs.utexas.edu/~EWD/transcriptions/EWD01xx/EWD117.htmlをお読みください
「そのすべての欠陥にもかかわらず、数学的推論は、限られた能力の脳で非常に複雑な構造を把握する方法の優れたモデルを提示します。そして、これらの実証済みの方法がコンピューター使用の技術にどの程度移植できるかを調査する価値があるようです。プログラミング言語の設計では、主に「機械ができること」を検討することで自分自身を導くことができますが、プログラミング言語はユーザーと機械の間の架け橋であり、実際には彼の道具と見なされている-「人間が何を考えることができるか」を考慮することも同様に重要であるように思われる。私たちが調査を続けるのはこの流れの中である。」
于 2009-09-10T02:43:04.143 に答える
2
主観でお答えします（だから訴えてください）。頭字語でプログラミングすると、問題が発生すると思います。
結局のところ、あなたはビジネスのために、あるいはできれば自分自身のためにお金を稼ごうとしているのです。そのため、各決定は、コスト、時間、および利点に基づいたエンジニアリング上の決定です。実装、保守などのコストで手法の使用を評価し、最良の選択を行う必要があります。
唯一の公正な答えは、選択したツールと技術がエンジニアリングの望ましい目標と一致する必要があるということだと思います.
于 2009-09-10T01:50:31.410 に答える
1
私見、あなたは（一般的に）複雑なデザインから始めたくありません。これはサービスではなくローカルメソッドでしょうか？IoCコンテナはもう必要ですか？これは、デザインパターンに関して特に関係があります。
ただし、コードをテストしてリファクタリングする場合、特定のパターン（Iocなど）は、テスト容易性やDRY（Do n't Repeat Yourself）などの目標を達成するのに役立ちます。デザインパターンをよく知っている場合は、適切なタイミングで適用できます。
于 2009-09-10T02:20:36.863 に答える
1
適切な仕事のための適切なツールの問題です。問題は、アーキテクトや開発者が、特定の方法論やテクノロジを「ゴールデン ハンマー」であると信じ始めたときです。それは物事が宗教的になり、宗教と理性がうまくかみ合わない時です ;)
ところで、「アジャイル」とは、言及した頭字語の一部、またはそれらを実装するフレームワークを使用しないことを必ずしも意味するものではありません。これらの決定は、通常、開発者がアジャイルに関連付けるようになった種類のもの (ユーザー ストーリー、スプリントなど) を実装するよりもはるかに前に行われます。
于 2009-09-10T01:48:30.647 に答える
1
まず、頭字語のリストは必ずしも意味を成すとは限りません。たとえば、POCO よりもはるかに単純なものはありません...
ただし、KISS と YAGNI は、パターンを正しく使用する限り、IoC、MVC、および MVVM などの概念を使用することによって、多くの状況で最も効果的に実現されます。
パターン自体は複雑ではありません。パターンが何を達成しようとしているのかを理解するには少し学習が必要かもしれませんが、多くの場合、パターンは純粋にコード、保守、または使いやすさのいずれかを単純化するために存在します。通常は上記のすべてを単純化します。これは、たとえば、シンプルに保つのに完全に適合します。
于 2009-09-10T01:51:20.783 に答える
-1
はい
-- このスペースは意図的に空欄にしています --
于 2009-09-10T01:58:33.140 に答える