大規模または古いコードベースは、ナビゲートが容易であることが期待されますか？

私は大規模なコンピューターサイエンスの学生で、現在、大規模なエンタープライズWebアプリケーションを作成およびサポートしている会社の就職年にいます。現実の世界でソフトウェアがどのように生産されるかを体験した経験を愛しており、既存の機能を維持および拡張するだけでなく、製品の完全に新しい機能を開発する機会を提供する会社を見つけることができてとても幸運です。

とはいえ、これが正しく開発するための完璧な例になる可能性は非常に低いと私は非常に意識しています。実際、それとはかけ離れています。ここでの経験から多くのことを学んでいるように感じます。間違ったことを学んだり、道を進むのが難しいかもしれない同僚から悪い習慣を身につけたりしたくありません。ほとんどの場合、良い点と悪い点を簡単に区別できます。たとえば、ここでの単体テストのカバレッジは、さまざまな理由で事実上存在しません（ほとんどの場合、1つまたは2つの有効なポイントが混じった不十分な言い訳）。しかし最近は、よくわからないことが定期的に発生していることに気づきました。

新しいプロジェクトを始めるときはいつでも、当然、拡張、変更、または削除する必要がある関連コードを見つける必要があります。ほとんどの場合、アプリケーションの最も一般的に使用されるセクション内にないものは、コードベース内で見つけるのに時間がかかります。コードのセクションをよく知っている1人または2人の技術リーダーがいますが、彼らは時々困惑し、必要なものを探すのに長い時間を費やす必要があるか、最近コードのその部分を編集している人に頼る必要があります（誰か）助けを求めて。長い時間を言うとき、私は時間（通常）を意味するわけではありませんが、システムに漠然と精通している誰にとっても、良いコードベースは最低でも数分以内の任意のポイントにナビゲートできるように思えます。

だから、私の質問。上記の問題は、不十分な構造のコードが原因ですか？あるいは、開発者がコードベースについて十分な知識を持っていないためでしょうか？または、大規模なアプリケーションでは、ファイル構造を明確に保つためにどれだけの労力がかかるかに関係なく、それは単に避けられないのでしょうか？

または、確かに...私は本当に重要ではないトピックに私の時間を無駄にしていますか？

大きなコードベースは設計されていませんが、進化します。現在のスナップショットを見るときに意味をなさない多くのことは、履歴を考慮に入れると完全に意味があります。そして、私はコードベースの個々の履歴を意味するだけでなく、一般的なソフトウェアエンジニアリングプラクティスの履歴も意味します。

ユニットテストはほぼ常にある程度存在していましたが、1999年から2003年にかけて極端なプログラミングとテスト主導の開発が「発明」されるまで、実際に広範囲に使用されることはありませんでした。単体テストを簡単にする方法で設計されています。

他のソフトウェアエンジニアリング手法の背後にも同様の歴史があります。たとえば、2005年のDVCS革命は、非分散バージョン管理を使用しても、ワークフローと分岐モデルについての人々の考え方を変えました。別の例として、たとえ存在していたとしても、Microsoftがその名前のフレームワークを作成するまでMVCの設計パターンについてほとんど誰も聞いていませんでした。モデルとビューの分離の失敗は、プロジェクトでも以前よりもはるかに推奨されていませんMicrosoftのフレームワークを使用しません。

オンラインピアレビューツールの作成と普及により、正式な会議であるピアレビューの実施が実質的に終了し、実行がはるかに容易になり、その結果、ユビキタスになった。ガベージコレクションされた言語の普及により、スマートポインターやRAIIのようなC ++でのメモリ管理の革新が促されました。私は何度も行くことができました。

企業が成長するにつれ、コードの再利用を可能な限り活用しようとするため、新しいコンテキストではアーキテクチャが少しぎこちなくても、1つの製品に理想的なコードアーキテクチャがほとんど変更されずに別のプロジェクトに組み込まれる可能性があります。 。これが数十年にわたって複数回発生すると、全体像が意味をなさなくなります。

企業が時代と共に変化したくないということではありませんが、コードベースはオーシャンライナーのようなものです。彼らは長い時間をかけて慎重に計画を立て直す必要があります。したがって、今日からゼロから始めても別の方法で再設計されない大きなコードベースが見つかることはほとんどありません。探すべき重要なことは、企業が正しい方向に向かっているかどうかです。

確かに人間の心が把握できる複雑さには限界があります。誰かが何百万行ものコードについて彼のやり方を知っていると期待することはできません。そのため、合理的かつ理解しやすい方法で構造化および文書化する必要があります。通常、コードを構築する機会はありません。グラフィカルユーザーインターフェイスのパッケージには、データベースクラスはありません。ただし、データベースクラスがまったく異なる（レポートなど）何かを実行している場合もあります。クラスとモジュールは、ほとんど有機的に成長する傾向があります。コードを理解しやすくするために、単一の責任を持つより多くの、より小さなクラスでコードを編成することも推奨されます。理解しやすいコードは、ソフトウェアエンジニアリングの目標を達成するための鍵です。たとえば、正確で、堅牢で、再利用可能で拡張可能なソフトウェアです。

たくさんのコードを書きたい開発者はいないでしょう。アイデアは、できるだけ多くを記述し、拡張可能な方法で記述させることです。

残念ながら、開発者はビジネス/販売/マーケティングからソフトウェア要件を収集する必要があり、通常、それらは特定のものではありません。そのため、最初の段階では何​​をするつもりでもなかったコードでパッチを適用しなければならないユースケースがあります。

あなたが人間の心を持つ方法がない限り、この状況を変える方法はありません。あなたを救うことができるのは、必須のドキュメント、強力なユニットおよび統合テストフレームワーク、バグ追跡システム、メールをアーカイブできる社内の開発者メーリングリスト、ピアレビュー、および一般的なプログラミング技術の学習です。

また、オープンソースのコンポーネントはできる限り使用することを検討してください。これらのコンポーネントには、一般的に優れたユーザーベースと中程度のレベルのドキュメントがあるためです。さらに重要なのは、技術リーダーが休暇中であるかどうかを質問する人がいることです。

大規模なソフトウェア設計関連の本も歓迎の追加です。

ブラウンフィールドアプリケーションに取り組む場合、理想的な最初のステップは、そのアプリケーションの単体テストを記述することです。

これにより、いくつかのことが実現します。

1. それはあなたにコードを通して働きそしてそれを理解することを強います
2. 単体テストは、既存の機能のドキュメントとサンプルコードとして機能します。
3. 単体テストは、リファクタリングのための安全策を提供します。

組織がこれを許可する傾向があるかどうかは、別の問題です。彼らはこの長い間、単体テストなしで生きてきました。この方法で技術的負債を削減することに同意してもらうことは難しいでしょう。