あなたが今まさに引き継いだレガシーC++コードベース、さてどうする？

 (gaultier.github.io)
1 ポイント 投稿者 GN⁺ 2024-03-01 | 1件のコメント | WhatsAppで共有

既存のC++コードベースを引き継いだらどうすべきか？

  • 新しい職場で働き始めたとき、チームを移ったとき、あるいは経験豊富な同僚が去ったあとに、複雑で独特な構造を持つ大規模なC++コードベースを任されることがある。
  • バグ修正や新機能の追加は必要だが、コードベースを無視したり捨てたりすることはできない。これは給料を払っている相手にとって重要であり、あなたにとっても重要である。

最初の一歩: コードをローカルで動かす

  • コードとビルドシステムには最小限の変更だけを加え、まずはローカルで動作させる。まだ大規模なリファクタリングは行わない。

不要なものを取り除く

  • 会社やオープンソースプロジェクトが宣伝・販売している機能を提供するうえで絶対に必要ではないものをすべて削除する。

プロジェクトを21世紀に引き上げる

  • CI（継続的インテグレーション）、リンター、ファジング、自動フォーマットなどを追加する。

段階的なコード改善

  • コードに小さく段階的な変更を加える。これを繰り返し、アプリケーションのセキュリティ、開発者体験、正確性、性能の面で、プロジェクトを受け入れ可能な状態にしていく。

メモリ安全な言語での一部書き直しを検討する

  • 可能であれば、一部のコードをメモリ安全な言語で書き直すことを検討する。

サポートするプラットフォームを明示する

  • READMEに、公式にサポートする<アーキテクチャ>-<OS>の組み合わせを明記する。たとえば x86_64-linux や aarch64-darwin など。

マシン上でビルドを動作させる

  • すべてのサポート対象プラットフォームで、信頼性が高く一貫してビルドできるようにする。

マシン上でテストを通す

  • テストがないなら、コード変更の前にテストを書き、通るようにしてから作業に戻る。

READMEにアプリケーションのビルド方法とテスト方法を書く

  • ビルドとテストのためのコマンドをシンプルにし、非専門家でも簡単に追えるようにする。

ビルドとテストを高速化するための手軽な改善点を探す

  • ビルドシステムを変更せずに、ビルドやテストを速くできる簡単な方法を探す。

不要なコードを削除する

  • コンパイラ警告やリンターを使って未使用コードを見つけ、削除する。

リンター

  • リンター規則に過度にこだわらず、基本的なものをいくつか追加し、開発サイクルに組み込む。

コードフォーマット

  • 適切なタイミングでコードベース全体に一括でコードスタイルを適用し、設定をコミットする。

サニタイザー

  • サニタイザーを使って実際のバグやメモリリークを検出し、修正する。

CIパイプラインを追加する

  • 導入した良い仕組み（リンター、コードフォーマット、テストなど）をすべて自動化し、すべての変更に対して本番環境向けバイナリを生成する。

段階的なコード改善

  • セキュリティ、正確性、性能といった具体的な目標に集中し、「クリーンコード」のような主観的基準から離れる。

メモリ安全な言語へ書き直す？

  • これは現在進行中のテーマであり、多くの注意点がある。明確な理由がある場合にのみ実施する。

結論

  • 複雑なレガシーC++コードベースから抜け出すための、具体的で段階的な計画を提示する。

付録: 依存関係管理

  • C++には依存関係管理がなく、多くはシステムのパッケージマネージャを使う。しかし、これは良い考えではない。
  • 依存関係管理についての著者の意見は、gitサブモジュールとソースからのコンパイル方式を使うべきだというものだ。

GN⁺の見解

  • この記事は、C++コードベースを引き継いだ初級ソフトウェアエンジニアにとって有用な、段階的ガイドを提供している。
  • レガシーコードを扱うことは多くの開発者に共通する課題であり、この記事はそのような状況で実践的な助言を与えている。
  • コードベース改善の過程でテストの重要性を強調している点は、良いソフトウェア開発実践を反映している。
  • 依存関係管理に関する著者の意見には議論の余地があり、実際のプロジェクトでは Conan や vcpkg のような現代的なパッケージマネージャをうまく使っているケースも多い。
  • 技術を導入する際には、プロジェクトの特性やチームの技術レベルを考慮する必要があり、この記事はその判断を下すための良い出発点になりうる。

関連記事

1件のコメント

 
GN⁺ 2024-03-01
Hacker Newsの意見

  • 一部のHacker Newsコメントでは、C++プロジェクトを引き継いだ際の助言が示されている:

    • 再現可能なビルド: Dockerのようなツールを使ってビルド環境を包み込み、ツールと依存関係を明確で再現可能なものにすることを推奨。
    • -Wall オプションでクリーンにビルドすること: 警告を解消してコードの問題を修正し、まれには内容を理解したうえで警告を無視することも可能。
    • Valgrind のようなツールで初期テストを行い、読み取り/書き込みエラーを調査することを提案。
    • リファクタリングは初期段階では局所的な範囲にとどめ、全体構造を理解する前に大規模な再設計を避けることを推奨。

  • 別のコメントでは、CI、linting、auto-formatting などをまず導入することが重要だと主張している:

    • コードから不要な部分を取り除く前にプログラムがどのように動作するかを理解し、静的解析ツールを通じてプログラムのどこに作業が必要かについて洞察を得られる。

  • あるユーザーは新しいチームや会社へ移ることを提案している。

  • コード理解ツールと技術の重要性に言及するコメントもある:

    • コードベースをインデックス化するツールの使用や、UMLシーケンス図の作成、まるで他人に教えるようにノートを書くことが重要。

  • あるコメントは、プロジェクトをモダン化するために CI、linters、fuzzing、auto-formatting などを追加することについて助言している:

    • CI によって他の環境でもビルドできるようにし、コンパイラ警告および静的解析器を活用してコードの問題を把握する。
    • 重要なコード部分に対する単体テストを設定し、コードが正しい処理を行うことを確認する。
    • 自動フォーマットの優先順位は低く、元のメンテナーのスタイルに従うことを推奨。

  • また別のコメントでは、メモリ安全な言語で一部を書き直すことに関する助言を批判している:

    • 追加作業に必要なリソースを確保するのが難しく、C++以外の追加言語に関する知識が必要で、テストがさらに複雑になる可能性がある。

  • gitサブモジュールとソースからコンパイルする方式が、パッケージマネージャーより優れていると主張するコメントもある:

    • vcpkg のようなツールを試す前にこうした批判をするのは奇妙だと指摘している。

これらのコメントは、C++プロジェクトを引き継いだときのさまざまなアプローチと助言を提供しており、プロジェクト管理、コード理解、リファクタリング、モダン化戦略などに関する多様な意見を示している。