もともとプログラミングが
好きだった人も、

それまでプログラミングを
したことがなかった人も、

職業としてソフトウェア開発をするとき、
まず、身につけなければならないのが、

 ソフトウェアエンジニアの思考回路

です。

趣味でプログラミングをやっていたとしても、
プロとしてソフトウェアを作っていくには、
プロとしての思考回路を、
手に入れなければならないのです。

趣味でやるプログラミングとでは、
通常、規模がまったく異なるからです。

日曜大工をしていても、
家を建てることができないのと同じです。

数ある思考の型のうち、
比較的身につけやすく、
役に立ちやすいのが、

構造化プログラミングです。

いまのプログラミングの主流は、
オブジェクト指向プログラミングで、
構造化プログラミングは、
やや古く感じるかもしれません。

しかし、
構造化プログラミングを学ぶことで、
モジュール分割の仕方、
段階的詳細化など、
プログラミングの基本を身につけることができるのです。

また、オブジェクト指向を学んだとしても、
構造化プログラミングの考え方を知らなければ、
スパゲッティソースを、
生み出すことなりかねません。

構造化プログラミングを学ぶ手段として、
わたしがすすめているのは、
「SPD」(※1)です。

SPDは、日本電気株式会社で考えられた、
プログラム設計図法です。

SPDのほかにも、
フローチャートや、HCP、PADなどがあります。

しかし、
フローチャートは、
CやC++でプログラミングするには不向きです。
同じアルゴリズムを、
幾通りかで表現することができるからです。

HCPや、PADも良い図法ですが、
書くのが手間だったり、
書くスペースを取ったりするきらいがあります。

SPDは書き方が非常にカンタンで、
図法をよく知らなくても、
直感的に理解することができます。

また、段階的詳細化に適し、
ソースコードに落としやすい特徴があります。

プログラミングの回路を育てるには、
まず、人の書いたプログラムを、
自分の手で、
SPDにしてみることです。

ソースコードをSPDに変換することで、
1段階、抽象化されます。
プログラムの構造が見えてくるのです。

この訓練を繰り返すうちに、
ソースコードをみれば、
その構造がアタマに描けるようになってきます。

私のまわりでは、
「SPDは魔法のツール」と言われています。

プログラミングや、
ソースコードの解析が苦手だった人が、
急速にできるようになるからです。

試してみて損はありません。

試してみて、
あわなければやめればいいのです。


何か発見があるはずです。

blue←いつもクリックありがとうございます。

※1:
SPDに関する文献は、
私が知る限り、
一冊しかありません。

構造化プログラム設計図法 SPD』(遠藤裕香/共立出版)
です。

非常によく出来た本です。
隠れた名著と言えると思います。

4章まで読んで、
あとは実践すればいいと思います。