プログラム作りは役割分担だ。
メソッドもクラスも構成には「役」がある。
自分の産み出したコードに役割とか意味とか「理由」をつけないプログラムは嘘だ。


産み出したコードの理由。
なぜそれが生み出されたのか。
なぜそれがそのカタチなのか。
なぜそれがそこにいるのか。
そいつの目的はなに?
これらの問いに答えられないプログラムコードは悲惨なことになっている。


プログラムとはロジックの実現である。
ロジカルなものになるのが自然であり、人の思考とのズレも少ないことがよい形であるべき類のものである。
そこに義理や人情は不要であり、むしろ持ち込んではいけない非情な世界である。
プログラムコードの実現結果にはロジカルな必然だけがあればよい。


「画面でデータを入力してデータベースに格納する」という当たり前にある処理をプログラムするときは
 ・データを集める
 ・集めたデータを検証
 ・検証結果がよければ登録
 ・登録結果がよければ成功
という手順を踏むのが自然なのだが、
が、しかし。
人のサボりたい生き物なので当たり前の手順を当たり前に踏まえることに対して抵抗感が沸き起こる。
こうしてロジックと感情の板ばさみから、理由付けの難しいコードが生まれる原因になる


画面のテキストボックス達をチェックしながら
アップデート用のSQLの材料にしたよ!


よく見受けられるコードの理由っぽい言葉だが、100%ダメコードだと認定できる。
出来上がったソースコードにそこにどんなロジカルな理由があるのだろうか。
「そうしてみたら動いたからこのカタチ」
ここには手順も効率化の考慮も処理の正当性も必然と呼べるものはなにもない。


必然性は何に役に立つかと言われれば「エラー時の対処」ってのに尽きる。
必然の結果のエラーは突き止めやすい性質をもつ。
〜という流れの結果がこうなるはずである。
こうならないのはこうなる前に原因がある。
一見当たり前のこんなロジックがまかり通るのと通らないのでは、
面倒くささにおいて天と地ほどの差がある。


ゆえに。
必然を積み重ねていくことには意義がある。
クラスやメソッドに役割を設けていくことは必然を積む行為となる。
プログラムコードがロジカルなことは大事なことなのだ。
必然があればこそ、プロジェクトの明日の保証が必然として行われるのだから。