■

プログラムを組むとき、ソフトウェア開発時に経てきた取捨選択。

・何はともあれ作り始める事。
作るものの形すら見えずに何ができよう。
仕様書という名の書類にある画面は完成形ではない。
機能を作りながら考えても、作り直す事ができなければ
バグが消える事はない。
事前に構築する形を想定し設計し試しようやくプログラミングする。
遠回りだと思えたこの行為が最速と平均値を叩き出せる行為であると実感できた時からやめた。

・とりあえず動くもので完成と言い張ること。
ちょっと触ればエラーがあふれ、
直しても直しても収束しないｸｻﾚｿｰｽ。
後の改変時にも読むのが辛くなる神経衰弱剤。
目先の納期に合わせようと走り始めても目標は自分で遠くしていと気づいた時にやめた。

・メソッド分割しない事。
用件を考えながらコード化するとしばしば行が長くなる。
これを分割しないことはその場では楽な選択肢なのだが、後が辛くなる。
考える時間が増える。解読する時間が増える。分岐を追加するときの処理の流れに悩む。
これらと同等の時間になっても処理をきれいに分けておく事が
作ったときよりはるか後、保守性の向上に繋がることを実感できたときからやめた。

・口だけで説明する事
ﾛｼﾞｯｸを口頭説明するには言うほうも聞くほうも脳みそが要る。
それをできる事が能力の証明と思っていたが、話と思いは必ずズレる。
ペラ紙に書いたたった１文の質問事項でも、１枚の紙いっぱいの内容でも、
そこに意識を共有する材料があるのと無いのでは雲泥の差が出るものだ。
不要なやりとりの時間を短縮できた時に開発がスムーズに行くと気づいたときにやめた。

・テクニカルなコードを書く事
必要な場面は局所的にあるのだが、だからといって常日頃から書く必要はどこにもない。
if文でﾒｿｯﾄﾞ呼び出してｷｬｽﾄしながら配列の要素を引数で渡すとかしない。
100万回実行してｺﾝﾏ何秒の違いとか気にしない。
その場で最速に思えるコードは、変更されることで意味をなさなくなることを知ってからやめた。
とはいえ、ネコにもわかるようなシンプルなロジックの連続を選ぶほうが、実はより書きにくい。

ちょいと外れてみて。

・「コーディング」と言う事。
不完全な仕様書もどきからプログラムに書き起こしたところでゴミしかできない。
要望を元に、それを実現するためのコードを書き起こす事をプログラミングと呼ぶ。
要求定義の仕方も実装の仕方も管理の仕方もボンクラな自分よりも出来てないﾔﾂﾗが
「SE」なる曖昧な呼び名の職種で「上流工程」なるﾄﾞｷｭﾒﾝﾄ整理をやってることが、おままごとに見えた時期がある。
出来てもいねぇ書類をコードにおこすことに従う必要は無いと感じたときに使うのをやめた。

・世の中のコーディング規約を遵守すること
とはいえ、８割以上は賛同できる。
しかして規約の元は英語圏の文化であることを思えば
日本語だけの人種にそぐう事ばかりではない。
最高効率を求めたときに、ひとつの文章で表せない事象がでてくる。
最低の技術者が入ってきたときに、理解できない事象があるなら遵守されはしない。
技術者達の効率と最低ラインへの心配りを天秤に掛けた結果の言葉は少なくない。
意味の無い変数の活用や、Prefixの活用、コメントの表記法、スペースの有効利用。
ただ書けばいいというものではない、そこに意思がなければ主張する価値は無い。
意思の源に向上心がなければ聞いてやる価値もない。
他人の知識と経験を取り込みながらCode Generate出来る今、些細な事にこだわる事もなくなった。
組織のやりかたってのはいつでもどこでも必ずあるものだから、
あれこれいろんなことに協力できるが、思考停止にだけは賛同できん。

・目先のスケジュールに従う事
正であるとは限らない。
それどころか遵守できる現実的なものであるかもわからない。
同じ画面を作るのにはじめの1回目と最後の1回と同じ時間であるはずが無い。
仕様が途中で変わらないはずも無い。
納期を守るという行動において、ソース上吸収できる仕組みはある。
コード構成上、変化を吸収できる仕組みがある。
これらなしに変化を受け入れられるはずがない。
それら有効手段を除外してでも目先の開発スケジュールを進める事に何の意味があるだろうか。
目先を追った結果、やっぱり作っておけばよかったとみんなで後悔した時からやめた。
現実対処は自分たちでできるスケジュールを立てるのだ。目先のスケジュールは辻褄あわせの指標値であれば問題ない。