最もエレガントなソリューションを見つけることに夢中
問題やタスクの最もエレガントな解決策を見つけることに夢中になっていることがあります。
私は問題を解決するための正しい方法や使用する最良のパターンについてのアイデアやディスカッションのためにインターネット/テキストを探し回るのに何時間も費やします。
私は常に戻ってコードをリファクタリングし、自分が書いたものがすでに機能しているときにマイナーおよびメジャーな変更を加えます。私は常に将来の要件が何であるかを予測し、私が現在自分のためにより多くの仕事をしているときに、将来もっと多くの仕事を避けるためにコードをできるだけ柔軟にする方法を考えています。
無限の時間を考えるとこれは問題ではありませんが、締め切りが迫っているのでプレッシャーはさらに強くなり、私が最善の解決策を探している間、私はより多くを成し遂げることができました。私は一人の開発者であり、私が働いている会社は「内部」に見えることは決してないので、なぜ私はこの執念に悩むのですか？誰かがこれを手に入れましたか？そして、それを成し遂げるためにやる気を起こさせるために何をしますか。
よく書かれたリファクタリングされたソースコードを用意するのはあなたの仕事です。あなたはそれで成功しています、そしてそれは素晴らしいです。
時間通りに配達することもあなたの仕事です。コードの品質にこだわるのをやめたいという動機付けが必要な場合は、すでに正しいコードに変更を加えるために貴重な時間を費やし、要件を満たし、期待通りに機能するという事実はどうでしょうあなたはできません他のリクエストされた機能の期限に達したため、あなたが支払われた仕事をしていませんか？
@bmused、私はあなたの痛みをよく知っている。私にとってそれの多くは、さまざまな場所で対処しなければならなかった驚くべきWTFコードから生じます。それは他人をがらくたにするのが専門的に恥ずかしいことです。チームリードがシステムにコードを許可することを拒否するように頼んだことを2回覚えています。しかたがない; コードが不良であると認識された場合でも、最終的に配信は品質に勝ります。私たち全員が処理しなければならないコードはそれを証明します。
動機
- 優れたスカウトは、キャンプサイトを見つけたときよりも常に離れています。アーメン。
- それはまだ既存の恐怖よりも優れています。
- 楽しい。優れた設計は、コーディングをより簡単で楽しいものにします。
- 自分と上司の両方が苦しむ痛みを避ける。私は単に十分に良いことをすることを学びました。それは大変だったので、私は常にこれを警戒していなければなりません。
- 「継続的改善の姿勢」により、あまり前から心配する必要がなくなりました。
良い、思慮深い、完全な、前もって設計するは非常に重要です。自分（および私たち）自身の利益のために賢くなりすぎないようにしてください。 「エレガント」、「ブリリアント」、「あいまいな言語機能のスムーズな実装」などと言っているわけではありません。完全でわかりやすい、オブジェクト指向だと言っています。コーディングの前にまともなデザインを作成するための時間のために戦います。
優れたデザインは、当然、夜眠ることができる「十分な」コーディングに役立ちます。あなたはコードコンプリート（必須の本のタイトルでのプレー）なので、将来の拡張のための場所の開発についてそれほど心配する必要はありません。そして、「完全」であると、それをいじり続ける衝動が少なくなります。
同じコードベースで2つの非常に異なる体験をしました。要件をカバーするために、完全に定義されたビジネスドメインクラスよりも適切に設計された1つ。 PEBCAK OOを知らない同僚から「多すぎる」、「多すぎる」と非難されました-しかし、コードはより簡単で高速にコーディングされています（あなたは、改善のためにどれだけ時間がかかっているように思われるかもしれません。コーディング！）、そして数日でテストを通過しました。設計がせいぜい無能だった他の時期と比較して、3か月の地獄のテストフェイルハックサイクルに行き詰まりました。これらの2つの経験を踏まえて、次回は絶対的に完璧にすることについてどう思うか想像してみてください。
継続的な改善は幸せな場所です。新しいコードを十分に、機会が存在するときに改善するようにしてください。
- コードベースは悪化している、または良くなっている。継続的な改善またはバスト。
- 既知の変化する要件に直面して、後で改善を行うか、またはそれについて考える時間は、すべての潜在的な将来の変化を前もって推測することよりもはるかに好ましいです。
- 来ない変更を見越して、過剰なエンジニアリングを意識的に防止します。私の不満は1つのクラスだけで実装されるインターフェースです。無邪気なことはあなたが思うだろうが、私はそれを何度も目にし、私が大規模なコードベースでIMHOを実行すると、無意味で役に立たないビットは痛い。
良いリファクタリングの実践と単体テストは、継続的な改善を実装する方法です。 Martin Fowlerによる Refactoring を強くお勧めします。
継続的に技術債務と呼ばれるものに取り組むことにはいくつかのメリットがあります。コードをクリーンに保つことで、システムの俊敏性と保守性が維持されます。しかし、バランスを取る必要があります。一方で、システム設計が大きくドリフトしてソフトウェアが保守不能になるのは望ましくありませんが、他方では、「金メッキ」をしてわずかな利益を得て、期限を逃したくないのです。
Seth Godinはこのように言っています：あなたの仕事は船に乗ることです予定通りに予算内でそれを行う方法は、お金が足りなくなったとき、または時間が足りなくなったとき、発送します。どちらかが不足しないように作業を計画する必要があります。
セスはこれをテッドトークでもっと詳しく議論します、ここ：
http://vimeo.com/5895898
はい、設計時よりも開発時の方がずっとこの問題に直面しています。エレガントな解決策が思いつかない場合は、可能な限り先に進み、潜在意識にハードワークを任せます。これにより、先延ばしが避けられます。
1日の終わりに、システムを（おそらく）完成させたいということを覚えておく必要があります。そのため、最終目標に到達するために過去に移動するように指示する必要があります。
問題の解決に費やした時間を、最小化しようとしているコストの1つと考えてください。これを完全に最適化することはできないので、最善の判断をしてください。
時間がかかりすぎてひどく醜いクラッジを実行する完全にエレガントなソリューションは、どちらも失敗モードです。単位時間あたりのエレガンスを最大化するようにしてください。ストレートなエレガンスではありません。
また、YAGNIと呼ばれる良い原則があります。あなたはそれを必要としません。これは少し誇張されていると思いますが、将来を計画しないことの言い訳だと考える人もいますが、多くの場合そうです。決して使用されないソフトウェアに何かを入れた場合、それが決して現れない問題の良い解決策であったとしても、それはエレガントではありません。
悪い方がいい は良い読書になると思います。これは、LISPマシンの失敗をLISPハッカーに説明する試みであり、詳細は今では古代の歴史ですが、詳細は重要な部分ではありません。