自明ではないアプリケーションを構築するとき、物事を迅速に機能させ、モデルロジックをビューと混合し、カプセル化を破るなどのコードのショートカットを取ることに集中するのが最善ですか？または、より多くのアーキテクチャを構築するために事前に時間をかけて、適切に構築する方が良いのですが、デザインが非常に流動的であり、フィードバックが原因でそれを捨てなければならない可能性があるため、この余分なコードはすべて使用されないリスクがあります別の方向に進むには？

コンテキストのために、デスクトップアプリケーションを構築しています。私は唯一の開発者であり、アルバイトをしているのでこのパートタイムで働いています。今、仕事のために、私は物事を正しい方法で行おうとしています。しかし、このプロジェクトは、人々からフィードバックを得ると変化すると予想されますが、それが正しいアプローチであるかどうかはわかりません。今週は数時間かけて、モデルの変更をビューに伝えるために、教科書のModel View Controllerの設計を導入しました。これは一般的に素晴らしいことですが、データを表示するために複数のビューが必要かどうかはわかりません。また、追加のアーキテクチャなしで物事をより迅速に表示できたことを知っています。プロジェクトに1週間に10〜15時間を費やすことになるので、優れたソフトウェアプラクティスに従えばデモできる何かを構築するには時間がかかると感じています。私はユーザーが ' 私がMVCを内部で使用していることに気をつけてください。彼らは問題を解決する何かが欲しいだけです。しかし、ショートカットの技術的負債が非常に大きいため、コードを維持したり、新しい機能を追加したりするのが非常に困難な状況にもあります。他の人がどのようにこの種の問題に取り組んでいるか聞いてみたいです。

それをうまく構築します。

全体像を見ると、「高速」に構築することは論理的な誤りです。それはあなたがそれをうまく構築するのを防ぎ、最終的にはリファクタリングを妨げるか、不可能に近い新機能を追加するバグや基本的なアーキテクチャの欠陥に行き詰まります。

それをうまく構築することは実際には反対です。最初は遅くなるかもしれませんが、最終的には、正しい選択を事前に行うのに時間をかけたことによる効率の向上に気付くでしょう。さらに、将来の要件に簡単に適応できるようになり（必要に応じてリファクタリング）、少なくともバグが少なくなるため、最終製品の品質が向上します。

言い換えれば（これが1つの契約である場合を除き）、高速でビルドする=低速でビルドする、適切にビルドする=高速でビルドする。

また、「うまく構築する」ことと、アーキテクチャを設計することについて理解することが重要です。あなたは尋ねました...

...しかし、デザインが非常に流動的であり、フィードバックにより別の方向に進む場合、それを捨てなければならないので、この余分なコードはすべて使用されないというリスクを冒していますか？

これは、「アーキテクチャ時間を費やす」ことによる本当のリスクではありません。 アーキテクチャデザインは有機的でなければなりません。正当化されるまで、あらゆる部分のアーキテクチャの設計に時間を費やさないでください。アーキテクチャは、プロジェクトで観察および確認されたパターンからのみ進化する必要があります。

SystemanticsのJohn Gallの法則：

ゼロから設計された複雑なシステムは決して機能せず、パッチを適用して機能させることはできません。動作するシンプルなシステムから始めて、最初からやり直す必要があります。

早くて

これは多くの異なる方法を試した私の個人的な経験からです。

通常、高速（およびリリース）のみの問題は、機能ごとにアプリケーションにタックすることであり、リリースされてからプログラムに根本的な変更を加えることは非常に困難です。長い目で見れば、基礎となる健全なアーキテクチャを持たないものに対しては、急な代償を払うことになります。まるで流砂の上で倒壊するようなものです。

それをうまく行うプログラムは、多くの時間とコードを無駄にすることです。それは青写真のない大邸宅を建てるようなものです。アプリケーションの作成は学習プロセスであり、事前に設計することはほとんど（私の経験では）不可能です。これは、多くのリファクタリングを行うことを意味し、すべてを「うまく」書くと、多くのコードを捨てることになります。

そのため、高速で、それから！

