ベストプラクティスと常識の違いは？

ソフトウェア開発のベストプラクティス¹に関する多くの会話があります。私は少なくとも3つの主要なポイントがSEと他の場所の両方で多くの議論を得るのを見ました：

• ベストプラクティスとして適格なものとその理由は何ですか？
• ベストプラクティスはそもそも議論する価値さえあります。プラクティスが「ベスト」プラクティスではないと断言するのが妥当だからです。
• 適用できないように思われる場合、またはトレードオフを非現実的にする外部の制約（時間、お金など）のために、いつベストプラクティス（またはおそらくベストプラクティス）を放棄する必要がありますか？

ソフトウェア開発の常識の概念は、はるかに少ない頻度で登場するように思われますが、決してないことではありません。最近の経験により、この概念が再び頭に浮かびました。

私の最初の印象は、それがベストプラクティスとは異なる議論であるが、おそらく他の受粉を伴うということです。

一般的に常識を考えるとき、あなたが選んだか教えられたルールのセットを考えて、それがあなたに判断と判断を下すためのベースラインを与える。常識に従うことは、足全体を撃ち落とさないようにする良い方法です。しかし、かなり低いベースラインを超えて、常識は教育された決定を下す必要性に道を譲り、教育された決定は、証拠が十分に説得力があるように見えるときでも常識を無効にすることができます。私はここで定義を少し緩めているかもしれませんが、私の例を先導するのに十分だと思います。

ソフトウェア開発の常識を考えるとき、コードベースが急速に不可解な混乱に陥ることを防ぐための基本的な衛生のすべてのルールを考えます。例として、次のようなものがあります。単一のグローバル構造を使用して、重要なプログラム内で状態を維持および伝達しない。ランダムで意味不明な変数/メソッド/クラス名を使用しない。おそらく、アンチパターンと呼ばれるようになったものに非常に近いものです。ベストプラクティスを実践パターンと学習パターンに適用する場合、常識を適用することはアンチパターン学習の実践アナログと見なすことができます。

これを念頭に置いて、私は他の人の答えを見ることが私がこれを介して私の道を推論するのに役立つかもしれないいくつかの質問を提起したいと思います。

他の人は、ソフトウェア開発に常識の概念があると信じていますか？いずれにせよ、推論を知ることに興味があるでしょう。

もしそうなら、それは議論する価値がある概念ですか？時々ベストプラクティスを実行するのと同じくらい、プッシュする必要があるものですか？それをさらに難しくする価値はありますか？

アンチパターンの類推が合理的であると思われる場合、一般的なルールは、アンチパターンは他の方法がない場合にのみ採用され、それでも非常に限られた状況下でのみ採用されるというものです。コードベースが常識から逸脱することを許容する上で、どれほど柔軟にすべきでしょうか？答えが「まったくない」のは不合理に思えます。なぜなら、便宜のために逸脱が必要になる場合があるからです。しかし、「ベストプラクティス」を採用する場合とは異なる種類の議論のようです。たぶんそうではありません。そう思わないなら、理由を知りたい。

これははるかに開かれた終わりであり、おそらくそれ自体の後続の質問に値する可能性がありますが、それはどのような種類の推奨事項を常識の問題のように思われますか？

他の考えも歓迎します。

¹おそらく私はそれらを「一般的に繰り返されるドメインパターン」と呼ぶ方が良いでしょうが、「ベストプラクティス」という名前は、彼らがそうであることに同意しなくても、誰でも彼らが何であるかを知っているほど十分に一般的です。「最高の」部分が気になる場合は、「ベストプラクティス」を信頼性の低いサウンドに置き換えたと想像してください。

ベストプラクティスとは、比較的広い範囲の状況でうまく機能することがわかっているプラ​​クティスです。それらの問題は、A）表現がマーケティングのために悪用されることがあり、B）固定されたルールとして、十分な柔軟性がないことです。現在の状況に適用されるかどうかを考えずに、一連の固定ルールに従う必要はありません。

ベストプラクティスは、「ベスト」である理由と、どのような状況で使用する必要があるかを説明するときに役立ちます。次に、それらを使用しない場合について考えることができます。

「常識」の問題は、柔軟性が高すぎることです。これは、ほとんど何でも正当化するために使用できます。チームが従うためのガイドラインとしては持っているのは良いことですが、貧弱です。

後方に持っていると思います。

プログラマにセキュリティの基本を教えるとき、私は常に使用するように教えますがbest practices、セキュリティの専門家（または、より「セキュリティの経験のある」プログラマ）に対処するとき、私は決して議論しませんbest practices。実際、しばしば違反します。

より良い定義は次のとおりです。

「ベストプラクティス」は専門家の常識であり、非専門家によって適用されるべきです。

