誇大広告駆動開発

ソフトウェア開発チームは、ソーシャルネットワークからの誤った意見や、よく研究されているよりもファッショナブルなものすべてに基づいて、プロジェクトに対する潜在的な影響を真剣に評価することなく、ソフトウェアアーキテクチャまたはテクノロジースタックについて決定することがよくあります。 私はこの傾向を「Hype Driven Development（HDD）」と呼び、それを有害であると考え、より専門的なアプローチを提唱します。 物事がどのようであり、私たちが何に反対できるかを見てみましょう。

新技術-新しい希望

そのような人に会ったことがありますか？ チームは、プロジェクトで使用する最新の最新テクノロジーを選択します。 ブログの投稿やTwitterのトレンドを読んでいる人もいれば、すばらしいことを言ったカンファレンスから来た人もいます。 そして今、チームはこの素晴らしい技術（またはソフトウェアアーキテクチャの新しいパラダイム）を使用していますが、約束された優れた速度と高品質の製品の代わりに、彼らはトラブルに巻き込まれます。 作業のペースが遅くなり、モチベーションが消え、作業バージョンのリリースで問題が発生します。 一部のチームは、新しい機能を追加する代わりに、バグ修正フェーズで立ち往生しています。 「すべてをクリーンアップするのにさらに数日」が必要です。

出版物のサポートはエジソンによって提供されます。 エジソンは 、 地理的特徴を追跡するためのSDK と、家具のホームチェーンのオンラインアカウンティングシステムを開発しています 。

誇大広告駆動開発

この誇大広告のソースは異なる場合があります。

• Reddit主導の開発 -有名なブロガーまたはreddit、hackernews、twitterブログ、Facebook、GitHubなどのサイトで公開されている資料による声明。
• 会議主導型の開発 -実際には両刃の剣である会議に参加した後のインスピレーション：最新の最新のライブラリ/インターフェイス/テクノロジーを使用することなく、それらを扱う経験は地獄にかかる可能性があります。
• 最強の男主導の決定 -新製品について話せずにはいられず、結局はチームにそれを使用する必要性を納得させる男の大声でのおしゃべり。
• Gem / lib /プラグイン駆動開発 -Ruby On Railsコミュニティの一部として、問題を修正するためにダウンロードした新しいgemが表示されますが、数行のコードを書くだけで問題を簡単に解決できます。 しかし、いや、ライブラリ、プラグイン、gemなどを追加した方が良いでしょう。 ...;
• Stack Overflowによる開発 -Stackoverflowリソース（またはインターネット）からのプログラマーによるソリューションの軽率なコピーの乱用についても言及する価値があります。

HDD-プログラマーが自分で作る文

問題は、影響を受けた状態で、悪い決断が下されることです。 その結果、開発チームは数か月間、さらには何年も苦しむことができます。 最悪の場合、それらはTotal Editionにつながります。 これはほとんど成功しません。

悪の根源は、アイデアをテストする時間よりも速く、人々がそのメリットとデメリットを理解する時間をとるよりも早く広めるメディアです。

誇大広告の解剖学

ほとんどのhyipは同様の構造を持っています。

ステップ1：実際の問題と解決策

一部の会社は問題に直面しています。 ソリューションを担当するチームは、現在のアーキテクチャまたは技術プロセスのフレームワーク内で問題を排除することは不可能であると判断します。 同社は新しいフレームワーク、ライブラリ、またはパラダイムを作成していますが、すぐに問題は終わりました。

ステップ2：発表、大騒ぎ、キーワード

チームは自分の作品を全世界に公開する機会を楽しみに待っており、現在は会議ですでにブログと講演を行っています。 多くの場合、解決された問題は自明ではないので、彼らは見つけた自明でない解決策を説明することに誇りを感じています。 聴衆は新しい技術について学ぶことを喜んでいます。 しかし、聴衆の賞賛は、すべてのメンバーが問題が何であったかを完全に理解している、または解決策の詳細に触れないことを意味するものではありません。

結局のところ、それはまだ非標準のソリューションを備えた非標準のタスクでした。 また、明確にするために、ツイート、チャット内の数行、またはブログ投稿さえ必要です。 現代のメディアでは、メッセージの本質は、広がるにつれて簡単にぼやけてぼやけることがあります。

