コーディングのベストプラクティスを常に使用する必要があります[終了]

ソフトウェアをコーディングする場合、構築するアプリケーションに関して、アーキテクチャは常にベストプラクティスまたは実践的プラクティスのどちらである必要がありますか？

5年間存続する可能性のある2ページのWebアプリケーションを構築し、その5年間で2つの機能拡張を行う場合、依存性注入、デザインパターン、ビューモデルを備えたモデルビューコントローラーなどでコーディングする必要があります

コーディングのベストプラクティスを常に使用すべきか

常に？いいえ、それはばかげています。

ベストプラクティスはガイドラインです。ほとんどの人にとって、ほとんどの状況で、ある程度のフィネスで実装されていれば、最良の結果が得られます。ソリューションを検討する際に開始する場所です。しかし、より良い解決策があるため、ベストプラクティスを無視できる場所と無視すべき場所があります。

問題は、人間が未来を見ることができないということです。そして、初心者（および多くの初心者）は、ルールが適用されない特別なシナリオにいると必然的に考えます。疑わしい場合は、ベストプラクティスを使用してください。あなたや私よりも賢い多くのエンジニアの間での長年の議論と経験が、彼らが一貫して良い結果を生むことを発見しました。しかし、あなたと同じようにあなたの特定の問題を知っている人はほとんどいません。ルールを曲げることができる例外的なケースに出くわすことがあります。

はい。それは自明です。なぜあなたは最高のことをしないのですか？

しかし、それは問題ではありません。難しいのは、ベストプラクティスが何であるかを見つけることです。答えるには、要件を正確に把握し、プロジェクトが何年にわたってどのように進化する可能性があるかを正確に知る必要があります。

ただし、1つの良い経験則：たくさんのデザインパターンの名前を取り、考えずにそれらをジャムすることは、決してベストプラクティスではありません。

それ以外は、あなたの質問には本当に答えられません。特定の状況における「ベストプラクティス」とは何かを正確に把握することが、ソフトウェアエンジニアであることのすべてです。より良い回答を得るには、それを絞り込む必要があります。

ベストプラクティスは、機能、保守性、パフォーマンスなどに関するソフトウェアの機能的および非機能的要件を最も効果的に満たすものです。しかし、そうでない場合、実用主義が勝ちます。

私が現在働いている場所では、製品の新しいWeb UIをゼロから構築しています。決してRESTfulではありません。POSTのみを使用します。多層ではなく、マイクロサービスを使用せず、NoSQLデータベースを使用しません。エンタープライズJavaのようなアーキテクチャはありません。

言い換えれば、それはまったくヒップではありません。

ただし、Angularのようなデータバインディング、モバイルやデスクトップなどのさまざまなデバイスタイプへの自動スケーリング、TelerikのKendo UIとの統合によるすべての手間のかかる作業、および完全に暗号化されて保護された最新のHTML5 フレームワークが組み込まれていますデータチャネル。

何よりも、それは30日で完了し、エンタープライズアーキテクチャのJava開発者の軍隊が達成するのに1年かかる偉業です。コードはES6 / Typescriptです。それは私が今まで見た中で最もクリーンなコードの一部です。

いいえ。ベストプラクティスとは、一般に99％の時間を行うのに最適であると一般に考えられていることですが、それがすべての状況に常に適用されるわけではありません。

開発者としてのあなたの仕事は、それらのベストプラクティスを知って使用することですが、それらを破棄することがいつ安全かを知ることでもあります。

これは自己宣伝ではありませんが、最近、Salesforce.comプラットフォームでの私の仕事に関連するブログ記事を書いて、これらの機会の1つを詳しく説明しました。そこにある黄金のルールの1つは「ループ内でクエリを実行しない」ですが、最近、プラットフォームでの作業を始めて7年で初めて、このルールに従わない完全に正当な理由がありました。

