依存関係を他のプログラマーに非常に明白にすることを促進するプログラミングパラダイムはありますか？

私は、さまざまなアーティファクトをリンクする迷路のような依存関係を持つ多くのストリームとレイヤーを介して複数のシステムを調達するデータウェアハウスで働いています。ほぼ毎日、このような状況に陥ります。何かを実行しますが、機能しません。大量のコードを調べますが、数時間後には、今わかっていることのごく一部のプロセスマップを概念化することができました。後日必要になるので、誰かに尋ねて、この他のストリームを最初に実行する必要があることと、ここでチェックした場合（他のコード化された依存関係の巨大なスタックの一見arbitrary意的な部分を示す）、これを見た。とてもイライラします。

再帰的なレベルのコードや、さらにはデータにオブジェクトを深く埋め込むのではなく、オブジェクト間の依存関係をより明確に見えるようにするためにもっとや​​った方がいいだろうとチームに提案できた場合おそらく、よく知られ、試行され、テストされたソフトウェアパラダイムを参照することで、別のストリームが存在するために存在する必要があります。

私のチームにこの利点を説明するのはちょっと難しいです。彼らは物事をありのままに受け入れる傾向があり、システム全体を新しい方法で概念化できる利点を見るという点で「大きく考える」ことはしません。巨大なシステムをモデル化できるなら、効率的な場合、メモリの非効率性、ストリーム停止の一意の制約、重複キー、ナンセンスデータに遭遇する可能性が低くなります。元のビジョンに沿って設計する方がはるかに簡単で、後でこれらすべての問題に遭遇することはありません私たちは現在、過去の仕事では珍しいことを知っていますが、彼らは避けられないと考えているようです。

では、依存関係を強調し、理想の長期的な順守を確保するために、システムの一般的な概念モデルを促進するソフトウェアパラダイムを知っている人はいますか？現時点ではかなり混乱しており、すべてのスプリントは「こことこことここにこのものを追加するだけ」であるように見えます。

発見可能性

その不在は多くの組織を悩ませています。フレッドが再び構築したツールはどこにありますか？Gitリポジトリで確認してください。どこ？

思い浮かぶソフトウェアパターンはModel-View-ViewModelです。初心者にとって、このパターンは完全な謎です。私は妻に、「テーブルの上に浮かぶ5つのウィジェットが神秘的な力で互いに話し合っている」と説明しました。パターンを理解し、ソフトウェアを理解します。

多くのソフトウェアシステムは、アーキテクチャが自明であるか、またはコードから自然に出現すると想定しているため、アーキテクチャの文書化に失敗します。そうではなく、そうでもありません。適切に定義されたアーキテクチャを使用していない限り、新しい人々は迷子になります。文書化されていない（または有名な）場合、新しい人々は迷子になります。また、退役軍人も、数か月間コードから離れると、道に迷ってしまいます。

賢明な組織アーキテクチャを考え出し、それを文書化するのはチームの責任です。 これには次のようなものが含まれます

• フォルダー構成
• プロジェクト参照
• クラスのドキュメント（それが何であるか、何をするか、なぜ存在するか、どのように使用されるか）
• プロジェクト、モジュール、アセンブリ、あらゆるドキュメント。

チームが常に車輪を再発明しないように、物事を整理して発見できるようにするのはチームの責任です。

ところで、「コードは自己文書化する必要がある」という概念は、部分的に正しいだけです。 コードですべての行をコメントで説明する必要がないように、コードを十分に明確にする必要があるのは事実ですが、クラス、プロジェクト、アセンブリ、インターフェースなどの成果物間の関係は非自明であり、文書化する必要があります。

この種の問題に対処する最善の方法は、段階的に行うことです。欲求不満にならずに、広範囲にわたる抜本的なアーキテクチャの変更を提案してください。それらは決して承認されず、コードは改善されません。それは、あなたが行うべき、広くて広範囲にわたる正しいアーキテクチャ変更を決定することさえできると仮定しているが、これはありそうもない。

何である可能性が高いことは、あなたがちょうど解決し、特定の問題であなたを助けていた小さな変更を決定することができるということです。そうかもしれない提案するなど、不足している依存関係を警告するスクリプトを書いて、インターフェイスを作成、いくつかのドキュメントを追加し、いくつかの依存関係を反転すること代わりに小さな変更を。さらに良いことに、あなたの会社の文化に応じて、彼らはあなたが元のタスクの一部としてあなたがそのような改善をすることを容認するか、さらに期待するかもしれません。

