コードの保守性とツール

今日のソフトウェア開発では、使っているプログラミング言語がコンパイル言語なのかインタープリタ言語なのかに関係なく、そのソースコードを静的に解析して、さまざまな問題点を報告するツールもしくはIDEが揃っています。また、ソースコードのフォーマッタとして、Go言語標準のgofmtコマンドや、多くの言語で使われているPrettierなどがあります。

このようなツール群が存在しなかった時代（私で言えば、1978年〜）、使われていない変数、関数、メソッドなどは、コードレビューで指摘して削除してもうら必要がありました。プロジェクト（あるいは開発組織）で、ソースコードの読みやすさのために「コーディング規約」を決めることも多かったです。開発者がコーディング規約を守っているかも、コードレビューでチェックする必要がありました。

幸い今日では、コードレビューでこのような指摘をしなくても、プロジェクトで使う静的解析ツールを決めて、それをCIで実行することで、さまざまな指摘を行ってくれます。その結果、開発者自身で指摘箇所を修正できます。

見方を変えると、昔はコードの読みやすさを含む保守性を向上させるために、人によるコードレビューに頼っていたことになり、そのための工数が必要だったことになります。一方で、そのような工数を費やさなかった開発組織では、フォーマットがばらばらだったり、使われていない変数や関数が散見されたりと、保守性を下げる要因を多く持つソースコードが積み上げられていました。

今日では、ソースコード解析ツールやフォーマッタを導入してCIで適用すれば、人によるコードレビューでは、本質的なコードのロジックや保守性の観点に集中できます。その分、組織としての生産性が向上するわけです。

ソースコード解析ツールやフォーマッタを導入している開発組織に、ソフトウェア開発経験が浅い人や新卒新人が入ってきた場合、ある基準レベルのソースコードが作られることになりますが、当の本人は、ソースコード解析ツールが警告する内容の背景やフォーマッタを使う背景を理解しないままになってしまうことが多くなります。それらの背景となるようなひどい開発を経験する必要はないですが、知識としてはさまざまな書籍を通して学習してもらうのがよいかと思います。