■

効率化模索

プログラマってのは、手順を細かく定義してく作業を生業としている。
処理の流れを一つ一つきちんと決めていく作業を行う者だ。
条件があればそれを考慮し、
予測外のことがあればそれも考慮する。
目的があり、目的を達成するために手順化していくのだ。
例外処理もきっちり決めていく作業のひとつだ。
論理的に破綻しないことを考え、定義していくのだ。


それを踏まえて1文字変数。
その昔語ったことがある。端的に要約すると「i,j,kは氏ね」って話。
いまだに真っ当な話は聞かない。
最近に至っては、聞けば聞くほど論理的に破綻しているとしか感じなくなってきた。
ロジック確認したら( ・ω・)o[バグ発見]って感じに似ているかも。


潜在バグは見てみぬふりをするのではなく、
きっちりリファクタリングせなあかんねん。


またとあるところでコーディング規約に
やっぱり盛り込まれていたらから聞いてみた。
あいかわらず「スコープが短かったら」の前提付だった。
( ´∀｀)ノ＜ほな長かったらどーすんの？
ってきくと一文字変数じゃないものを適用するっていわれた。


ここで疑問。
スコープの長い短いの基準はどこにあって、誰が判断すんの？


１行から5行くらいまで各人様々なのだが、
(..゜Д゜)＜早い話がその人任せってやつですか？
答えはそうだっていわれた。


その人任せってほど危険な要因があろうか？
いやない。（反語）


厭らしいやつはどこにでもいる。
10行くらいの処理があっても「短い」と言い張れば「短い」となり、
例えばこんなソース*1があって、「まだ見易いから短い部類に入る」って言い張れば「短い」となる。

for( int i=0; i < n; i++ ){
　　entity.setHoge01( record[i].getHogehoge01() );
　　entity.setHoge02( record[i].getHogehoge02() );
　　entity.setHoge03( record[i].getHogehoge03() );
　　entity.setHoge04( record[i].getHogehoge04() );
　　〜〜 中略 〜〜
　　entity.setHoge49( record[i].getHogehoge19() );
　　entity.setHoge50( record[i].getHogehoge20() );
}

おいらはそんな低レベルな言い争いに発展するような会話がしたいのではない。
未来にやってくる改変作業時、どれだけバグを生み出さない仕組みにするかを模索したいのだ。
今現在の作業のほんの一瞬をケチった結果、すんげーツケを払わされないようにしたいのだ。
ひとつ許せばほかでもええやんと思うのが人の性。
一時的な変数になら使ってええやんと
String s = nantaraObject.getHogehoge();
ってなものが出現し、
それを真似た誰かがあたりまえのように使い出したりするのだ。
ほっとくと連鎖がおきていくのだ。
人とはそれほどまでにサボりたい欲求が高い生き物なのだ。
かく言うおいらも例外ではない。ただ発露の矛先が違うだけ。
ちなみにおいらはこう書く。
ループ内でオブジェクトの配列を直接扱うことをしない。

for( int intCount=0; intCount < n; intCount++ ){
　　record = record[ intCount ];　　　// ←この1文
　　entity.setHoge01( record.getHogehoge01() );
　　entity.setHoge02( record.getHogehoge02() );
　　entity.setHoge03( record.getHogehoge03() );
　　entity.setHoge04( record.getHogehoge04() );
　　〜〜 中略 〜〜
　　entity.setHoge49( record.getHogehoge19() );
　　entity.setHoge50( record.getHogehoge20() );
}


そう。
１文字変数推奨派は「今」「コードを書いている時」に楽をしたいのだ。
決して未来を見据えているわけじゃない。
可読性の向上を模索しているわけでもない。
保守性の向上を模索しているわけでもない。


(..゜Д゜)＜自分だけが楽したいって単なるわがまま言ってますか？


