コード標準を無視できるとしたら、いつですか？[閉まっている]

私の会社では、データベースを処理するすべてにストアドプロシージャを使用することを決めました（生のSQL以外に他の方法を知らなかったため）。最近、データベースの値を取得する必要があるハック修正を追加する必要がありました。これは単一のテーブルからの単一の値なので、インラインSQL（もちろんパラメーター化）として記述しました。アプリケーションの単一の部分でkludgeとして使用されている1行のコードのストアドプロシージャ。

もちろん、私は今それを修正するように言われました、そして、データベースに関連する何かのために保存されたProcを使用するだけです。これは、常識を使うのではなく、盲目的にドグマをたどるように少しだけ感じすぎます。誤解しないでください。私はコーディング標準の目的を理解していますが、意味がないときに標準を無視することの賛成者でもあります。単なる盲目的にゴスペルであるかのようにフォローするだけではありません。

コード標準は通常、単なるガイドラインです。ただし、会社にはポリシーがあり、ポリシーは通常無視できないもののようです。それを提示し、代わりにストアドプロシージャを使用するように指示された場合は、権限があれば別の決定をすることになりますが、私は先に進みます。

彼らは実際にアプリのコードとDBの間のコントラクトを分離しようとしていると思います。したがって、たとえば列名を変更する必要がある場合でも、契約（SP）が機能することを確認するだけで済みます。

Get_Costumer（）などは、DBの構造からアプリのコードを抽象化する方法であり、私の考えでは、以下のことを考慮する必要がある実際のベストプラクティスです。構造的には、ほとんどの場合、DBとアプリのコードを分離する必要があります。

最初は、このようなガイドラインに厳格すぎると思われるかもしれませんが、非常に正当な理由がない限り、ガイドラインを守ることが重要だと思います。壊れたウィンドウ理論のために私はこれを言います。これは、優れた実践や習慣を掘り下げる必要があるジュニア開発者がいる場合に特に当てはまります。

あなたの修正が迅速だったか、ハックが本当にウィンドウを壊すのに十分な理由ですか？

コードを保守する経験の浅い開発者を考えてみてください。彼らはクエリを変更したり、同様の方法で別のクエリを追加したりする可能性があります。クエリを変更すると、実行方法も変更する必要があることに気づかなかったため、突然セキュリティが悪用されました。

注：ガイドラインが最初から常に使用されるべきものであるかどうかは別の問題ですが、ガイドラインを設定するときに考慮すべき問題です。私の要点は、常に良いことを決めたら、それを守ることが重要だということです。

他の答えを要約する

ここに他の人が以前にここで言ったことの簡単な要約があります。

プロ企業ポリシー：

• データベースオブジェクト間の依存関係と、計画された変更がスキーマに与える影響の概要を追跡できます。
• DBAチームは、アプリケーションのアクセス権を確認および制御できます。
• DBAチームは、変更によるパフォーマンスへの影響を予測できます。
• アプリケーションコードからデータベースを分離します。
• 壊れたウィンドウ理論...それは彼らがコードを編成する方法であり、一貫性を壊すことはインフラストラクチャーを新規参入者が理解することを困難にし、彼らが品質を尊重し、努力することを少なくします。
• あなたはあなたにあなたがするように頼まれた事をするための給料をもらいます。これは会社の方針であり、現在、あなたにはそれを変更する権限がありません。

対会社方針：

• この会社の考え方は非常に厳格で独断的であり、そのポリシーは開発者の作業を不必要に面倒なものにします。残念ながら、長所セクションの最後のポイントを参照してください。
• 以下のようback2dosは言って、それを指し、「データベースに対して行われたすべてのクエリの場合、ストアドプロシージャをルックアップする必要があり、」別の開発者がストアドプロシージャが自分のために再利用することができないアイデアを持っていないため、ストアドプロシージャのみのポリシーは、多くの場合、コードの重複になり手元の問題;
• また、皮肉にも前のケースとは逆に、あるアプリケーションがsprocを所有し、別のアプリケーションがそれを再利用し、最初のアプリケーションが他の誰がそれに依存し始めたかを知らずにそれを更新すると、問題も発生します。DBAは、DBサーバールームの壁よりも先に依存関係を追跡しないため、どのアプリがそれ以外に依存しているのかを気にしてはいけません。問題がアプリケーションチーム間で追跡されない場合、DBAが対象になります。

