どのような「ベストプラクティス」が常にベストとは限らないか、そしてその理由は何ですか？[閉まっている]

「ベストプラクティス」は業界のいたるところにあります。「コーディングのベストプラクティス」のGoogle検索では、ほぼ150万の結果をアップになります。このアイデアは多くの人に快適さをもたらすようです。指示に従うだけで、すべてがうまくいきます。

ベストプラクティスについて読んだとき-たとえば、最近Clean Codeのいくつかを読んだだけで-緊張しました。これは、このプラクティスを常に使用する必要があるということですか？添付されている条件はありますか？それが良い習慣ではないかもしれない状況はありますか？問題についてさらに学ぶまで、どうすれば確実に知ることができますか？

Clean Codeで言及されているプラ​​クティスのいくつかは私と相性がよくありませんでしたが、それが悪い可能性があるからなのか、それとも私の個人的な偏見によるものなのかは正直わかりません。ハイテク業界の多くの著名人がベストプラクティスがないと考えているように思われることを知っているので、少なくとも私のしつこい疑念が良い会社に私を置きます。

読んだベストプラクティスの数は多すぎて、ここにリストしたり、個々の質問をしたりすることはできないため、これを一般的な質問として言いたいと思います。

「ベストプラクティス」として一般的にラベル付けされているコーディングプラクティスは、特定の状況下で次善または有害な場合があります。それらの状況は何ですか？なぜ彼らは練習を貧しいものにしますか？

具体的な例や経験について聞きたいです。

この声明であなたは頭に釘を打ったと思う

私は物事を額面どおりに受け取り、批判的に考えないことを嫌います

なぜ存在するかについての説明が付いていない場合、ほとんどすべてのベストプラクティスを無視します

レイモンド・チェンは、彼が言うとき、この記事でそれを最もよく述べます

良いアドバイスには根拠が付いているので、いつ悪いアドバイスになるかを知ることができます。なぜ何かを行うべきなのか理解していない場合、貨物カルトプログラミングのtrapに陥り、それが不要になった場合や有害になった場合でも、それを続けます。

これをリングに投げ込むこともできます：

Premature optimization is the root of all evil.

いいえ、ちがいます。

完全な引用：

「私たちは小さな効率を忘れて、時間の約97％を言うべきです。時期尚早な最適化はすべての悪の根源です。しかし、その重要な3％で機会を逃すべきではありません。」

つまり、設計プロセス全体を通じて、特定の戦略的なパフォーマンス強化を活用できます。 これは、パフォーマンス目標と一致するデータ構造とアルゴリズムを使用することを意味します。これは、パフォーマンスに影響する設計上の考慮事項を認識していることを意味します。ただし、最適化を行うと保守性が低下しますが、軽微な最適化は行われません。

アプリケーションは適切に設計されている必要があります。そのため、アプリケーションに少しの負荷をかけたときに最後に落ちないようにしてから、書き直します。省略された引用符の危険性は、多くの場合、開発者はそれを何もするのが遅すぎるかもしれない最後までパフォーマンスについて全く考えない言い訳としてそれを使用することです。細かい点に焦点を合わせていない場合は、最初から良いパフォーマンスを構築することをお勧めします。

組み込みシステムでリアルタイムアプリケーションを構築しているとします。「早すぎる最適化はすべての悪の根源である」ため、プログラミング言語としてPythonを選択します。今、私はPythonに対して何もありませんが、それはインタプリタ言語です。処理能力が制限されており、一定量の作業をリアルタイムまたはほぼリアルタイムで実行する必要があり、作業に必要以上の処理能力を必要とする言語を選択した場合、あなたは非常に頭がおかしくなります。今、有能な言語でやり直す必要があります。

関数/メソッドごとに1つの戻り。

車輪を再発明しないでください、広く誤用された教義です。そのアイデアは、適切なソリューションが存在する場合、独自のソリューションを作成する代わりにそれを使用することです。労力を節約することに加えて、既存のソリューションは、最初に思いついたものよりも実装（バグがなく、効率的、テスト済み）のほうが適切です。ここまでは順調ですね。

問題は、100％の適切なソリューションがほとんど存在しないことです。80％の適切なソリューションが存在する場合がありますが、それを使用することはおそらく問題ありません。しかし、どのように60％が適切でしょうか？40％？どこで線を引きますか？線を引かないと、「ホイールの再発明」を避けたいという理由だけで、その機能の10％を使用しているため、プロジェクトに肥大化したライブラリを組み込むことになります。

