IT開発の速度は非常に速いため、多くのテクノロジーやアイデアには、時の試練に合格して事実上の標準となる時間がありません。 時々、私たちは群れの原則に基づいてこれらの基準に従います-皆と私の両方。 とても簡単で快適です。 そして時々、これらのアイデアは非常に揺るぎないものになり、私たちはそれらを熱狂的にフォローし、正しいかどうかを考えようとはしません。
1.メソッドコードはモニター画面に収まる必要があります。
文字通りに受け取らないでください。 このように言い換えます。アプリケーションロジックの観点から複数の明確な具体的なアクションを実行するメソッドを記述しないでください。 つまり メソッドが300行未満にならないような状況である場合、別のメソッドに分割しないでください。 そのようなメソッドの名前は、開発者に何も伝えません。 コードに混乱を引き起こすだけです。 結局のところ、これらのメソッドは特定の順序でのみ呼び出すことができ、不変の連鎖を形成します。
アプリケーションロジックメソッドにいくつかの特別なオーバーロードを追加する必要がありましたが、UI、パブリックパーツ、および管理パーツのレイヤーに影響しました。 私はすぐに管理コントローラーを見つけました。 しかし、公衆に問題がありました。
変更する必要があるかもしれないメソッド呼び出し。 何も言わない一連のアクションをループするだけの神秘的な方法でした。 しかし、彼は10行でした！ ここで何が起こっているのかを理解するために、私はこの方法が呼ばれるレベルに上がりました...それから、私はデジャヴの鋭い感覚を得ました。 そして、これらのコードのいくつかで私のビジネスロジックメソッドがどれほど悪かったのか。 この実装の作成者に感謝します。モニター画面に収まらない場合でも、明確で具体的な1つのメソッドを読む手間を省いてくれました。 それをかかとで置き換えて、いまいましい。
2.静電気は悪い！
私の周りには、これを確信している多くのプログラマーがいます。 このステレオタイプの脚がどこから生まれたのかさえ知りません。 私は1つの重要な議論だけを聞きました-静的はテストでカバーするのが難しいです。 ここで重要な点が考慮されていないことを常識だけが教えてくれます：何がプライマリで何がセカンダリですか。 つまり 誰が誰に適応すべきか それは、人体が私たちが店で買う服に適応しなければならないことと同じです。
ところで、このステレオタイプの別の興味深いバリエーションがあります：静的は悪く、拡張メソッドはクールです！ <irony>できません... </ irony> 。
3.実装で使用するパターンが多ければ多いほど、プログラマとしての能力が向上します。
自己肯定の非常に興味深い方法。 FAQを残し、5番目のラッパーをシャベルで実行して実装を変更しようとする同僚に同情します。ほとんどの場合、彼は次のように考えます。明らかな機能ではfalse。」
ここで適切な場合ではなく、使用の具体的な利点が見られる場合<irony>またはコードの難読化レベルを追加する場合</ irony>にパターンを使用します。
4. IoCコンテナー-これがすべてです！
これは同僚の間で主張する別の方法だと思います。 ある実装を別の実装に簡単に置き換えることができるのは素晴らしいことです！ これは本当に素晴らしいです。 しかし、あなたがそれを必要とするかもしれない状況を見た場合のみ。 たとえば、あるエンジンを別のエンジンに交換します。 しかし、これは、このメカニズムがすべてのコードをサポートする必要があるという意味ではありません。 不条理のポイントになります。 いくつかのシンエンティティ（プロパティがロジックなしで宣言されているクラス）をすばやく置き換える機能が実装された商用コードを見ました。 非常に便利な機能ではありませんか？
5.私たちは最初にコードを愛しています（Entity Frameworkについて話しています）！
賢明なアプローチとして、常に最初にコードを検討してください。 私にとって、コードはプライマリです。 コード内のデータをどのように操作するかが重要です。 データベースは、データへの並列アクセスのための単なる箱です。 今日は明日、別のボックスを使用します。 しかし、5年前、最初にコードへのコミットメントが禁止されたことを認めます。 このアプローチは、同僚からのrid笑、または私の無能さのヒントを引き起こしました。 このデータベースはどのようにプログラムコードに依存しますか？
さて、Microsoftが最初にコードを宣伝し始めたとき、誰もが急速にその支持者になりました。 つまり 多数意見が逆転しました。 ITで何かが変更されましたか？ 広告会社のマイクロソフトは数えていません。 ステレオタイプが変更されました。
結論 ：ステレオタイプ的に傾向を追跡することは悪です。 そして、私の意見では、これは現代のプログラミングの最大の悪です。 それぞれのアプローチ、決定には、抽象的な正当化ではなく、具体的なものが必要です。 トレンドの使用例がこれらの現実に対して明確でない、または不合理な場合、使用を拒否します。 それ以外の場合は、後になって、同行するのが不快になるアプリケーションを作成します。