先日の仕事中に「docker環境が壊れたが、解決まで時間がかかった上に自力のみでの解決に至れなかった」という個人的に手痛い失敗があった。
最終的な結論として
- laradockをnginx1.21.5にした際にエラーが起きる
- nginx1.21.4に下げる
- ↑の修正をしようとした際に、default.confでtypoしていた
- logの確認で原因のtypo箇所が分かった
と至ってシンプルで、結論だけ見ると自力で解決出来そうな気もする。
それなのに上手くいかなかった点に自分のエラーとの対峙の仕方に問題がある様に思えたので、その原因やらを深堀りしてみる。
状況の認知をしていない
今回の事件を振り返ると「エラーが起きた瞬間に前後の状況を認知していない」という事に気が付いた。
誰かに説明する際に「○やって、✖︎やって、そしたら▲のエラーが出ました。」といった感じで状況を伝えたりするが、それがエラーが出た段階で全く分かっていなかった。
実際にslackなどで質問する際に、上記に様に状況をまとめると、「俺何してたっけ？？」と色々遡るところから始めないといけない。
状況を理解していないのに、エラーが出ている内容に対してあれこれアクションしようとするから深みにハマる。そういった事を繰り返している様だった。
状況を正しく認知するには
じゃあ状況を正しく認知するにはどうしたらいいのか？？
これは「普段の作業でゴールと手順を把握しておく」だと思う。要するに「○やって、✖︎やったら、ここに✳︎が出るはず」を自分が認知いた上で作業するという事だ。
それが分かっていれば、エラーが起きた際に「原因はここかもしれない」という状況を踏まえた上での検討がつきやすいし、何より今までそれが曖昧になっていたのが良くない気がする。
TDDに近い感覚だ。
先にこれができればゴールというスモールな目標を掲げて、それに対してプログラミングを行なっていくイメージだ。
今まではフロントからサーバーまでの開発を機能単位でやっていて、エラーが起きた際に「ここが足りていないな」といった雰囲気で諸々修正をしながら、最終的に必要な状態になったら作業を完了していたが、それだと終わった際にどういう思考で作業工程を行なったのかが分からないというデメリットがあった。
小さいマイルストーンを置く(todoを書く)などのことはしていたが、それに対して結果まで書く事がミソになるだろう。
例として
- DBのカラム追加に対応してModelを更新する
- apiを開発する(Controlleで追加カラム分のデータを取得できる様にする)
- 追加カラム分のデータを対応している機能のstoreに反映する
- 更新したstoreを用いて画面に機能を追加する
というマイルストーンだったのを
- DBのカラム追加に対応してModelを更新する
- Contoroller側で取得できればOK
- apiを開発する(Controllerで追加カラム分のデータを取得できる様にする)
- api経由で意図通りに取得できていればOK(devtoolのnetworkで確認)
- 追加カラム分のデータを対応している機能のstoreに反映する
- 対応している機能で使うstore一覧を出しておく
- 対応箇所のstoreに反映されていればOK(devtoolで確認)
- 更新したstoreを用いて画面に機能を追加する
- 画面に正しいデータが入っていればOK
という各マイルストーン毎に正確にこうなっていればOKを認識する形にしていこうと思う。
作業に入る前段階ではこれにより時間がかかるかもしれないが、これにより各マイルストーンで、結果がどこに出力されているのかを把握して確認する様にしていきたい。(logやdevtoolなど)
今までエラーが出る段階までなあなあにしてきたが、厳格に追跡していく事でプログラミングをより良くしていきたいと思った今日この頃だった。