エンジニアをやっている身ながら未だに手を出していなかった達人プログラマーをようやく読んでいます。
今回はこの本の冒頭に出てくる「割れ窓理論」について気になったので私の感想を残しておきます。
まず割れ窓理論というのは、Wikipediaによると下記の通り。犯罪に関する理論です。
割れ窓理論（われまどりろん、英: Broken Windows Theory）とは、軽微な犯罪も徹底的に取り締まることで、 凶悪犯罪を含めた犯罪を抑止できるとする環境犯罪学上の理論。アメリカの犯罪学者ジョージ・ケリングが考案した。 「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなく全て壊される」との考え方からこの名がある。
本によると、エンジニアの世界にもこの現象が当てはまり、質の低いコードを放置していくといつかプロジェクト全体の質が低くなるというものです。
そのため、質の低いコードを見つけた段階で修正したり、無理ならコメントを残すなどしよう、というものでした。
さて、私はこの答えに半分賛成であり半分反対です。
反対でもある主な理由は、担当するエンジニアの能力や環境によってリファクタの質も変化する点です。
質の低いコードを修正すること自体は素晴らしいことです。
しかし、修正した結果、プロジェクト全体と調和が取れていないコードになるかもしれません。
そもそもエンジニアによって知識や価値観、経験が異なります。
修正方針に対立が生じるかもしれませんし、質の低いコードだと気づかない場合もあるかもしれません。
コメントを残したり、書き溜めておくことは大事ですが、その場その場での修正が適切とは限らないと思います。
割れ窓理論を正しく遂行するためのポイントとして、ドキュメント整備、自動化が大事だなと感じてます。
コーディング規約を整えたり、静的解析で自動化などしていけば、修正方針がエンジニア間でブレにくく整えやすくなります。
質の低いコードに出会った時は上記を見直すことも検討していきたいです。
(余談)
私は価値を生むコードが一番偉いと思っています。
割れ窓がなく綺麗でも人の少ないビルより、ボロボロでもたくさんの顧客がいるビルの方が価値のあるものだと思います。
グロース思考寄りのエンジニアとは少し価値観がずれそうな考え方かもしれません。
(そういう人は達人プログラマーという定義からは少し外れるかもしれませんが)