仮に、容認したとしよう。
開発時に楽して時間を短く出来るのならよいことだ。
1秒でも2秒でも積み重ねれば結構な時間になる。
そして、スコープの長い短いの定義も決めたとしよう。
規約にも乗せたとしよう。
その上で。
ではどこまで時間が稼げるのかを思索してみよう。


やはり誰かの目がないと、やりたい放題になる。
やりたい放題になると規約違反にもなるし、スパゲッティも出てくるからおいしくない。
最低限それを回避するためには誰かの目にさらす必要がある。
これにはやはり「ソースレビュー」が一番だ。
1回限りで終わると意味がないので何回もやるのが効果的。
ペアプログラミングも有効な手段だ。
ここまでは使おうが使うまいが同じだ。
んで、
「i」に出くわしたとする。
んで、ビミョーなラインで使われてるものが出てきたとする。
Ａさん：( ´∀｀)＜オレ的にはこれはギリギリＯＫと思うねん。
Ｂさん：( ・ω・)＜ほんまか？○○主任に聞いたら結構やばいんちゃうん？
Ａさん：( ´∀｀)＜そかな？そーいわれればそんな気になってくるな。
　　　　　　　　　どーしよ。直そか？でもめんどいな。
多かれ少なかれこんな悩む経緯が発生することが予測される。
ってか、規約で悩んだぺーぺーの頃を思えば起こらないはずながない。
リスクマネジメントの精神からするとまー起こるだろうと予測するのが正しそうだ。
規約にのっとった形式ってのを管理するとなると、例外ケースなりスレスレラインの出来事ってのは必ず起きてくる。
そういう場合は上司に確認するものだ。
んで確認される。
Ａさん：( ´∀｀)＜すんません。ここの部分って規約的にはＯＫですか？
上司は確認するのだ。ソースを読むのだ。
○○主任：(..゜Д゜)＜まーこのくらいならええんちゃうん。
なり、
○○主任：(..゜Д゜)＜いやあかん。直し。
って言う会話がおこるだろう。


さて。必要な時間をどんぶり勘定
ソースを確認してレビュー者と作成者があーだこーだ言う時間は会話にかかる時間＋読む時間だ。
なんだかんだと話していると5分や10分はあっという間に経っている。
そこから相談しに行き、結論を得るまでには移動時間にくわえて
またソースを読む時間と会話にかかる時間が必要になる。
それに加えて相談者にしれみれば、今の手持ちの仕事を遂行している流れを断ち切られることになる。
そこからの回復時間も考慮要因だ。


ここまで考えてみるとなんとなくたいしたことがないように思えてくる。
がしかしそれが落としアナ。
そう思えた前提にはこんなのがあるはずだ
　・レビュー結果には他の要因もある
　・相談時にはその他のことも話すから、たいした時間の差にはならないと思える


しかし今回の話の前提を思い出す。
「開発時の１秒を惜しむ話」である。


仮に会話に5分割かれたとすると、ソース作成時間から捻出しようとすると300回くらいないとあわない計算になる。
ループ文内の処理が1行でも最低3行になるから900行になる。
1行に押し込めるソースはそもそも却下だ。
900行ってたいした量ですよ。Σ(゜д゜　)！！


1回分でこの分量なのだから、2回3回と相談に行けば行くほどソース書かなきゃいけないことになりそうです。(゜∀゜)ｗ


なんか1秒を惜しむどころか
　ム　ダ　に　時　間　が　か　か　っ　て　し　ま　い　そ　う


これ全て「開発中」にかかる時間であることも思えば
元の木阿弥ですねヽ(´ー`)ノ



ってことで。
時間短縮にすらならないことが想定される手法を、時間短縮目的で導入するのには反対。
みんなでプロジェクトを成功させましょうって時に
ウォーターフォールモデルを導入するくらい反対。


そもそも。
（n´Д｀)η＜楽して開発したいという目的を達成できてないやんけー
端的に言うと。
（n´Д｀)η＜そんな破綻したロジック組み込めるかぼけー

*1:DBから取得してきた値の代入式なんかはそんな感じになるもんだ。