ソフトウェアのオーバーエンジニアリングにつながる10個のバグ

星間距離、宇宙のエントロピー、ビジネスソフトウェアの要件など、時間の経過とともに増加することが保証されています。 多くの記事は「複雑にしないでください！」と書いていますが、その理由や方法を書いてはいけません。 10の明確な例を示します。

1.エンジニアはよく知っている

私たちのエンジニアは、自分自身を最も賢い人だと考えています。 まあ、私たちはさまざまなものを作成するからです。 そして、このエラーはしばしば過剰なエンジニアリングにつながります。 100個のモジュールを計画および構築している場合、ビジネスは常に101番目のモジュールを要求します。 あなたがあなたの強さを集めて1000の問題を解決すると、彼らはあなたのところに来て、テーブルに10,000の新しいものを配置します。 あなたはすべてが制御されていると思いますが、実際には、道路が明日あなたを導く方向を想像することさえできません。







プログラマーとして働いた15年間で、ビジネスの問題が完全で安定したソフトウェア要件であることを一度も見たことがありません。 それらは常に変化し、拡大します。 そして、これはビジネスの性質であり、それを管理する人々の間違いではありません。



道徳 ：カジノ（ビジネス）は常に勝ちます。

2.ビジネス機能の再利用

ビジネスがますます多くの要件を（予想どおり）投げるとき、私たちは時々、「OK、可能性のあるすべてをグループ化して要約しよう！」と言います。







これが、ほとんどのMVCシステムがBig ModelまたはFat Controllerで終わる理由です。 しかし、すでにわかっているように、ビジネス要件が追加されることは決してありません。つまり、これはどこへも行かないことを意味します。 実際、次のように応答する必要があります。







例 ：顧客の1人に対して一度、ユーザープロファイルモジュールを開発しました。 古典的なCRUDコントローラーから始めました。それは単なるユーザープロファイルであり、すべてがシンプルである必要があるためです。 すべては、このプロファイルを作成および入力するための13の異なるシナリオの実装で終わりました。ソーシャルネットワークを介した登録、定期的、簡略化、その後の編集による迅速化、サブサイトの非常に異なる外観など。 彼らはお互いにほとんど共通点がありませんでした。 「注文の表示」と「注文の編集」のシナリオも同様に異なります。

まず、ビジネス機能を水平に分割する前に、垂直に分割してみてください。 モノリスをマイクロサービスに分割する作業も簡単になります。 場合によっては、モノリシックになったり、サービスでモノリシックになったりすることもあります。 そうしないと、システムの一部を変更することがますます困難になります。



道徳 ：孤立したアクションを好む、結合を避けます。



ヒント ：プログラムのユーザーに見える部分を取ります（フォーム\ページ\コマンド）。 プログラマーは、それに関連するすべてのコードを理解するためにいくつのコンテキストスイッチを必要としますか？

3.すべてを一般化する

（前の段落と多少似ていますが、時にはそれとは独立して発生します）

• データベースに接続する必要がありますか？ 汎用アダプターを作成しましょう。
• お問い合わせは？ 一般化されたリクエスト。
• パラメーターを渡しますか？ 一般化パラメータ。
• いくつかのパラメーターを何かに集めますか？ 汎用ビルダー。
• 結果を何かに反映しますか？ 一般化データマッパー。
• ユーザーリクエストを処理しますか？ 一般化されたリクエスト。
• 何かする？ 総合請負業者。
• など

時々、エンジニアが持ち込みます。 ビジネス上の問題を解決する代わりに、適切な親クラスを選択することに時間を費やします。 そして答えは簡単です。







ソフトウェアアーキテクチャは常にビジネス要件に追いつきます。 そのため、今日何らかの魔法の助けを借りて完璧な抽象化を見つけたとしても、その有効期限はすぐに来ます-上記のポイント1を参照-ビジネスは常に勝ちます。 したがって、アーキテクチャのビルド品質の最適な尺度は、アーキテクチャをどれだけ迅速に分解できるかです。 変更が簡単ではなく、簡単に削除できるコードの記述方法に関する素晴らしい記事があります。

