■

新人であってもあんまり手間をとられることなく現実の結果を出す事の検証みたいな最近がありました。

適材適所をモットーに、プログラマとしては最高の結果に最短の手順でたどり着けるように要員体制をとっているつもりな今があって、
画面デザインとかこまごまとした調整とかやってもーてすっかり戦力化してた実感を得てた最近。
テスト用のエリアでは好きなようにプログラミングするがよいわ！
っとしていたものの、1から作らせることを暗に避けていた現状もあったので、
物は試しとばかりにやらせてみた。

やっぱりハマるねぇ( ´∀｀)

今のおいらの視点からするとなんてこたーないループと
付随する処理とにらめっこすること約2時間。
ちょっとは進むものの、
根本的原因にたどり着けないままソースがこきたなくなっていく様が観察できましたよ。
苦労するときには思う存分苦労してもらうのが後の成長のための糧。
安易な手助けなり助言は余計な要因だ( ´∀｀)
こんなとこでこっそり語るのもなんだけどがんばれ、めっちゃがんばれ。

効率化模索のために

苦労を自力で解決した経験はものっそい大事。
しかしてそれにまったりばかりはしていられない。
現実問題としては苦労して解決されたソースは保守性が高い事はないのだ。
可読性が高い事も稀であるのだ。
容赦のない手直しが必要になるってことだが、これには手間がかかる。

手間が掛かる事はなるべく少なくしたい。

っとしたときに、今回でいうと何が違うのだろう、何をすれば違うのだろう。
それを考えてたら一つ気づいたことがあった。

１メソッドの難易度で見たときに、
戦っているメソッドは間違いなく新人くんの方が難しい。

処理をつけたし、分岐をつけたし、役割がたくさん増え、
それをメンテナンスしてる。
だいぶめんどくさいソースと格闘しているのだ。

めんどくさいコードを自ら作り出し、それと格闘する。
今のおいらが100%やらないことがそこにあった。

単純に差分を考えたとき、
そこにあるのは「観点」と「問題対処方法」に集約される。
作ってみておかしな動きをするソースがあって、
原因がよく分らないとき、おいらはいったんコードと戦うのをやめる。
なんで動かないんだろう？こうやったら動くかな？っという類の実験をやめるのだ。
「わからないこと」を減らすために試行錯誤を繰り返すのであって、
「動くための方法」を見つけるために試行錯誤を繰り返すことではない。

原因の要因はどこか？
問題となっているソースはどこか？
問題は絡み合うと複雑化するけれど、単純な理由であれば対処しやすい。
ならば一つずつ対処すればよいと思える。
ので1つずつ対処すべく情報収集を行う。
最低限動く状態のソースを作るべく余分を全部削除してみるとか、
テキトーな値を入れて「確実に動く前提」や「確実に動かない前提」を作ってみて試すとか、
1回のデバックに必ず何らかの仮説を用意してから行う。
これでダメなら次の方法と語れるくらいの理由は常に用意してある。
ってのをわが身の事ながら考えてみた。

ひょっとしたら「なんとなく」で済ましているか済ましていないかの差なのかもしれないな。
ってのを思った。

先日の会話のヒトコマ
(,,ﾟДﾟ)＜画面が動きがおかしいな〜と思ったので共通部品直しました
( ´∀｀)＜なぬ？どこ？
(,,ﾟДﾟ)＜ここです。この部分を反転したら直りました。
( ´∀｀)＜ほうほう。っつか反転した部分のソース見たら
　　　　「事前準備をしてたら次の処理をやる」から
　　　　「事前準備をやってなかったら次の処理をやる」に変わってるけどどーなの？
(,,ﾟДﾟ)＜あれ？
(ﾟДﾟ)＜反転する場所はここじゃねぇ！！画面で処理しろっ!!

たかが1画面の事情でみんなの前提覆すんじゃねぇというも、
そこに見えてる範囲が違うからおこる意識の違いなんだろなと思ったよ。
解決策は理論の学習と実践あるのみだな。