プログラミングは比較的専門性が非常に強い技術職であり、世界中に多くのプログラマーがいます。毎日、どのプログラミング言語が最良か、優れたプログラマーの基準などについて議論されています。次に、最も議論を呼ぶプログラミングの観点を見てみましょう。
1. 余暇に楽しみでプログラミングしないプログラマーは、プログラミングを楽しむ人には永遠に及ばない。
たとえ最も賢く才能のある人でも、プログラミングを単なる仕事としてしか見なさないなら、真に優れたプログラマーには永遠になれないと思う。プログラミングを楽しむ人は、余暇にも小さなプロジェクトに取り組んだり、さまざまなプログラミング言語やプログラミング思想を試したりする。
2. ユニットテストは優れたコードを書くのに役立たない。
ユニットテストを書く唯一の理由は、すでに動作しているコードに問題が起きないことを確認するためだけだ。テストを先に書いたり、テストに合わせてコードを書くのはまったくもって不合理だ。コードの前にテストを書くなら、境界条件が何かわからない。テストを通過させることはできても、予期しない状況では問題が発生するだろう。さらに、優れた開発者はできるだけ結合度を下げるように努めるので、新しいコードを追加しても既存のコードに問題が発生することはない。
3. 唯一、どこでも通用するベストプラクティスは「頭で考えること」だ。
あまりにも多くの人が、数多くの流行のテクノロジーを追いかけ、あらゆる方法・パターン・フレームワークを不適切な場所に何とかして使おうとする。新しい技術や有名人・大御所の意見は、必ずしも実際の状況に適用できるとは限らない。
4. コード中のコメントのほとんどは、実際にはコード重複の悪質な現れである。
私たちはほとんどの時間を、他の誰か（または自分自身）が書いたコードのメンテナンスに費やしている。そして、ひどい・間違った・時代遅れの・誤解を招くコメントは、間違いなくコード中最も頭を悩ませるものの一つだ。多くの人は結局それらを削除してしまう。精力は、コードの可読性を高めること、必要に応じてリファクタリングすること、イディオムや小賢しいテクニックを多用しないことに注ぐべきだ。さらに、多くの教科書は、コメントはコードよりも重要だとさえ宣伝しており、その結果、大量の冗長なコメントが生まれている。
5. Googleに頼っても何ら問題はない。
このような意見は、学識豊かな博識な人々を怒らせるだろう。しかし、誰もが資料を調べる必要があるではないか？正しい答えは正しい答えであり、それがどの秘密の書物や私的な伝承から来たものであれ、Googleで見つけたものであれ、関係ない。重要なのは、本当に理解し、顧客と上司を満足させる成功したプログラミング解決策を提供できることだ。
6. プログラマーは生まれながらにして平等ではない。
マネージャーは、プログラマーA==プログラマーBと考えがちだ。彼らの経験年数が同じだからだ。実際には、ある開発者の効率は別の開発者の10倍、いや100倍にもなり得る。
7. なぜJavaが大学で教える最初の言語として最適なのか、私には本当に理解できない。
まず、最初のプログラミング言語は、オブジェクトや構文ではなく、制御フローと変数を学ぶことに重点を置くべきだと信じている。次に、C/C++のメモリリークをデバッグした経験のない人には、Javaの本来の意図を完全に理解することは不可能だと思う。さらに、自然な発展過程は「どうやってこれを行うか」から「これを行うライブラリをどうやって見つけるか」へと進むべきであり、その逆ではない。
8. たとえ一つの言語だけを完全にマスターしていたとしても、それしかできないなら、まだ優れたプログラマーではない。
C#やJava、あるいは最初に学んだ他のどの言語を熟知していれば十分だと考える人もいる。私はそれには同意しない。私が学ぶ新しい言語はどれも、プログラミングに関する多くの新しい知識をもたらしてくれ、それを仕事に生かすことができる。一つの言語に限定されている人は、自分の可能性を十分に発揮できない。そして、知識欲や探求心の欠如は、優れたプログラマーの資質に合わない。
9. たまには汚いコードを書いても構わない。
時には、特定のタスクは、迅速で汚いコードで済ませればいい。パターン、ORM、SRP（単一責任原則）などは、気にするな。
10. print文は効果的なデバッグ方法である。
System.out.println のような出力文を使ってコードをデバッグするのはよいと思う。これは多くの場合、正式なデバッグより速く、異なる実行の出力結果を比較することもできる。ただし、本番環境に投入する前に、これらの文を必ず削除するか、ログ文に組み込む必要がある。
11. あなたの仕事は、自分が不在でも済むようにすることだ。
あなたが書くソフトウェアは、他のどの開発者でも少し時間をかければ理解して引き継げるものであるべきだ。ソフトウェアは、美しく設計され、コードは明確で一貫性があり、フォーマットはきれいで、ドキュメントは適切で、毎日ビルドされ、適切なバージョン管理が行われているべきだ。もしあなたが交通事故にあったり、解雇されたり、辞めたりしても、会社はすぐに代わりの人を立てられるはずだ。それができないなら、あなたはあまりにも悲劇的だ。面白いことに、そうすればするほど、あなたの会社に対する価値は高くなる。
元の投稿の下に、こんなコメントがあった。「もし代替できなければ、昇進もできないよ。」
12. getterとsetterは極度に濫用されている。
何千人もの人々が、パブリックフィールドは悪であり、プライベートに設定してgetterとsetterを提供すべきだと言っている。私に言わせれば、実際には何も変わらない。プログラムがマルチスレッドであるか、アクセスメソッドにビジネスロジックや表示ロジックがある場合（これはかなり変だが）を除いては。私はパブリックフィールドを支持するわけではない。ただ、アクセスメソッドやプロパティで包んだだけで、カプセル化や情報隠蔽だと称するのには反対だ。
13. SQLもコードである。同様に扱ってほしい。
SQLはC#、Java、その他のオブジェクト指向言語や手続き型言語と何も変わらない。コードのフォーマット、可読性、保守性に注意してほしい。
14. UML図は過大評価されている。
もちろん有益な図もある。例えばCompositeパターンのクラス図などだ。しかし、多くのUML図には何の価値もない。
CSDN編集者注：Robert Martinが『アジャイルソフトウェア開発（C#版）』でUMLについて述べたとき、基本的にある図を説明してから「どうもあまり役に立たないようだ。私はあまり使ったことがない……」と言っていたのを覚えている。同じ質問の下には、もう一つの関連する答え「コード==設計」もある。高水準言語のコードはUML図やドキュメントよりも効果的だと考える。
15. 可読性はコードの最も重要な側面である。
正確性よりも重要だ。読みやすいコードは修正も容易で、最適化・変更・理解もしやすい。そして、他の開発者もその恩恵を受けることができる。
16. XMLは大幅に過大評価されている。
多くのかっこうに乗ってXMLという黒船に飛び乗った人々は、何も考えていない。XMLはWebアプリケーションに使うのは良い。元々そのためにあるからだ。それ以外の問題定義や設計アイデアには、できるだけXMLを使うべきではない。
17. ソフトウェア開発はただの仕事にすぎない。
私はソフトウェア開発が大好きだ。今はスタートアップ企業で働いており、毎週60時間働いているが、給料は高くない。ただ、チームが素晴らしく、仕事がとても面白いからだ。しかし、少し高い視点から見れば、これは依然としてただの仕事にすぎない。家族、彼女、他の友人、幸福などよりも重要ではない。十分なお金があれば、むしろバイクやヨット、スノーボードを楽しみたい。多くの開発者は、プログラミングが最終目的ではないことを忘れている。それは、人生で最も重要なことを楽しく行うための条件を私たちに提供するだけだ。
CSDN編集者注：この項目は第1項目と矛盾しているようだ。
18. 開発者はコードを書けるべきだ。
昨年は多くの面接を行った。主に、ホワイトボード上で比較的単純なアルゴリズムを実装する方法について、人々の考え方を試した。私はよく次のような問題から始める：
円周率Piは関数4 * (1 – 1/3 + 1/5 – 1/7 + …) で計算でき、項が多いほど正確になる。小数点以下5桁のPiを計算する関数を書きなさい。
これはC#で10行あればできる問題だ。しかし、多くの面接者は考え方すら浮かばなかった。そこで、やむを得ず次のような問題を出した：
円の面積はPi×半径の2乗であることを踏まえ、それを計算する関数を書きなさい。
なんと半数以上の人が、どの言語でもこの関数を完成させられなかったのだ！ああ、開発者はコードを書けるべきだというのに、今やこれさえも議論を呼ぶ意見になってしまった……
19. デザインパターンは悪影響の方が大きい。
ソフトウェア設計は、特に優れたソフトウェア設計は千差万別であり、パターンで有意義に要約することはできない。特に、皆が覚えているような数個のパターンは抽象のすぎて、実際にはほんの少しの人しか多くを本当に覚えていない。したがって、デザインパターンは実際にはあまり役に立たない。一方で、あまりにも多くの人がデザインパターンの概念に魅たされ、あちこちで何とかして使おうとする。その結果、コードには無意味なシングルトンや抽象ファクトリ以外には、ほとんど設計が見つからないことが多い。
20. コードは少なければ少ないほど良い。
ユーザーがあなたの仕事を見えないなら、それが正しいやり方だ。栄光は別のところにある。
他にも比較的人気の高い回答がある：
21. パフォーマンスは本当に重要だ。
22. エンタープライズアプリケーションは滑稽だ。n年の経験が必要というのはでたらめだ。コンピュータサイエンスの学位課程は完全にごまかしだ。
23. ユニットテストは良いコードを書くのに役立たない。ソフトウェアエンジニアリングにおけるいわゆるベストプラクティスの大半は、下手なプログラマーが大きな損害を引き起こすのを防ぐためのものだ。
24. すべてのプログラマーは、現代のコンピュータのアーキテクチャに精通すべきだ。
25. 小さなメソッドを書け。
26. PHPは本当にひどい！
27. C++は史上最悪の言語の一つだ。
28. ほとんどのプロのプログラマーはひどい。
29. プログラマーになるには、まずタイピングを覚えるべきだ。
30. プログラミング以外のさまざまなプロセスや規則が多ければ多いほど、コードの品質は悪くなる。
ベテランのゲームプログラマーであるJames Hague（有名ブログProg21の本人）もこの記事を見て、これらの意見はそれほど議論を呼ぶものではないと考えた。彼はわざわざブログを書き、自分がより議論を呼ぶと考える意見をさらに提示した。そのうちの多くは、彼が以前発表した他の記事に向けられている：
31. コンピュータサイエンス専攻は副専攻の学位としてのみにすべきだ。
32. 新しいプログラマーが、問題を分解して解決策をコードに変換することを理解する前に、オブジェクト指向を紹介するのは大きな間違いだ。
33. 複雑なコンパイラ最適化にはほとんど価値がない。たとえより速いコードが得られるとしてもだ。それらはコンパイル速度を大幅に低下させ、対処が難しいバグを生み出す可能性が高く、パフォーマンス問題への対処を一層困難にする。
34. 10年のプログラミング経験がない人に、他人が使用するライブラリを書かせてはいけない。この条項を無視すると、一生後悔することになる。
35. コードの美醜は重要ではない。フォーマットの有無は、コードが動作するかどうかや信頼性とは関係がない。フォーマットは自動化ツールに整理させればよい。
36. 純粋関数型プログラミングはあまり役に立たない。しかし、命令型コードに少し混ぜると効果が良い。
37. ソフトウェアエンジニアリングの既成概念は、むしろ偉大な作品を生み出す妨げになる。