道徳 ：コードの複製は、誤った抽象化よりも優れています。



さらに、コードの複製は、非常に正確な抽象化を見つけるのに役立つ場合があります。 なぜなら、同じコードを同じ方法で使用しているシステムの複数の部分を見ると、それらが一体となっているものを理解できるからです。 抽象化の品質は、最も弱いリンクの品質によって決まります。 コードを複製することにより、さまざまな角度からさまざまな状況を見て、抽象化の境界をより明確に見ることができます。

4.すべての外部ライブラリのラッパーを書く

使用する外部ライブラリごとにラッパー（ラッパー）を作成する習慣があります（主に主な製品のスタイルに従うため、場合によっては前の2つの段落で説明した理由のため）。 エンタープライズプログラミングで非常に一般的なアプローチ。 Node / Ruby / Pythonのような動的言語のプログラマーは、ライブラリを追加して使用を開始するだけです。 しかし、エンタープライズ開発者はそのために行くことができません-彼はラッパーを作成する必要があります。 そして、ラッパーの別のラッパー。 おそらく、これはほとんどのライブラリがミッシュマッシュであり、オープンソースコードがそれほど多くなかった2000年代に意味をなすものでした。



しかし、今日は2016年です。 外部ライブラリーが大幅に改善されました。 彼らはただ幻想的になりました。 ほとんどの場合、優れたプログラマーによって作成され、メインコードよりも優れたテストが行​​われています。 それらには明確なAPIがあります。 それらにログインを埋め込むことができます。 すでに優れたコードのラッパーを書くのに時間を費やす必要はありません。 さらに、ほとんどのラッパーは完全に無意味です。 それらのインターフェースは、以下のライブラリと非常に密接に関連しており、多くの場合、1対1の機能を反映した形になっています。 ライブラリが将来変更される場合、このラッパーを使用するコードのほとんども変更する必要があります。 たとえば、ライブラリを完全に置き換えて別のライブラリに置き換える場合でも変更されない「不可知な」ラッパーを作成することは、簡単な作業ではありません。 そのようなタスクは、一般的なソリューションの潜在的な「構成可能性」の考えとともに提起されることがあります。そのアイデアについては、以下で説明します。



道徳 ：ラッパーは例外であり、標準ではありません。

5.コード品質メトリックのブラインドアプリケーション

コード品質の概念に不注意に従うと（すべての変数を「private final」として宣言する必要があり、各クラスにインターフェイスが必要になるなど）、コードが自動的に適切になりません。 FizzBu​​zzまたはHello Worldの エンタープライズ版をまだ見ていない場合はチェックしてください。 画期的なコード。 ミクロレベルでは、各クラスは固い原則に従っており、優れたパターンを使用しています。 このコードにコード品質分析ツールを設定すると、それは素晴らしい製品であり、目が痛くなるということです。 ただし、一歩後退すると、このプログラムが悪夢であることがすぐにわかり、「Fizz Buzz」と印刷されるだけです。



道徳 ：常に一歩後退し、全体像を見てください。



同様に、自動化ツールはコードのテストカバレッジを適切に定義しますが、必要なものをテストしているかどうかについては絶対に言いません。 彼らはいくつかのテストでパフォーマンスを測定できますが、別のケースではプログラムがデータをどれだけうまく処理しているかはわかりません。 彼らはすべてミクロレベルを見ています：このクラス\メソッド\文字列は何をしますか？ そして、全体像を見るのは人間だけです。



別のプログラミング言語を学び、すでに知っている問題を解決するためのさまざまなアプローチを試してください。 これにより、非常に優れたプログラマーになります。 1つのことだけにこだわらないでください。

5.1。 サンドイッチ層