車輪を再発明すれば、まさにあなたが望むものを手に入れることができます。車輪の作り方も学びます。実践することで過小評価されるべきではありません。最終的に、カスタムホイールは市販の汎用ホイールよりも優れている可能性があります。

「すべてを単体テスト」。

私は、すべてのコードがユニットテストを持つべきだとしばしば言ったと聞いていますが、これは私が同意しない点です。メソッドのテストがある場合、そのメソッドの出力または構造への変更は2回（コードで1回、テストで1回）行う必要があります。

そのため、私の意見では、単体テストはコードの構造的安定性に比例する必要があります。レイヤードシステムをボトムアップで記述している場合、データアクセスレイヤーはwazooをテストします。私のビジネスロジックレイヤーはかなりよくテストされ、プレゼンテーションレイヤーにはいくつかのテストがあり、ビューにはほとんどテストがありません。

常にインターフェイスにプログラムします。

実装が1つしかない場合もあります。インターフェースの抽出プロセスを、その必要性がわかるまで遅らせると、多くの場合、それが不要であることがわかります。

オープンソース（またはMicrosoft以外の.NET開発者）を使用しないでください。

Microsoftが開発しなかった場合、ここでは使用しません。ORMを使用する-EF、IOCを使用する-Unity、ログに記録する-エンタープライズロギングアプリケーションブロック。非常に多くの優れたライブラリが存在しますが、私は常に開発の世界のドルメニューからの注文にこだわっています。マイクロソフトのベストプラクティスを聞くたびに、「マクドナルドの栄養ガイドライン」と思います。確かに、あなたがそれらに従うならおそらく生きますが、あなたはまた栄養失調と太りすぎになります。

• これはあなたのベストプラクティスではないかもしれないことに注意してください。しかし、これは私が働いたほぼすべての場所で一般的なものです。

オブジェクトの向き

コードが「オブジェクト指向」であるという理由だけで、魔法のように優れているという仮定があります。したがって、人々は機能をクラスとメソッドに絞り込み、オブジェクト指向にするだけです。

すべてのコードにコメントを付ける必要があります。

いいえ、ありません。明らかなコードがある場合があります。たとえば、セッターは特別なことをするまでコメントしないでください。また、なぜ私はこれをコメントする必要があります：

/** hey you, if didn't get, it's logger. */
private static Logger logger = LoggerFactory.getLogger(MyClass.class);

方法論、特にスクラム。大人が「スクラムマスター」というフレーズを使っているのを聞いたとき、私はまっすぐな顔を保つことができません。開発者が抗議するのを聞くのにうんざりしているのは、Methodology Xのある側面が彼らの会社のために働いていないということです。方法論Xの「スクラムをもっと難しくしてください、私のパダワンの学習者でなければなりません！」

アジャイル方法論には知恵のナゲットがあります---それらの多くは---しかし、それらはしばしば私が私のギャグ反射と戦うことができないほど多くの肥料で覆われています。ウィキペディアのスクラムページからこのビットを取ります：

スクラムでは多くの役割が定義されています。すべての役割は、開発プロセスへの関与の性質に基づいて、豚と鶏の2つの異なるグループに分類されます。

本当に？豚と鶏、あなたは言う？魅力的！これを上司に売り込むのが待ち遠しい...

オブジェクトリレーショナルマッピング... http://en.wikipedia.org/wiki/Object-relational_mapping

データから抽象化されたくないし、その正確な制御と最適化を失いたくもない。これらのシステムでの私の経験は非常に貧弱です...これらの抽象化レイヤーによって生成されたクエリは、オフショアリングで見たものよりもさらに悪いです。

まるで英語の文であるかのように関数名を書く：

Draw_Foo()
Write_Foo()
Create_Foo()

これは素晴らしいように見えるかもしれませんが、APIを学習しているときは苦痛です。「Fooで始まるすべて」のインデックスを検索するのはどれくらい簡単ですか？

Foo_Draw()
Foo_Write()
Foo_Create()

等

MVC-多くの場合、Webデザインの多くの問題をMVCアプローチに組み込むことは、単純さや構造よりもフレームワーク（レールなど）を幸せにすることの方が多いと感じています。MVCは、単純さよりも過剰な足場を重視しているように見える「建築宇宙飛行士」のお気に入りです。ymmv。