ステップ3：狂気の始まり

ニュースがブログや会議を経てまもなく、世界中の開発者が新しい技術に精通し始めます。 そして、情報の曖昧さのために、現在の問題を解決できない場合でも、記載されている技術を使用することを急いで決定します。 しかし、彼らは彼女を信じています。

ステップ4：失望

必死の努力にもかかわらず、このテクノロジーは人々の生活を楽にするものではありませんが、逆に多くの追加の心配をもたらします-大量の書き直されたコードとそれを研究するために費やされた時間。 チームの仕事は遅くなり、管理は非常に不満です。 人々はcheされたと感じます。

ステップ5：実装！

最後に、開発チームは過去を振り返り、テクノロジーの目的を認識しており、その場合に最適です。 彼らは次のような誇大宣伝まで...賢くなってきています。

誇大広告の例：

例1：React.js

• ステップ1 ：問題はFacebookにあります-アプリケーションは大量の情報でハングします。
• ステップ2 ：Facebookは、機能、仮想DOM、コンポーネントという流行語を使用した新しいパラダイムを発表します。
• ステップ3 ：マニア。 Facebookは未来の外部インターフェイスを作成しました！ コメントをもっと早く書きましょう！
• ステップ4 ：待ってください。多くの作業がありますが、投資に対する迅速なリターンは期待できません。
• ステップ5 ：このソリューションは、多数のリアルタイム通知を備えた高度な単一ページアプリケーション用に見つかりましたが、必ずしも単純なアプリケーションには適していません。

例2：DHHによりTDDが停止している

• ステップ1 ：Ruby on Railsフレームワークの作成者であるDavid Heinemeier Hansson（DHH）は、テスト（Test-Driven Development、TDD）による開発とRailsを組み合わせることは難しいと発表しています。 後者には、適切なオブジェクト指向プログラミングをサポートするアーキテクチャがありません。 そして彼は実用的な選択をします-事前にテストを書くのではありません。
• ステップ2 ：ヒステリーは、Hensonのブログ投稿と会議スピーチから始まります。 タグ：TDD DEAD。
• ステップ3 ：テストをスキップしましょう！ 私たちの第一人者はそう言った。 まだ書きませんでした。 今、私たちはふりをしません。 最後に、偽善とダウン。
• ステップ4 ：待って！ 以前よりもさらに少ないものが機能しています。 不器用なコードを作成しました。
• ステップ5 ：「TDDは死んでも生きていません。 TDDは、アプリケーションのソフトウェアインターフェイス、アーティストスキル、および既存のデザインを変更するリスクを含む譲歩です。」-ケントベック

例3：マイクロサービス

• ステップ1 ：大規模なモノリシックアプリケーションのスケーラビリティを評価することは困難です。 特定の段階で、いくつかのサービスに分割できます。 したがって、クエリ/秒の比率を簡単に判断できます。
• ステップ2 ：誇大宣伝キーワード：スケーラビリティ、弱い接続性、モノリス。
• ステップ3 ：すべてを書き直して、サービスに分割しましょう！ 「スパゲッティコード」があるのは、 モノリシックアーキテクチャがあります！ すべてをマイクロサービスにペイントする必要があります！
• ステップ4 ：くそー​​！ 現在、アプリケーションの開発は非常に遅く、インストールが非常に困難であり、さまざまなシステム間でエラーの検索に多くの時間が費やされています！
• ステップ5 ：マイクロサービスには、開発と情報および技術サービスの両方の分野で高いスキルが必要であり、適切な投資により、最終的にはスケーラブルになります。 しかし、一定の制限に達する前に、それは過剰な投資になります。 マイクロサービスは書き込まれずに取得されます。 マイクロサービスを使用するには、これほど背が高くなければなりません。

例4：NoSQL