密接に関連するいくつかの機能を取り上げて、それを10〜20のレイヤーに分割します。各レイヤーは、他のレイヤーなしでは意味を持ちません。 それは、「テスト可能なコード」または「共有責任の原則」の概念を実装するか、それを他のファッショナブルなものと呼びたいからです。 過去には、これは継承によって行われていました。 クラスAはBから継承し、BはCから継承します。







今日、人々は同じことをしています。ただし、SOLIDがあるため、各クラスはインターフェイス/クラスのペアで表され、次のレイヤーに挿入されます。







道徳 ：概念は思慮深いアプリケーションを必要とします。 それらは、ツールのように、どこでも常に使用することはできません。

6.新しい症候群

ジェネリック医薬品の研究。 これで、単純な「HelloWorldPrinter」が「HelloWorldPrinter <String、Writer>」になります。

本当に必要なフォームが常に同じデータ型でインスタンス化される場合、ジェネリックを使用する必要はありません。 ほとんどの場合、パラメーターで十分です。



戦略パターンを研究しました。 これで、すべてのifステートメントが戦略になります。

なんで？



DSLを書くことを学びました。 今、私たちはどこにでもすべてのためにDSLを持っています。

まあ、私も知りません...



モキが見つかりました。 今、私たちはすべてに沿ってチェーンされます。

まあ...



メタプログラミングは素晴らしいことです。こことここで使ってみましょう！

理由を説明してください...



拡張メソッド\コンセプト\何か他のものは良いことです。

そして、やめましょう！



道徳 ：何もどこにでも常に適用する必要はありません。 また、「道徳」セクションも各段落に書かれてはなりません。

7.「X – st」

• 構成可能性
• 安全性
• 拡張性
• サポート性
• 拡張性
• ...

あいまい。 常に。 議論するのは難しいです。

例1 ：CMSを作成して、クライアントがこのフォーム自体にフィールドを追加できるようにします。

結果 ：顧客はそれを決して使用しません。 必要に応じて、開発者を見つけて困惑させます。 おそらく、本格的なCMSの代わりに、フィールドをすばやく追加する方法についての短い説明をスケッチする価値がありました。



例2 ：「設定可能性」を簡素化するために、データベースを操作するための大きなレイヤーを設計しましょう。 1つの構成ファイルを編集して、データベースを変更できるはずです。

結果 ：10年以上の作業で、客観的な理由で1つのデータベースを別のデータベースに変更する必要があるプロジェクトが1つだけ見られました。 そして、そのことになると、「1つの構成ファイルを編集する」ことは何もしませんでした。 関連する仕事がたくさんありました。 非互換性、機能のギャップ。 そしてもう一度、クライアントがデータモデルの半分を新しいNoSQLデータベースに転送するように要求しました。 データベース接続を備えた「マジックファイル」がありましたが、最初はリレーショナルのみで、2番目はすべてではなく、半分ではありません。 おそらく、20人のプログラマーを雇うようなコストのOraklovデータベースのようなものになると、これらの構成可能性のあるダンスはすべて理にかなっています。 しかし、現代のデータベースに必要なのは、広い水平ORMレイヤーではなく、単純な垂直DAOクラスのセットだけです。 SQLとNoSQLをうまく組み合わせた単一のモデルはないので、互換性のないひどい間違った抽象化を組み合わせようとするのではなく、それぞれのケースでどちらかを使用して実際に分離する必要があります。



例3 ：エンタープライズクライアント用のOAuth認証システムを構築しました。 このシステムの管理者向けに、Google OAuthによる管理者の承認という別のレベルを追加するよう求められました。 「安全なはずだから」 誰かが私たちのOAuth認証に侵入した場合、少なくとも管理者アカウントを使用不可にする必要があります。 Google OAuthは信頼できるものなので、ここで気にする必要はないようです。

