リファクタリングを進めていく。
十分な単体テストをしてリファクタリングしていかなくてはならない。
自分ならもっと上手に書けるのにという場合でも、今あるコードを壊さないことが大事。
単体テストしやすいライブラリは、外部仕様の設計が大切です。よい外部仕様を作成することは、手離れのよいライブラリになって、自分の作業を減らしていくことにつながります。
ヘッダファイルは、外部への約束です。ですから約束する(記述する)内容は最小限にします。そして約束の内容がテキストファイルとして人が読んでわかるものにします。ですからDoxygenのdocumentation コメントは .cppファイルではなく、ヘッダファイルに記載します。
一連のモジュールの設計が妥当かどうかをチェックするには、ヘッダファイルの依存関係を確認することです。ヘッダファイルが名前空間やディレクトリ構造を持っている場合には、それらの依存関係も見てみます。それらが交互に依存している場合には、設計が何か変である可能性が高いと思われます。Doxygenを使いながら設計と実装の妥当性を検証していきましょう。
開発をすすめていく中では、その仕様が開発のしやすいものになっているかが重要です。開発の経験が少ないマネジャーの場合には、開発のしにくい仕様を作成してしまう場合があります。そのような判断間違いをしやすい事例をいくつか示し、どういう理由で間違いと考えるのかを述べています。
モジュールの関数を作成する場合には、「関数が多ければ便利でいい」というわけではないことを単一責務の原理にしたがって、次のようにまとめました。
次の３つの記事は、いずれもよいデータ構造を使うことで、コードは簡潔になり、データ構造の操作（例：データ追加、データの検索）とロジックのコードが区別しやすくなることの利点を指摘していて、STLなどの標準的なデータ構造を積極的に活用すべきと主張しています。
データ構造の操作とロジックのコードは区別しよう。
よいデータ構造でコードを簡潔にする
std::map型を使って見通しのよいコーディングをしよう
次の記事はmap型を使えば、switch文を使う必要はなくなり、一連の記述の可読性が大幅に向上し、分岐が増えたときでも保守しやすいことを述べています。
モジュールの設計がどこかしら変で、再利用性をそこなっている例の１つとしてextern があります。
そのextern を削除する設計の変更方法を示しました。
問題のあるソースコードの１つは、マクロ定数の多すぎるヘッダファイルです。その引き起こす問題と対策とを示しました。
さらに、リファクタリングをしていくためのコツを以下に示します。変数のスコープを少しでも狭めることは、ソースコードの理解をしやすいものにすることだと主張しています。
不幸にして長すぎる関数を読んで保守する必要を生じたときのヒントを示しました。
これらの記事が、あなたの関わっている開発でのリファクタリングをしやすくするものであれば幸いです。
執筆後1年以上経過しての付記
自動ビルド・自動テストを活用すること。
継続的インテグレーション(デリバリー)サービスを利用しないという罪悪