クラスベースのオブジェクト指向-私の意見では、可変状態の複雑な構造を奨励しています。私が長年にわたってクラスベースのオブジェクト指向で見つけた唯一の説得力のあるケースは、オブジェクト指向の本の第1章を形成する「シェイプ->長方形->正方形」の例です。

ヤグニ

（あなたはそれを必要としません）

このアプローチは、既存のコードベースに機能を実装する必要があり、慎重な計画がこれらの機能を事前に含んでいた場合、何時間もかかりました。

私の考えはしばしばYAGNIのために拒否され、ほとんどの場合、誰かがその決定に対して後で支払わなければなりませんでした。

（もちろん、適切に設計されたコードベースでも機能を後から追加できると主張することができますが、現実は異なります）

SQLの場合

1. トリガーを使用しないでください
2. ビューの後ろにテーブルを常に隠す

順番に：

1. それらは場所がある機能です。テーブルへの複数の更新パスがあるか、100％監査が必要ですか？

2. なんで？契約を維持するためにリファクタリングを行っていたとしても、テーブルの変更に合わせてビューを変更している人を読んだときはそうではありません

編集：

番号3：EXISTSによる*の回避。1/0を試してください。できます。列リストは、SQL標準に従って評価されません。さちえ191

主にデザインパターン。それらは過剰に使用され、十分に活用されていません。

単一責任の原則

^{（「すべてのクラスに1つの責任のみを持たせる必要があります。言い換えれば、すべてのクラスに1つだけの変更理由を持たせる必要があります」）}

同意しません。私が考える方法を変更する唯一の理由があるはずであり、クラスのすべてのメソッドが持つべき1-別の論理的な関係を、しかし、クラス自体は実際にあります行う、いくつかの（関連）のものを。

私の経験では、この原則はあまりにも熱心に適用されすぎており、多くの小さな1つのメソッドクラスになってしまいます。私が働いたアジャイルショップは両方ともこれを行っています。

.Net APIの作成者がこの種のメンタリティを持っているとしたら、 List.Sort（）、List.Reverse（）、List.Find（）などではなく、ListSorter、ListReverser、およびListSearcherクラスがあると想像してください！

SRP （それ自体は理論上ひどいものではありません）に反論するのではなく、長年の逸話的な経験をいくつか紹介します。

私が働いたある場所で、ノード、グラフ、グラフ作成者、グラフソルバー、グラフ作成者/ソルバーを使用して問題を解決するクラスの5つのクラスで構成される非常にシンプルな最大フローソルバーを作成しました実世界の問題。特に複雑なものや長いものはありませんでした（ソルバーは、最大で150行まで）。ただし、クラスには「責任」が多すぎると判断されたため、同僚はコードのリファクタリングに取り掛かりました。それらが完了すると、私の5つのクラスは25のクラスに拡張され、コード行の合計は元の3倍以上になりました。コードの流れはもはや明らかではなく、新しい単体テストの目的でもありませんでした。私は自分のコードが何をしたかを理解するのに苦労しました。

同じ場所で、ほぼすべてのクラスには1つのメソッドしかありません（「責任」のみ）。プログラム内のフローを追跡することはほぼ不可能であり、ほとんどの単体テストは、このクラスが別のクラスのコードを呼び出したことをテストすることで構成されていました。文字通り数百のクラスがあり、そこには数十のクラス（IMO）しかありませんでした。各クラスは「もの」を 1つだけ実行しましたが、「AdminUserCreationAttemptorFactory」のような命名規則を使用しても、クラス間の関係を伝えることは困難でした。

別の場所（クラスは1つだけのメソッドを持つという考え方もあります）で、特定の操作中に95％の時間を費やすメソッドを最適化しようとしました。（少し愚かな）最適化を少し行った後、なぜそれが何千回も呼ばれている理由に注意を向けました。それはクラスのループで呼び出されていました...そのメソッドは別のクラスのループで呼び出されていました..これもループで呼び出されていました..

すべてのことを言って、13のクラスに（真剣に）広がる5つのレベルのループがありました。あるクラスが実際に何をしていたかは、それを見ただけでは判断できませんでした。クラスが呼び出したメソッド、それらのメソッドが呼び出したメソッドなどのメンタルグラフをスケッチする必要がありました。すべてが1つのメソッドにまとめられていた場合、問題のメソッドはすぐにわかる5つのレベルのループ内にネストされているため、長さは約70行でした。

