他のプログラマーに依存関係を非常に明白にすることを促進するプログラミングパラダイムはありますか？
私は、さまざまなアーティファクトをリンクする迷路のような依存関係を持つ多数のストリームとレイヤーを介して複数のシステムを調達するデータウェアハウスで作業しています。ほとんど毎日、次のような状況に遭遇します：何かを実行しますが、機能しません。コードのロードを実行しますが、数時間後、今わかっていることのごく一部のプロセスマップを概念化できたことに気付きましたその日の後半が必要なので、誰かに尋ねると、この他のストリームを最初に実行する必要があること、そして私がチェックした場合here（他のコード化された巨大なスタックの見かけ上任意の部分を示している）依存関係）、それから私はこれを見たでしょう。それは信じられないほどイライラさせられます。
再帰的なレベルのコードやデータにオブジェクトを深く埋め込むのではなく、オブジェクト間の依存関係をよりはっきりとわかりやすくするために、もっと多くのことをするほうがいいとチームに提案できたとしたら別のストリームが存在するため、存在する必要があります。よく知られ、試行錯誤されたソフトウェアパラダイムを参照することにより、自分の仕事を他の人よりもはるかに簡単にできる可能性があります。
これの利点を私のチームに説明するのはちょっと難しいです。彼らは現状をそのまま受け入れる傾向があり、システム全体を新しい方法で概念化できることの利点を見ると「大きく考える」ことはありません。巨大なシステムをモデル化できるかどうかは実際にはわかりません。効率的にすると、メモリの非効率性、一意の制約のストリーム停止、重複キー、無意味なデータに遭遇する可能性が低くなります。これは、元のビジョンに沿って設計する方がはるかに簡単であり、後でこれらすべての問題に遭遇しないためです。私たちが今経験していることは、過去の仕事では珍しいことですが、彼らは避けられないと考えているようです。
それで、誰かが依存関係を強調し、理想の長期的遵守を保証する目的でシステムの共通概念モデルを促進するソフトウェアパラダイムを知っていますか？現時点では、大きな混乱があり、すべてのスプリントの解決策は「こことこことここに追加するだけ」のようで、本当にバラバラになり始めていることを心配しているのは私だけです。
発見可能性
その欠如は多くの組織を悩ませています。フレッドが再構築したそのツールはどこにありますか？ Gitリポジトリでは、確かに。どこ？
頭に浮かぶソフトウェアパターンは、Model-View-ViewModelです。初心者にとって、このパターンは完全な謎です。私はそれを妻に「テーブルの上に浮かぶ5つのウィジェットが不思議な力で互いに話し合っている」と説明しました。パターンを理解すれば、ソフトウェアを理解できます。
多くのソフトウェアシステムは、それが自明であるか、またはコードから自然に浮かび上がると想定しているため、アーキテクチャを文書化できません。そうではありませんし、そうでもありません。明確に定義されたアーキテクチャを使用していない限り、新しい人は迷子になります。文書化されていない（またはよく知られている）場合、新しい人々は迷子になります。また、退役軍人も、コードから数か月離れていると、迷子になります。
賢明な組織アーキテクチャを考え出してそれを文書化するのはチームの責任です。これには以下のようなものが含まれます
- フォルダ構成
- プロジェクト参照
- クラス文書（それが何であるか、何をするか、なぜ存在するか、どのように使用されるか）
- プロジェクト、モジュール、アセンブリ、あらゆるドキュメント。
チームが常に車輪を再発明しないように、物事を整理して発見可能にすることはチームの責任です。
ちなみに、「コードは自己文書化する必要がある」という概念は部分的にしか正しくありません。コードは十分明確であるべきですが、すべてのコード行をコメントで説明する必要はありません。クラス、プロジェクト、アセンブリ、インターフェースなどのアーティファクト間の関係は明白ではなく、文書化する必要があります。
この種の問題に取り組む最善の方法は、段階的に行うことです。イライラしないで、広範囲にわたるアーキテクチャの変更を提案してください。それらは決して承認されることはなく、コードは決して改善されません。それはあなたが正しい広い、広範囲にわたるアーキテクチャの変更を行うことさえ決定できると仮定している、それはありそうもない。
はである可能性が高いのは、解決したばかりの特定の問題を解決するのに役立つ小さな変更を特定できる可能性があることです。たぶん、いくつかの依存関係を逆にし、いくつかのドキュメントを追加し、インターフェースを作成し、欠落している依存関係を警告するスクリプトを書くなどします。そのため、代わりにthatの小さな変更を提案します。さらに良いのは、会社の文化によっては、元のタスクの一部としてそのような改善を許容するか、期待することさえあります。
これらの小さな変更をあなたの仕事の通常の部分に加え、あなたの例では他の人にもそうするように勧めるとき、それらは本当に時間の経過とともに増加します。許可されていない1つの大きな変更を愚痴るよりもはるかに効果的です。
私は@RobertHarveyの規則の考え方が好きで、それが役立つと思います。また、@ KarlBielefeldtの「あなたが進むにつれて文書化する」というアイデアも気に入っています。それが文書を最新に保つ唯一の方法であるため、それが不可欠であることを知っています。しかし、私は包括的な考え方は、コードのすべての部分を見つけ、ビルドしてデプロイする方法を文書化することが重要だと思います！
私は最近、コードを生成するXML構成がまったく文書化されていない重要なオープンソースプロジェクトにメールを送りました。私はメンテナに尋ねました、「このXMLコード生成プロセスはどこに文書化されていますか？テストデータベースのセットアップはどこに文書化されていますか？」 「そうではない」と彼は言った。これは基本的に単一の寄稿者によるプロジェクトであり、今はその理由を知っています。
あなたがその人であり、あなたがこれを読んでいるなら、私はあなたがしていることを本当に感謝しています。私はあなたの労働の成果を実際に崇拝します！しかし、本当にクリエイティブなものがどのようにまとめられているかを1時間かけて文書化した場合、私は数日かけて、役立つ可能性のある新機能のコーディングに費やすかもしれません。 「ドキュメントの不足は問題ではない」というレンガの壁に直面したとき、私は試すつもりもありません。
ビジネスでは、ドキュメントの欠如は時間とエネルギーの大きな浪費です。そのようなプロジェクトは、「すべての要素がどこにあり、どのように組み合わされているのか」などの基本的なことを理解できるようにするために、さらにコストのかかるコンサルタントによく提供されます。
結論として
必要なのは、技術や方法論ではなく、文化の転換です。物事がどのように構築され、なぜ重要であるかを文書化するという共通の信念。これは、昇給に関連するコードレビューの一部であり、本番環境に移行するための要件です。誰もがそれを信じて行動すると、状況は変わります。そうでなければ、それは私の失敗したオープンソース貢献のようになるでしょう。
（特定の状況についてアドバイスを与えるのではなく）提示された質問に答えるには：
純粋な関数型プログラミングとして知られるプログラミングパラダイムでは、関数の出力に影響するすべてのものを入力パラメーターで指定する必要があります。隠された依存関係、グローバル変数、またはコードベース全体で目に見えない形で機能するその他の不可解な力はありません。 「最初にこれを実行する必要があります」時間的結合はありません。
ソフトウェアエンジニアリングへようこそ（両方の意味で）;）これは良い質問ですが、確かに簡単な答えはありません。それは実際、時間の経過とともにより良い実践へと進化し、人々をより熟練するように訓練するケースです（定義上、業界のほとんどの人々は平凡な能力です）...
分野としてのソフトウェアエンジニアリングは、最初にそれを構築し、一部は便宜性から、一部は必要性から、そのままでのメンタリティを設計することに悩まされています。それはまさに獣の性質です。そしてもちろん、ハックは時間の経過とともにハックの上に構築されます。前述のコーダーは、短期的なニーズを解決する機能的なソリューションを迅速に導入して、技術的負債をもたらすことを犠牲にしています。
使用する必要があるパラダイムは、基本的にはより優れた人材を獲得し、有能な人材を育成し、計画とアーキテクチャに時間をかけることの重要性を強調することです。モノリシックシステムで作業する場合、その「アジャイル」は簡単にはできません。小さな変更でも導入するにはかなりの計画が必要です。優れた高レベルのドキュメント作成プロセスを実施することで、主要な人々がコードをより早く理解できるようになります。
焦点を当てることができるアイデアは、システムの主要部分を（徐々に）徐々に分離してリファクタリングし、モジュール化して分離し、読みやすく、保守しやすくすることです。トリックは、これを既存のビジネス要件に合わせて機能させることです。そのため、目に見えるビジネス価値の提供と同時に、技術的負債の削減を行うことができます。ですから、解決策は、実践とスキルを改善することと、すでにお伝えしているように、長期的な建築的思考へと移行することです。
この質問には、コーディング手法の観点ではなく、ソフトウェア開発の方法論の観点から回答していることに注意してください。これは、コーディングの詳細やアーキテクチャスタイルよりもはるかに大きな問題であるためです。それは本当に変化をどのように計画するかという問題です。
データウェアハウスはそれぞれ異なりますが、自分で簡単にできることはたくさんあります。
まず、データベースのすべての行にDATE_ADDEDおよびDATA_UPDATED列があったため、データベースにいつ追加されたかを確認できます。それが変更されたとき。 SOURCE_CODE列もあり、データのすべてのビットがシステムに入力された場所を追跡できます。
次に、ソート、テーブルマッチ、スライサー、ダイサーなど、すべてのデータウェアハウスに共通のツールがありました。
オーダーメイドのコードは最小限に抑えられ、それでも、さまざまなコーディングとレポートのスタイルを確認する必要がありました。
[〜＃〜] etl [〜＃〜] スイートについては、すでにご存知だと思います。私が10年ほど前にゲームにいたときに存在しなかった、最近無料で入手できる多くの機能があります。
また、データウェアハウスのよりフレンドリーでサニタイズされたバージョンを表示するために、 データマート を確認することもできます。もちろん特効薬ではありませんが、データウェアハウスを再構築/修正する必要はなく、特定の問題を解決するのに役立ちます。
私はそれがあなたのケースにどれだけ関連しているかはわかりません、依存関係をより見やすくするためのいくつかの戦略とコードの一般的なメンテナンスがあります-
- グローバル変数を避け、代わりにパラメーターを使用してください。これは、クロスランゲージコールにも適用されます。
- 可能な限り、変数の値を変更または変更しないでください。新しい変数を作成し、可能であれば値を変更する必要があるときに使用します。
- コードをモジュール化します。 what（not not how）の部分を実際に簡単な文で記述できない場合は、条件を満たすモジュールに分割してください。
- コード部分に適切な名前を付けます。コードの一部が何をしているかを実際に簡単に説明できる場合、それらの用語がその部分の名前になります。したがって、コードは、モジュール/クラス/関数/プロシージャ/メソッドなどの名前によって自己文書化されます。
- コードをテストします。前のポイントで説明したように、コード内のエンティティが名前を正当化するかどうかをテストします。
- コードにイベントを記録します。少なくとも2つのレベルのログを維持します。最初のものは常に有効になっており（本番環境でも）、重要なイベントのみを記録します。そして、もう一方を使用して基本的にすべてをログに記録しますが、オンまたはオフにすることができます。
- コードベースを閲覧、保守、開発するための適切なツールを見つけて使用します。 Visual Studio Codeの単純な[すべてを検索]オプションを使用しても、特定のケースでの生活がずっと簡単になりました。