プログラミング

プログラミングの過程

まず、そのプログラムの目的、さらには「本当に解決したい問題は何なのか」ということについて十分な検討が必要である（ワインバーグの著書などを参考のこと）。
続いて、全体のスタイルをおおまかに2つに分けると「トップダウン設計」と「ボトムアップ実装」になる。「なんとかの設計と実装」といったようなタイトルの本が多くあるように、どちらも重要だが、一般に対象についてよくわかっているものについてのプログラミングでは前者のスタイル、よくわかっていない場合は後者のスタイルとする。「設計された通りに実装することは不可能」といった場合に開発体勢の問題などから正しい対処がされないまま、設計と実装がちぐはぐになったプロダクトは悲惨である。また反復型開発では、あまりに大きなプログラムを一方通行のプロセスで書くことは最初から避けるものとされる。
目的のプログラムを書き始める前に、まずテストを書く、というスタイルもある（これを、「テストファースト」という。詳しくは、テスト駆動開発を参照）。あるいは対象が有限オートマトンやプロセス計算など、形式手法的な方法でモデル化できるのであれば、まずはそのようにすべきである（本来はモデル主導というのはそのような意味のはずである）。
最初の段階として、トップダウン設計では軽量プログラミング言語や、非形式的な記述が適している場合には擬似言語（擬似コード）などで全体設計を検討する。ボトムアップ実装では、階層構造の「葉」にあたるサブルーチンの実装を検討する。なお、流れ図（フローチャート）はコンピュータの黎明期である1940年代後半に、当時のプログラムは機械語で読むのも書くのも難しかったことから、補助のために使われその当時には有用性が高く（en:Herman Goldstine#The First Draftに当時の流れ図がある）、MIXという機械語を使っている教科書『The Art of Computer Programming』などでは使われているが、現代のプログラミング言語でも有用と信じられていることもあるようである。
プログラミングの過程で、ソースコードを記述することを特に指してコーディングという。元々は機械語が符号であること、またはアセンブリ言語のニモニックがまるで暗号みたいである（正確には「コード」は暗号の1分類。コード (暗号) を参照）というところからコンピュータプログラムに「コード」という語が使われ、それを書く作業というきわめて限定された意味の語だったが、近年はHTMLを書くという意味にも使われるなど濫用され気味である（なお、デモシーンでは機械語のテクニックを駆使して高効率のプログラムを書く、というような本来の意味に近い意味で使われている）。
可能な限り避けたいものではあるが、プログラムにはバグ(bug)の混入が避けられない。場合によっては仕様にバグがあることもある（もっとひどい場合には標準規格のようなものでもバグがある）。デバッグ(debug)とはバグを取る作業であり、プログラミングの過程に必要なものとして見積りなどでは含めておかなければならない。
一旦の完成の後も、ある程度の期間使われるプログラムでは、使用しているうちに、プログラムの性能や機能に新しい要求が発生したり、プログラムの設定を変更する必要がでてきたり、テストにより発見できなかったバグが見つかることがある。このような事態に対応するため、プログラムを保守していく作業が必要になる。

プログラマ

プログラミングをする人をプログラマという。プログラミングには一般に、コンピュータ科学を中心としたプログラミングそれ自体についての能力や知識と、書こうとするプログラムが対象とする問題領域などについての能力や知識の、両方が必要である。

プログラミングの歴史