開始する際の主なことは、すべての機能を確認して、サポートする必要があるアーキテクチャの種類を確認できるように、すべてをコードにまとめることです。この方法論のもう1つの良い点は、すぐに何かを実行できるようになるので、モチベーションを維持できることです。また、一般的なアーキテクチャに影響を与えるため、「エッジケース」機能を実装することも重要です。この段階では、単体テストの作成や詳細の作業を行わないでください。将来、多言語をサポートする必要があると思われる場合は、それ以外のプラグインアーキテクチャを実装する必要がありますが、迅速かつ汚いです。アプリケーションを管理しやすくするためにリファクタリングを行いますが、過剰なことはしません。

作業用の「プロトタイプ」があると感じたら、リファクタリングを開始します。基本的に、あなたが今知っていることをすべて知ってゼロから始めたなら、あなたがするようにアプリケーションをやり直したいと思うでしょう。重要なことは、フェーズ1で行ったすべての機能を再実装するのではなく、アーキテクチャを正しくすることですが、後でそれをサポートするためにアーキテクチャを配置する必要があります。

この方法では、とにかく私の経験では、可能な限り効率的なサウンドアーキテクチャを備えたアプリケーションになります。

構築する

市場投入までの時間が品質よりも重要な場合は迅速

まあ品質は市場までの時間よりも重要である場合

迅速に構築すると、短期的な利益と長期的な損失が生じます。

それをうまく構築すると、短期的な損失が発生しますが、長期的なメリットがあります。

それをうまく構築するには忍耐と知恵が必要ですが、あなたは報われるでしょう。

それを速く構築することは、迅速なプロトタイピングと捨て物にのみ適しています。長期的な目標は、最初から正しい姿勢でのみ達成できます。

あなたが他の人のために配布することを計画しているプロジェクトの場合、私は常に前もっての仕事の側で間違いを犯します。よく考えられたアーキテクチャは、必要に応じて簡単に拡張できます。ショートカットをとることは、技術的負債を蓄積するための単なるモデルです。

時々イライラするほど遅くなることがあります。やりがいのあることは正しくやる価値があります。

うまく構築する=速く構築する

ショートカットは好転する傾向があり、思ったよりも早く噛みつきます。時には昼食前でも。

コンテキストについて; すぐに抽象化しないでください。YAGNIに固執し、重複を削除します。実際に2番目のビューがある場合は、そのビューベースのパターンを実装します。これは、将来1つのビューがあると思われるためです。2番目のビューが到着すると、通常、作成した抽象化は、最初の1回の出現で作成した抽象化よりもはるかに優れています。

あなたがすでに何をしているのかをすでに知っているなら、知らないなら速い

私は研究科学者であり、全体像やプロジェクトがどのように発展するかについての手がかりを得る前に、多くの探索的コードを書きます。これらの場合、「ウェル」がどのように定義されるべきかを見ることさえ困難です。また、前もって拡張されるかもしれない小さな詳細や方法をすべて見るのは通常困難です。したがって、古い格言が適用されます。

1. 動作させます。
2. 正しくしてください。2番目に正しくすることには、いったん動作させた経験があれば「正しく」定義することができるという利点があります。

それをうまく構築します。

しかし、高速にするには、小さくするだけです。フィードバックを得るのに十分重要な全体の小さなサブセットを構築します。一定のペースで漸進的に追加すると、不眠症の夜を強打するという連鎖反応にあなたの魂を売ることなく、速く構築するのと同じ利点が得られます。

私はそれが常に「うまく構築」されるべきだと思います。市場投入までの時間が大きな懸念事項である場合は、段階的な開発プロセスを使用してください。最悪のシナリオでは、機能が少ない製品がありますが、少なくとも、将来の機能リリースで拡張できる高品質の製品を出荷する必要があります。

バランス

コードを完璧に設計したり、いくつかのコードをまとめてマッシュアップしたりするのは実用的ではありませんか？それは本当に適切なバランスを打つことについてです。私の意見で重要なのは、あなたがいつ何をするかです。

ここで最も重要なことは、アプリケーションのコアである基本構造を確実に構築することです。気密。それが達成されると、時間の制約に応じて、時間が不足している場合にコードをまとめて後でリファクタリングすることができ、基礎を得ることに注意を払うので、その贅沢を買うことができます正しく、コードをリファクタリングしても害はありません。

