プログラミング_(コンピュータ)

このため、より抽象化されたプログラミング言語が開発されるようになっていった。抽象化レベルの高い言語はオーバーヘッドも大きいが、コンピュータ自体の性能の向上が激しいため、多少オーバーヘッドが増えても以前よりも高性能な動作が実現された。このような抽象化レベルの高い言語の利点は、習得が容易であることと、プログラム作成時間が短縮されること。そして何より、バッファオーバフロー等の危険性を孕んだプログラムを書く余地が無いこと、である。しかしそれでも、巨大で複雑なプログラムや、高速性が何よりも重視されるプログラムでは、現在でも比較的低レベルな言語を使っている。

20世紀後半を通して、先進国ではプログラマが魅力的な職業の1つとされてきた。しかし、発展途上国の安い労働力をプログラミングに利用する傾向が強まっている。この傾向がどれだけ続くのか、それによってどのような影響があるのかは未知数である。
プログラミングの過程 BASICによるプログラム例

まず、そのプログラムの目的、さらには「本当に解決したい問題は何なのか」ということについて十分な検討が必要である（ワインバーグの著書などを参考のこと）。プログラミングの過程は文書化され、将来の拡張に利用できるため、これは非常に重要なことである [4]。

続いて、全体のスタイルをおおまかに2つに分けると「トップダウン設計」と「ボトムアップ実装」[5]になる。「なんとかの設計と実装」といったようなタイトルの本が多くあるように、どちらも重要だが、一般に対象についてよくわかっているものについてのプログラミングでは前者のスタイル、よくわかっていない場合は後者のスタイルとする。「設計された通りに実装することは不可能」といった場合に開発体勢の問題などから正しい対処がされないまま、設計と実装がちぐはぐになったプロダクトは悲惨である。また反復型開発では、あまりに大きなプログラムを一方通行のプロセスで書くことは最初から避けるものとされる。

目的のプログラムを書き始める前に、まずテストを書く、というスタイルもある（これを、「テストファースト」という。詳しくは、テスト駆動開発を参照）。あるいは対象が有限オートマトンやプロセス計算など、形式手法的な方法でモデル化できるのであれば、まずはそのようにすべきである（本来はモデル主導というのはそのような意味のはずである）。

最初の段階として、トップダウン設計では軽量プログラミング言語や、非形式的な記述が適している場合には擬似言語（擬似コード）などで全体設計を検討する。ボトムアップ実装では、階層構造の「葉」にあたるサブルーチンの実装を検討する [注釈 2]。なお、流れ図（フローチャート）はコンピュータの黎明期である1940年代後半に、当時のプログラムは機械語 [注釈 3]で読むのも書くのも難しかったことから、補助のために使われその当時には有用性が高く（en:Herman Goldstine#The First Draftに当時の流れ図がある）、MIXという機械語を使っている教科書『The Art of Computer Programming』などでは使われているが、現代のプログラミング言語でも有用と信じられていることもあるようである。

プログラミングの過程で、ソースコードを記述することを特に指してコーディングという。元々は機械語が符号であること、またはアセンブリ言語のニモニックがまるで暗号みたいである（正確には「コード」は暗号の1分類。コード (暗号) を参照）というところからコンピュータプログラムに「コード」という語が使われ、それを書く作業というきわめて限定された意味の語だったが、近年はHTMLを書くという意味にも使われるなど濫用され気味である（なお、デモシーンでは機械語のテクニックを駆使して高効率のプログラムを書く、というような本来の意味に近い意味で使われている）。

可能な限り避けたいものではあるが、プログラムにはバグ (bug) の混入が避けられない。場合によっては仕様にバグがあることもある（もっとひどい場合には標準規格のようなものでもバグがある）。デバッグ (debug) とはバグを取る作業であり、プログラミングの過程に必要なものとして見積りなどでは含めておかなければならない [注釈 4]。

一旦の完成の後も、ある程度の期間使われるプログラムでは、使用しているうちに、プログラムの性能や機能に新しい要求が発生したり、プログラムの設定を変更する必要がでてきたり、テストにより発見できなかったバグが見つかることがある。このような事態に対応するため、プログラムを保守していく作業が必要になる。
プログラマ詳細は「プログラマ」を参照

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

 要求分析

 ソフトウェア設計

 プログラム仕様

 ソフトウェアアーキテクチャ

 コーディング

 コンパイル

 ソフトウェアテスト

 ソフトウェアドキュメンテーション

 ソフトウェア保守

この他、プログラムが、作者以外の人によって利用される場合には、プログラムの利用方法や機能について質問を受けることがある。プログラムを、意図したとおり稼働させてゆくためには、これらの問い合わせに対応する必要もある。

一般に、職業としてプログラミングを行う場合、これらの作業が工程として含まれる。大規模なプログラミングでは、これらの作業を分業することも多い。

このような業務は、ソフトウェア工学という学問のソフトウェア開発工程の分野として扱われる。
プログラミング言語詳細は「プログラミング言語」を参照

プログラミング言語が異なれば、プログラミングのスタイル（プログラミングパラダイム）も異なる。どの言語を使うかの判断には、企業としてのポリシー、その用途への適合性、サードパーティのパッケージが使えるか、個人の好みなど様々な要素がある。理想的には、用途に最も適した言語を選ぶべきである [6]。しかし、その言語を使えるプログラマが十分揃えられないとか、その言語の処理系に問題があるとか、実行時の効率が悪いといった問題から、最適な言語を選べないこともある。

アレン・ダウニー (Allen Downey) は、著書『計算機科学者のように考える方法』(How To Think Like A Computer Scientist) で次のように書いている。

言語が違えば、詳細も違って見えるが、どんな言語にも次のような基本的命令要素がある。入力: キーボード、ファイル、その他の機器からデータを入手する。出力: 画面にデータを表示したり、ファイルその他の機器にデータを送る。演算: 加減算のような基本的算術操作を行う。条件付き実行: 条件をチェックして、一連の処理を行うか否かを判断する。繰り返し: ある処理を繰り返し実行する。通常、毎回何かが変化している。 ? Allen B.Downey、 ⇒How to Think Like a Computer Scientist§What is a program?
プログラミングパラダイム詳細は「プログラミングパラダイム」を参照

今日までに、プログラミングの進歩に貢献したパラダイムとして、次があげられる：

プログラムの実行制御の仕組みとして、命令から命令へと直接移動する代わりに、論理的な順接・反復構造を用いてロジックの抽象化を目指した構造化プログラミング

 変数の使用による副作用の発生を排除しようとした関数型プログラミング

 宣言型プログラミングを可能にした論理プログラミング

データと手続きの直交化を押し進め、人間の概念構成に近い表現を可能にしたオブジェクト指向プログラミング

Size:91 KB
出典: フリー百科事典『ウィキペディア（Wikipedia）』
担当:undef