最古のプログラマブルな機械（プログラムによって動作の変化を制御できる機械）としては、1206年にアル＝ジャザリが作った二足歩行ロボットがあると言われている。アル・ジャザリのロボットは、ボートに4体の演奏人形が乗ったもので、宮廷のパーティで池に浮かべて音楽を演奏したと言われている。プログラムはカムにあり、それによって小さなてこを押して、打楽器を演奏する。カムは実際には円筒にペグが突き刺された形であり、このペグの配置でプログラミングし、演奏パターンを変更した。
1801年に開発されたジャカード織機がプログラマブルな機械の起源とされることが多い。この機械は、穴を開けた一連の厚紙（パンチカードの原型）を使った。穴の配列が布を織る際のパターンに対応している。従って、カードを入れ替えることで全く異なる布を織ることができた。1830年ごろには、チャールズ・バベッジがパンチカードを使った解析機関を考案した。
このような先駆者の発明をさらに発展させたのがハーマン・ホレリスであり、1896年にタビュレイティング・マシン・カンパニー（Tabulating Machine Company、後のIBM） を設立した。彼はホレリス式パンチカード、タビュレーティングマシン、キーパンチ機などを発明した。これらの発明が情報処理産業の基礎となったのである。1906年には、タビュレーティングマシンにプラグボードを追加することで、組み替えれば様々な仕事ができるようになった。これがプログラミングへの第一歩である。1940年代には、プラグボードによるプログラマブルな機械が各種登場していた。初期のコンピュータにもプラグボードでプログラムを組むものがあった。
フォン＝ノイマン・アーキテクチャの発明により、プログラムをコンピュータのメモリに格納できるようになった。初期のプログラミングは機械語のコードを直接並べる（「コーディング」の本来の意）ことで行われた。入力方法としては穿孔カードや鑽孔テープが利用された他、スイッチなどで直接入力したり、まだ半導体技術などのない時代のため、ROMに相当する電気的配線を直接変更したりすることもあった。しかし、機械語の命令は人間にとって扱いにくく、代わりにニーモニックと呼ばれる略語を割り当てたアセンブリ言語により、プログラマは命令をテキスト形式で記述できるようになった。しかし、アセンブリ言語は機械語と同様にプロセッサの種類ごとに異なるため、（意図的に互換性があるように設計された機械以外では）他機種にはそのまま流用できなかった。また（人間から見れば）単純な処理でも、機械が操作できる基本的な処理命令は細粒度であり、大量に記述する必要があった。
そこで、特定のコンピュータに依存しない記述方法で、処理の内容をより抽象的に記述するためのプログラミング言語が開発された。そして、プログラミング言語によって記述されたプログラムを、コンパイラを利用して機械語に翻訳することで、実行プログラムを作成することが一般的になった。1954年、最初のプログラミング言語の1つであるFORTRANが開発された。これにより、演算を直接数式のように記述できるようになった（例えば、Y = X*2 + 5*X + 9）。このプログラムの記述（あるいは「ソース」）はコンパイラと呼ばれる特別なプログラムで機械の命令に変換される。他にも様々な言語が開発された（ビジネス用途のCOBOLなど）。プログラムの入力は依然としてパンチカードやさん孔テープで行われていた。1960年代後半、記憶装置や端末の価格が低下してきたことにより、キーボードから直接コンピュータにプログラムを入力できるようになってきた。また同じ頃、コンピュータによる処理対象のデータとしての文書についてもコンピュータ自身を利用して編集されるようになり最初はラインエディタ、続いてスクリーンエディタといった、テキストエディタが開発され、それらによってソースコード自身がコンピュータ上で編集されるようになった。
コンピュータの能力は時と共に飛躍的に向上した。このため、より抽象化されたプログラミング言語が開発されるようになっていった。抽象化レベルの高い言語はオーバーヘッドも大きいが、コンピュータ自体の性能の向上が激しいため、多少オーバーヘッドが増えても以前よりも高性能な動作が実現された。このような抽象化レベルの高い言語の利点は、習得が容易であることと、プログラム作成時間が短縮されること。そして何より、バッファオーバフロー等の危険性を孕んだプログラムを書く余地が無いこと、である。しかしそれでも、巨大で複雑なプログラムや、高速性が何よりも重視されるプログラムでは、現在でも比較的低レベルな言語を使っている（といった認識があるようだが、巨大で複雑なプログラムの全体を（危険な）低水準言語で書く、というのは甚だ怪しい。高水準言語で書けば1行で済むことに1000行かけているだけ、といった無駄な努力を過剰に肯定している可能性がある。巨大で複雑で、危険なプログラムを肯定する者は、たとえば自分の命が懸かっていたら普通は珍しい）。
20世紀後半を通して、先進国ではプログラマが魅力的な職業の1つとされてきた。しかし、発展途上国の安い労働力をプログラミングに利用する傾向が強まっている。この傾向がどれだけ続くのか、それによってどのような影響があるのかは未知数である。