おそらく動作する可能性のある最も簡単なことを行います。あなたの特定のケースでは、あなたのプログラムは非常に大きくなることはなく、あなたがパートタイムで作業する唯一の人です。私はgotoの悪用、非記述変数名などの悪いマナーを提唱していませんが、必要以上に複雑にすべきではありません。たぶんMVCはあなたの特定のプロジェクトにとってはやりすぎだろう。

私は人々からのフィードバックを得ると、それが変化すると期待しています

あなたはそれを自分で最高と言った：

しかし、ショートカットから技術的な負債が非常に多く発生し、コードの保守や新機能の追加が非常に困難な状況に陥っています。

時間に余裕がない場合は、同じ理由を使用して雇用主からプロジェクトを完了するための時間をさらに要求することを恐れないでください。彼らはあなたにそれを与えると確信しています。これを言って、私は時々何かに一生懸命に取り組み、結果のほとんどを披露することができないのがどれほどイライラするのを感じることができるかを理解しています。しかし、心配しないでください、あなたはそこに着くでしょう、そしてあなたがそうするとき、それをうまく構築することは確かに価値があります。

通常、構造をうまく構築し、特定の実装の詳細を気にしないことで時間を節約したいと思います。あなたが言うように、彼らはとにかく変わるでしょう。適切に作成された下部構造を構築する背後にある考え方は、ベースが構築されると、変更が非常に迅速に発生する可能性があるということです。私はクラスで可能な限り一般的であり、可能な場合はそれらを再利用可能にすることに集中しようとします。私は通常、最も基本的な使いやすさの要件のみを満たす、しっかり構築されたアプリをユーザーに提供します。ユーザーがツールを手に入れると、あらゆる種類のアイデアが得られるため、はるか先まで考えることは無意味です。

それを構築するだけでなく。時間がない場合は、機能セットを減らします。

可能な限りユニバーサルに設計します。たとえば、プラグインアーキテクチャを設計します。知っていても、最初に使用するプラグインは1つだけです。最初に1つのパラメーターしかない場合でも、ユニバーサル構成スキーム（拡張可能な構成、言語の編成）を使用します。これは非常に良い投資であり、この投資はプロジェクトの開始時にのみ行うことができます。

物事を迅速に機能させ、モデルロジックをビューと混合し、カプセル化を破るなど、コードのショートカットを取ることに集中するのが最善ですか？または、より多くのアーキテクチャを構築するために事前に時間をかけるほうが良いですか

私の耳では、あなたがそこにそれを置く方法で、あなたは2つの極端をリストしています。最初の選択肢は、カプセル化を破り、モデルロジックをビューに配置することです。これは単に怠poorなプログラミングです。私見、これらの問題を解決することは、より多くのアーキテクチャを入れることと同じではありません。おそらく、あなたが話しているのでない限り、UIコードはSQLステートメントを実行しているということです。しかし、その後、アーキテクチャをさらに構築するとは言いません。デザインとアーキテクチャが完全に欠けているので、それを手に入れるべきだと言います。

アーキテクチャに関して言えば、私はあなたの問題を今すぐ解決する最も簡単なものを選択し、問題が発生したら拡大します。

たとえば、単一のデータベーステーブルからデータを返すために今すぐ必要な機能は、問題が最終的に発生することがわかっていても、関連するテーブルからデータをロードする方法などの問題は心配しません。その機能を実装しようとすると、私はそれを心配し始めます。

したがって、私自身の住宅開発プロジェクトでは、次のアプローチを取ります。現在取り組んでいる問題を解決するできるだけシンプルなソリューションを構築しますが、それをうまく構築します。さらに複雑さが必要な場合は、ソリューションをリファクタリングします。TDDプラクティスに従うと、リファクタリングが安全になり、コードのにおいを回避するのにも役立ちます（カプセル化を解除する場合、適切な単体テストを作成することは困難です）。

ちなみに、それは私がプロとして働くときに取るアプローチでもあります。;）

最初にソフトウェアを立ち上げ、すべての側面をカバーし、最初にソフトウェアを立ち上げてから、徐々にそのパフォーマンスを飾り、改善することをお勧めします

通常、次の2つのエッジの中間にいる必要があります。

それをうまく構築する = 人々の生活が依存する、命に関わるリアルタイムソフトウェア。すなわち、ソフトウェア制御：原子炉、透析機、MRI機など。

速く構築する =誰も実際に使用しない役に立たないソフトウェア。