こんにちは!プログラマーの金です。
最近、昼休みに気温35度、湿度60%の屋外に出ると、もう溶けてしまいそうです……。
皆さんも、熱中症対策はしっかりしていきましょう。
今回のテーマは「1年前の自分に伝えたいこと」です。
去年の7月ごろを振り返ってみると、ちょうど新しいプロジェクトの開発が始まったばかりでした。旧プロジェクトのコードをベースに、既存機能の調整や新機能の開発を進めていく形でした。
細かい制限はあまりなく、機能がきちんと動けば大丈夫という雰囲気で、かなり自由に進めさせてもらっていました。
ただ、自由度が高かったからこそ、逆に迷ってしまいました。
先輩が書いたコードをできるだけ真似したほうが、バグは少なくなるのではないか。
それとも、それを理解する時間を考えると、思い切って新しく書いたほうが早いのではないか。
当時は、どちらのほうがバグが少なく、効率も良いのか判断できませんでした。
その結果、「どうしてもコードが読めないときだけ新しく書く」という、少し受け身な選択になっていたように思います。
今振り返ると、エンジニアとしての経験が足りなかったのだと思います。
経験が足りないから、一から書くのにどれくらい時間がかかるのか分からない。既存のコードを流用するメリットも、うまく比較できない。
さらに、今後変更されるかもしれない仕様に対して、どこまで先に備えておくべきかも分からない。
そう考え始めると、
「一番安全な方法はないのかな……」
という思考の穴にはまってしまっていた気がします。
慎重になりすぎていた自分にとって、高い自由度は少し怖いものでした。
判断しなければならないことが増える分、失敗する可能性も増えるように感じていたからです。
でも見方を変えれば、それは自分の考えを試せるチャンスでもありました。
既存のコードをただ直すだけでは、なぜその構造になっているのかまで深く考える機会は少なかったように思います。
一から書いてみて初めて、かかる時間やぶつかる問題が見えてきます。
そうした予想外のコストも、認識を更新していくための大切な経験なのだと思います。
とはいえ、大事なのは期限内にきちんと提出することです。
逆に言えば、進捗に問題がないのであれば、リスクをコントロールできる範囲で、思い切って試してみる。
それが、当時のベストだったのかもしれません。
この結論を、1年後の自分も忘れずにいられますように。
ちょうど今も、新しいプロジェクトの開発初期です。
今回は、試してみたい機能や設計をいくつかのモジュールに分けて
TODOリストに書き出し、
パズルのピースを一つずつはめていくような感覚で進めています。
今回の提出時には、どこまで形になっているのでしょうか……。
そんな開発者ならではのパズルゲームを、今まさに攻略中です。
次回は松村さんです!お楽しみに!