これらの小さな変更を作業の通常の部分にし、例によって他の人にもそうするように勧めると、それらは時間の経過とともに実際に合計されます。許可されていない単一の大きな変更について泣き言を言うよりもはるかに効果的です。

建築。

すべてのソフトウェアのすべての側面に適用される発見可能性と保守性の問題を解決する、単一の、具体的な、普遍的な原則または慣行はありません。しかし、のための広範な用語プロジェクト正気を作るものがあるアーキテクチャ。

アーキテクチャは、潜在的な（または歴史的な）混乱の各ポイントに関する決定の集合体です-アーキテクチャの決定が行われ、文書化される方法の指定を含みます。など、開発プロセス、フォルダ構造、コードの品質、デザインパターン、およびに関するすべてが行くかもしれないすべてのものですにあなたのアーキテクチャではなく、そのうちの一つは、あるアーキテクチャ。

理想的には、これらのルールは心の特異性によって統一されています。

小規模なチームでも確かに共同でアーキテクチャを作成できます。しかし、意見が異なると、これはすぐにあなたの正気を維持するのに役立たない非常に統合失調症の建築につながる可能性があります。アーキテクチャ、およびその中の多くのTLAとパターンがすべて、単一の心でチームの成功に役立つことを保証する最も簡単な方法は、単一の心に責任を持たせることです。

さて、それは必ずしもに「建築家」を必要としない司教職を。また、一部のチームは経験豊富な人にこれらの決定を下してもらいたいと思うかもしれませんが、主なポイントは、特にチームが成長するにつれて、誰かがアーキテクチャを所有する必要があることです。誰かがチームの脈動を把握し、アーキテクチャの議論を調整し、意思決定を文書化し、意思決定を監視し、アーキテクチャとその精神に準拠するために前進します。

私はすべての決定を下す一人の大ファンではありません。しかし、アーキテクチャの議論を調整し、決定を文書化する責任を負う「アーキテクト」または「技術製品の所有者」を特定することは、より大きな悪と戦う：認識できるアーキテクチャをもたらさない責任の拡散。

（両方の意味で）ソフトウェアエンジニアリングへようこそ;）これは良い質問ですが、実際には簡単な答えはありません。これは、時間をかけてより良いプラクティスに進化し、より熟練するように人々を訓練するというケースです（定義により、業界のほとんどの人々は平凡な能力です）。

専門分野としてのソフトウェアエンジニアリングは、最初に構築し、私たちのようにメンタリティを設計することに苦しみます。それはただ獣の性質です。そしてもちろん、前述のコーダーが技術的な負債を導入することを犠牲にして短期的なニーズを解決する機能的なソリューションを迅速に導入するにつれて、ハックは時間の経過とともにハックに基づいて構築されます。

使用する必要があるパラダイムは、基本的にはより良い人材を獲得し、有能な人材を訓練し、計画とアーキテクチャに時間をかけることの重要性を強調することです。モノリシックシステムで作業するとき、その「アジャイル」を簡単に実現することはできません。小さな変更であっても、導入するにはかなりの計画が必要です。優れた高レベルの文書化プロセスを導入することは、主要な人々がコードをより迅速に把握するのにも役立ちます。

あなたが焦点を当てることができるアイデアは、システムの重要な部分を分離し、リファクタリングして、徐々にモジュール化し、分離し、読みやすく、保守しやすくする方法です。これは、既存のビジネス要件を満たすための秘trickです。したがって、目に見えるビジネス価値を提供すると同時に、技術的負債の削減を行うことができます。そのため、ソリューションは、実践とスキルを改善することと、長期的なアーキテクチャー思考に向かっていくことの一部です。

本当にこれはコーディングの詳細やアーキテクチャスタイルよりもはるかに大きな問題であるため、コーディング技術の観点ではなくソフトウェア開発方法論の観点からこの質問に答えていることに注意してください。それは本当にあなたがどのように変化を計画しているかという問題です。

@RobertHarveyの規約の考え方が好きで、それが役立つと思います。また、@ KarlBielefeldtのアイデア「好きなようにドキュメントを作成する」も気に入っています。それがドキュメントを最新の状態に保つ唯一の方法だからです。しかし、包括的な考え方は、コードのすべての部分を見つけ、それらを構築し、デプロイする方法を文書化することが重要だと思います！

