分野に関係なく『組込みソフトウェア開発のための構造化プログラミング』を読んでおかなきゃあかん

『組込みソフトウェア開発のための構造化プログラミング』を軽く読んだのだが、この本は組込み系以外の分野でコードを書いている人も読むべきだ。

組込みソフトウェア開発のための構造化プログラミング (組込みエンジニア教科書)

全部で8章で、そのうちC言語成分が含まれているのは2章と5章だけ。だから残りの6章はC言語とは縁遠い分野のプログラマでも読めるはず。

意外と忘れがちなのだけど、オブジェクト指向プログラミングが必須であるような大規模な開発であっても、分割統治を繰り返した結果として、個々のクラス／モジュールといった粒度においては小規模なプログラミングの世界となる。

で、構造化プログラミングは元々高々3000行程度のプログラムが大規模プログラムと呼ばれていた時代に原典が考案された上で、頭の良い人たちが10年以上もの間に寄ってたかってそういった粒度の世界において高品質なコードを書くにはどうすればよいのかを考えて散々揉みしだいた結果として導き出された結晶な訳だ。

構造化プログラミングに関する文献を探せば分かるが、1968年の最初の論文以降、10年以上もの間、原典を継承・派生させた文献がコンスタントに出現している。それだけ色々な人たちに揉まれているのだ。例えば『ソフトウェア作法』の原著である『Software Tools』が出版されたのは1976年だ。

だから出たばかりの頃と散々揉まれた後では割と別物というか、ダイクストラ本人の論文だって1968年の「Go To Statement Considered Harmful」と1970年の「Structured Programming」とでは随分と内容が異なる。

散々揉まれた後の構造化プログラミングは今でも十二分に通じる。むしろ構造化プログラミングを古臭いと言われると「じゃあ、クラス／モジュールの中身としてメソッドを書くときに、何を指標とすればよいの？」と途方に暮れるものだ。

手続き型の系譜に連なる言語を使っているなら（それがオブジェクト指向プログラミング言語だろうと関数型言語とのハイブリットだろうとも）、現代においても「小規模なプログラミング」――クラスやモジュールの中身を実装する際には非常に有効な技法だ。

構造化プログラミングを軽視するのは、考え方によっては「質の悪い建材で家を建てる」に等しいものだ。設計品質が同じならば、出来上がる家（クラス／モジュール／コンポーネント）の品質は建材の質に左右されるものである。