これらの13のクラスを1つのクラスにリファクタリングするという私の要求は拒否されました。

Clean Codeに言及しましたが、いくつかの優れたアイデアが含まれていますが、すべてのメソッドをサブメソッドにリファクタリングしたり、サブメソッドなどにリファクタリングしたりすることへの執着は行き過ぎだと思います。いくつかの10行のメソッドの代わりに、20の（おそらく適切に命名された）ワンライナーを好むことになっています。明らかに誰かがそれはきれいだと思っていますが、私には元のバージョンよりもずっと悪いようです。

また、次のような単純な基本的なものを置き換える

0 == memberArray.length

クラス内で次のようなクラス独自のメソッドを呼び出します

isEmpty()

疑わしい「改善」私見です。追加：違いは、最初のチェックで正確に言うことです：配列の長さが0であるかどうかをisEmpty()チェックします。配列の長さもチェックするかもしれません。ただし、次のように実装することもできます。

return null != memberArray ? 0 == memberArray.length : true;

つまり、暗黙的なnullチェックが含まれています！これは、パブリックメソッドの場合は正常な動作かもしれません-配列がnullの場合、何かが確実に空になります-しかし、クラス内部について話しているとき、これはそれほどうまくありません。外部へのカプセル化は必須ですが、クラス内部はクラス内で何が起こっているかを正確に知る必要があります。クラス自体をカプセル化することはできません。明示的は暗黙的よりも優れています。

これは、長いメソッドを分解したり、論理的な比較を伴うことは良くないと言うことではありません。もちろんそうですが、それをどの程度行うか（スイートスポットの場所）は、明らかに味の問題です。長いメソッドを分解すると、より多くのメソッドが作成されますが、それは無料ではありません。実際に何が起こっているのかを確認するには、ソースコードを飛び回らなければなりません。そのすべてが単一のメソッドに含まれている場合、一目でそれを見ることができます。

場合によっては、1行のメソッドは短すぎてメソッドに値しないと言うことさえできます。

「コメントで寛大に」

コメントは間違いなく良いことですが、あまりにも多くのコメントは、十分でないというよりも悪くないとしても同じくらい悪いです。どうして？不要なコメントが多すぎる場合は、コメントを調整する傾向があります。完全に自己文書化できるコードを作成できると言っているわけではありませんが、説明のためにコメントが必要なコードの方が望ましいです。

有害と見なされるGoTo

ステートマシンを実装している場合、GOTOステートメントは、「構造化プログラミング」アプローチよりも理にかなっています（読みやすさと効率的なコード）。新しい仕事で書いた最初のコードに1つだけでなく複数のgotoステートメントが含まれていたとき、同僚を本当に心配していました。幸いなことに、彼らはそれが実際にこの特定のケースで最良の解決策であることに気付くのに十分な知性を持っていました。

ルールに対する賢明で文書化された例外を許可しない「ベストプラクティス」は、単に怖いだけです。

コードをテスト可能にするための犠牲

私はコードをテスト可能にするために多くのフープを飛び越えますが、選択肢が与えられないならふりをしません。しかし、これらは「ベストプラクティス」であるという考えを推進している人々をよく耳にします。これらのプラクティスには以下が含まれます（.Netの言語で記述されていますが、他の言語にも適用されます）。

• クラスごとにインターフェイスを作成します。 これにより、処理するクラス（ファイル）の数が2倍になり、コードが複製されます。はい、インターフェースプログラミングは良いですが、それはパブリック/プライベート指定子が意図しているものです。
• 起動時にインスタンス化されないすべてのクラスには、ファクトリが必要です。 明らかに、new MyClass()ファクトリを書くよりもはるかに簡単ですが、今ではそれを作成するメソッドを単独でテストすることはできません。この事実がなければ、私が今やるファクトリークラスの数は1/20になります。
• すべてのクラスをパブリックにします。これにより、クラスでアクセス指定子を使用するという目的が失われます。ただし、非パブリッククラスは他のプロジェクトからアクセス（したがってテスト）できないため、他の唯一のオプションは、すべてのテストコードを同じプロジェクトに移動することです（したがって、最終製品でリリースします）。
• 依存性注入。明らかに、他のすべてのクラスにフィールドを使用する必要があり、コンストラクターパラメーターは、必要なときにそれらを作成するよりもはるかに多くの作業が必要です。ただし、このクラスを単独でテストすることはできません。
• 単一責任の原則。これは非常に多くの頭痛の種を引き起こしたので、独自の回答に移しました。