つまり、特定の分野で微妙なトレードオフを理解するのに十分な専門知識が得られるまで、「常識」を主張することはできません。そして、あなたがやるとき、あなたはもはや盲目的にクッキーカッターの「ベストプラクティス」に従うべきではありません。

「ベストプラクティス」は、独自の「常識」を使用するのに十分な経験を積むまでの一時的なプレースホルダーです。

ベストプラクティス->「最初に、ルールを学習します」。経験->「それから、いつ、どのようにそれらを壊すかを学びます」。

代替手段（もちろん、重要ではないコードで-できれば個人的なプロジェクトやスローアウェイで）を試す意欲は、必要なエクスペリエンスの構築に役立ちます。

もちろん、常識は経験と同じではなく、間違った場所に良いテクニックを適用する際の欠陥を見るために必ずしも多くの経験を必要とするわけではありません-しかし、過剰に適用し、テクニックの適用が不十分であり、ここでの「常識」は明らかにプログラミングの生得的な知識ではないため、その感覚は特定のグループ内でのみ「共通」であることは明らかです。

「味方する」のはとても簡単です。実際、回避することは不可能です-時には一方が本当に正しい場合と、他方が実際に間違っている場合があり、バランスを主張するのは非合理的です。ここでの問題は、本当の地獄が関連性のために1つのベストプラクティスをそれほど重視していないが、2つの相反するベストプラクティスの意見が衝突する場合です。

これに対処することは、おそらく技術的なスキルよりも人のスキルに関するものです。私はそれがとても下手です:-(

それにも関わらず、自分だけでなく他の人の経験から学ぶことも重要です。つまり、ベストプラクティスとは何か、それらが使用される理由、利点（および欠点）を知ることです。

この質問はセマンティックなトリックであるように思えます。これらの定義を使用する場合、質問はありません。

ベストプラクティス：特定のドメインの問題を解決するための現場で実証済みの方法（つまり、リアルタイムのベストプラクティスは、データベースのベストプラクティスとはまったく無関係です）

常識：避けるべき落とし穴をプログラマーに警告するのに役立つ専門的な経験

最終的に、ベストプラクティスは問題の特定の一致を解決するメタデザインパターンであり、実世界の経験に基づいて選択されますが、Common Senseは複数の問題セットにわたる一般的な観察に基づく問題解決のガイドです。

Common sense = You.CommonSense

Best practices = Sum(Experts.Experience + Experts.CommonSense)

興味深いタイミング。先週、この記事が公開され、常識が必ずしもすべての状況で理想的ではない理由が議論されました。

常識は、日常の状況で発生する種類の複雑さの処理に絶妙に適合しています...そして、これらの状況で非常にうまく機能するため、すべての状況でそれを信頼する傾向があります

（太字の言葉）

基本的には-人間は、我々がする必要がありますので、私たちが染み付いシステムを開発していないこのような分野での常識を使用して得意ではありません常に標準の文書セットを使用し、私たち自身の常識に依存しないで！

常識はアンチパターンの学習に対応しておらず、ベストプラクティスとは異なるものでも、ベストプラクティスとは対照的でもありません。

常識の最初の問題はその名前です-それはそれが常識であり、賢明であるという結論につながります。一般的に使用されるように、それは両方の点で攻撃を受けやすい。あなたの例を使用して：

アンチパターンは、他に方法がない場合にのみ使用され、それでも非常に限られた状況下でのみ使用されます

これはアンチパターンが生じる方法ではないことは私の理解です。それは文化的および社会的要因の付加によるものです。相当な期間にわたってベストプラクティスと標準を無視すること。短期的な利益を達成するために将来のコストを無視すること-たとえば、メンテナンスの悪夢であるショートカットソリューションを使用して期限を守ること などアンチパターンを意図的に採用しようとする体はありません-彼らはただ成長します。

同様に、常識は「一般的に行われている」ことを意味するためにあまりにも頻繁に使用され、ソリューションの提供に関与するものを解決する際の思考、洞察、および努力の欠如を正当化します。また、「そのやり方であるため、明らかに常識である」ことの正当化として、またレビューや批判に対する防御としても使用されます。

ベストプラクティスに関する限り、@ Michaelの最初の2つのパラグラフは、ベストプラクティスのあり方に関する優れた要約です。また、意思決定の透明性（特に設計上の意思決定）と他者から学ぶ能力も提供します。ベストプラクティスのマイナス面は、チェックリストカルチャを生成するときです-「すべてのボックスにチェックを入れたので、やったことは大丈夫です」-チェックリストの適用性の性質に思考、注意、注意を適用しません。

これは、しばしば宗教戦争に発展する滑りやすい斜面の議論です。

ほとんどすべてのベストプラクティスは、反対のことを行うための有効なケースで対処できます。

一部のベストプラクティスは、他のベストプラクティスよりも「ベスト」です。グローバル状態変数は、ほとんどの場合、別の方法でより適切に実行され、GOTOは通常悪い考えですが、パターン/アンチパターンまたは直接データ/抽象化されたデータ引数に入ると、それは少しわかりにくくなります。さらに、開発の方法論と実践について話し始めるときにもそうです。

状況によっては、常識とベストプラクティスが互いに対立することさえあります。

ベストプラクティスの統治機関はなく、たとえ存在したとしても、単一のグループが、あらゆる可能な状況に対してあらゆる可能な「ベスト」を定義することはできません。ベストプラクティスとしてラベル付けされているものの多くは、知識のない個人のツールやトレーニングを販売しようとする悪いマーケティングです。

チーム全体が何かが最善であることに同意したとしても、さまざまな制約要因に対して常にそのように実装できるとは限りません。

私見では、ベストプラクティスをガイドとして使用して、設計でより慎重に検討する必要があるものを選択する必要があります。逸脱する正当な理由があるかもしれませんが、おそらく何か他の奇妙なものを構築する前に、チームの他の全員が同意することを確認する必要があります。

それ以降のベストプラクティスに関する議論のいくつかは、次の開発者がそれを処理しなければならないようなものを構築しないということにかなり要約されます。誰もが自分のスタイルではないコードを嫌い、誰もが去った人のすべてを非難するので、何かについて不平を言った後、次の開発者にそれを説明するか、あなたがそこにいて悪い話をするつもりはありませんコーディング方法に関係なく これにより、その懸念はほとんど無関係になります。

常識が常に最良の結果をもたらすとは限りません。ただし、ベストプラクティスが試行されています。これにより、ベストプラクティスがより信頼できる情報源になります。

ベストプラクティスはベストではなく、常識は一般的ではありません。;-)

