大規模または古いコードベースは、ナビゲートしやすいと期待されるべきですか？
私は現在、大規模なエンタープライズWebアプリケーションを作成およびサポートしている会社に配置されている学部のコンピューターサイエンスの学生です。ソフトウェアが実際にどのように生産されるかを体験した経験を愛しており、既存の機能を維持および拡張するだけでなく、製品の完全に新しい機能を開発する機会を提供する会社を見つけることができてとても幸運です。
とはいえ、これが正しく開発するための完璧な例になる可能性は非常に低いと私は非常に意識しています。実際、それからはほど遠い。ここでの経験から多くのことを学んでいるように感じます。間違ったことを学んだり、同僚から悪い習慣を身に付けたりして、今後さらに先へ進むのが難しいと思いません。ほとんどの場合、良い点と悪い点を簡単に区別できます。たとえば、ここでの単体テストのカバレッジは、さまざまな理由で事実上存在しません（ほとんどの場合、1つまたは2つの有効なポイントと混じった不十分な言い訳）。しかし、最近、私はよくわからない定期的な出来事に気づいています。
新しいプロジェクトを開始するときはいつでも、拡張、変更、または削除する必要がある関連コードを見つける必要があります。ほとんどの場合、アプリケーションの最も一般的に使用されるセクション内にないものは、コードベース内で見つけるのに年齢がかかるように思われます。コードのセクションをよく知っている1人または2人の技術リーダーがいますが、時には困惑し、長い時間をかけて必要なものを検索したり、コードのその部分を最近編集している人に頼ったりする必要があります（誰かが）助けを求めて。私が長い間言うとき、私は（通常）時間を意味するわけではありませんが、システムに漠然と精通している人なら誰でも、最悪の場合、数分以内の任意のポイントに優れたコードベースをナビゲートできるように思えます。
だから、私の質問。上記の問題は、構造化されていないコードが原因ですか？あるいは、コードベースについて十分な知識を持っていない開発者のせいですか？それとも、大規模なアプリケーションでは、ファイル構造を明確に保つための作業量に関係なく、それは単に避けられないのですか？
または、確かに...本当に重要ではないトピックに時間を無駄にしているだけですか？
大規模なコードベースは設計されておらず、進化しています。現在のスナップショットを見るときに意味をなさない多くのことは、履歴を考慮に入れるときに完全に意味があります。そして、私はコードベースの個々の履歴を意味するだけでなく、一般的なソフトウェアエンジニアリングプラクティスの履歴も意味します。
単体テストはほぼ常にある程度存在していましたが、1999年から2003年頃に、エクストリームプログラミングとテスト駆動開発が「発明」されるまで、実際には広く使用されることはありませんでした。多くのコードベースはそれ以前のものであり、その結果、そうではありませんでした。ユニットテストを容易にする方法で設計されています。
他のソフトウェアエンジニアリング手法の背後にも同様の歴史があります。たとえば、2005年のDVCS革命は、非分散バージョン管理を使用した場合でも、ワークフローと分岐モデルについての人々の考え方を変えました。別の例として、MVCデザインパターンは存在していても、Microsoftがその名前のフレームワークを作成するまでほとんど誰も聞いていませんでした。現在、プロジェクトであっても、モデルとビューを分離できないことは、以前よりもはるかに推奨されていません。 Microsoftのフレームワークを使用していません。
オンラインのピアレビューツールの作成と普及により、正式な会議であるピアレビューの慣行は本質的に終了し、実行がはるかに容易になり、したがってよりユビキタスになりました。ガベージコレクション言語の普及により、スマートポインターやRAIIなどのC++でのメモリ管理の革新が促進されました。これらは現在、標準的な手法と見なされていますが、現在の多くのコードベースが開始されたときは前代未聞でした。私は何度も行くことができました。
企業が成長するにつれ、コードの再利用を可能な限り活用しようとするため、ある製品に理想的なコードアーキテクチャは、新しいコンテキストではアーキテクチャが少しぎこちなくても、ほとんど変更せずに別のプロジェクトに組み込まれる可能性があります。 。これが数十年にわたって複数回発生すると、全体像が意味をなさなくなります。
企業が時代とともに変化したくないということではありませんが、コードベースは外洋船のようなものです。彼らは長い時間と慎重な計画を立てて向きを変えます。したがって、今日ゼロから始めた場合に別の方法で再設計されない大きなコードベースを見つけることはほとんどありません。探すべき重要なことは、企業が正しい方向に向かおうと努力しているかどうかです。
確かに、人間の心が把握できる複雑さには限界があります。誰かが数百万行のコードについて自分のやり方を知っていると期待することはできません。そのため、合理的でわかりやすい方法で構造化して文書化する必要があります。通常、コードを構造化する機会は省略されています。グラフィカルユーザーインターフェイスのデータベースクラスはパッケージにありません。ただし、データベースクラスがまったく異なる何か（レポートなど）を実行している場合もあります。クラスとモジュールは、ほぼ有機的に成長する傾向があります。コードをより多くの、しかしより小さなクラスに編成し、単一責任を持たせることも、コードを理解しやすくするために望ましいことです。理解しやすいコードは、ソフトウェアエンジニアリングの目標を達成するための鍵です。正しく、堅牢で、再利用可能で拡張可能なソフトウェア。
たくさんのコードを書きたい開発者はいないでしょう。アイデアは、できるだけ多くのことを書いて、拡張可能な方法で書いてもらうことです。
残念ながら、開発者はビジネス/販売/マーケティングからソフトウェア要件を収集する必要があり、通常は特定されません。そのため、そもそも実行していることを実行することを意図していないコードにパッチを適用する必要があるユースケースがあります。
あなたが人間の心を持っている方法がない限り、この状況を変える方法はありません。あなたを救うことができるのは、必須のドキュメント、強力なユニットと統合テストフレームワーク、バグ追跡システム、メールをアーカイブできる社内の開発者メーリングリスト、ピアレビュー、ジェネリックプログラミング技術の学習です。
また、オープンソースのコンポーネントはできる限り使用することを検討してください。これらのコンポーネントには、一般に優れたユーザーベースと中程度のレベルのドキュメントがあるためです。さらに重要なのは、技術リーダーが休暇中かどうかを質問する人がいることです。
大規模なソフトウェア設計関連の本も歓迎すべき追加です。
ブラウンフィールドアプリケーションに取り組むときの理想的な最初のステップは、そのユニットテストを作成することです。
これにより、いくつかのことが達成されます。
- それはあなたにコードを通して働きそしてそれを理解することを強います
- 単体テストは、既存の機能のドキュメントとサンプルコードとして機能します。
- ユニットテストは、リファクタリングのためのセーフティネットを提供します。
組織があなたにこれを許可する傾向があるかどうかは別の問題です。彼らはこの長い間、単体テストなしで生きてきました。この方法で技術的負債を削減することに彼らに同意させることは難しいでしょう。