■

先日ペアプログラミング中に感じたことがある。
同じソースを見、同じソースをデバッグしながらも、
把握力が違うなと。

自分が作った自分のソース。
目指すものは「作りやすいよりメンテナンスしやすいソースコード構成」
それは誰かがメンテナンスする際に評価されるもの。

今までの傾向と対策からすると。
(,,ﾟДﾟ)＜やっぱり人それぞれだｺﾞﾙｧ

いわゆるシンプルコードの特性は、
メソッドひとつひとつはシンプルに構成されている。
けど、メソッド数やクラス数は増える。
これに適性があるなしはやはりあるということだ。

今、この形式はとっても楽だし馴染んでいる自分がある。
しかしてペーペーの頃は難儀したであろう形式だとも思う。

さて。この思考速度差はどこからくるのだろう。
慣れであれば、さして問題ではない。
性格であれば、すげー難儀な事になる。
知識、経験、考え方。
これらであればどうだろう。
(,,ﾟДﾟ)＜学習するしかないんでね？

ならばどうあればより効果的に学習できるのだろう。

実感のポイント

同じようにコードを追いながら決定的に
「あ。こりゃ違うな」と思った事があった。
(,,ﾟДﾟ)＜わからないことをわからないなりに保留できるかどうかだ。

詳細を追う事で、見知らぬコードの情報が山ほど手に入るのだが、
同時に「そもそも何追ってたっけ？」という事態を招くことに繋がる。
駄々流しのコードはそもそも隠蔽化とは無縁な存在なので
このような悩みは起こるべくもないけれど、だからといって推奨するわけではない。わけもない。

デバッグ時の行動にこれが現れる。
ほぼ毎回ステップインで余計な部分を見に行ったり、
肝心要の原因が目の前に見えているにもかかわらず、
他のメソッドの中身を見に行ったり。
(,,ﾟДﾟ)＜考えてねぇのか、混乱してるのかどっちだ？
考えてないのは論外だけれども、
混乱しているのであれば、混乱が起きないように、起き難いような方法があるはずだ。
混乱が無ければその分だけ時間はかからない。

けどほなどーなっていれば混乱は抑えられるのだろう。
ん〜。

[追加]

いかにコード形態がチーム内で同じだからといって、
他の誰かの作ったコードを分析する際、作った当人の判断速度を超えれる事などない。
ある一定以上のシンプルさ、凝集度は高く、結合度は低い形式を実現してあるソースコードにおいて言い切れる。
自分が人のソースを追っかける時に考える判断基準がある。
これとチームメイトのそれとを照らし合わせながら考えてみると、見えないところが見えてくる気がする。
ソース構成を「役割分担」と考え、クラス分け、メソッド分けをする者にとって、
ソースコード上のオブジェクトは役割があると考え、それを行うのが適正かどうかをまず考える。
しかし、メソッドの先にある隠蔽化されたコードが気になって気になってしかたがない者にとっては違う。
ソースコードはまず動く事が最優先であり、メソッド化や役割分担は動く事を阻害する要因と考えている節が見えたりする。

ソースコードが動く事などゴールではなくスタートラインであると認識しているかどうかかなこれ。

意識の違いがデバッグの実行速度ってか遂行速度の違いに出るという事かも。
そう考えると、思考の方向がまず違うんだから、全力で走っていても見当違いの方向だったらおせぇことになりますわな。

当人が早い理由はソースコードの構成を知っているから。
どこに何があったかを調べることなく思い出せるから。
これは他の誰にも真似出来ないことだけれども、近づく事は出来るはず。
どこに何があるか想像できる。
どこに何があればよいかの判断ができる。
ここにあるべきはなにかの判断ができる。
多少の手順は踏むけれども、全員がこのレベルの思考手順を持っていれば、
現代のその他大勢ほどの無駄を行わなくて済む。