プログラミングの道具を考察する

構造化定理で言われるような順次・反復・分岐というプログラミングの基礎の基礎と言える要素を、たかだか数個組み合わせることで対処できるようなコーディングというのは、設問に対するパターンマッチングで回答することができる。

受験勉強でもそうなのだが、こうした問題のパターンに対して定型の答えを返す、という機械的な対処は、黙々とパターンを暗記することである程度の成果が出るわけだが、応用がまるで効かない。

必要となった時に、応用することができるかどうかがコーダとプログラマ分水嶺のように思う。

プログラマとコーダの狭間 - プログラマーの脳みそ

と述べたように、プログラミングの技能というのは応用力の類だということ。

この稿で言う「プログラミングの道具」というのはエディタとかデバッガとかの話ではなく、プログラムを組み立て上で用いるプログラミングパラダイム、つまり思考の道具のことを指す。

道具の獲得と使い方の熟練

より高度なプログラミングパラダイムを手にすることで、より高度な応用ができ、より難度の高い問題を解決できる。例えば、フェルマーの最終定理は指数を理解していれば設問は理解できるが解を出すことができない。構造化定理の順次・反復・分岐のような、算数の四則演算程度の基礎だけでは太刀打ちできない世界がある。*1

では、高度のプログラミングパラダイム、つまるところ道具を獲得したら直ちに解決できるのかというと、そう言うわけではない。オブジェクト指向プログラミングは大規模なプログラムを複雑化させない、という点で非常に効果を発揮するのだけど、OOPなら誰がやってもスパゲッティ化しないというわけではない。

道具は使いこなせて初めて効果を発揮する。包丁が良ければ鯛を生け作りにできるわけでもなければ、筆が良ければ世紀の名作を描けるわけでもない。

プログラミング技能を考えるなら、「どんな道具を持っているか」と「その道具の熟練度」を考慮しなければならないだろう。

考察すべきプログラミングの道具メモ

以下はメモ書き。

順次・反復・分岐の制御構文 算数で言う四則演算に相当する基礎中の基礎
変数スコープ 局所的に用いる変数の機能。分割統治の為の下準備
構造体 データ構造の階層化。ポインタ/参照の理解の第一歩とも言える
構造化プログラミング サブルーチン化(関数・メソッド)による冗長性の排除、分割統治。大規模化に向けた第一歩
例外処理機構 制御されたgoto文。エラーなどに対しては厳密な構造化定理適用は実用的ではない
関数ポインタ 動的な処理フローへの入口
オブジェクト指向 データ構造とメソッドを束ねることで動的な処理フローを整理して扱う。後付けでの機能拡張などに効果を発揮
静的型付け オブジェクトの適合性チェックをいちいちコードに書かずとも静的にチェックできる。静的解析を用いた大規模開発の効率化の第一歩
デザインパターン オブジェクト指向のクラス群を整理して用いる方法論
アスペクト指向 すべてのXXでYYをするという横断的関心事への対処。ヒューマンエラーへの対抗法とも言える
ジェネリクス指向 オブジェクト指向のクラス群をより抽象化して共通化することができる。静的型チェックを活かす技法
宣言型プログラミング HTMLのようにデザインなどの宣言に用いる。処理フローが不要な部分に対して簡素な記述ができるように配慮したモノ
関数型言語 マルチスレッド下での同期に関連したバグへの対処法。*2
アノテーション オブジェクトなどに情報を付加しておきプログラミング言語外と接合することができる

*1:もっとも、算数の四則演算ぐらいできれば日常生活で困ることはない。SIerには「コードなんて誰が書いても一緒」などと主張する人もいる。確かに家計簿をつける程度のことしかしない前提でなら四則演算できればいい。その前提でなら誰が計算しても同じ。誰がコードを書いても同じ。

*2:というか、関数型はまだ私も勉強中でよくつかめていない。関数型言語で言う副作用というのは同期系バグへの対抗策だと理解しているのだがどうなのだろうか。OOでimmutableパターンを多用すればそれなりには対抗できるが言語機能として持つ威力には及ばない