😽

「全部読まなくてよかったんだ」って気づいた日

に公開

「え、これ表示されてる値、間違ってない?」

そんな一言から、長い長いコードリーディングが始まりました。

あるWebサービスの表示値と、データベースで集計した値が微妙にズレていたんです。

依頼者の指示は「コードを頭から読んで、どこでズレてるのか探してほしい」。
正直、膨大なコードにうんざりしながらも、言われた通り最初から読み進めていました。

でも、ふとした瞬間に「このやり方、非効率すぎるんじゃ?」と我に返りました。

課題じゃなくて「ゴール」から考えるべきだった

今回のゴールは、「表示されている値」と「データベース上の値」に差がない状態にすること。

だったら、ゴールを起点に逆算するべきだったんですよね。

・表示している値は、どこで画面に描画されているのか?
・その値は、どの関数で生成されているのか?
・その関数は、どんなロジックで計算しているのか?
・どこでデータベースとやり取りしているのか?

こんなふうに「最終的に欲しい状態(ゴール)」から逆算すれば、コードを全部読む必要なんてなかった。

実際、そう切り替えてからはスムーズに問題箇所にたどり着けて、根本原因もすぐに特定できました。

「課題」ではなく「目的」から考えるという習慣

この経験を通して強く思ったのは、課題ベースで動くと視野が狭くなりやすいということ。

「課題=データがズレてる」にフォーカスしすぎて、
ゴールである「正しく表示される」状態を見失っていた。

結果として、時間も無駄にしたし、モヤモヤも残った。

けれど、もし最初に「どうなっていれば理想か?」を描けていれば、
もっと早く、正確にアプローチできていたはずなんです。

この気づきを応用していきたい

それ以来、何か問題に直面した時、まず「ゴール」をイメージするようにしています。

・どんな状態になれば満足か?
・そのためには、どんな要素が必要か?
・どこがブラックボックスになっているか?

場当たり的に「とりあえずやってみる」よりも、
地図を描いてから歩き出す方が、圧倒的に早くたどり着ける。

そんな当たり前のことを、今回のちょっとしたデータのズレが教えてくれました。

Discussion