（巨大な）プロジェクトで複雑なコードを処理する方法

「なぜ（一部の）ITプロジェクトが複雑になりすぎるのか、それを回避する方法は？」についての回想録を準備しています。

複雑なコードを含むプロジェクトに遭遇したり、維持するのが困難だったりした場合、どうやってそれをやり遂げましたか？

プロジェクトで使用する複数のアプリケーションから選択する必要がある場合、それらの機能で何が最優先事項であり、その理由は何ですか？

ドキュメント、ドキュメント、ドキュメント！

私はかなり複雑なMVCコードを使用しており、信仰でそれを受け入れるのではなく、実際にそれがどのように機能するかを理解しています。理解するのが難しい変更を加えるときはいつでも、そのセクションのコードにコメントを入れて、何が起こっているのかを明確にするのに役立てます。それがなかったのでそれは私を助けなかったかもしれませんが、それは次の人を助けるでしょう。私はまた、私の周りのプログラマーに私の変更を見て、それらが明確であるかどうかを確認するように依頼することも好きです。

私の会社には、仮想サーバーの問題、一般的なクエリなど、私たちが行う多くのメタタスクを文書化するために使用する内部wikiがあります。これまで行ったことのないことを頻繁に行う必要がある場合は、その上にwikiがあるかどうかを確認します。ない場合は作ります。最近はもっとたくさんの人が関わってきたので、もっと早く成長してほしいと思います。それは私たちが持っているより平凡なタスクのコミュニケーションに本当に役立つと思います。

時間の経過とともに複雑さを完全に回避できるとは思いませんが、それを軽減する方法はいくつかあります。

• 理由の範囲内で、コードを常に可能な限りクリーンにしてください。（「ボブおじさんが「クリーン」をどのように定義するか」という意味で。）
• コードレビューやペアプログラミングを適用して、1人の開発者が不必要にエンジニアリングしすぎる可能性を低くします。
• 適切な単体テストと統合テストを維持します。
• 継続的インテグレーションサーバーに投資し、頻繁にビルドします。可能であれば、頻繁にリリースします。

これはすべて、プロジェクトが実際に必要とするものに多少依存しています。たとえば、パフォーマンスと引き換えに複雑さを受け入れることが有益な場合があります。すべての複雑なコードが必ずしも悪いことではありません。ただし、一般的には、これらのガイドラインに従うことが役立つと思います。

• 技術的負債

  除去するリファクタリング

• ビジネスの変化

  適応して消去する

• ツールの変更

  新しいツール、同じ古いアーキテクチャ=インピーダンスの不一致

また、コードはすでに複雑/不良/ハッキーなので、迅速なハックを追加する誘惑に抵抗します。私の経験では、あなたは指数関数的により複雑になるでしょう。