結果 ：このシステムをハッキングしたい人は、OAuthレイヤーを突破する必要はまったくありません。 この脆弱性はもっと簡単なもので見つけることができます（常にそうです）。 その結果、2レベルのOAuthをサポートするすべてのコスト（およびそれらはシステム全体を通過しました）はほとんど結果をもたらしませんでした。 この時間を費やして、一般的な脆弱性を修正することをお勧めします。







道徳 ：これらの特性のすべてを、「-st」で終わるものを不変の指定として受け取らないでください。 それらには価格があります-シナリオ\履歴\使用法を明確に定義してください。

8.自転車の建設

最初はいつもクールです。 しかし、数年後にはすでに遺産の貨物になります。

いくつかの例：

• 独自のライブラリ（HTTP、ミニORM、キャッシュ、構成）
• カスタムフレームワーク（CMS、イベント処理、マルチスレッド、バックグラウンドタスク）
• 独自のツール（アセンブリシステム、展開システム）

何が悪いのか：

• 些細なことのように思えますが、タスクには実際に適切な知識と主題領域への深い没入が必要です。 ある種の「プロセスランチャー」を使用するには、OSでのプロセス管理、デーモンの動作、入力/出力システム、およびその他多くの知識が必要です。 CMSは、テンプレート内のデータを置き換えるだけのものではありません。依存関係、チェック、ウィザード、一般化などがあります。 最も単純なライブラリには、重要な機能が含まれている場合があります。
• これもすべて維持、更新する必要があります。
• コードをパブリックドメインに配置する場合、誰も気にしません。 まあ、多分、以前にこのコードに取り組んだ人を除いて。
• このコードを理解している人は遅かれ早かれ去ります。 そして、それらのほかに、世界中の誰もこの実装を理解していません。
• プロジェクトに既存のライブラリとフレームワークを導入し、ニーズに合わせてそれらを研ぎ澄ますには今時間が必要です。 しかし、あなた自身の自転車を発明することは、長い目で見ればより多くの時間を必要とします。

道徳 ：再利用。 善を借りる。 決定を確認します。

自転車を作ることに決めた場合は、少なくとも社内の「内部オープンソース」の原則に基づいて行います。 これが必要な理由を人々に説明してください。 最初のスケッチを表示します。 これを使用または改善するように招待します。 そして、あなたの同僚が承認を表明していなくても、この自転車を作り続けることは価値があると考えてください。

9.コードを開発する

特定の方法で何かを実装するとすぐに、他の誰もがそれを実装した形式で使用し始めます。 これが正しいのかと疑問に思う人はいません。 コードが機能する限り、これは「良いコード」です。 人々は、本来それが解決することになっていないタスクにもそれを適用し始めます。 時には良いこともあれば、非常に悪いこともあります。 そしてここでは、現在のタスクのためにコードを改善するために、コードを取得して変更することを恐れる必要はありません。 健康的なソフトウェアシステムは常に変化します。 不健康-補完のみ。 コードの一部が非常に長い間コミットを見ていなかった場合-何かが間違っている場合、それは「スマック」です。 すべてのコードを進化させる必要があります。 これを説明する素晴らしい記事があります。



チームがどのようにタスクに取り組むか、そして、彼らがそれをどのようにすべきか、毎日です：







道徳 ：リファクタリングはあらゆる開発の一部です。 変更されないコードはありません。

10.期限が無効です

多くの場合、一見優れていると思われるチームや個々のコーダーが、率直に言って弱い製品を突然提供することがわかります。 私たちはコードベースを見て驚いています-「どのように、本当にこのチーム/人によって本当に作成されましたが、私は彼/彼をとても賢く/賢く考えました！」 品質にはスキルだけでなく時間も必要です。 賢い開発者でさえ、しばしば彼らの能力を過大評価しています。 そして突然、彼らは燃える締め切りの前にいることに気づき、ひどい松葉杖をコードに痛々しいほど書いて、どうにかして締め切りに間に合わせる機会を与えました。



道徳 ：コードの最初の行が書かれる前であっても、期間の誤った推定はプロジェクトの品質を損ないます。