私は最近、完全に文書化されていないコードを生成するXML構成が含まれていた重要なオープンソースプロジェクトにメールを送りました。メンテナーに、「このXMLコード生成プロセスはどこに文書化されていますか？テストデータベースのセットアップはどこに文書化されていますか？」と尋ねました。彼は言った、「そうではない」。それは基本的に単一の貢献者プロジェクトであり、今ではその理由がわかっています。

あなたがその人で、あなたがこれを読んでいるなら、あなたがやっていることに本当に感謝しています。私は実質的にあなたの労働の成果を崇拝します！しかし、あなたの本当に創造的なものがどのようにまとめられるかを文書化するのに1時間を費やしたなら、私はあなたを助けることができる新しい機能をコーディングするのに2、3日費やすかもしれません。「ドキュメンテーションの不足は問題ではない」というレンガの壁に直面したとき、私も試してみるつもりはありません。

ビジネスでは、ドキュメントの欠如は時間とエネルギーの大きな浪費です。そのようなプロジェクトは、多くの場合、「すべての部品はどこにあり、どのように組み合わせるのか」などの基本的なことを理解できるように、さらに費用のかかるコンサルタントに蓄えられます。

結論として

必要なのは、テクノロジーや方法論ではなく、文化の変化です。物事がどのように構築され、なぜ重要であるかを文書化するという共通の信念。これは、プロダクションに移行するための要件であるコードレビューの一部である必要があります。誰もがそれを信じて行動すると、状況は変わります。そうでなければ、それは私の失敗したオープンソースの貢献のようになるでしょう。

（特定の状況についてアドバイスするのではなく）提起された質問に答えるには：

純粋な関数型プログラミングとして知られるプログラミングパラダイムでは、関数の出力に影響するすべてのものを入力パラメーターで指定する必要があります。隠された依存関係やグローバル変数、またはコードベース全体に目に見えないように作用するその他の不可解な力はありません。「これを最初に行う必要がある」一時的な結合はありません。

各データウェアハウスは異なりますが、自分で物事を簡単にするためにできることはたくさんあります。

まず、データベースのすべての行にはDATE_ADDED列とDATA_UPDATED列があり、データベースに追加された時刻と変更された時刻を確認できました。また、SOURCE_CODE列があるため、データのすべてのビットがシステムに入った場所を追跡できます。

次に、並べ替え、テーブルマッチ、スライサー、ダイサーなど、すべてのデータウェアハウスで実行される共通ツールがありました。

オーダーメイドのコードは最小限に抑えられていましたが、それでもさまざまなコーディングとレポートのスタイルを確認する必要がありました。

あなたはすでにETLスイートに精通していると仮定します。最近では無料で入手できる機能がたくさんありますが、それは私が10年ほど前にゲームに参加していたときにはなかったものです。

また、データマートを調べて、より使いやすく、データウェアハウスのサニタイズされたバージョンを提示することもできます。もちろん特効薬ではありませんが、データウェアハウスを再構築/修正する必要はなく、特定の問題を解決できます。

あなたのケースにどれほど関連があるのか​​わかりません。依存関係をより目立たせるための戦略と、コードの一般的なメンテナンスがあります。

• グローバル変数を避け、代わりにパラメーターを使用します。これは、言語間の呼び出しにも適用されます。
• 変数の値の変更/変更はできる限り避けてください。可能であれば、値を変更する必要がある場合は、新しい変数を作成して使用します。
• コードをモジュール化します。部分が実際に何を（どのようにではなく）行っているかを簡単な文で説明できない場合は、条件を満たすモジュールに分割します。
• コード部分に適切な名前を付けます。コードの一部が実行していることを簡単な用語で実際に説明できる場合、それらの用語はその部分の名前になります。したがって、コードは、モジュール/クラス/関数/プロシージャ/メソッドなどの名前を通じて自己文書化されます。
• コードをテストします。前のポイントで説明したように、コード内のエンティティが名前を正当化するかどうかをテストします。
• コードにイベントを記録します。少なくとも2レベルのログを維持します。最初のものは（実稼働環境でも）常に有効であり、重要なイベントのみを記録します。そして、基本的にすべてを記録するために他を使用しますが、オンまたはオフにすることができます。
• 適切なツールを見つけて使用し、コードベースを参照、保守、開発します。Visual Studio Codeのシンプルな「すべてを検索」オプションでさえ、特定のケースで私の生活をずっと楽にしました。