私はGoto2018のModular MonolithsでSimon Brownのこの素晴らしい講演を見ていました。
この中で彼はCargo Cult Programmingと呼ばれる用語に言及しており、それは本当に私と一緒に和音を打った。
私は最近、新しいプログラミング言語、新しいツール、新しいプロセス、新しいチームを持つ新しい会社に入社しました。 実際には、それはかなり”新しい”すべてです。
これは私にここ数カ月の間に多くの学習をさせてくれました。 比較的経験豊富なので、私は新しいことを学ぶときに”hows”ではなく”whys”を調べるのが好きです。 私が気づいたのは、これが最も一般的なアプローチではないということです。
ユーザーが既存のコードベースに追加し、現在のソリューションを拡張することを任されているとき、彼らはおそらくこれが以前にどのように行われたかを 彼らはそれが以前にどのように行われたかのように、このパターンに盲目的に従うかもしれません。 追加のブロックは、それが行うには正しいことだかどうかを疑問視することなく、塔の上に追加されます。 誰もがこれを行う場合、これは最終的に起こります。
これは”貨物カルトプログラミング”という用語がどこから来ているのかです。
Wikipediaは次のように説明しています:
カーゴカルトプログラミング（Cargo cult programming）は、実際の目的を果たさないコードやプログラム構造を儀式的に包含することを特徴とするコンピュータプログラミングのスタイルである。 Cargo cultプログラミングは、通常、プログラマが解決しようとしていたバグや明らかな解決策のいずれかを理解していないことを示しています（shotgunデバッグ、deep magicを比較してください）。 貨物カルトプログラマという用語は、未熟なまたは初心者のコンピュータプログラマ（または手元の問題に経験の浅い人）が、それがどのように動作するか、
Cargo cult programmingは、その設計原理の背後にある理由を理解せずに、設計パターンやコーディングスタイルを盲目的に適用する実践を参照することもできます。 例としては、自明なコードに不要なコメントを追加したり、特定のプログラミングパラダイムの規則を過度に遵守したり、ガベージコレクションが自動的に収集したオブジェクトの削除コードを追加したりすることがあります。
障害の原因となっているコードを見つけて、バグに取り組んでいるシナリオを想像してみてください。 あなたは大規模に何が起こっているかわからないので、あなた;
- あなたはStackOverflowの質問を見つけます。
- 最もupticked答えを検索します。
- ソリューションをコピーしてコードに貼り付けます。
- デバッグして、問題が修正されているかどうかを確認してください。
ありますので、チェックインして移動してください。
おなじみの音？
なぜそれをするのですか？ なぜ私たちは盲目的にこのスニペットを取り、私たちの実装でそのまま使用するのですか？
ユースケースはおそらく同じではないので、解決策があった場合、私は驚かれるでしょう。 簡単な例はさておき、解決策の背後にある推論を理解することは、解決策自体よりも重要です。 あなたが理解していない何かであなたができないことがたくさんあります。 変更、改善、またはテストすることはできません。 あなたはそれを文書化することはできませんし、あなたはそれを所有することはできません。
私たちは皆、新しいものを愛しており、経営陣は特に人気のある傾向に従うことを好み、技術の進歩に追いついているようです。
ほとんどのチームはアジャイルアプローチに従います。 TDDと自動テストは、特定のシナリオで非常に有用であり、継続的な統合は、インフラストラクチャチームからのオーバーヘッドの多くを削除し、ビッグデータとAIは、ユーザーの満足度とコンテナ化を大幅に向上させることができ、最近ではマイクロサービスは、古いモノリスアーキテクチャをより小さな自己完結型サービスにシフトさせることができます。
これらの進歩はそれぞれ素晴らしいものであり、私はそれらのいずれかを容認しません。 私の苦境は、それらのすべてをすべてのプロセスとコードに採用する必要があるかどうかです。 Netflix、Facebook、Twitterからのブログ投稿が、その使用がどのように機能するかを示しています。 大企業が必要と判断した場合、私たちもそうすべきではありませんか？ これは、貨物カルトプログラミングが再びその醜い頭を育てる場所です。
私たちは、現在の設計の問題、なぜ起こったのか、そして将来どのように捨てられるのかを理解する必要があります。 はい、これらの新しいプロセスは私たちの問題で私たちを助けるかもしれませんが、盲目的に彼らが行うかすかな希望でそれらに従うことは、前進の道ではなく、論理的な意味もありません。
私は、多くの企業が移行を行っているように見えるように、マイクロサービスに特に言及しています。:
- 開発時間の短縮
- 高いスケーラビリティ
- 簡単に拡張
- 展開の容易さ
- 技術を自由に選択できる自律チーム
そのようなリストで、何を考え のは、すべての時流にジャンプしてみましょう！
ちょっと待って…このアプローチに欠点はありますか？
- アーキテクチャの複雑さ
モノリシックアーキテクチャでは、複雑さと依存関係の数はコードベース内に存在し、マイクロサービスアーキテクチャでは複雑さは特定のドメインを実装する個々のサービスの相互作用に移動します
- 運用の複雑さ
- スケーラブルでコスト効率の高い方法でリソースをプロビジョニングする方法
- 努力を掛けずに数十または数百のマイクロサービスコンポーネントを効果的に操作する方法
- 標準の欠如と異種に対処する方法 異なる技術と異なるスキルセットを持つ人々を含む環境
- バージョニングに対処する方法
- システム全体の相互作用を追跡およびデバッグする方法
- コードデプロイメントの何百ものパイプラインとそれらの相互依存性を追跡する方法
これらは、Amazon自身の”マイクロサービスの挑戦”ホワイトペーパーから取り除かれている。 今私はあなたについて知りませんが、欠点は利点よりも私にはずっと恐ろしいように見えます。 もう一度、私はこれが下がるための正しいアプローチではないと言っているわけではありませんが、これらの利点が欠点を上回る場合を除き、このアプ
“公共”問題。
それは本当に簡単です、Publicキーワードの使用を停止し、自動的にPublicクラスの作成を停止します。 なぜ我々はそれを行うのですか？
publicキーワードを使用する際の問題は、カプセル化に関連する利点を逃していることです。 なぜ私たちはそれをそんなに使うのですか？ これは、クラスを作成するときに使用するデフォルトの単語であり、すべての例ではパブリッククラスを使用し、ウィザードとスニペットではパブリッククラスを実装します。 それは停止する時間です。 どのように多くの人々が公共のFacebookのアカウントを持っていますか？ この世界のほとんどのものは、私たちのクラスがあるべきように、プライベートです。 デフォルトでは非公開にし、公開する必要がある場合は変更してください。
素晴らしい経験を持つことは大きな不安をもたらします。
あなたがフィールドにいる時間が長くなればなるほど、新しいツールやプロセスがもたらす改善を認識することはあまり素朴ではありません。 今日の考えのほとんどは最終的に包含されている分野に十年の古い研究から来る。 何かが大量採用を得たら、それを完全に受け入れることで快適に感じる方が簡単です。 それが正しいことであれば、です。
“良い判断は経験から来て、経験は悪い判断から来る”
-Rita Mae Brown
だから、あなたの問題に対する解決策やチュートリアルのためにinterwebsを精練し続けること自由に 単にどのようにするのではなく、なぜ彼らが働くのかに注意してください。 私達はすべて私達の自身の経験および間違いから学ぶ、従って基礎を理解することは同じ道の下で将来続くことからの保つ。