仕様4

規格

-------------------------------------------------- ----------------------------
バグ追跡システムは早期に作成し、あまり頻繁には作成しないでください
早い人ほどバグの使用に慣れます追跡システムがあればあるほど良い。プロジェクトが 3/4 終わった時点でバグ追跡システムをインストールしても、それは使用されません。人々がそれを使用できるように、バグ追跡システムを早期にインストールする必要があります。
プログラマーは一般的にバグ追跡に抵抗しますが、正しく使用すれば、プロジェクトに非常に役立ちます:
問題が床に落とされることはありません。
問題は自動的に責任者に転送されます。
問題のライフサイクルが追跡されるため、人々は適切な情報をもとに議論することができます。
マネージャーは、システム内のバグの数と種類に基づいて、大きなスケジュールと人員配置の決定を下すことができます。
構成管理は、パッチが修正する問題と一致することを期待しています。
QA とテクニカル サポートには、開発者とのコミュニケーション手段があります。
セクシーなものではなく、プロジェクトの優れた堅実な改善です。
参考までに、修正したバグの数によって報酬を与えるのは良い考えではありません :-)
ソース コード管理はバグ追跡システムにリンクされるべきです。リリース前にソースが凍結されているプロジェクトの一部では、有効なバグ ID を伴うチェックインのみが受け入れられる必要があります。また、バグを修正するためにコードが変更された場合は、チェックイン コメントにバグ ID を含める必要があります。
出典
いくつかのプロジェクトで、DDTS が実行可能なシステムであることがわかりました (このリンクはこの PHP リリースでは検証されていません。DDTS は PHP では動作しない可能性があります)。 GNU バグ追跡システムも利用できます。独自のシステムを作成することは一般的なオプションですが、既存のシステムを使用する方がコスト効率が高いと思われます。
------------------------------------------------- -------------------------------
責任の尊重
ソフトウェアモジュールに対する責任の範囲は限定されています。モジュールは特定の人の責任であるか、共通のものです。この責任分担を尊重してください。自分に変更する責任がないものは変更しないでください。結果として生じるのは間違いとつらい感情だけです。
実際のところ、コードを所有していない場合は、コードを変更する立場に立つことはできません。文脈が多すぎます。あなたにとって合理的であると思われる仮定は、完全に間違っている可能性があります。変更が必要な場合は、担当者に変更を依頼してください。または、これこれの変更を加えてもよいかどうかを尋ねます。 OK と言われたら先に進み、そうでなければエディターをホルスターに入れてください。
どのルールにも例外があります。午前 3 時に成果物を作成するために変更が必要な場合は、変更する必要があります。誰かが休暇中で、誰もそのモジュールを割り当てられていない場合は、あなたがそれを行う必要があります。他の人のコードに変更を加える場合は、その人が採用しているのと同じスタイルを使用するようにしてください。
プログラマーは、特に変更に敏感なコードをコメントでマークする必要があります。ある領域のコードを別の領域のコードに変更する必要がある場合は、そのように指示してください。データ形式を変更すると永続ストアやリモート メッセージ送信との競合が発生する場合は、その旨を伝えてください。メモリ使用量を最小限に抑えたい場合、または他の目的を達成しようとしている場合は、そう言ってください。誰もがあなたほど優秀なわけではありません。
最悪の罪は、コーディング スタイルに合わせてシステム内を飛び回ってコードの一部を変更することです。誰かが標準に従ってコーディングしていない場合は、その人に尋ねるか、標準に従ってコーディングするように上司に依頼してください。一般的な礼儀を守りましょう。
共通の責任を持つコードは注意して扱う必要があります。対立を解決するのは難しいため、根本的な変更は避けてください。全員が同じルールに従うように、ファイルを拡張する方法についてファイルにコメントを追加します。すべての共通ファイルで共通の構造を使用するようにしてください。そうすれば、人々がどこで何を見つけ、どのように変更を加えるかを推測する必要がなくなります。競合が発生しないように、できるだけ早く変更をチェックインします。
余談ですが、バグ追跡の目的でもモジュールの責任を割り当てる必要があります。
------------------------------------------------- -----------------------------
PHP 文書扩展名
我见过许複数の PHP 文書の扩展名（.html 、.php、.php3、.php4、.phtml、.inc、.class...）
すべての览者可见页面使用.html
全类、函数库文件使用.php
理由
扩展名説明的是那このようなデータはユーザーが受信するものです。PHP は HTML に解釈されます。 ------------------------------------------------
不要信じられない数字
ソース コードで使用されている赤い裸の数字は、作成者が含まれており、3 か月以内に人間が含まれていないため、信じられない数字です。 例:
if (22 == $foo) { start_thermo_nuclear_war( ); }
else if (19 == $foo) {refund_lotso_money(); }
else if (16 == $foo) { 無限ループ(); }
else {cry_cause_im_lost(); }
上の例の 22 と 19 は何を意味しますか?数字が変わったり、単に数字が間違っていたりしたらどう思いますか?
信じられないほどの数値を使用することは、そのプログラマーがアマチュアアスリートであるという大きな兆候であり、そのようなプログラマーはチーム環境で働いたことがない、
あるいはコードを保守するためにやらなければならないことである、そうでなければ決してそんなことはしないでしょう。
何かを表したい値に、裸の数値を使用するのではなく、実際の名前を与えるには、define() を使用する必要があります。例:
define("PRESIDENT_WENT_CRAZY", "22");
define("WE_GOOFED", " 19");
define("THEY_DIDNT_PAY", "16");
if (PRESIDENT_WENT_CRAZY == $foo) { start_thermo_nuclear_war(); }
else if (WE_GOOFED == $foo) {refund_lotso_money(); }
el se if（they_didnt_pay == $ foo）{infinite_loop（）;
------------------------------------------------- ----------------------------------
OOの約束
OOはあなたが想像できる程度に誇大宣伝されていますそれは世界の飢餓を解決し、世界平和の新たな時代をもたらすでしょう。そうではありません。OO はアプローチであり、哲学であり、盲目的に従うことで品質が得られるレシピではありません。
OO は、適切に使用されれば、ソフトウェアの再利用性は向上しますが、そのためには複雑さと設計時間がかかります。また、再利用可能なコードはより複雑になり、わずかにでも再利用できるものを作成するのに 2 回以上の試行が必要になります。
OO を適切に使用すると、ソフトウェアの変更に対する耐性が向上しますが、このトレードオフはほとんどの場合有利ですが、
OO がうまくいかない場合もあります。ソフトウェアの概念と人間の現実世界の地図の間には、魔法のようなマッピングは存在しません。ある人はシンプルでエレガントなデザインと認識しますが、別の人は複雑で不透明であると認識します。
チームが上記のポイント 1 を適用することで、再利用可能なアイテムのリポジトリを作成できた場合、再利用により開発時間が大幅に短縮され始める可能性があります。
チームが上記のポイント 2 を適用することができた場合、変更に強いソフトウェアを作成すると、そのソフトウェアのメンテナンスがはるかに簡単になり、エラーが発生しにくくなります
--------------------------- -------- -------------------------------------- --------
Thin クラス インターフェイスと Fat クラス インターフェイス
オブジェクトにはいくつのメソッドが必要ですか? もちろん、正しい答えは適切な量です。これをゴルディロックス レベルと呼びます。しかし、ゴルディロックス レベルとは何ですか。それは存在しません。状況に応じて適切な判断を下す必要があります。これがプログラマーの目的です :-)
2 つの極端なクラスは、薄いクラスと最小限のクラスです。必要なメソッドを追加して、ユーザーがシン クラスから独自のクラスを派生することが期待されています。目的は型を設定することです。シン クラスの機能は非常に少ないため、プロジェクトの多くのプログラマは基本的に同じメソッドを追加する派生クラスを作成します。これがコードの重複とメンテナンスの問題につながります。これが、オブジェクトを使用する理由の 1 つです。まず、明らかな解決策は、基本クラスにメソッドをプッシュすることです。そうすれば、厚いクラスがたくさんのメソッドを持ちます。これが問題になるのはなぜでしょうか? 問題ではない可能性があります。メソッドがクラスに直接関連している場合、問題は、人々がそのクラスに関連するメソッドを追加し始めることです。クラスは柳のような方法で分解されますが、判断は再び影響を及ぼします。クラスが大きくなると、相互作用としてのデバッグも難しくなる可能性があります。予測可能性が低くなり、使用しない、またはコードを気にしないメソッドが変更された場合でも、再テストして再リリースする必要があります
----------------- -------- -------------------------------------- -------- ----
最近の変更点
2000-11-16 リリース
-------------------------------------------------- ------------------------------
?著作権は 1995 ～ 2000 年です。トッド・ホフとフレドリック・クリスチャンセン。無断転載を禁じます。