完璧主義の境界線はどこにありますか？
完璧主義はプログラミングの際に良い点と悪い点があります。
- 問題解決時にいつどこで線を引くのですか？
- 解決策が多すぎる、一般的すぎる、または単に未来的すぎる時期はいつ決定しますか？
不明な点があればコメントしてください。
[〜＃〜] kiss [〜＃〜] および [〜＃〜] yagni [〜＃〜] 、特にYAGNI。
すぐに必要になることがわかっているものに対してのみ、ソリューションを設計してください。 2年以内に必要になる可能性のあるものを設計しないでください。非常に異なるものが必要になり、とにかくそれを再設計する必要があるためです。
「この設計では、将来のある時点で、XまたはYを使用することもできる」と話し始めた瞬間に、「この設計により、次のリリースでお客様の要件Zを実行できるようになります」ではなく、建築天文学に。
コメントに応じて：
- KISS =シンプルに保つ、愚かな=独り言を言ってデザインを理解する必要がある
- YAGNI =必要ではない=デザインの未来を予測できるふりをするのをやめる
反復アプローチを使用すると、この問題はほとんどなくなります。コードは最初の日とその後ほぼ毎日実行する必要があります。最初に最小要件を満たし、時間のあるときにさらに追加してください。コードを長期間実行できない大きな変化を決して忘れないでください。
私は非常に完璧主義者でした（ソリューションではなく、フレームワークの作成に時間を費やしていました）。
しかし、制作を加速するのに本当に役立ったのは、原則として外部を含むBDD/TDDの原則を習得し、それに従うことでした（これを受け入れるのが特に難しいと感じました）。
これにより、テストが存在する前にコードを1行も記述しないようにすることができました。ただし、単体テストは、受け入れテストが存在する前には存在しません。受け入れテストは、実際のユーザーのニーズに基づいています。
したがって、すべてのコード行は実際のユーザーのニーズに基づいています。
原則として外部に慣れていない場合は、アプリケーションの最も外側の層（事実上すべてのケースでGUI）のテストを作成し、テストダブルを使用して下位層の動作をシミュレートする必要があります。次に、テストに合格するのに十分なだけ実装します。トップレイヤーのこの実装は、アプリケーションのボトムレイヤーに到達するまで、次のレイヤーなどに書き込む必要があるテストを指示します。
より簡単なソリューションが完成してから次に自然にアップグレード/修正されるまでの潜在的な悪影響よりも、完了するまでにかかる余分な時間が価値がある場合、ソリューションは過剰です。
基本的に、あなたは現在時間を後で取引しています。 今より多くの時間を費やすと、後で節約することになりますが、それは間違っています。本当にエンジニアリングをやり過ぎている場合は、時間を費やしているため、時間に影響はありません（またはそれ以上）あなたは後で使う。
経験を積むほど、これをうまく処理できるようになります。 （私の経験から）物事に取り組む最善の方法は、今必要なことをすることですが、後の要件で必要になったときに最も簡単に拡張できる方法で行います。それを行う方法を考え出すことは、少し難しいです。
私はこれで経験が上手くなることに気づきました。
私が（非常に）若かったとき、私は妥協することなく、常に最も完璧な解決策を求めました。今では、予算や時間などを覚えておく方が上手です。
時間制限はこの線をかなり明確にします。
私の上司は実際に:)
良くなっていることは認めざるを得ませんが、妥協の余地はあまりありません。ありがたいことに、上司に私を抑制してもらいます;）
ただし、オーバーエンジニアリングは非常に簡単に検出できるため、オーバーエンジニアリング以外の問題を提起したいと思います。
私の主な問題はリファクタリングです。問題は、ほとんどの場合、私ができる限り良いコードを書こうとしたにもかかわらず、私が今知っていることを当時知らなかったということです（より多くのコード、より多くのパターン、新しいイディオム、新しい問題、新しいソリューション）。だから、たとえそれがうまくいくとしても、私は今それを行うためのより良い方法を知っています：
- ユーザビリティを向上させ、バグが発生する可能性を減らす方法
- 依存関係を減らし、コンパイル時間を改善する方法
しかし、それはそのままの状態で機能しているため、リファクタリングは優先事項ではなく、真実は私を悩ませています。私は経済的な理由を理解しており、クライアントの期待を理解しています（彼らにはコードが表示されておらず、新機能やバグ修正を好んでいます）が、まだそれに取り組む時間があるといいのですが。
今のところ、私は上司の指示に従うだけですが、本番環境に配信されたコードが今のところ思いつく最高ではないことを知って不安を感じていることを認めざるを得ません。完璧主義だと思います。
専門的にも個人的にも、私が自分に適用しようとしている基準は次のとおりです。
勝つことに満足してください。
私のコードが問題を解決し、それが解決することを意図していて、新しい問題を作成しない場合*、次に進む時間である可能性が非常に高いです。設定する必要のある高さまでバーを設定することを学ぶと、「十分に良い」はまあ、十分になります。
完璧さは光の速さのようなものです。決してそこに到達することはできませんが、試すことに費やすことができるエネルギーに制限はありません。
（*-「バギー」と「維持が難しい」はどちらも「新しい問題」の見出しに確実に該当することに注意してください。したがって、コードがテストされ、余分なビットがトリミングされ、最新のコメント/ APIドキュメント。）
私は、他の多くのプログラマーと同様に、保守するレガシーコードをたくさん持っています。すべてをやり直すという誘惑は常に存在しますが、基本的には1つの原則にまで煮詰めました。
私（または他の誰か）はこれを理解する必要がありますか再度？
これは通常、多くのスパゲッティコードを処理し、やや扱いやすいスパゲッティチャンクコードにします。チャンクの一部を抽象化し、テストを投入します。これで、完全を必要とするようには見えなくなります。
経験から、私は特定のコンテキスト（言語、フレームワーク、プラットフォーム、標準）で少なくとも数年の経験を積むまで、完璧主義は不可能であることさえわかってきました。初心者としてwill気づかないあらゆる種類の特異性（エスケープ、優先順位、予約語、構文シュガー、タイムアウト、非同期呼び出し、文書化されていない機能とバグ）になるので、私は試してみます良い解決策として、できるだけ多くのことを学びながら。重要なことに、私は常に結果を簡単にリファクタリングできるように努めています-モジュール式のアーキテクチャ、必要な場合のコメント、そして 巧妙なトリック はありません。