これを修正するにはどうすればよいでしょうか？言語アーキテクチャを大幅に変更する必要があります。

• クラスをモックする機能が必要です
• 別のプロジェクトから、内部クラスのプライベートメソッドをテストする機能が必要です（これはセキュリティの脆弱性のように思えるかもしれませんが、テスト対象者にテスタークラスの名前を強制する場合、問題は発生しません）。
• 依存性注入（またはサービスの場所）、および既存のファクトリパターンと同等のものは、言語の中核部分である必要があります。

つまり、テスト容易性を念頭に置いてゼロから設計された言語が必要です。

アプリケーションを層に分離します。データ層、ビジネス層、UI層

私がこれを嫌う主な理由は、この方法に従うほとんどの場所が、それを実現するために非常に脆弱なフレームワークを使用することです。IE UIレイヤーは、ビジネスレイヤーオブジェクトを処理するために手動でコーディングされます。ビジネスレイヤーオブジェクトは、ビジネスルールとデータベースを処理するために手動でコーディングされます。

なぜこれが悪いのですか？最も一般的な拡張要求は、おそらく「画面XにYを持つフィールドが必要です」です。バング！すべてのレイヤーに影響を与える新機能があり、異なるプログラマーでレイヤーを分離すると、非常に簡単な変更のために、複数の人やグループが関与する大きな問題になりました。

さらに、私はこのようなことをする議論に何回参加したかわかりません。「名前フィールドの最大長は30に制限されています。これはUIレイヤー、ビジネスレイヤー、またはデータレイヤーの問題ですか？」そして、100の議論があり、正しい答えはありません。答えは同じです。すべてのレイヤーに影響します。UIをバカにしてすべてのレイヤーを通過する必要はなく、データベースで失敗します。これは、ユーザーがエントリが長すぎるとわかるためです。変更すると、すべてのレイヤーなどに影響します。

「レイヤー」も漏れる傾向があります。レイヤーがプロセス/マシンの境界（IE Web UIおよびビジネスバックエンドロジック）によって物理的に分離されている場合、ルールが複製され、すべてが適切に機能するようになります。つまり、ユーザーが応答するUIを必要とするため、一部のビジネスロジックは「ビジネスルール」であるにもかかわらず、UIで終了します。

使用するフレームワーク、または使用するアーキテクチャが、小さな変更や漏洩に対して耐性があり、つまりメタデータに基づいており、すべてのレイヤーで動的に調整されていれば、それほど苦痛はありません。しかし、ほとんどのフレームワークは王室の痛みであり、小さな変更ごとにUIの変更、ビジネスレイヤーの変更、データベースの変更が必要であり、この手法が想定しているよりも多くの作業と少ないヘルプを引き起こします。

私はおそらくこれに非難されますが、そこにあります:)

JavaBeans

JavaでのJavaBeanの使用。私の質問を参照してくださいJavaBeansの代わりに不変のPOJOを使用すべきではないのはなぜですか？StackOverflowで。

ユーザーストーリー/ユースケース/ペルソナ

あなたが慣れていない業界向けにプログラミングしているとき、これらの必要性を理解していますが、完全に実装された場合、それらは企業になりすぎて時間の無駄になると思います。

80文字/行の制限は馬鹿で​​す

GUI側の最も遅いランナーのペースに合わせていくつかの妥協を行う必要があることを理解しています（画面解像度の制限など）が、その規則がコードのフォーマットに適用されるのはなぜですか？

参照...右端のピクセル境界の外側の仮想画面スペースを管理するために作成された水平スクロールバーと呼ばれるこの小さな発明がありました。構文の強調表示やオートコンプリートなどの優れた生産性向上ツールを作成した開発者は、なぜそれを使用しないのですか？

確かに、VT220端末の疲れた古い制限に従う* nix恐竜によって宗教的に使用されるCLIエディタがありますが、なぜ私たちの残りは同じ標準に拘束されていますか？

私は言う、80文字の制限をねじ込みます。恐竜が1日中emacs / vimをハッキングするのに十分なほど壮大である場合、CLI IDEに自動的に行を折り返すか、水平スクロール機能を提供する拡張機能を作成できないのはなぜですか？