要点は、プラットフォームでは特定の実行コンテキストで実行できるクエリの数に制限があることですが、この場合、ヒープスペースが不足しないようにループ内でクエリを実行する必要があり、クエリの範囲内に収まることがわかりました限定。

そのため、まれですが、ベストプラクティスがシナリオに関連しない場合もあるため、適合しない場合は強制しないでください。

「ベストプラクティス」とは、誰かが本に書いたルールのリストを意味すると思います。もちろん、フレーズを文字通りに意味するのであれば、もちろん、可能な限り最高のコードを常に書くべきです。

広く受け入れられている単一の「ベストプラクティス」のセットがないことを指摘する必要がありますか。1人の専門家によって昇格されたルールの場合、ほとんど常に、同等の資格を持つ別の専門家を見つけることができます。

しかし、要点：短い答え：通常、しかし常にではありません。

すべての分野には、「ベストプラクティス」と「教科書ソリューション」があります。これらは、長年にわたる多くの多くの人々の蓄積された経験と知恵を表しており、無視すべきではありません。しかし！特別な状況、フリンジケースなどが常にあります。あらゆる分野の真に有能な人は、いつルールに従うべきか、いつ破るのかを知っています。

一般的に言うと、教科書のルールに従うことから始めましょう。教科書のルールに従うと、不必要な複雑さ、パフォーマンスの低下などのトラブルにつながる場合、この1つのルールを一度破るのは良い考えではないかどうかを検討してください。

ルールを無視して、その気まぐれがあなたを導くところならどこにでも行けば、あなたのコードはごちゃごちゃになりそうです。あなたがどんなに頭がいいにしても、あなたは世界で最初のプログラマーではありません。他人の経験から学ぶことは理にかなっています。私たちの日常生活の中で、これが私たちが両親と教師と説教者を持っている理由です。ですから、それは愚かな間違いであることを学ぶために、すべての愚かな間違いを繰り返す必要はありません。

しかし、ある本のルールのリストに100％従順に従うと、四角い釘を丸い穴に打ち込んでしまうことがよくあります。ルールブックを書いた人は、あなたのようなケースに出くわすことはなかったかもしれません。そして、たとえ彼らが持っていたとしても、それが十分にまれであるならば、彼らはそれを無視したかもしれません。80％の時間で機能するルールは、100％ではなく80％の時間で機能することを理解している限り、優れたルールです。

私は、データベース設計者が従うことを勧める多くの規則を含むデータベース設計に関する本を書きました。（タイトルを与えることは控えますので、恥ずかしがらずに自己宣伝をしているようには見えません。）データベースを設計したい人は、私のような本を読んで、それからできることをすべて学ぶことをお勧めします。しかし、もちろん、私がリストした規則を破る必要がある場合があります。

かつて私が率いた開発者チームのためにプログラミング標準ドキュメントを書いたことがあります。最後のルールは次のようになりました。「上記のルールのいずれかを破る正当な理由がある場合は、先に進みます。ただし、コードにコメントを入れて、ルールを破った理由を説明する必要があります。正当な理由を考えてから、ルールに従ってください。コメントを書くことがルールに従うよりも厄介な場合は、ルールに従ってください。」理由を説明しなければならない面倒に値するルールを破った人がいるのはほんの一握りしかありませんでした。

することで、ベストプラクティス、私はあなたが、特定のタスクを行うための最善の方法リテラルのないある種「ソフトウェアの品質を向上させることができ、ソフトウェア開発コミュニティが時間をかけて学習したことを非公式のルール」を意味すると仮定しています。

はい、そうしない理由があるまで。真剣に検討し、手元のタスクの状況と制限に適用したのは、十分な理由になるはずです。つまり、実践を完全に理解し、それを適用できるということです。あなたがそれを理解しないなら、それは最高の種類の思考であってはならないというこの概念には入らないようにしましょう。定義を参照してください。

