これは間違いなく主観的ですが、私はそれが議論になることを避けたいと思います。人々が適切に扱うなら、興味深い質問になると思います。
この質問のアイデアは、「お気に入りの言語で嫌いな5つのことは何ですか？」に対する私の回答のコメントスレッドから生まれました。質問。私はC＃のクラスはデフォルトでシールされるべきだと主張しました-私は私の推論を質問に入れませんが、この質問への回答としてより完全な説明を書くかもしれません。コメントでの議論の熱さには驚かされました（現在25コメント）。
それで、あなたはどんな異論のある意見を持っていますか？結局のところ、比較的少ない根拠でかなり信心深くなるようなことは避けたいですが（例：ブレース配置）、「ユニットテストは実際にはあまり役立たない」、「パブリックフィールドは本当に大丈夫」などの例が含まれる場合があります。（とにかく）私にとって重要なことは、あなたにはあなたの意見の背後に理由があるということです。
あなたの意見と論拠を提示してください-あなたがそれらに同意するかどうかにかかわらず、私は人々がよく議論され、興味深い意見に投票することをお勧めします。
回答:
余暇の時間にコードを書かないプログラマーは、そうするプログラマーほど優秀になることはありません。
私は、最も賢く、最も才能のある人々でさえ、それを仕事以上のものとして扱わない限り、真に優れたプログラマーになることはないと思います。彼らが脇で小さなプロジェクトを行ったり、余暇にたくさんの異なる言語やアイデアを台無しにしたりすることを意味します。
（注：優れたプログラマーがプログラミング以外に何もしないと言っているのではありませんが、彼らは9から5までのプログラム以上のことをしています）
常に使用する必要がある唯一の「ベストプラクティス」は、「Use Your Brain」です。
あまりにも多くのバンドワゴンに飛び乗り、メソッド、パターン、フレームワークなどを、それらを正当化しないものに押し付けようとする人々が多すぎます。何かが新しいから、または尊敬されている誰かが意見を持っているからといって、それがすべてに当てはまるとは限りません:)
編集：明確にするために-私は人々がベストプラクティスや価値ある意見などを無視すべきではないと思います。人々がこの「もの」がとても優れている理由を考えずに盲目的にジャンプするべきではないということだけです。やっている、そしてそれは何の利点/欠点をもたらしますか？
「ググって」大丈夫！
はい、私はそれが彼らの何年もの激しい暗記やプログラミング本の見事な積み重ねが誰かが数秒以内にアクセスできるリソースへの道端に落ち始めていることをそこに何人かの人々を怒らせることを知っています、しかしあなたはそれを人々に対して保持すべきではありませんそれを使用します。
批判の結果、問題に対するグーグルの答えを聞くことがあまりにも多く、それは本当に意味がありません。まず第一に、誰もが参照する資料が必要であることを認めなければなりません。あなたはすべてを知っているわけではなく、物事を調べる必要があります。それを考えると、情報をどこで入手したかは本当に重要ですか？本で調べたり、Googleで調べたり、幻覚を起こした話しているカエルから聞いたりすることは重要ですか？いいえ。正解は正解です。
重要なのは、資料を理解し、それをプログラミングソリューションを成功させるための手段として使用し、クライアント/雇用主が結果に満足していることです。
（あなたが幻覚の話しているカエルから答えを得ているなら、あなたはおそらく同じようにいくつかの助けを得るべきです）
コード内のほとんどのコメントは、実際にはコードの重複の有害な形式です。
私たちはほとんどの時間を他の人（または私たち）が作成したコードの保守に費やしており、貧弱で、不正確で、古く、誤解を招くコメントは、コード内の最も厄介なアーティファクトのリストの上部にあるはずです。
結局のところ、多くの人々はそれらを、特にそれらの花屋の怪物たちをただブランクにするだけだと思います。
コードを読みやすくし、必要に応じてリファクタリングし、イディオムと奇妙さを最小限に抑えることに集中する方がはるかに優れています。
一方、多くのコースでは、コメントはコード自体よりも非常に重要であることを教えており、この次の行につながると、invoiceTotalスタイルのコメントに1つ追加されます。
すべてのプログラマーが平等に作成されているわけではありません
マネージャーがDeveloperA == DeveloperBと考えるのは、彼らが同じレベルの経験を持っているなどの理由でかなり頻繁に起こります。実際、ある開発者のパフォーマンスは、別の開発者の10倍または100倍にもなり得ます。
それについて話すことは政治的に危険ですが、時々私はいくつかのチームメンバーが同等のスキルを持っているように見えても、常にそうであるとは限らないことを指摘したくなります。リード開発者が「希望を超えている」ケースや、ジュニア開発者が実際の作業をすべて行ったケースを見たこともあります。:)
1つの言語しか知らない場合は、どれだけ知っていても、優れたプログラマーではありません。
C＃やJava、または他の言語で学習を始めたら、それで十分だという態度があるようです。私はそれを信じていません。これまでに学んだすべての言語は、他のすべての人と私の仕事に持ち帰ることができるプログラミングについての新しい何かを私に教えてくれました。自分を1つの言語に制限する人は、誰もができるほど良くなることはないと思います。
それはまた、探究心と実験への意欲がある程度欠如していることを私に示しています。これは、本当に優れたプログラマーに見られると期待される資質と必ずしも一致しないものです。
パフォーマンスは重要です。
あなたの仕事は、仕事から抜け出すことです。
雇用主向けのソフトウェアを作成する場合、作成するソフトウェアはすべて、開発者が選択して最小限の労力で理解できるような方法で作成する必要があります。適切に設計され、明確かつ一貫して記述され、きれいにフォーマットされ、必要な場所に文書化され、期待どおりに毎日ビルドされ、リポジトリにチェックインされ、適切にバージョン管理されます。
バスに当たったり、解雇されたり、解雇されたり、仕事を辞めたりした場合、雇用主は一瞬であなたを置き換えることができ、次の人があなたの役割に踏み込み、コードを手に取り、立ち上がることができます。一週間以内に実行されます。彼または彼女がそれをすることができないなら、あなたは惨めに失敗したでしょう。
興味深いことに、その目標を持つことで、雇用主にとってより価値のあるものになっていることがわかりました。使い捨てに努力すればするほど、彼らにとって貴重なものになります。
1）ビジネスアプリ茶番：
「エンタープライズ」フレームワーク全体が煙と鏡であると思います。J2EE、.NET、Apacheフレームワークの大部分、およびそのようなものを管理するためのほとんどの抽象化は、それらが解決するよりもはるかに複雑になります。
通常のJavaまたは.NET ORMのいずれか、あるいはどちらかで「マジック」を実行して退屈でシンプルなタスクを解決するための、いずれかの最新のMVCフレームワークを使用します。検証と迅速な記述が難しい、醜いXMLボイラープレートを大量に作成することになります。大規模なAPIがあり、その半分は他のAPIの作業、リサイクルが不可能なインターフェース、JavaとC＃の柔軟性の欠如を克服するためだけに必要な抽象クラスを統合するためのものです。それはほとんど必要ありません。
独自の厳格な記述子構文を備えたさまざまなアプリケーションサーバー、非常に複雑なデータベースおよびグループウェア製品についてはどうでしょうか。
これのポイントはその複雑さ==悪いことではなく、それは不必要な複雑さ==悪いことです。私は大規模なエンタープライズインストールで作業しましたが、その一部は必要でしたが、ほとんどの場合でさえ、ほとんどのユースケースを解決するために必要なのは、いくつかの自家製スクリプトとシンプルなWebフロントエンドだけです。
私は、これらのエンタープライズアプリをすべて、シンプルなWebフレームワーク、オープンソースDB、および簡単なプログラミング構造に置き換えようと思います。
2）必要なn年の経験：
アプリケーション、API、フレームワークに関連する特定の問題を処理するためにコンサルタントまたは技術者が必要でない限り、そのアプリケーションで5年の経験を持つ人は実際には必要ありません。必要なのは、ドキュメントを読むことができ、自分がやっていることに関するドメインの知識があり、すばやく学習できる開発者/管理者です。なんらかの言語で開発する必要がある場合、まともな開発者が2か月足らずでそれを習得します。X Webサーバーの管理者が必要な場合は、2日以内にmanページとニュースグループを読んで、すぐに理解できるはずです。何も少なく、その人は彼が支払われるものの価値はありません。
3）一般的な「コンピュータサイエンス」学位カリキュラム：
コンピュータサイエンスとソフトウェアエンジニアリングの学位の大半は強引です。最初のプログラミング言語がJavaまたはC＃の場合は、何か問題があります。代数学と数学でいっぱいのいくつかのコースを取得しない場合、それは間違っています。関数型プログラミングについて詳しく説明しないと、不完全です。ささいなforループにループ不変式を適用できない場合、想定されるコンピューターサイエンティストとしての価値はありません。xとyの言語とオブジェクト指向の経験があれば、s ***でいっぱいです。実際のコンピューターサイエンティストは、使用する概念と構文の観点から言語を理解し、プログラミング方法論を多くの人の1つと見なしており、新しい言語、設計方法、または仕様言語の選択の両方の根本的な哲学を十分に理解しています。ささいなこと。
ゲッターとセッターは頻繁に使用されます
私は何百万人もの人々がパブリックフィールドは悪だと主張しているので、それらをプライベートにして、すべてのゲッターとセッターを提供しているのを見てきました。これは、フィールドをパブリックにすることとほぼ同じだと思います。スレッドを使用している場合（ただし、通常はそうではありません）、またはアクセサーにビジネス/プレゼンテーションロジック（少なくとも「奇妙な」何か）がある場合は、少し異なる可能性があります。
私はパブリックフィールドに賛成ではありませんが、それらすべての人のためにゲッター/セッター（またはプロパティ）を作成することに反対し、それを行うことはカプセル化または情報の隠蔽であると主張します... ha！
更新：
この回答はコメントでいくつかの論争を引き起こしたので、私はそれを少し明確にしようと思います（多くの人々が賛成したので、元の情報はそのままにしておきます）。
まず第一に、パブリックフィールドを使用する人は誰でも刑務所に入る価値があります
現在、プライベートフィールドを作成してから、IDEを使用してそれらすべてのゲッターとセッターを自動的に生成することは、パブリックフィールドを使用するのとほぼ同じくらい悪いことです。
多くの人が考えています：
private fields + public accessors == encapsulation
私は、フィールドのゲッター/セッターペアの（自動かどうかにかかわらず）生成は、達成しようとしているいわゆるカプセル化に効果的に対抗すると言います。
最後に、このトピックでボブおじさんを引用させてください（「クリーンコード」の第6章から引用）：
変数を非公開にする理由があります。私たちは他の誰かにそれらに依存してほしくない。私たちは、気まぐれや衝動に基づいてタイプや実装を自由に変更できることを望んでいます。では、なぜ多くのプログラマーは、ゲッターとセッターをオブジェクトに自動的に追加し、プライベートフィールドをパブリックであるかのように公開するのでしょうか。
UMLダイアグラムは非常に過大評価されています
もちろん、合成パターンのクラス図などの便利な図がありますが、多くのUML図にはまったく価値がありません。
意見：SQLはコードです。そのように扱う
つまり、C＃、Java、またはその他のお気に入りのオブジェクト/プロシージャ言語と同様に、読みやすく保守しやすいフォーマットスタイルを開発します。
ずさんなフリーフォーマットのSQLコードを目にしたら嫌です。ページに中括弧の両方のスタイルが表示されたときに悲鳴を上げる場合、無料の書式設定されたSQLまたはJOIN条件を覆い隠すまたは難読化するSQLが表示されたときに、なぜまたはなぜ悲鳴を上げませんか？
読みやすさは、コードの最も重要な側面です。
正確さよりももっと。読みやすいものであれば、簡単に修正できます。また、最適化、変更、理解も簡単です。そして、うまくいけば、他の開発者もそれから何かを学ぶことができます。
あなたが開発者であれば、コードを書くことができるはずです
私は昨年かなりのインタビューを行いましたが、私のインタビューの一部として、人々がどのように考えているか、そして彼らがホワイトボードに簡単なアルゴリズムを実装する方法をテストすることになっていた。私は最初に次のような質問から始めました：
Piが関数4 *（1-1/3 + 1/5-1/7 + ...）を使用して推定できるため、より多くの項で精度が高くなるため、Piを小数点以下5桁の精度で計算する関数を記述します。 。
それはあなたが考えさせるべき問題ですが、熟練した開発者の手の届かないところにあるべきではありません（C＃の約10行で答えることができます）。しかし、私たちの候補者の多く（代理店によって事前に選別されていると思われます）は、回答を開始することさえできず、回答方法についても説明できませんでした。しばらくしてから、次のような簡単な質問をし始めました。
円の面積がPiと半径の2乗の積で与えられる場合、円の面積を計算する関数を記述します。
驚くべきことに、候補者の半数以上がこの関数をどの言語でも書くことができませんでした（私はほとんどの一般的な言語を読むことができるので、疑似コードを含む任意の言語を使用させました）。この関数をC＃で記述できない "C＃開発者"がいました。
びっくりしました。開発者はコードを記述できるべきだといつも思っていました。今日、これは物議を醸す意見であるようです。確かに面接候補者の一人です！
編集：
最初の質問が良いものか悪いものか、そしてインタビューでこれと同じくらい複雑な質問をするべきかどうかについてのコメントには多くの議論があります。投稿の要点を大幅に逃していると言うことは別として、ここではこれを掘り下げるつもりはありません（まったく新しい質問です）。
はい、私はこれで人々はどんな前進もできなかったと言いました、しかし2番目の質問は些細なことであり、そして多くの人々はそれでどんな前進もできませんでした！自分を開発者と呼ぶ人は誰でも、数秒で2番目の答えを何も考えずに書くことができるはずです。そして、多くはできません。
デザインパターンは、優れたデザインを支援するよりも傷つけています。
IMOソフトウェア設計、特に優れたソフトウェア設計はパターンが多すぎて意味がありません。特に、実際に覚えることができる少数のパターンでは意味がありません。また、抽象化されているため、ほんの一握りでは覚えられません。だから彼らはあまり役立っていません。
そしてその一方で、あまりにも多くの人々がコンセプトに夢中になり、どこにでもパターンを適用しようとします-通常、結果のコードでは、すべての（完全に無意味な）シングルトンと抽象ファクトリの間の実際の設計を見つけることができません。
ユニットテストは良いコードを書くのに役立ちません
単体テストを行う唯一の理由は、すでに機能しているコードが壊れないようにすることです。最初にテストを書く、またはテストにコードを書くのはばかげています。コードの前にテストに書き込んだ場合、エッジケースが何であるかさえわかりません。テストに合格したが、予期しない状況でも失敗するコードが存在する可能性があります。
さらに、優れた開発者は凝集度を低く保つため、新しいコードを追加しても既存のものに問題が発生する可能性は低くなります。
実際、さらに一般化します。
ソフトウェアエンジニアリングのほとんどの「ベストプラクティス」は、悪意のあるプログラマーが過度の損害を与えないようにするためのものです。
彼らは、悪い開発者を手に入れ、彼らが愚かな過ちを犯さないようにするためにそこにいます。もちろん、ほとんどの開発者は悪いので、これは良いことですが、良い開発者は合格する必要があります。
小さなメソッドを書く。 プログラマーは、複数の異なることを行うloooongメソッドを書くのが好きなようです。
メソッドは、名前を付けることができる場所に作成する必要があると思います。
ソフトウェア開発は単なる仕事です
誤解しないでください。私はソフトウェア開発をとても楽しんでいます。この件について過去数年間ブログを書いてきました。私はここに十分な時間を費やして> 5000の評判ポイントを得ました。チームは素晴らしく、仕事が面白かったので、私は起業して通常60時間の週をやって、請負業者として得ることができるよりもはるかに少ないお金で働いています。
しかし、物事の壮大な計画では、それは単なる仕事です。
家族、ガールフレンド、友人、幸福など、多くの事柄よりも重要度が高く、バイクに乗ったり、セーリングヨットやスノーボードをしたり、現金を無制限に提供したりしたい場合、私はむしろそうしたいと思っています。
多くの開発者は、開発とは、それ自体が最終目標ではなく、人生においてより重要なものを（そして私たちが楽しむことによって）持つことを可能にするものにすぎないことを忘れていると思います。
また、ソース管理にバイナリがあることには何の問題もないと思います。正当な理由があれば。ソースがないアセンブリがあり、各開発マシンの同じ場所にあるとは限らない場合は、通常、それを「バイナリ」ディレクトリに貼り付け、相対パスを使用してプロジェクトで参照します。
同じ文章で「ソース管理」と「バイナリ」に言及したとしても、私は危機に瀕していると思う人はかなり多いようです。私はあなたがそれらを加えることができないと言っている厳しい規則がある場所さえ知っています。
すべての開発者は、現代のコンピュータの基本的なアーキテクチャに精通している必要があります。これは、仮想マシンをターゲットとする開発者にも当てはまります（メモリ管理などについて心配する必要がないことを何度も何度も言われているため、さらにそうかもしれません）。
ソフトウェアアーキテクト/デザイナーは過大評価されている
開発者として、私はソフトウェアアーキテクトのアイデアが嫌いです。彼らは基本的に、フルタイムでコーディングを行わず、雑誌や記事を読み、ソフトウェアの設計方法を教える人々です。実際にフルタイムでソフトウェアを書いている人だけがそうすべきです。あなたがアーキテクトになる前の5年前にあなたが世界最高のコーダーであったかどうかは気にしません。あなたの意見は私には役に立たないのです。
それは物議を醸すためにどうですか？
編集（明確にするため）：ほとんどのソフトウェアアーキテクトは優れたビジネスアナリスト（顧客との対話、要件の作成、テストなど）を作成していると思います。単純に、彼らはソフトウェアの設計、高レベルなどに場所がないと思います。
開発に「1つのサイズですべてに対応する」アプローチはありません
これは常識のように思えるため、これは物議を醸す意見であることに驚いています。ただし、人気の高いブログには「1つのサイズですべてに対応」という開発アプローチを宣伝するエントリがたくさんあるので、実際には少数派かもしれません。
私はとして宣伝されて見てきたもののための正しいアプローチ任意の任意の情報が、それについては知られている前に- -プロジェクトは、テスト駆動開発の使用（TDD）、ドメイン駆動設計（DDD）のようなもの、オブジェクト・リレーショナル・マッピング（ORM）です、アジャイル（大文字のA）、オブジェクト指向（OO）など。方法論からアーキテクチャ、コンポーネントまで、すべてを網羅しています。もちろん、市場性のある頭字語もすべて含まれています。
人々も、このような、「私はテスト駆動てる」または類似したとして自分のブログにバッジを置く限り行くように見えるかのように、プロジェクトのプロジェクトの詳細は、実際にあるものは何でも、単一のアプローチへの厳守は良い事。
そうではありません。
正しい方法論、アーキテクチャ、コンポーネントなどを選択することは、プロジェクトごとに行う必要があり、作業しているプロジェクトのタイプとその固有の要件だけでなく、サイズと能力にも依存します。一緒に働いているチームの