1920x1080ピクセルモニターは最終的には標準になり、世界中の開発者はまだ同じ制限の下で生活していますが、それ以外の理由は関係ありません。それは、プログラミングを始めたばかりの年長者から言われたものです。

80文字の制限はベストプラクティスではありませんが、ごく少数のプログラマーにとってはニッチなプラクティスであり、そのように扱われるべきです。

編集：

多くの開発者がマウスジェスチャーを必要とするため、水平スクロールバーを好まないことは理解できます。現代のディスプレイを使用している私たちにとって、列幅の制限をより大きな数（80以上）に増やしてはどうでしょうか。

800x600のコンピューターモニターがほとんどのユーザーの標準になったとき、Web開発者は大多数に対応するためにWebサイトの幅を増やしました...開発者が同じことをできないのはなぜですか。

測定、測定、測定

結構ですので、離れて測定してください。しかし、パフォーマンスのバグを分離するために、測定は連続的な除去と同様に動作します。ここに私が使用する方法があります。

私は、メジャーとメジャーの「知恵」の源を突き止めようとしてきました。背の高い十分な石鹸箱を持っている人がそれを言って、今では旅行します。

私の先生は、すべての識別子（定数を含まない）を小文字で始めるよう要求していますmyVariable。

些細なことのように思えますが、多くのプログラミング言語では大文字で始まる変数が必要です。私は一貫性を大切にしているので、すべてを大文字で始めるのが私の習慣です。

シングルトンを使用する

何かのインスタンスを1つだけ持つ必要がある場合。私はこれ以上反対できない。シングルトンは決して使用せず、一度だけ割り当てて、必要に応じてポインター/オブジェクト/参照を渡します。これをしない理由はまったくありません。

反復子としてunsigned intを使用する

彼らはいつsigned intを使用するほうがはるかに安全でバグが少ないことを知るでしょう。配列インデックスが正の数値のみであることが非常に重要であり、4-5が4294967295であるという事実を見落として喜んでいるのはなぜですか？

メソッドは1つの画面より長くしないでください

私は単一責任の原則に完全に同意しますが、なぜ人々はそれを「機能/メソッドは論理的な粒度の最高レベルで単一の責任しか持ち得ない」ということを理解しているのでしょうか？

アイデアはシンプルです。関数/メソッドは1つのタスクを実行する必要があります。その関数/メソッドの一部を他の場所で使用できる場合、それを独自の関数/メソッドに切り分けます。プロジェクトの他の場所で使用できる場合は、独自のクラスまたはユーティリティクラスに移動して、内部でアクセスできるようにします。

コード内で1回だけ呼び出される27個のヘルパーメソッドを含むクラスを作成するのは愚かであり、スペースの無駄遣い、不必要な複雑さの増加、膨大な時間の無駄遣いです。忙しいリファクタリングコードを見たいが、あまり生成しない人にとっては、より良いルールのように思えます。

これが私のルールです...

何かを達成するための関数/メソッドを書く

コードをコピー/貼り付けようとしている場合は、そのコードの関数/メソッドを作成する方が良いかどうかを自問してください。関数/メソッドが別の関数/メソッドで一度だけ呼び出される場合、そもそもそれを持っていることに本当にポイントがありますか（将来より頻繁に呼び出されるでしょうか）。デバッグ中に関数/メソッドのジャンプを追加または追加することは価値がありますか（つまり、追加されたジャンプはデバッグをより簡単または難しくしますか？）

200行を超える関数/メソッドを精査する必要があることに完全に同意しますが、一部の関数は同じ行で1つのタスクのみを実行し、プロジェクトの残りで抽象化/使用できる有用な部分が含まれていません。

API開発者の観点から見ます...新しいユーザーがコードのクラス図を見る場合、その図のどの部分がプロジェクト全体の中で意味を持ち、いくつだけが次のように存在するでしょうか。プロジェクト内部の他のパーツのヘルパー。

私が2人のプログラマーから選択する場合：最初のプログラマーは、やり過ぎを試みる関数/メソッドを作成する傾向があります。2番目は、すべての関数/メソッドのすべての部分を細かく細分化します。私は最初の手を選びます。1つ目はより多くのことを実行し（つまり、アプリケーションのより多くの部分を書く）、彼のコードはデバッグしやすくなり（デバッグ中の関数/メソッドのジャンプの回数が少なくなるため）、コードの見た目とコードの動作の完璧さ。

不要な抽象化を制限し、オートコンプリートを汚染しないでください。