THOSE 2セント

まず、ここでの多くの回答では、標準という単語を使用しています。直接クエリを禁止し、sprocのみを許可する慣行は、標準と呼ばれていません。これはポリシーです（jzdの回答を参照）。

第二に、あなたの問題に固有です：ストアドプロシージャを排他的に使用するというこのような制限的なポリシーに対する私の主な反対の議論は、SQL言語自体であり、必ずしもそれが促進する集中型のビジネスロジックリポジトリインフラストラクチャではありません（反対論もあります）。 。

SQLはかなり厳密で構成できない言語であり、表現力は非常に限られています。これは、コードの再利用性に関して、非常に早い段階で行き止まりに直面することを意味します。この厳格さの理由の1つは、（ポリモーフィズムを使用するOOP言語のように）ファーストクラスの関数を渡す方法がないため、構成可能性が大幅に制限されるためです。表現力でそれに最も近い方法は、文字列連結を使用して構築された動的SQLクエリを記述することです。きちんとしたことではありません。動的クエリは、DBオブジェクト間の依存関係の追跡など、「長所」セクションのいくつかのポイントを無効にし、通常はパフォーマンスが低下し、エラーが発生しやすく、デバッグが困難で、SQLインジェクション攻撃のリスク。残念ながら、SQLを使用すると、壁にぶつかって動的に実行されるクエリに頼らざるを得ずに、sproc間で共通の再利用可能なロジックを抽出することは非常に困難です。

更新：最初のクラス関数のほかに、ストアドプロシージャのもう1つの大きな制限は、リスト、セット、レコード、またはキーと値のペアのいずれであっても、複合データ型を引数として渡すことと返すことです。これは、コンポーザビリティを著しく損ないます。

最後に、上記のプロポイントの1つであるJorgeの「DBをアプリケーションから切り離す」に必ずしも同意するわけではありません。カスタムAPIを使用するのではなく。SprocはこのようなカスタムAPIであり、ユーザーとプリミティブリレーショナルデータの中間にあり、一般的な構成可能なデータ操作プリミティブ（select、join、where、group by）を使用してクエリします。、など）。SQL自体は、上記の厳格性のため、構成可能なデータ操作プリミティブのDSLとして理想的な選択ではありませんが、より適切な言語の選択（.NET Linq ...またはLisp / Clojureなど）を使用すると、単純なリストに対するロジックは、DB ResultSetに対するものと同じです。明らかに、それによってテストが容易になります。これは良いことです。単純なCSVでスタブできるように、データストアは単純でプリミティブであることが望ましいと私は言います。ご覧のように、このモデルはDBをアプリケーションからも切り離しますが、抽象化のより低いレベルで線を引くだけです。

次はどうする？

これは質問とは少し関係ありませんが、上記の観察のいくつかに沿って、データの保存とクエリを行う興味深い斬新なアプローチであるDatomicをご覧になることをお勧めします。（もちろん、私はそれで平均を見厳密外の作業環境最初に...間違いない、NOT翌日CTOのオフィスに行くと言うやあみんな、私はDatomicであなたのストアドプロシージャの一部を書き直しました」と比べてこのピカピカのprodサーバー上に展開します！、そこは本当にクール」を見ています彼らは、そうでない場合は、完全に理解興奮を理解していないかもしれません。）

私がコーディング標準を日常的に無視する唯一の場所は自動生成されたコードです。それ以外の場合は通常、ケースバイケースで処理され、コードレビューでダブルチェックされます。あなたはコーディング標準の奴隷になることはできませんが、私の経験では例外はかなりまれです。

