つんだらわける

大した話じゃない話。

気付けば社会人、エンジニア5年目なので、
新しく入った方が詰んだときなんかに質問を受ける機会が多いです。

どの処理が動かないんですかーと聞くと、
だいたいが結構大きな単位だったりします。

具体的には、たとえば
「入力内容を受け取って、それに合ったファイルを生成して、そのファイルを別サーバに転送する」
という処理があったとします。

この処理はすごいざっくり言っても、以下の3つの処理に分けられます。

・入力内容を受け取る

・入力内容に合ったファイルを生成する

・生成したファイルを別サーバ転送する

なんですが、質問側はこの処理を一括りにした大きな単位で
「上手くいかない」と言うケースが多いように思います。

初歩的な話で大変恐縮ではあるんですけど、
私的にその「上手くいかない」を解決するためにまずとるべき行動は、
「どこまで成功しているか」を確認すること。
ざっくり言うと「問題の切り分け」だと思ってます。

この「どこまで成功しているか」を確認するには、
問題を細分化して考える必要があり、
今回のケースではその第一段階が上に挙げた3つの処理に分けることです。

ですが、意外にそれが出来てなくて、
自分なりに考えて目星もつけても的外れで、ストレスがマッハで、
なかなか解決しないというケースが結構あるみたいです。

場合によってはそもそも適切にログ出力をしていれば分かる問題ではあったりするんですけど。

挙げた例はまあ極端な例ではあるものの、
結局のところ切り分けが上手く出来てないケースは本当に多い。

新しいライブラリやフレームワークを使うにしても同じ話で、

いきなり大きなものを作ろうとしてガリガリコード書いていざ実行、
としたときに動かなくて、どこが原因で動いてないのか見当もつかないみたいな。

それも結局大きな単位で対象を扱ってしまっているのが原因なので、
最小構成から徐々に膨らませていけばそもそも詰まないものだったりもします。

あとは、あるプロジェクトがあって、
Aという環境では動くのにBという環境では動かないみたいなケース。

これって確実にAとBの環境に何らかの違いがあるはずなんですが、
それも考えをまとめずにあっちいじったりこっちいじったりした結果、
どこが原因か掴めないまま時間を浪費してしまう人をちらほら見かけます。

これも結局切り分けの問題で、これまた当然の話なんですが、
まず環境の差分を探して、そのあとで差分を一つずつ埋めていけば、
だいたいは具体的にどこが問題で上手くいかなかったのか掴めるはず。

ただ、その差分の探し方だったり、
ある程度細分化したあとどこに疑問を持つかって部分に関しては経験が関わってきたりはすると思うので、
そこは積み上げていくしかないのかなーと。思ったり思わなかったり。

なんか毎年同じ話をしてる気がするのでまとめ。
文章に起こしてみるとほんと大した話じゃない…！

でも切り分けって本当に大事だと思う。というお話。
長文を書くリハビリとも言います。