常に最善を尽くすとは限りません。上司が「このくだらないものを出荷するか、解雇されます！」と言ったら あなたはそれを出荷し、おそらく別の仕事を探しに行きますが、あなたはまだそれを出荷します。十分なことをしていることがあります。もちろん、これを習慣にしたくはありませんが、時にはワゴンを動かさなければならないことがあり、馬が盲目になるのを心配することはできません。

重要なものもあれば、そうでないものもあります。

言語とスタイルの選択は、当面の問題に合わせて調整する必要があります。

たとえば、例外処理の「ベストプラクティス」は、常に例外をキャッチしてログに記録することですが、ユニットテストを作成する場合、ユニットテストフレームワークが正しく報告できるように、ベストプラクティスは例外をスローすることです。

一方、「DRY」ルールを検討してください。明白な理由だけでなく、そのようにコーディングするほどコーダーが良くなるため、それ自体を繰り返さないコードを探すことは常に良いです-それはあなたのコーディング/思考スキルを柔軟にする素晴らしい方法ですタイピングやコピー/貼り付けのスキルの代わりに、長期的には、賢明な規則に従えば、一般的にコードを再検討するほうがよいでしょう（スローコードであると思っていたとしても）。

要約すると、柔軟性がありますが、読み捨てられたジャンクを捨てないでください。

別の視点から見てみます。

今日の最新のフレームワークにより、mvc、依存性注入、階層化アーキテクチャなどを使用した基本的なプロジェクトのセットアップが非常に簡単になります（ここではスプリングブートが大好きです）。生成されたベースから始めて、手作りのソリューションを必要とする何かにぶつかるまで、提供されたツールを使用すると言います。次に、それらのベストプラクティスから角を切り取ることができます。

2ページのWebアプリ用のSpring Bootのようなものを使用してから、独自のサーブレット、jdbcクエリなどをローリングすることは難しくありません。

私の経験では、必須と考えるベストプラクティスは1つだけです。

シンプルで愚かなこと（KISS）

言い換えると、選択するツール、API、アーキテクチャなどは何でも-シンプルにすれば、将来の作業が簡単になり、バグが少なくなり、高速で、メモリ効率が良くなり、必要なすべてが可能になります。

人々が話す他のすべてのこと：原則、パターン、実践など-私は選択できるツールのパレットであるとみなし、現在取り組んでいるプロジェクトに最適なものを選択します。それらはすべて、問題を解決するためのテクニックとアイデアを提供します。トリックは、そもそもこれらの問題があるかどうかを把握することです。

最高の「ベストプラクティス」には、マニュアルの項目が不適切である場合を識別するために、あなたの知性と経験を使用する必要があるセクションが常に含まれています。また、そのような例外をレビュー、承認、文書化し、それらを「ベスト」プラクティスの一部にするセクションを含めることもできます。

ソフトウェアをコーディングする場合、構築するアプリケーションに関して、アーキテクチャは常にベストプラクティスまたは実践的プラクティスのどちらである必要がありますか？

理論では、はい。

現実の世界では、そうする余裕がある限り [はい]はい。

もちろん、これは「いいえ」を意味します。

時間とお金のプレッシャーは、クライアントに「より良い」価値を提供するため、常に「迅速で汚れた」ソリューションの道を押し広げようとします。それがどのように実装されるかは、クライアントやその会計士には関係ありません。2日間で（ひどく）仕事をすることができる場合、または3か月で完全に仕事をすることができるなら、彼らはあなたに尋ねるだろうと思いますか？

2つの間のギャップ-ベストプラクティスと「逃げる」必要があるものは、「技術的負債」と呼ばれます。あなたがそれを「返済」する計画を持っている限り、すなわち、戻って後で物事を改善するということを持っている限り、それは完全に受け入れられます。繰り返しますが、あなたがいつも（今まで？）予算を得るものではありません。

1つの方法は、「クイック」フィックスを含む初期のベータバージョンをリリースすることですが、「フル」リリースの前に必要なアーキテクチャの改善が優先されるようにします。繰り返しになりますが、あなたがいつも（今までに）できることではありません。