ストアドプロシージャを使用しない場合、dbasは、知らないインラインコードにどのような影響があるかを知らずに、データ構造を変更します。カウボーイコーダーが設計に従わない場合、これはメンテナンスの大きな問題です。これはコーディング標準についてではなく、デザインについてです。常にデザインを気に入ったりフォローしたりする必要はありませんが、それはあなたの電話ではないので、求められていることを実行してください。私はあなたにこのようなものに1つの無料パスを与え、それからあなたを解雇します。

長い間、コーダーとチームリーダーとして、私は箱から出して考えることができなければなりません。コーディング標準は物事をうまく保つのに役立ちますが、それらが邪魔になると、支払うべき地獄があるかもしれません。この場合、それは彼らの手順の定義に依存します。それが許容的ではなく制限的である場合、問題がある場所を示すのはリード次第です。

コードの品質は、その読みやすさによって測定できます。あなたが望むのは、コードを見て、それが何をするかを見ることです。

同僚のコードを調べてそれが何をするのかを見たいので、コーディング標準の要点は、チーム全体で読みやすさを強化することです。
理想的には、これがコードにつながり、誰でも読むことができます。それは、人々がすべてをlolcat-またはleetspeekで書くのではなく、自分のアクセントでつぶやくのではなく、きれいな英語を話し、適切なレベルのスペルと文法で書くことを期待するようなものです。

あなたの会社が標準として考えたものは、チーム全体で読みやすさを強制するのではなく、むしろそれを減らします。データベースに対して行われるすべてのクエリについて、ストアドプロシージャを検索する必要があります。
これは、普通の文章を「コーヒーはいかがですか」と言うのではなく、人々に期待するようなものです。通常の通信では、「受信トレイに「コーヒー」という件名の電子メールがあります」と伝えます。ストアドプロシージャ（または電子メールの内容）は完全なジャンボジャンボである可能性があるため、チーム全体の理解が深まることはありません。

したがって、これは（賢明な）コーディング標準ではなく、単なる愚かな形式です。愚かな手続きの唯一のポイントは、人が時間あたりに作成できるでたらめの量を制限するのに役立ちますが、実際に貢献する人々の邪魔をすることです。

あなたはそれに対して責任がある人に話しかけることを試みるべきです（そして私よりはるかに礼儀正しいです;））。

あなたがそれをうまく動かすことができないなら、あなたはあなたの例外を見つけたと思います。ある時点で、チームは、標準のコンテキスト内でそれを行うと、あまりに多くの労力を費やすか、不十分なソリューションを生成するだけであると特定し、文書化された例外を作成します。これがあまりにも頻繁に起こり始めたら、基準を変更します。

これは例として使用しているだけですが、ストアドプロシージャでselectステートメントをラップするのは本当に難しいですか。あなたは明らかにあなたの店で多くの練習をしています。これよりもおそらく従うのが難しい他の標準があります。なぜプログラマーがこれをdbaに渡すのを好まないのかわかりません（私は知っています、あなたのケースではありません）。個人的には、ほとんどのプログラミングIDEのSQLはがらくたに見えますが、他のすべてと同様に、それに慣れるか、ORMの使用を開始します。

次の状況では、標準を無視できます。

仲間の開発者と話し合って合意を得たとき、または適切なポリシーを適用するためのポリシーを設定したとき、またはビジネスが標準に従っていないことが正しいビジネスの決定であると判断したとき（たとえば、数百万ドルが要求される可能性がある）標準と競合するかどうかに関係なく、「今」の修正）。

これは次の場合にルールに適用されます。

• それらは無視され、コードの大部分が従わないところまで悪用されてきました。

• 競合する標準のセットがいくつかあり、どちらを適用するかは明確ではありません。

• ローカル標準は業界標準に反します。たとえば、会社はインデントに9個のスペースを使用すると（！）

しかし、上記の3つの例でも、ゴールデンルールは、可能な限り、最初に関係者全員に話しかけます。少なくとも（午前2時の修正など）可能な限り早く決定について話し合う必要があります。また、行ったことに関する情報を送信するだけでなく、それについて話し合う必要があります。批判や変化を起こす準備をしてください。

コーディング標準に違反することは常に問題ありません。ただし、そうする場合は、違反が意図的なものであるというコメントを常に記述し、何らかの正当化を行う必要があります。