すべてのプログラマーがプログラミングについて知っておくべきことは何ですか？

技術的な問題にとどまり、行動、文化、キャリア、政治的な問題を避けてください。

1. バグはであるあなたのコードではなく、コンパイラやランタイムライブラリ。

2. 発生する可能性のないバグが見つかった場合は、プログラムを正しくビルドおよび展開したことを確認してください。（特に、煩雑な詳細を隠そうとする複雑なIDEまたはビルドフレームワークを使用している場合、またはビルドに多くの手動ステップが含まれる場合）

3. 並行/マルチスレッドプログラムは、記述が難しく、適切にテストするのが困難です。同時実行ライブラリとフレームワークにできる限り委任することをお勧めします。

4. ドキュメントの作成は、プログラマーとしての仕事の一部です。「他の誰か」に任せないでください。

編集

はい、私のポイント＃1は誇張されています。最高の設計されたアプリケーションプラットフォームでさえ、バグのシェアを持っています。そして、あまり良く設計されていないもののいくつかは、それらであふれています。しかし、そうであっても、常に最初にコードを疑い、コードに誤りがないという明確な証拠がある場合にのみ、コンパイラ/ライブラリのバグを非難し始めてください。

C / C ++開発を行った頃、オプティマイザーの「バグ」が原因であることが判明した場合や、言語仕様に記載されていることを行った他のプログラマーが未定義の結果をもたらした場合を覚えています。これは、Javaのような安全性の高い言語にも当てはまります。たとえば、Javaメモリモデルをじっくりと見てください（JLS 17章）。

• 他の人のコードを読む方法。
• バージョン管理システムでチェックされていない場合、コードは存在しません。

浮動小数点計算は正確ではありません。

学習をやめないでください。

コードの品質と保守性を向上させるためにできる一番のことは、重複を削減することです。

トラブルシューティングとデバッグのスキル

彼らは私が受講したどのプログラミングコースでもこのトピックにほとんど時間を費やしておらず、私の経験では、プログラマの生産性の最大の決定要因の1つです。好むと好まざるとにかかわらず、アプリのメンテナンス段階では、新しい開発段階よりも多くの時間を費やします。

私は、問題を見つけるための戦略なしに、ランダムに変更することによってデバッグする非常に多くのプログラマーと協力しました。この会話は何十回もありました。

他のプログラマー：修正されるかどうかを確認する必要があると思います。
私：さて、それはそれを修正すると仮定します。それは、問題の原因がどこにあるのかを教えてくれますか？
他のプログラマー：わかりませんが、何か試してみる必要があります。

1. 賢くならないでください。明確にしてください。
2. 再利用の前に使用してください。
3. 名前は重要です。
4. 関数は1つのことを行い、それをうまく行います。
5. 小さい方が大きいよりも優れています。

基礎。現在、プログラマは概念ではなく技術を学びます。それは間違っています。

すべてのプログラマーは、「この数値は正で有限である」、「このコードは一瞬のうちに常にサーバーに接続できる」など、常にコードに仮定を置いていることを知っている必要があります。

そして、彼は、それらの仮定が破られたときに備えなければならないことを知っているべきです。

すべてのプログラマはテストについて知っておく必要があります。

概念を学ぶ。Google構文を使用できます。

批判的かつ論理的な思考。それなしでは良いことはできません。

単体テスト。これは、コードの使用方法に関する前提を体系化するのに最適な方法です。

少なくともすべてのソフトウェア開発者が最低限、Unicodeとキャラクタセットについて知っておく必要があります（言い訳！） 。

それはあなたが思うより難しいです。

通常使用時に機能する何かをまとめるのは簡単ですが、誤った入力、すべてのエッジおよびコーナーケース、起こりうる障害モードなどに対処するのは時間がかかり、おそらく最も難しい部分です。

次に、アプリケーションの見栄えも良くする必要があります。

領域知識。仕様が100％になることはありません。開発対象の実際のドメインを知ることで、常に製品の品質が向上します。

Big O表記とその意味。

いくつかの便利なリファレンス

• http://www.perlmonks.org/?node_id=227909
• http://www.programmerinterview.com/datastruct/big-o-notation-example.php
• http://en.wikipedia.org/wiki/Big_O_notation

ポインタ、明らかに。:)

コード完了2-カバーツーカバー

データはコードよりも重要です。

データがスマートな場合、コードは愚かになる可能性があります。

ダムコードは理解しやすいです。スマートデータも同様です。

私がこれまで経験したほとんどすべてのアルゴリズムの悲嘆は、データが間違った場所にあるか、その真の意味を濫用したことが原因です。データに意味がある場合は、その意味を型システムに入れてください。

仕事に最適な言語と環境。そして、それは常にあなたのお気に入りではありません。

分割統治。通常、スケジューリングからデバッグまで、あらゆるタイプの実用的な問題を解決するための最良の方法です。

真のスキルは、複雑なデザインを機能させることではなく、シンプルなデザインをうまく実行する能力に反映されます。

このスキルは、不可解なものをマスターするのではなく、基本をよりよくマスターすることから生まれます。優秀なプログラマーは、他の人ができないこと（高レベルの機能、高度な機能プログラミング、what-have-youを使用）をコーディングする能力によって定義されるのではなく、完全にありふれたコーディングを洗練する能力に定義されます。クラス間の機能の適切な分解の選択。堅牢性の構築; 防御的なプログラミング手法を使用します。そして、より多くの自己文書化につながるパターンと名前を使用して、これらは高度なプログラミングの基本です。

自分または他の誰かが1週間、1か月、または1年で戻ってくることができ、そのコードを使用、変更、強化、または拡張する方法を理解できる適切なコードを書くことが重要です。時間と精神的な労力を節約できます。それはあなたが前につまずいたはずの障害を取り除くことで生産性の車輪に油を差します（おそらくあなたの思考の流れを中断したり、おそらく他の仕事から数時間または数日努力を払うなど）困難な問題に集中するのを容易にします、場合によっては難しい問題がなくなります。

一言で言えば、エレガンス。すべてのクラス、すべてのメソッド、すべての条件、すべてのブロック、すべての変数名：優雅さのために努力します。

よりクリーンなユーザーエクスペリエンスまたはより良いドキュメントで修正できるものをユーザーに非難しないでください。多くの場合、プログラマーは、問題が全体的なエクスペリエンスの低下またはコミュニケーションの欠如である場合、ユーザーは正しく何もできないバカだと自動的に想定します。プログラムは使用されることを意図しており、ユーザーを軽して扱うことは、そもそもプログラミングのポイントを見逃すことです。

すべてのプログラマーは、デバッガーの使用方法と、デバッガーの適切な使用方法を知っている必要があります。

データ構造

Googleの使用方法

短絡評価。ただし、ブール演算子について最初に教えることの1つです。

機能の実装にかかる時間を正確に推定する方法。さらに重要なことは、その見積もりを提出するときに強気でないことを伝える方法です。

コーディングスタイルが重要：

• 一貫したインデントの問題、
• 空白の一貫した使用（例：オペレーターの周り）、
• {}の事項の一貫した配置、
• 適切に選択された識別子が重要です。
• 等

...そして良いデザインが重要です。

理想的には、プログラマはこれらのことを最初のコードレビューの前（またはその最中）に学習します。最悪の場合、上司が恐ろしいコードに重要な変更を急いで行うように命じると、プログラマはそれらを学習します。