完璧主義は初心者の友達や敵ですか？
重複の可能性：
あなたの完璧主義のためにどこに線を引きますか？
開発コミュニティは正しい方法で物事を行うことに非常に集中していると思いますが、個人的にも同じようにしたいのですが、初心者が設計原則、設計パターン、コメントコードに焦点を当てることは良いか悪いかです始めるとき、または創造性を暴走させ、ずさんなコードを書く可能性がある方が良いでしょう。初心者はどこに線を引くべきですか？
完璧主義は、仕事を終わらせないための開発者の言い訳にはなりません。
Larry Wallは Programming Perl の初版の用語集で、有名に次のように述べています：
プログラマーの3つの優れた長所である怠惰、焦り、そして傲慢さを開発することをお勧めします。
本の第2版では、用語がさらに定義されています：
怠惰：全体的なエネルギー消費を削減するために多大な努力を払わせる品質。他の人が役に立つと思う省力化プログラムを書いて、あなたが書いたものを文書化するので、それに関する多くの質問に答える必要はありません。したがって、プログラマーの最初の大きな美徳。また、したがって、この本。焦りや傲慢も参照してください。 （p.609）
焦り：コンピューターが怠けているときに感じる怒り。これにより、ニーズに反応するだけでなく、実際にそれらを予測するプログラムを作成できます。または、少なくともふりをします。したがって、プログラマーの2番目の大きな利点です。怠惰と傲慢も参照してください。 （p.608）
Hubris：プライドが高すぎます。Zeusがあなたをあざけるようなものです。また、他の人が悪いことを言いたくないプログラムを作成（および維持）できる品質。したがって、プログラマーの3番目の大きな利点です。怠惰と焦りも参照してください。 （p.607）
Perlはすべての人のお茶ではありませんが、上記の引用で表現されたアイデアはプログラミング全般に適用されます。ごく最近、比較的新しい開発者に簡単な作業だと思ったものを割り当て、特定の「ベストプラクティス」をスキップするための明確なガイドラインを彼に与えました。このタスクはパフォーマンスに敏感で、バックグラウンドプロセスであり、Webサービス（制御できない）から大量のXMLを受け取り、データを変換し、いくつかの簡単なチェックを行ってからデータベースに格納します。 XMLデータのサイズは非常に大きく、近い将来に巨大化することが予想されたため、この処理は高速である必要がありました。本当に速い。
彼が思いついたのは、その1週間後、過剰に設計されたがらくた（正直な評価）としてのみ説明できます。データ変換をテストするために私が彼に与えたいくつかの小さめのXMLファイルに対しては問題なく動作しましたが、実際のWebサービスに接続すると、通常はバックグラウンドで動作するように、対応できず、ランダムにクラッシュしました。プロセスはパフォーマンスの問題に直面しています。恐ろしいことに、彼が私を完全に無視していたことに気付いた彼のコードを確認したところ、コードは...デザインパターンでいっぱいでした！貧しいnoobは、とりわけ 戦略的パターン のほとんど学術的な例を、とりわけ switchステートメント が本質的に小さかったものに美しく書いていました。
誤解しないでください。彼がパターンを適用することは、私たちが直面しているパフォーマンスの問題の根本的な原因ではありませんでしたが、彼はコードをすばやくハッキングする必要があるときに可能な限り「最高の」コードを書くことに一週間費やしていました。 1日か2日、残りの時間を費やして、いまいましいものをテストし、ボトルネックを特定します。そして今、私は何が起こっているのかを理解し始めるために、何千もの不要な行のコードを掘り下げる必要がありました。私がそのように私の時間を無駄にする可能性はなく、全部を廃棄して、数時間でゼロから書きました。
私は彼のコードを彼と話し合った、そして私の結論は：
- 彼は自分が適用したいくつかの概念を発見したばかりであり、それらが実際に動作するのを見るには熱心すぎました。
- 彼は無意識のうちに、印象を与えたかった（私ではなく、チーム全般）。
熱意は素晴らしく、コードでまだ完全に理解していない可能性がある概念を適用するために急いでいるのはそうではありません。それらを完全に理解したとしても、実際にはそれらを必要としないことが多いです。 Extreme Programming の基本原則の1つは、「あなたはそれを必要としない」（ [〜＃〜] yagni [〜＃〜] ）であり、それは原則です私は常に新しい開発者に渡そうとしています。 XPの創設者の一人であるRon Jeffries氏 説明 ：
多くの場合、クラスを構築していて、「必要になります...」という自分の声が聞こえます。
いつもその衝動に抵抗してください。実際にそれらを必要とするときは常に実装し、必要があると予測しているときは決して実装しないでください。その理由は次のとおりです。
- あなたの考えは軌道に乗っていません。クラスがどうあるべきかではなく、クラスが何であるかを考えています。そのクラスの構築を始めたとき、あなたは使命を帯びていました。一瞬でも気が散るのではなく、その使命を続けてください。
- あなたの時間は貴重です。コードを叩き出すだけでなく、実際のタスクに集中するように、進捗状況を磨いてください。
- 結局それは必要ないかもしれません。その場合、メソッドの実装に費やす時間が無駄になります。他の人がそれを読むのに費やす時間は無駄になります。占有するスペースが無駄になります。
- インスタンス変数のゲッターが必要であることがわかります。よし、書いて。 「必要になる」ので、セッターを記述しないでください。 「必要になる」ため、他のインスタンス変数のゲッターを作成しないでください。
コードをすばやく実装する最善の方法は、実装するコードを少なくすることです。バグを減らす最善の方法は、実装するコードを減らすことです。
あなたはそれを必要としないでしょう！
プログラマーに対する私の回答のいくつかはベストプラクティスを提唱していますが、私は、それらのベストプラクティスを適用することがそれ自体が目標であると誰かに誤解させてはいけないと思います。目標は、物事を成し遂げることです 完了は完全よりも優れています 。 and掻きむずむずむし あなたはただ自分を世界に向けただけですトラブルの。
参考文献：
プロトタイプを自由に記述します。それが機能している場合-それは大丈夫です、そのままにしておきます。他の人にコードを見せたい場合は、何がより良くでき、リファクタリングできるかを考えてください。
しばらくすると、気付くことなく正しい方法でコードを書くことができます。もちろん、「正しい方法」は、会社のポリシー、言語の共通コード規定、規制などによって異なります。
最初から完璧であることを試みれば、あなたは非常にゆっくりと進歩するでしょう。次のような質問をします。
- たぶん、ここでデザインパターンを使用できますか？
- 機能が短すぎたり長すぎたりしませんか？または、おそらく間違った方法で名前が付けられていますか？
- 他のいくつかの言語固有の愚かな質問:)
どの分野にも習熟するには時間がかかります（コード行）。プログラミングに習熟するには、問題を解決する必要があります。 100個のCRUDアプリケーションを作成すると、いくつかの複雑なアプリケーションよりも少ない知識が得られます。
物事を時間通りに終わらせることは、物事を適切に終わらせることよりも重要です。あるいは、すべてを達成するのではなく、すべてのコードを完全に磨き上げて未完成にすることよりも重要です。
あなたが書くコードの品質を絶えず改善することは単に与えられたものです。あなたはそれをする必要があります。
ただし、状況を把握しておいてください。投資を取り戻すために、新しい生産性、信頼性、将来の保守性など、重要な要素を学習して適用します。
完全主義という言葉を聞くと、私は一般的に、主な動機は生産的ではなく完璧であると思います。その人になってはいけません。生産性の向上にユーティリティが必要です。あなたの努力が具体的で現実的なペイオフによって推進されるようにしましょう。 「すべてを学ぶ価値がある」という罠に巻き込まれないでください。
私はまだ初心者ですが、2セントを差し上げます。
私は完璧主義者のようなプログラマーです。エレガントな答えを見つけるのに数日も苦労することもあれば、見つからないこともあります。しかし、それはそのようなことを学ぶことが私の焦点だからです。それもあなたなら、あなたは少し完璧主義者であると考えるかもしれません（しかし以下を参照）。
あなたの焦点が何かを完成させることであり、その後それを二度と使用しない場合は、気取らないでください。派手なコードを書くことは、そのコードを再び使用する必要がある場合に役立ちます。そうでない場合は、動作させるだけです。
今、私があなたに与えることができるいくつかのヒント：
-同じ機能を何度も作成する場合は、自分で使用できるように、適切に構造化されたライブラリにその機能をリファクタリングすることを検討してください。そうすれば、何かを維持する方法を学ぶことができ、二度と書き直す必要がなくなります。
-あなたの目的に実用的である。あなたは学びたいですか？よし、派手なコードを書く。発送してマンテインしたいですか？中期を見つけます。
-一度に1つのフォーカスを持っています。たとえば、学習、出荷、教育を同時に行わないでください。一度にできることは1つだけです。
-時間があれば、たくさん読んでください。時々それはあなたがあなたがいくつかの特定の問題について洞察を持っているのを助ける.
私が何かを助けてくれたことを願っています:)
このコード学習の問題からパターンを作成すると、次のような多くの影響を受けます。
- 練習は永続的になります。
- 理解することです。
- 人々はユニタスクの頭脳を持っています。
間違った方法で何かを繰り返したくありません。それが将来の習慣になるからです。しかし、あなたは何かをしたいのですが、完璧主義があなたを麻痺させたままにするなら、あなたはいくつかの間違いの危険を冒したいかもしれません。
最近、子供たちが書くことを教えられている方法といくつかの類似点があります。綴りを無視して書くことをお勧めしますが、創造性を流すことを非常に重視しています。小学校の掲示板でこの種の成果物を見るとうんざりしますが、フォローアップステップ（おそらく同じ日または少なくとも1週間）があり、辞書や先生、彼らはスペルを調べ、おそらくCの後を除いてiの後にeのようなルールをドリルダウンします。
プログラミングは非常に複雑であるため、新しいプログラマーはプログラミングのすべてのルールを同時に頭に置くのに苦労します。おそらくより良いツールとより良いチュートリアルを除いて、それについて行うべきことは多くありません。バランスのとれた素晴らしいトレーニングは複雑な仕事です。ウェイトトレーニングや他の種類のスポーツトレーニングをしている人が、1つの体の部分の強度のトレーニングだけを考えたり、柔軟性、速度、持久力、またはバランスに関する作業を行わずに強度のトレーニングだけを考えたりしないのと同じように。
トレーニングには、短いプログラム、中程度のプログラム、長いプログラム、他の人のプログラムを再入力するプログラム（運動学学習）、コードから始めて何か新しいことをするように変更するプログラム、またはWordからコードを作成するプログラムを含める必要があります問題（これは数学を教えるときによく起こります）。テキストや図として表されているもの、いくつかのステートメントに焦点を当てているもの、ステートメントの種類がさまざまに混在しているもの。すべての作業を直接行うものと、APIを介してほとんどすべての作業を行うものが表示されます。
敵
完全主義は、定義により、すべての人の敵です。それは（ウィキペディアによると）
個人が完璧を目指して設定することを特徴とする性格特性過度に高いパフォーマンス基準
ほぼすべての決定はトレードオフです。
- 実行時間と開発時間：「これをCまたはRubyで記述しますか？」
- シンプルさと柔軟性：「MySQLのクエリ、または複数のデータベースをサポートできる抽象クエリツールを記述しますか？」
- 作成の容易さと保守の容易さ：「コメントのない使い捨てのスクリプトや十分に文書化されたライブラリを作成できますか？」
- 上記のすべてとタスクをすばやく完了する
基準が1つの領域で高すぎるである場合、おそらく別の領域を無視しています。
速く、読みやすく、柔軟性があり、保守が容易で、十分に文書化され、十分にテストされたコードを記述した場合、タスクの重要性に基づいて必要な時間の3倍の時間がかかりますが、それは完璧ではありません。それ？