■

(1)『作業精度や効率化など、自身のレベルアップ目的』のこと。

プログラムを組み上げる前に完成予想図を思い浮かべているか？
プログラムを組んでいる最中にいびつな形になったことに気付くか？
いびつな形を放置してはいないか？
バグが取れない。
バグが増える。
ソースが直せない。
ソースが直らない。
なぜそうなる。なぜそうなった。なぜそれに至ったか。

自身の作業の細分化を行えない時代は答えに至れない。

きっかけは始まりのときに楽をしたからってのに他ならない。
作っている最中、もっとも大事なことから目を背けたってのに他ならない。
今を誤魔化しても後に跳ね返ってくるという不変の事実から逃げただけだ。

そうならないように。
そう至らないように。
逃げたくなる自分に言い聞かせるために。
手順の細分化が必要になってくる。

あれやってこれやって、これもやる。あれもやらなあかん。
この項目がたくさん出せれば、次なにをやるか？そのうちやってくる作業は何であるか？
それらをつなぎ合わせれば、今の作業がどこに影響がでてくるかが解るようになる。
流れを理解できれば必然としてやるやらないの判断がつく。

これらを繰り返して繰り返してロジックの組み方が得られるのだとわしゃ思う。
言語知識はそれらを表現するための材料であるともわしゃ思う。

ロジックの組み方。ソース構成時に行うこと。
これらは知識と言うか経験と言うか、なんちゅーか、精神論的な話になる。
「プログラマの心構え」そーゆーもんになると思う。

ｺﾚに比べて言語の話。
決しておろそかにしちゃいけないけれども、それが全てじゃない。
かつてのおいらも含めてプログラマ入門生には全部と思ってしまう時期がある。
C++最強！とかVB氏ね！！とか言ってしまい時がある。
でもね。
けどね。
言語種類なんてのは特性の違いだけ。
言語知識なんてものでも重要ではあるけれども最重要じゃない。
今になってそう思う。
優れたプログラム言語知識をもっていても、それだけで
優れたプログラマとは言えないってことですよ。

っと。
そういいきってくれる先生は学校にはいなかったし、
教本類にもまったくなかった。

学校出たての人員に即戦力を求めない理由はそこにあって。
ソフトウェア開発ってのを知らない「先生」が教える内容に何を期待しましょう？
言語の使い方だけ書いてある本から「ロジックの構築のしかた」なんて知れません。
UMLを学んだところで言語知識がなければまともなモデル作りなんてできゃしない。

知識と実践と反省と反復が大事です。

ってのをなんとなくでも知れるかどうか、
聞いたら実践できるかどうか、
実践しうる動機にできるかどうかが細分化できるかってのに繋がる。と思う。

己を知らなくてもある程度のレベルまではこれる。
しかして己を省みることなく己の限界は破れない。
誰かの1000倍の作業がこなせることが夢物語ではない我らが仕事。
めんどくさいと思えることでも、
取り返すこと何ざたやすいことになることは多い。