• ステップ1 ：SQLデータベースには、多数のダウンロードと非構造化データに関する問題があります。 世界中のチームが新世代のデータベースの開発を始めています。
• ステップ2 ：誇大宣伝キーワード：スケーラビリティ、BigData、高性能。
• ステップ3 ：データベースが遅すぎて十分な大きさではありません！ NoSQLが必要です！
• ステップ4 ：テーブルを結合する必要がありますか？ それはしません。 単純なSQL操作は複雑になります。 開発は遅く、重要な問題は解決されていません。
• ステップ5 ：NoSQLツールは、特定の問題（大量のデータ、非構造化データ、大量のダウンロード）を解決するように設計されています。 SQLは実際には優れたツールであり、巧妙に使用されていれば、大量のダウンロードと大量のデータを処理できます。 2016年のNoSQLに適した状況はあまりありません。

例5：ElixirとPhoenix（または他のお気に入りの言語/インターフェイスのペア）

• ステップ1 ：Ruby On Railなどのネットワークフレームワークは、実際には高性能アプリケーション、分散アプリケーション、またはWebソケット用に設計されていません。
• ステップ2 ：誇大宣伝キーワード：スケーラビリティ、高性能、分散、フォールトトレラント。
• ステップ3 ：なんてこった、私たちのアプリケーションは遅く、チャットはスケーラブルではありません！
• ステップ4 ：すごい、関数型プログラミングや分散アプローチを学ぶのはそれほど簡単ではありません。 私たちは今非常にゆっくり動いています。
• ステップ5 ：エリクサーとフェニックスはうまく機能しましたが、それらに慣れるには多くの努力が必要です。 優れたパフォーマンスを備えたアプリケーションが必要な場合、長期的に見れば見返りが得られます。

例のリストは無限です。

私たちのコンピューター開発者の密集したサークルには、誇大広告が一般的なものである多くの領域があります。 JavaScriptの世界では、Node.js（キーワード：イベント指向プログラミング）、リアクティブプログラミング、Meteor.js（キーワード：共有状態）、フロントエンドMVC、React.jsという新しいフレームワークが毎日登場しています。 自分で例を挙げてください。 ソフトウェア開発の分野では、新しいアーキテクチャが登場します：プロジェクト駆動開発（ドメイン駆動開発）、DCIヘキサゴン。 どんな誇大広告が好きでしたか？

公正な実践

インターネットや他の人の意見に頼ることができない場合、どうすれば賢明な決定を下すことができますか？ 実用的なヒントをいくつか紹介します。

決定を下す前のテストと調査

• 自分のテクノロジーを自分で調べて、ブログで読んではいけません。 最終的な選択を行う前に、1〜2日かけて新しいテクノロジーのプロトタイプを作成してください。 チームにすべての長所と短所を分析させてください。 または、いくつかの競合技術のみを使用し、残りはプログラマーによってテストされます。
• ハッカソンをお楽しみください。これは、新しいテクノロジーを導入する際にチームを気遣うのに最適な方法です。 1〜2日間新しい技術を使用してもらい、最も有望なものを選択します。 彼らの決定はよりバランスが取れているでしょう、なぜなら 自分の経験に基づいています。

いつですか？

• 原則として、投資収益率が重要な場合。 ほとんどのテクノロジーは、特定の問題を解決するように設計されています。 この問題はありますか？ このソリューションは時間を節約しますか？ テクノロジーの使用は、その実装と関連する困難に関する作業に対価を支払うのですか？ 作業が最終的に半分に遅くなったらどうなりますか？ または4時？ まだ価値がありますか？
• 優れたプログラマーのチームはより多く許可されます-一部のチームは、他のチームが利益をもたらし始めているよりも高速です。 彼らは簡単なものを扱うことに飽きてしまいます。 これらのチームは、より頻繁に新しいテクノロジーを導入できます。 これは、ハッカソンを使用せず、新しい提案を真剣に分析しないという言い訳ではありません。 一方、チームが作業に問題がある場合は、新しいテクノロジーに注意してください。

適切な人を雇う：

• 真剣な技術トレーニングはあなたの友達です。 さまざまなパラダイムに精通している人は、プログラミングの理論（アルゴリズム、並列コンピューティングなど）を理解しており、優れたエンジニアリング文化を持っているため、誇大宣伝の傾向がありません。
• 経験-若者は誇大宣伝が大好きです。 長年にわたり、多くの異なる新しいソリューションを見て、何度も多くの困難に直面してきた人々は、テクノロジーをより冷静に選択しています。

翻訳：セルゲイダンシン