ベストプラクティスまたは常識のいずれかのために、私はそれらをパターンとして考えたいです。：パターンの定義を覚えておいてくださいソリューションにおけるコンテキスト解決力をへたコンテキストを。

あなたがしたいことについては、それが適用されるコンテキスト、それが解決する力、そしてそれが作成する結果のコンテキストを知っている必要があります。次に、一般的に使用するパターンをチームで決定します。（これは正式なものでも非公式なものでもかまいませんが、いずれにしても、Gang of Fourの本よりもはるかに大きくなります。これには、公開されたパターンだけでなく、言語イディオムやローカルヘルパーライブラリが含まれます。）

経験に基づいて、特定の状況では、特定のパターンを使用するのではなく、他のことをする方がよいと感じた場合は、人々に知らせてください。おそらく、ここではコンテキストまたは力が異なります（または、結果として生じるコンテキストは望ましくないでしょう）。会議、コードコメント、または何であるかは気にしませんが、意図的にパターンを壊したことを明確にした場合、あなたは何マイル先になります。

ベストプラクティスは彼らが学校であなたに教えることであり、常識は上司があなたから望んでいることです。前者は、エレガンスやスタイルなどの特定の基準を満たすソフトウェアを作成します。後者は請求書を支払う/お金を稼ぐので、毎週支払われます。

1つは芸術であり、もう1つはビジネスです。あまりにも多くの人がそれを忘れています。

少し誇張するために：違いは常識は偏見であり、ベストプラクティスは科学であるべきです

私の経験では、「常識」は、証拠を提供したくない場合、または少なくとも物事を行う方法についての議論を望まない場合に使用されます。それは、その方法が必ずしも間違っているという意味ではありませんが、それが良いということでもありません。

私が遭遇したものの中で、常識を破ることとして合理化されたのはこれらの宝石です。

• HTTPメソッドはほとんど無関係です。少しのデータを送信する場合はGETを使用し、より多くを送信する場合は（つまり、URLを大量に）POSTを使用します
• 関数は小さすぎてはいけません。何をするのか思い出すのが難しいからです。1つの大きな関数は5つの小さな関数よりも望ましいです。
• データベースとWebサーバーは同じマシンで実行する必要があります。そうしないと、Webサービスが遅くなります。スケーリングする唯一の方法は、ハッキングによって、抽象化を控えることによってコードを高速化し、1台のマシンのパワーで十分にすることです。

「常識」の面白いところは、それほど一般的ではないということです。2つのチームを選んで、彼らが「常識」であるものを述べさせ、宗教戦争を楽しんでください。

一方、「ベストプラクティス」として、もう少し「ピアレビュー」があることを行う方法を検討します。何かを「ベストプラクティス」と見なすには、コンセプトとして提示できるように明確に定式化されることを期待します（「構造化プログラミング」がベストプラクティスであり、「ゴトスは混乱し、それらを避ける」ことが常識です）、 2回以上適用すると、良い結果が得られます。