引継いだクソコードもリスペクトするべき

何年も使われてきたソフトウェアには少なからずクソコードが紛れています。 むしろぜんぶクソ、と言いたくなりますが、ぐっと堪えて敬意をもって接するべきだと思います。
仕事について
- エンジニアの学びに「自分プロジェクト」が最適な理由
我々はお客様からお金をいただいてお客様の課題を解決する専門家です。 どんなプログラミング言語を使うかはお客様からの評価には関係ないのです。
我々が仕事としてコードを書いてる以上、コードの品質よりも優先せざるを得ないことがあります。 その筆頭はみんな大好き 納期 ですね。
ワタシの経験から言えるのはビジネスの変化するスピードはリファクタリングを終えるよりもはるかに速いということです。
エンジニアについて
ほとんどの場合、クソコードのコミットログは過去に在籍していたらしい、会ったことのない先輩のものです。 まだ生き残っている先輩のコードの場合もありますが、クソだと叫ぶ前に質問できるのでクソコード認定されることは少ないです。
生き残っている先輩のクソコードが発見された場合、ぜひ当時の状況をインタビューしてみてください。 きっと営業が絶対間に合わない納期で合意してきたとか、納期直前に顧客がちゃぶ台をひっくり返したとか、何かしらのエピソードがあると思います。
あなたの目の前にあるクソコードは、コードよりも優先しなくてはいけない事柄に直面して、それでも納期を守り検収を通過した諸先輩方の汗と涙と責任感の濃縮5倍汁なのです。 クソと間違えるのも仕方ないですが、その裏に何かしらの闘いがあったということを忘れないで欲しいと思うのです。
自分自身について
翻ってあなたは、そしてワタシも、駆け出し時分の遅れや品質についてクソコードを理由にしたことがないとは言わせません。 ですが長年エンジニアを続けていればクソの一本や二本、誰だって垂れ流して来ているものです。 ワタシも、あなたも。
あなたがクソだと叫んだそのコードは昨日のワタシが書いたものです。 ワタシがクソだと叫んだこのコードは明日のあなたが書くものです。 どちらにもやむにやまれぬ理由があるのです。
- 謝辞
- 画像は Unsplash 様より使わせていただきました。