ソフトウェア会社で最も一般的に使用されている Web 開発ポリシーは何ですか?[閉まっている]
-
19-09-2019 - |
質問
開発者の間で最高のフォーラム Web サイトを持っているので、どのようなポリシーとベスト プラクティスが優れたコーディングを実現するかについて、非常に良いコンセンサスを見つけることができると思います。そのうちのいくつかをここに載せますので、私がアイデアを示しますが、あなたの意見を聞きたいと思います。そしておそらく投票が最良の政策を判断することになるでしょう。
- 開発チーム間のコーディングのための特定のインデント
- 各メソッドの前、各変数宣言の前に特定のコメント
- 命名規則、キャメルケースなど。
- HTML では、各コンテナー タグの後にコメントを付けます。
- CSS では、各宣言は 1 回だけ使用します。
わかりますね。会社が私たちに何を求めているのか、そしてそれらのうち何が実際に保守可能で美しいコードを取得するために機能するのかを知りたいと思っています。
解決
私なら、コードの書式設定ではなく、開発実践に関するポリシーに焦点を当てます。いくつかの例は次のとおりです。
- 常にパラメータ化された SQL クエリを使用してください。ユーザー入力をクエリに連結しないでください。
- HTML、CSS、JavaScript を別のファイルに保存します。
- 使用
jslint
または同等のツール 毎 コードをコミットするとき。 - HTML 標準 (HTML 4.01 strict など) を選択します。すべての HTML を検証する必要があります。
そして、政策ナチスにならないでください。時にはルールを破らなければならないこともありますが、そうするのには十分な理由があるはずです。
他のヒント
- コードがバージョン管理されていない場合、コードは存在しません。具体的には、リポジトリにコミットされない限り、実稼働サーバー上には何もありません。
- プロジェクトで古いコードをリファクタリングする機会がある場合は、その機会を利用してください。
- 手順、標準、ライブラリ コードの使用法を文書化した Wiki または類似の文書を維持します (そのような文書がコード コメントとして多すぎる場合)。
(PHP プロジェクトの場合、少なくとも -- PHP はオープンソースであり、重要なコミュニティがあることに注意してください。そのため、多くのことはコミュニティで行われていることによって大きく左右されます)
まず第一に、プロジェクトでフレームワークを使用するとき(つまり、常に)、明確に定義されている場合はそのポリシーに従うように努めます。 (少なくとも Zend Framework には当てはまります) :これにより、このプロジェクトに参加する誰もが次のことができるようになります。
- 標準の定義を見つける
- 同じフレームワークを使用する他のプロジェクトで再利用します。
- たとえ他の会社に行ったり、別の顧客のために働いていたとしても
- または別の会社から来た場合 ;-)
私が働いている会社では、PHP プロジェクトに 3 ~ 5 つのフレームワークしか使用しておらず、標準で定義されている多くのルールが同じであることを考慮すると、これは大きな問題ではありません。
もちろん、ある種の CMS の内部または周囲でコーディングする場合にも同じことが当てはまります。
特定のフレームワークを使用しない場合は、PHP コミュニティで広く受け入れられている共通のルール セットに従うように努めます。同様に、それらのルールが確実に周知されるようにします (当社に初めて入社された方でも), 、見つけやすく、多くの人がそれらを試して強化しました。
コメントについては、PHP でよく使用されるツールが 1 つあります。phpドキュメント (javadocとほぼ同じです) ;これは標準を定義します。これほど頻繁に使用されるツールは他にないため、これが事実上の標準です。
特定のコメントタグについて:
- 私たちは常に @param / @return を使用します。これらは IDE に統合されており、タイプヒントを提供するため便利です。
- それ以外の場合は、あまり使用しません。メソッドが明確でない場合に何を行うかを数行で説明します。難しいアルゴリズムを使用する場合は数行で済みます。
キャメルケースまたはその他:私たちは、PHP コミュニティとフレームワークの両方に共通するものにこだわります。
this_is_a_function
そして
ThisIsAClassName
そして
thisIsAMethodName
HTML の場合:HTML コメントはブラウザに送信されるため、できる限り使用しません。
- より大きなページを意味します (OK、それほど多くはありません)
- ユーザーが必要としない情報を提供することを意味します
可能であれば、テンプレート エンジンからのコメントを使用します。
CSS の場合:必要に応じてコメントします。さらに重要なことは、非常に具体的ないくつかの小さな CSS ファイルを使用することです (ビルド プロセス中にマージ ツールを使用する場合でも)。
しかし、おそらくこれよりも重要なことは次のとおりです。私たちは、小さな「単位」のことだけを行う小さなメソッドを使用し、自己記述的な名前などを使用して、「クリーンな」コードを使用しようとします。
魔法のような効果はありませんが、コードを理解するのに役立ちます...そしてまた、それをテストし、再利用する...
また、ネイトが言ったように:これらはほとんどがガイドラインです。ただし、クライアントから特に要求された場合を除きます。この場合、何らかの自動ツールを導入する必要があります (たとえば、ビルドプロセスにおいて) 文字の後に続くことを確認します。