方法論

ソフトウェア開発の第一段階は要求分析であり、その後モデル化し、実装し、デバッグする。これら作業については様々な方法論がある。要求分析で一般的な方法論としてユースケース分析がある。
モデル化技法としてはオブジェクト指向分析設計（OOAD）とモデル駆動型アーキテクチャ（MDA）がある。統一モデリング言語（UML）は OOAD や MDA での記法として使われている。
データベース設計では、似たような技法として実体関連モデルがある。
実装技法としては様々なプログラミングパラダイムがある（オブジェクト指向プログラミング、手続き型プログラミング、関数型プログラミング、論理プログラミングなど）。
デバッグには統合開発環境（IDE)が使われることが多い（Visual Studio、NetBeans、Eclipseなど）。独立したデバッガ（gdbなど）も使われている。

言語利用状況

どのプログラミング言語が一番使われているかというのは、非常に難しい問題である。言語によっては特定の分野でのみ一般的なものもあるし（例えば、COBOLは企業のデータセンターでよく使われており、FORTRANは科学技術計算に強く、C言語は組み込み市場で強い）、汎用的に様々なアプリケーションを書くのに使われている言語もある。
言語の人気を測定する手段として、求人広告に挙げられている言語を数え上げる方法がある。また、既存のソースコードの行数を言語毎に推計する方法もある（ただし、言語によって同じ機能を実現するのに必要な行数が異なるため、補正が必要）。

デバッグ

バグだらけのプログラムは使いものにならないため、デバッグは重要である。C言語やアセンブリ言語などは、慣れたプログラマであっても、バッファオーバーランや不正なポインタやメモリの初期化忘れ/解放忘れといったバグを作りこみやすい。バッファオーバーランは隣接するメモリ領域を破壊し、全く関係ない箇所でプログラムに異常が発生する原因となる。このため、C言語やC++でのプログラミング向けに Valgrind、Purify、BoundsChecker といったメモリデバッガが開発されてきた。
Java、C#、PHP、Python といった言語にはそのような問題がほとんどないが、性能は低い。ただし、データベースアクセスやファイル入出力が性能を決定付けるような分野では、これらの言語の性能でも何ら問題ない。また、最近ではこれらの言語の処理系でも性能が向上してきている。

プログラミングレス思想

プログラミング言語が使えるようになったことにより、機械語によるプログラミングを人間が直接する必要がなくなったのも一種の「プログラミングレス」だと言えばそれは大成功していると言えるだろうし（プログラミング言語の研究はその初期には「自動プログラミング」等と呼ばれていた）、結局「思想」というものが何を指すのか明確でないので、どうとでも言えることである。あるいは、現代においてはアプリケーションソフトウェアを使うだけでもコンピュータの利活用の幅がおおいにある、というのも一種の「プログラミングレス」であろう。理屈としては、ドメイン固有言語のうち、チューリング完全でないようなものは汎用の言語ではないから、それらを使ったコンピュータの利活用も「プログラミングレス」と言えなくもない。また、GUIによる設定やドラッグ＆ドロップでアプリケーションが開発できることなどを指して、プログラミングレス、あるいは、ノンプログラミングということもある。

議論

プログラムを書くことはアートなのか、クラフトなのか、工学なのかという議論がある。よいプログラミングには、それら3つの要素すべてが必要とされ、最終的に効率的で保守しやすいソフトウェアを生み出すことを目的とする（何が効率的で、何が保守しやすいかという判断も様々である）。「プログラムを書くことは設計をすること」という意見もある。