プログラミング|標準
PHP プログラミング スタンダード
最終更新日: 2000-11-16
PHP プログラミング スタンダードは、Todd Hoff の許可を得て、「C++ プログラミング スタンダード」に基づいて PHP 用に書き直されました
著者は Fredrik Kristiansen です
この標準を使用してください。自分で使用するためにコピーを作成したい場合は、完全に無料です。それが私たちが作成した理由です。バグを見つけた場合や改善点がある場合は、最新の更新に組み込むことができるように電子メールを送ってください。
目次
はじめに
標準化の重要性
説明
アイデンティティの観点
プロジェクトの4つのフェーズ
命名ルール
適切な命名
略語にはすべて大文字を使用しないでください
クラスの命名
クラスライブラリの命名
メソッドの命名
クラス属性の命名
メソッド内のパラメータの命名
変数の命名
参照変数と関数の戻り参照
グローバル変数
定義の命名/グローバル定数
静的変数
関数の名前付け
phpファイル拡張子
ドキュメントのルール
コメントはストーリーを伝えるべき
文書決定
ヘッダー命令を使用する
注意事項を明示する
インターフェースと実装のドキュメント
ディレクトリのドキュメント
複雑さの管理ルール
階層化
オープン/クローズの原則
契約による設計
クラスルール
異なるアクセサースタイル
オブジェクトアーキテクチャフェーズでは実際の作業を行わない
シンクラスインターフェースとファットクラスインターフェース
短いメソッド
プロセスルール
設計表記法とプロセスを使用する
ユースケースを使用する
コードレビュー
ソースコード管理システムを早期に、あまり頻繁に作成しない
バグ追跡システムを早期に、あまり頻繁に作成しない
RCS キーワード、変更記録と履歴ルール
名誉の責任
書式設定
中括弧 {} ルール
インデント/タブ/スペースのルール
括弧、キーワード、関数のルール
If then Else の書式
書式の切り替え
Continue の使用法、休憩して
1行に1つのステートメント
宣言ブロックの位置
よくある神話
OOの約束
その他
信じられないほどの数字は禁止
エラーリターン検出ルール
デフォルトを使用しないゼロ以外の値の値テスト
ブール論理型
通常、埋め込み割り当てを避けます
自分や他の人が苦労して作成したものを再利用します
if (0) を使用して外側のコード ブロックをコメントアウトします
その他のその他
---- ------- -------------------------------------- ------- -------------------
はじめに
標準化の重要性
標準化の問題は、ある面では誰もが同じ状況にあると感じています。これにより、多くのプロジェクトで推奨事項が進化し、多くの企業が何週間もかけて一字一句議論することになりました。標準化は特別な
個人的なスタイルではなく、ローカルな改善に完全に開かれています。
利点
プロジェクトが公的標準に準拠しようとすると、次のような利点があります:
プログラマーはあらゆるコードを理解し、プログラムのステータスを理解できます
新人はすぐに環境に適応できます
新しい接触を防止しますPHP を使用する 時間を節約する必要から、人々は独自のスタイルを作成し、生涯にわたる習慣を身につけます
PHP を初めて使用する人が同じ間違いを何度も繰り返さないようにします
一貫した環境では、間違いを犯す可能性を減らすことができます
プログラマには共通の敵がいます :-)
短所
次に短所です:
標準はphpを知らない人によって作られているため、標準は通常愚かに見えます
私に従っている標準が異なるため、そのため、標準は愚かに見えることがよくあります
標準は創造性を低下させます
長期にわたって共同作業する人々の間では標準は不要です
標準はあまりにも多くのフォーマットを強制します
要するに、人々は標準を無視しています
議論してください
多くの人の経験プロジェクトでは、プログラミング標準を採用することでプロジェクトをよりスムーズに完了できるという結論に至る可能性があります。成功の鍵は標準ですか?もちろん違います。しかし、彼らは私たちを助けてくれるはずです。私たちはできる限りの助けを必要としています。正直に言うと、
詳細規格に対する議論のほとんどは主に利己主義に由来しています。妥当な基準をほとんど決定しないことが技術性に欠けていると言えるとすれば、それは単なる好みの問題です。したがって、柔軟性を持ってエゴを抑制し、どのプロジェクトもチームの協力的な努力に依存していることを忘れないでください
。
説明
規約
この文書で「必須」という言葉を使用していることは、この仕様を使用するすべてのプロジェクトが指定された標準に準拠する必要があることを意味します。
「すべき」という言葉を使用する機能は、プロジェクトの詳細をカスタマイズするようにプロジェクトを導くことです。プロジェクトには要件を適切に含めたり、除外したり、調整したりする必要があるためです。
「できる」という単語の使用は、オプションの要件を指定するという点で「すべき」と同様に機能します。
標準実装
最初に、開発チーム内の最も重要な要素をすべて見つけ出す必要があります。もしかしたら、その標準があなたの状況に十分に適切ではないかもしれません。重要な問題がまとめられている場合もあれば、その一部に対して強い反対意見がある場合もあります。
どんな状況であっても、最終的にうまくいっていれば、人々はこの標準が合理的であることを理解するのに十分成熟し、他のプログラマ
もそれが合理的であると判断し、多少の留保を付けても快適に感じるようになるでしょうこの基準に従うことは有益です。
自発的な協力がない場合は、要件を策定することができます。標準はコードによってテストする必要があります。
検証しないと、この解決策は不正確さに基づいたばかげた人々の集まりにすぎません。
私もそう思います
これはうまくいきません
多分それは非現実的で退屈です
これは私が最初に考えたことです
そうあるべきです。
もしあなたがネガティブな偏見を持って物事を見るようになった場合は、広い心でいてください。それでも「くだらない」と結論付けることはできますが、そのためには、さまざまなアイデアを受け入れる必要があります。時間に余裕を持って取り組んでください。
プロジェクトの 4 つのフェーズ
データベース構造
デザイン
データ層
HTML 層
---------------------- -------------------------------------------------- -- ----
ネーミングルール
適切なネーミング
ネーミングは番組企画の根幹です。古代人は、人の本当の名前を知っている限り、その人に対して信じられないほどの力を得ることができると信じていました。物事に適切な名前を考えている限り、それはあなたとあなたの後に続く人たちに、コードよりも大きな力を与えるでしょう。笑うな！
その名前は、それが位置する生態環境における何かの長期的かつ広範囲にわたる結果です。一般に、システムを理解しているプログラマだけが、システムに最も適切な名前を選択できます。すべての名前が自然に適切であれば、関係は明らかであり、意味を推測することができ、一般の人々の推論が期待できます。
対応するオブジェクトに一致する名前が少数しかない場合は、デザインをもう一度よく見ることをお勧めします。
クラスの名前付け
クラスに名前を付ける前に、まずそれが何であるかを理解する必要があります。クラス名から得られる手がかりに基づいても、このクラスが何であるかを思い出せない場合は、設計が十分ではありません。
3 つ以上の単語で構成される名前が混在していると、システム内のさまざまなエンティティ間で混乱が生じやすくなります。設計を確認し、(CRC Se-
セッション カード) を使用して、その名前に対応するエンティティが存在するかどうかを確認してください。このような多くの機能を備えています。
派生クラスに名前を付けるときは、その親クラスの名前を使用する誘惑を避ける必要があります。クラスの名前はそれ自体にのみ関連し、その親クラスの名前とは何の関係もありません。
たとえば、システムがエージェントを使用している場合は、実際に情報を送信するコンポーネントに「DownloadAgent」という名前を付けます。
メソッドと関数の名前付け
通常、各メソッドと関数はアクションを実行するため、名前付けはその動作を明確に示す必要があります。ErrorCheck() の代わりに
CheckForErrors() を使用し、DataFile() の代わりに DumpDataToFile( ) を使用します。そうすることで、関数と
データのオブジェクトもより区別しやすくなります。
サフィックス名が役立つ場合があります:
Max - エンティティに割り当てることができる最大値を意味します。
Cnt - 実行中のカウント変数の現在値。
キー - キーの値。
例: RetryMax は最大再試行数を表し、RetryCnt は現在の再試行数を表します。
場合によっては接頭辞が便利です:
Is - 何かについて質問することを意味します。 Is を見るたびに、人々はそれが問題であることがわかります。
Get - 値を取得することを意味します。
Set - 値を設定することを意味します
例: IsHitRetryLimit。
略語にはすべて大文字を使用しないでください
いずれの場合でも、次の状況に遭遇した場合は、略語を表すためにすべて大文字を使用する代わりに、最初の文字を大文字にし、残りの文字を小文字にすることができます
。
使用: GetHtmlStatistic
使用しない: GetHTMLStatistic.
理由
名前に略語が含まれる場合、人々の直感は大きく異なるようです。このようにして、ネーミングの意味が完全に予測できるよう、統一した規定を設けるのが最善です。
NetworkABCKey の例を考えてみましょう。C が ABC の C であるべきか、それとも C のキーであるべきかに注意してください。これは非常に混乱します。これを気にしない
人もいれば、それを嫌う人もいます。したがって、コードごとに異なるルールが表示されるため、それを呼び出す方法がわかりません。
例えば
class FluidOz // FluidOZ
を書かないでください。 class GetHtmlStatistic // GetHTMLStatisticを書かないでください
---------------------------- -------------------------------------------------- --
クラスの名前付け
単語の区切り文字として大文字を使用し、他の文字には小文字を使用します
アンダースコア ('_') は使用しないでください。理由
多くの命名方法によると、ほとんどの人がこれが良い意味で最良の方法であると考えています。
例:
クラス名OneTwo
クラス名
--------------------------------- ------------------------ -------------------------------------------- ---
クラス ライブラリの命名
現在の名前空間 異なるベンダー間やグループ クラス ライブラリ間のクラス名の競合を避けるために、ますます広く採用されるようになってきています。
名前空間がまだ採用されていない場合、クラス名の競合を避けるために、一般的なアプローチはクラス名の前に一意の接頭辞を追加することです。もちろん、それ以上の文字を使用することをお勧めします。
たとえば、
John Johnson のデータ構造クラス ライブラリには、次のように Jj というプレフィックスを付けることができます:
class JjLinkList
{
}
---------------- ---------------- ---------------------------------- ---------------- ----------
メソッドの命名
クラスの命名と一貫したルールを採用する
理由
ほとんどの人が異なるルールをすべて使用しているこれが最良の妥協点であることがわかります。
例:
class NameOneTwo
{
function DoIt() {};
function HandleError() {};
}
---------------- -------------------------------------------------- --------
クラス属性の名前付け
属性名の先頭には文字「m」を付ける必要があります。
接頭辞「m」は、クラス命名に関する一貫した規則に従います。
「r」で始まるのが参照を表すのと同じように、「m」は常に名前の先頭を修飾します。
理由
接頭辞「m」は、クラス属性とメソッド名の競合を防ぎます。メソッド名とプロパティ名は、特に要素にアクセスする場合によく似ています。
例:
class NameOneTwo
{
function VarAbc() {};
function ErrorNumber() {};
var mVarAbc;
var mErrorNumber;
var mrName;
}
- -------------------------------------------------- - ------------------------
メソッドパラメータの名前
の最初の文字は小文字を使用します。
最初の文字以降の単語はすべて、クラスの命名規則に従って大文字になります。
理由
どの変数がどの変数に対応するかをいつでも知ることができます。
名前の競合を引き起こすことなく、クラス名に似た名前を使用できます。
例:
class NameOneTwo
{
function StartYourEngines(
&$rSomeEngine,
&$rAnotherEngine);
}
---------------- -------------------------------------------------- --------
変数の名前付け
すべて小文字を使用してください
各単語の区切り文字として「_」を使用してください。
理由
このアプローチにより、コード内の変数の範囲が明確になります。
すべての変数はコード内で異なって見えるため、簡単に識別できます。
Functionfunction handleError（$ erronumber）
{
$ error = oserr（）;
----------------------------------------------- - ------------------------
参照変数と関数の戻り参照
参照には接頭辞「r」を付ける必要があります
理由
型を作成します。さまざまな変数を簡単に識別できます
どのメソッドが変更可能なオブジェクトを返し、どのメソッドが変更不可能なオブジェクトを返すかを決定します。
例:
class Test
{
var mrStatus;
function DoSomething(&$rStatus) {};
function &rStatus() {};
}
-------- -------------------------------------------------- - ------------------
グローバル変数
グローバル変数には接頭辞「g」を付ける必要があります。
理由
変数のスコープを知ることは非常に重要です。
例:
global $gLog;
global &$grLog;
---------------------------- -------------------------------------------------- -
命名/グローバル定数の定義
グローバル定数 各単語は「_」で区切ります。
理由
これは、グローバル定数に名前を付ける伝統です。他の定義と矛盾しないように注意する必要があります。
例:
define("A_GLOBAL_CONSTANT", "Hello world!");
---------------------------- ---------------------------------------------------- ----
静的変数
静的変数には接頭辞「s」を付ける必要があります。
理由
変数のスコープを知ることは非常に重要です。
例:
function test(){ static $msStatus = 0;
}
---------------------------- ---------------------------------------------------- ----
関数名
関数名は C GNU の規則に従い、すべて小文字を使用し、単語を区切るには「_」を使用します。
理由
これにより、関連するクラス名を区別しやすくなります。
例:
function some_bloody_function()
{
}
-------------------------------- - ----------------------------------------
エラーリターン検出ルール
エラーを無視したい場合を除き、すべてのシステムコールでエラーメッセージを確認してください。
インクルードの各システム エラー メッセージのシステム エラー テキストを定義します。
------------------------------------------------ ------------------------
中括弧 {} ルール
3 つの主要な中括弧配置ルールのうち、許容されるのは 2 つで、最初のルールは次のいずれかが最適です:
キーワードの下の同じ列に中括弧を配置します:
if ($condition) while ($condition)
{ {
.. ...
} }
従来の UNIX 括弧ルールでは、最初の括弧はキーワードと同じ列にあり、最後の括弧はキーワードと同じ列にあります。
if ($condition) { while ($condition) {
... ...
} }
理由
激しい議論を引き起こした非原則的な問題は、妥協によって解決できますが、ほとんどの場合
人々は最初の方法を好みます。その理由は、心理学の研究と研究の分野にあるものです。
前者を好む理由は他にもあります。使用する文字エディターが括弧一致をサポートしている場合 (vi など)、最も重要なことは適切なスタイルを持つことです。なぜ？大規模なプログラムがあり、この大規模なプログラムがどこで終わるのかを知りたい場合に、このように言います。まず開始括弧に移動し、次にボタンを押すと、エディターは対応する終了括弧を見つけます。例:
if ($very_long_condition && $second_very_long_condition)
{
...
}
else if (...)
{
...
}
あるプログラム ブロックから別のプログラム ブロックに移動するには、カーソルと括弧を使用してキーを一致させるだけです。前後に移動する必要はありません。行の末尾で一致する括弧を見つけます。
------------------------------------------------ ------------------------
インデント/タブ/スペースのルール
インデントにはタブを使用します。
各レベルのインデントには 3 ～ 4 つのスペースを使用します。
必要なときにインデントする必要はもうありません。インデント レベルの最大数に決まった規則はありません。インデント レベルの数が 4 つ、
、または 5 つを超える場合は、コードを除外することを検討できます。
理由
多くのプログラマーがタブをサポートしています。
タブは暴走族のために発明されました
人々があまりにも異なるタブ標準を使用すると、コードを読むのが非常に面倒になります。
非常に多くの人がインデントレベルの最大数を制限しようとしますが、多くの場合、それは仕事とは見なされません。私たちは、プログラマーがネストの深さを賢明に選択することを信頼しています
。
例:
function func()
{
if (何か悪いこと)
{
if (別の悪いこと)
{
while (さらに入力)
{
}
}
}
}
------------------------------------------ ------- ----------------------------------
かっこ、キーワード、関数のルール
キーワードと括弧を組み合わせないでください。キーワードはスペースで区切られ、密に配置されます。
括弧と関数名を近くに配置しないでください。
必要な場合を除き、Return ステートメントでは括弧を使用しないでください。
理由
キーワードは関数ではありません。関数名とキーワードを括弧で囲んでいると、その 2 つが 1 つであることが簡単にわかります。
例:
if (条件)
{
}
while (条件)
{
}
strcmp($s, $s1);
ターン1に戻ります;
---------------------------------------------- -- ------------------------
RCS キーワード、変更記録および履歴ルール
RCS キーワードを直接使用するためのルールは次のとおりです。 RCS スタイルのキーワードをサポートする CVS やその他の同様のソース コード管理システムの使用を含む変更:
ファイル内で RCS キーワードを使用しないでください。
変更履歴の記録をファイルに保存しないでください。
著者情報レコードをファイルに保存しないでください。
理由
その理由は、ソース管理システムがこれらすべての情報をすでに保持しているためです。次のような重複した情報でソース ファイルを乱雑にする理由はありません。
ファイルが大きくなり、
ソース コード以外の行が変更されるため、差分が困難になります。
ファイルの数十行下にエントリを作成するため、各ファイルの検索またはジャンプが必要になります
ソースコード管理システムから簡単に利用でき、ファイルに埋め込む必要がありません
ファイルを他の組織に送信されるコメントには、外部に公開すべきではない内部情報が含まれる可能性があります
。-------------------------------------------------- ------------------------
オブジェクト アーキテクチャ期間中は実際の作業を行わないでください
オブジェクトの期間中は実際の作業を行わないでくださいアーキテクチャ期間。アーキテクチャ中に変数を初期化したり、エラーのない処理を実行します。
オブジェクトの構造が完了したら、オブジェクトの Open() メソッドを作成します。 Open() メソッドには、オブジェクト エンティティにちなんだ名前を付ける必要があります。
理由
コンストラクトはエラーを返すことができません。
例:
class Device
{
function Device() { /* 初期化とその他のもの */ }
function Open() { return FAIL }
};
$dev = newデバイス ;
if (FAIL == $dev->Open()) exit(1);
----------------------- -------------------------------------------------- -
If then Else フォーマット
レイアウト
これはプログラマによって決定されます。ブレースのスタイルが異なると、外観も若干異なります。一般的な方法は次のとおりです:
if (条件 1) // コメント
{
}
else if (条件 2) // コメント
{
}
else // コメント
{
}
else if ステートメントを使用する場合、通常は、処理されない他の状況を処理するために else ブロックを用意することが最善です。可能であれば、else にアクションがない場合でも、
else にレコード情報のコメントを入れてください。
条件付き書式設定
常に等号/不等号の左側に定数を置きます。例:
if ( 6 == $errorNum ) ...
理由の 1 つは、何かを省略した場合です。方程式に等号を追加すると、文法チェッカーによってエラーが報告されます。 2 番目の理由は、式の最後で値を見つけるのではなく、すぐに値を見つけることができるためです
。この形式に慣れるまで少し時間がかかりますが、非常にうまく機能します。
------------------------------------------------ ----------------------------
形式の切り替え
case ステートメントを経由して次の case ステートメントに移行することは、次の条件を満たす限り許可されます。コメントが含まれています。
デフォルトのケースは常に存在する必要があり、これに達する必要はありませんが、これに達するとエラーが発生します。
変数を作成している場合は、すべてのコードをブロックに入れます。
例:
switch (...)
{
case 1:
...
// FALL THROUGH
case 2:
{
$v = get_week_number();
...
}
休憩;
デフォルト:
}
--------------------------- ------ --------------------------------------
用途continue、break、? の:
Continue と Break
Continue と Break は、実際には隠れた goto メソッドです。
Continue と Break は goto に似ており、コード内で魔法のように機能するため、使用は控えめに (できるだけ少なく) 行います。
この単純な魔法を使用すると、何らかの理由は明かされていませんが、読者は神だけが知っている場所に誘導されます。
Continue には 2 つの主な問題があります:
テスト条件を回避する可能性があります。
等式/不等式式をバイパスできます。
以下の例を見て、どこで問題が発生するかを検討してください:
while (TRUE)
{
...
// 大量のコード
...
if (/ * some条件 */) {
continue;
}
...
// 大量のコード
...
if ( $i++ > STOP_VALUE) Break;
}
注: プログラマがエラーを簡単に見つけられないように、「大量のコード」が必要です。
上記の例を通じて、さらなるルールを導き出すことができます。「継続と中断を混合することは、災害を引き起こす正しい方法です」ということです。
?:
問題は、人々は ? と : の間に多くのコードを詰め込もうとする傾向があることです。以下に、リンクに関する明確なルールをいくつか示します。
条件をかっこで囲んで、コードの残りの部分から分離します。
可能であれば、アクションには単純な関数を使用できます。
アクション、「?」、「:」は、明確に同じ行に配置できない場合は、別の行に配置します。
例:
(条件) ? funct1() : func2();
or
(条件)
?: 別の長いステートメント;
------ -------------------------------------------------- -------------------
宣言ブロックの配置
宣言コードブロックは整列する必要があります。
正当化
明確です。
変数初期化のための同様のコード ブロックがリストされるはずです。
??トークンは名前ではなくタイプに隣接する必要があります
たとえば、
var $mDate
var& $mrDate
var& $mrName
var $mName
$mDate = 0;
$mrDate = NULL;
$mrName = 0;
$mName = NULL;
------------------------------------- ----------------------------------------
1 行に 1 つのステートメント
ステートメントが密接に関連している場合を除き、1 行に 1 つのステートメントのみを記述します。
------------------------------------------------ ----------------------------
短いメソッド
メソッドのコードは 1 ページに制限してください。
理由
その考えは、各メソッドが個別の目的を達成するテクノロジーを表すということです。
無効なパラメーターが多すぎると、長期的には間違いになります。
関数を呼び出すと、まったく呼び出さないよりも遅くなりますが、この決定には慎重な考慮が必要です (時期尚早の最適化を参照)。
------------------------------------------------ ----------------------------
空のステートメントをすべて記録する
for または while の空のブロック ステートメントを常に記録します。コードが欠落しているのか、意図的に書かれていないのかが明確にわかります。
while ($dest++ = $src++)
; // VOID
---------------------------- --- --------------------------------------------------- ---
ゼロ以外の値をテストするデフォルトのメソッドを使用しないでください
ゼロ以外の値をテストするためにデフォルト値を使用しないでください。つまり、次を使用します:
if (FAIL != f())
は次のメソッドよりも優れています:
if (f( ))
FAIL にも値 0 が含まれる可能性があり、PHP はこれを false と見なします。誰かが失敗の戻り値として 0 の代わりに -1 を使用することを決定した場合、
明示的なテストが役に立ちます。比較値が変わらない場合でも、明示的な比較を使用する必要があります。たとえば、if (!($bufsize % strlen($str)))
は次のように記述する必要があります: if (($bufsize % strlen($str) ) == 0) は、テストの数値 (ブール値ではない) タイプを表します。よくある問題は、strcmp を使用して文字方程式をテストすると、結果がデフォルト値と等しくなることがないことです。
非ゼロ テストはデフォルト値に基づいているため、他の関数または式には次の制限が適用されます:
は失敗を示す 0 のみを返すことができ、他の値を返すことはできません。
真の戻り値が完全に明らかになるように名前が付けられており、Checkvalid() の代わりに関数 IsValid() を呼び出します。
------------------------------------------------ ----------------------------
ブール論理型
ほとんどの関数はFALSEの場合は0を返しますが、ゼロ以外の値を再生します。 TRUE なので、ブール値を検出するために式 1 (TRUE、YES など) を使用する代わりに、不等式 0 (FALSE、NO など) を使用します。
if (TRUE == func()) { ...
は次のように記述する必要があります:
if (FALSE != func()) { ...
-------- -------------------------------------------------- -- -----
通常は埋め込み代入を避けてください
場合によっては、埋め込み代入ステートメントがいくつかの場所で見られることがありますが、これらの構造は冗長性が低く、可読性が高いため、より良い方法ではありません。
while ($a != ($c = getchar()))
{
文字を処理します
}
++ と -- 演算子は代入ステートメントに似ています。したがって、多くの目的で、関数を使用すると副作用が発生する可能性があります。埋め込み割り当てを使用すると、実行時のパフォーマンスを向上させることができます。いずれにせよ、プログラマは、埋め込み代入ステートメントを使用する場合、速度の向上と保守性の低下との間のトレードオフを考慮する必要があります。例:
a = b + c;
d = a + r;
d = (a = b + c) +
とは書かないでください。ただし、後者は 1 サイクルを節約できます。しかし、長期的には、プログラムの保守コストが徐々に増加し、プログラム作成者がコードのことを徐々に忘れていくため、成熟期における最適化の効果は減少します。
------------------------------------------------ ------------------------
自分や他の人の努力を再利用する
共通の構造なしでプロジェクト間で再利用する 状況はほぼ不可能です。オブジェクトは既存のサービス要件を満たします。プロセスごとにサービス要件環境が異なるため、オブジェクトの再利用が困難になります。
共通の構造を開発するには、事前に設計に多大な労力が必要です。理由が何であれ、努力がうまくいかないときは、いくつかの方法が推奨されます:
アドバイスを求めてください!グループにメールを送信して助けを求めてください
この単純な方法はめったに使用されません。なぜなら、プログラマの中には、他人に助けを求めると自分が劣っていると思われると考える人がいるからです。他人がやったことを何度も繰り返すのではなく、新しくて興味深い仕事をしてください。
何かのソースコードが必要な場合、誰かがすでにそれを作成している場合は、グループにメールを送信して助けを求めてください。その結果は驚くべきものになるでしょう！
多くの大規模なグループでは、個人は他の人が何をしているかを知らないことがよくあります。何か取り組むべきことを探していて、あなたのためにコーディングをボランティアでやってくれる人も見つかるかもしれません。人々が協力すれば、そこには常に金鉱が存在します。
教えて！何かをしたときは、それについてみんなに伝えてください
何かを再利用できるようにした場合は、他の人にも知らせてください。恥ずかしがらずに、自分のプライドを守るために自分の仕事を隠してはいけません。
自分の仕事を共有する習慣が身につくと、全員がより多くの成果を得ることができます。
小さなライブラリを恐れないでください
コードの再利用に関するよくある問題は、人々が自分が作成したコードからライブラリを作成しないことです。再利用可能なクラスはプログラム ディレクトリに隠れている可能性があり、プログラマがクラスを切り出してライブラリに追加しないため、決して共有されることはありません。
その理由の 1 つは、人々が小さな図書館を作ることを好まず、小さな図書館に対して誤った感情を抱いていることです。この感覚を克服してください。コンピューターはライブラリの数を気にしません。
再利用でき、既存のライブラリに入れることができないコードがある場合は、新しいライブラリを作成します。もし人々が再利用を本気で考えているなら、図書館は長い間それほど小さいままではないだろう。
ライブラリが再構成または追加されるときにメイクファイルを更新する必要があるのが怖い場合は、メイクファイルにライブラリを含めず、サービスのアイデアを含めてください。ベースレベルのメイクファイルは、それぞれが一連のサービスで構成されます。上位レベルの Makefile は必要なサービスを指定します。サービスのライブラリが変更されると、下位レベルの Makefile のみを変更する必要があります。
ほとんどの企業は、どのようなコードを持っているかを知りません。ほとんどのプログラマーは依然として、自分が何をしたかを伝えたり、現在存在するものを尋ねたりすることができません。その解決策は、利用可能なもののリポジトリを保持することです
理想的な世界では、プログラマーは Web ページにアクセスして、そのリストを参照または検索できます。プログラマーが自発的にそのようなシステムを維持できるようなシステムをセットアップできれば、再利用性の検出を担当するライブラリアンがいる場合は、さらに良いでしょう。
別のアプローチは、自動的に生成することです。ソース コードからのリポジトリ。これは、マニュアル ページとリポジトリ エントリとしても機能する共通のクラス、メソッド、ライブラリ、およびサブシステム ヘッダーを使用して行われます。 -------------------------------------------------- -- --------
評価ノート
コメントはストーリーを伝える必要があります
コメントはシステムを説明するストーリーであると考えてください。コメントはロボットによって抽出され、クラス コメントに形成されることを期待してください。はストーリーの一部であり、メソッド署名のコメントはストーリーの別の部分であり、メソッドの引数は別の部分であり、メソッドの実装はさらに別の部分であり、これらすべての部分が織り込まれ、別の時点であなたが何をしたかを正確に他の人に知らせる必要があります。なぜ
決定事項を文書化する
何をするかを選択したすべての時点で、どのような選択をしたのか、そしてその理由を説明するコメントを記述する必要があります。
ヘッダーの説明を使用します。
ccdoc に似たドキュメント抽出システムを使用します。 ccdoc を使用してクラスとメソッドを文書化する方法については、このドキュメントの別の場所で説明します。
これらのヘッダーの説明は、通常のヘッダーのように役に立たない方法で抽出、分析、整理することができます。
それでは、時間をかけて彼を埋めてください。
注釈レイアウト
プロジェクトの各部分には、特定の注釈レイアウトがあります。埋め込みキーワードは、問題や潜在的な問題を指摘するために使用されます。キーワードを抽出し、必要に応じて特別な努力をすることができるようにレポートを作成します
キーワードを見つけました
:TODO: トピック
ここでやるべきことがまだあることを意味します
。
:BUG: [bugid] topic
は、ここに既知のバグがあることを意味します。それを説明し、必要に応じてバグ ID を指定します。
:KLUDGE:
何か醜いことをしたときは、その旨を述べ、どのようにするかを説明します。次回はもっと時間があれば別の方法で説明します。
:TRICKY:
次のコードは非常に難しいので、何も考えずに変更しないでください。
:警告:
何か注意してください。
:
ファーザーの問題を回避する必要がある場合があります。この問題は最終的に解決される可能性があります。独自の属性を作成できます。
Gotcha の書式設定
コメントの最初の記号にします
コメントは複数の行で構成されますが、最初の行は内容が含まれた意味のある要約である必要があります
。コメントには、筆者の名前と発言の日付を含める必要があります。この情報はソース リポジトリにありますが、いつ、誰によって追加されたかを調べるにはかなりの時間がかかる場合があります。問題は必要以上に長く残ることがよくあります。日付情報を埋め込むと、他のプログラマがこの決定を下せるようになります。誰の情報を埋め込むと、誰に質問すればよいかがわかります。
例
// :TODO: tmh 960810: パフォーマンスの問題の可能性があります
// ここでは実際にはハッシュ テーブルを使用する必要がありますが、今のところは線形検索を使用します
// :難問: tmh 960810: 安全でない型キャストの可能性があります
// 派生型を回復するには、ここでキャストが必要です。
// おそらく仮想メソッドまたはテンプレートを使用する必要があります。
関連項目
ドキュメントのレイアウト方法の詳細については、「インターフェイスと実装のドキュメント」を参照してください。
------------------------------------------------ ----------------------------
インターフェイスと実装のドキュメント
ドキュメントの主な対象読者は 2 つです:
クラス ユーザー
クラスの実装者
少し考えれば、両方のタイプのドキュメントをソース コードから直接抽出できます。
クラスユーザー
クラスユーザーは、正しく構造化されていればヘッダーファイルから直接抽出できるクラスインターフェース情報を必要とします。クラスのヘッダー コメント ブロックに記入するときは、そのクラスを使用するプログラマが必要とする情報のみを含めてください。クラスのユーザーが詳細を必要とする場合を除き、アルゴリズム実装の詳細を掘り下げないでください。ヘッダー ファイル内のコメントが待機中のマニュアル ページであると考えてください。
クラス実装者
クラス実装者には、クラスの実装方法についての深い知識が必要です。このコメント タイプは、クラスを実装するソース ファイル内にあります。インターフェースの問題については心配しないでください。ソース ファイル内のヘッダー コメント ブロックは、アルゴリズムの問題やその他の設計上の決定をカバーする必要があります。メソッドの実装内のコメント ブロックでは、さらに詳しい説明が必要です。
------------------------------------------------ ----------------------------
目录文档
すべての目录下都にはREADME文档が必要です。その中に含まれるもの:
该コンテンツの機能とその機能连接相关资源：
源文件索引
在線上文档
纸文档
设计文档
その他对读者有帮助的东西
考虑一下，当每原有の工程人员走了，在6月内に来た新人の孤独な探索者は、
工程全体のソースコード目録、ソースファイルの説明文、ソースファイルの説明文などを管理しており、これは工程全体を横断する能力を持っています。
------------------------------------------------- -------------------------
デザインの表記法とプロセスを使用する
プログラマーはコーディングやデザインについて話すための共通言語をもつ必要がある、およびソフトウェアプロセス全般。これはプロジェクトの成功にとって重要です。
どのプロジェクトにも、さまざまなスキル、知識、経験を持つ人々が集まります。たとえプロジェクトの参加者全員が天才だったとしても、プロジェクトを結び付ける共通の言語やプロセスがないため、人々は際限なくすれ違い続けるため、失敗することはあります。大規模な戦い、燃え尽き症候群、そしてほとんど進歩が得られないだけです。グループをトレーニングに参加させた場合、経験豊富な専門家が戻ってくるとは限りませんが、少なくともグループ全員が同じ認識を持つことになります。チーム。
世の中には人気のある方法論がたくさんあります。重要なのは、リサーチを行い、方法を選択し、それについて従業員をトレーニングし、それを使用することです。このページの上部にあるさまざまな方法論へのリンクをご覧ください。
デザインを解明するための CRC (クラス責任カード) アプローチが役に立つかもしれません。他にも多くの人がそうしています。これは、チームの協力を促進し、属性を持つオブジェクトではなく、何かを実行するオブジェクトに焦点を当てる非公式なアプローチです。これについては、Nancy M. Wilkinson 著『Using CRC Cards』という本も出版されています。
---------------------------------------------- ------------------------
ユースケースの使用
ユースケースとは、複数のオブジェクトが関与するトランザクション全体の一般的な説明です。 。ユースケースは、組織などの一連のオブジェクトの動作を記述することもできます。したがって、ユース ケース モデルはユース ケースのコレクションを表し、通常はアプリケーション システム全体と、システムと対話する 1 つ以上の外部アクターの動作を指定するために使用されます。
個々のユースケースには名前が付いている場合があります (ただし、通常は単純な名前ではありません)。その意味は、多くの場合、トランザクションを構成する外部アクターとオブジェクト間のイベントのシーケンスに関する非公式のテキスト記述として記述されます。ユースケースには、その動作の一部として他のユースケースを含めることができます。
要件のキャプチャ
ユースケースは、システムの要件をわかりやすい形式でキャプチャしようとします。このアイデアは、一連のユースケースを実行することで、システムが本来行うべきことを実行していることを検証できるというものです。
システムが何を達成する必要があるかを説明するために、必要なだけ多くのユースケースを用意します。
プロセス
構築しようとしているシステムを理解することから始めます。
さまざまな利用者全員がシステムをどのように使用するかを説明する一連のユースケースを作成します。
システムのクラスとオブジェクト モデルを作成します。
すべてのユースケースを実行して、モデルがすべてのケースを処理できることを確認します。必要に応じてモデルを更新し、新しいユースケースを作成します。
------------------------------------------------ ----------------------------
オープン/クローズの原則
オープン/クローズの原則では、クラスはどこで開いていても閉じていなければならないと規定されています。 :
open は、クラスが拡張できることを意味します。
closed は、クラスが拡張以外の変更に対して閉じられていることを意味します。コード レビュー、単体テスト、その他の認定手順を経てクラスの使用が承認されたら、クラスをあまり変更せず、拡張するだけでよいという考え方です。
オープン/クローズの原則は安定性のためのピッチです。システムは、すでに動作しているコードを変更するのではなく、新しいコードを追加することによって拡張されます。プログラマーは、古いコードが機能するからといって、それを変更することに抵抗を感じることがよくあります。この原則は、あなたの懸念を学術的に正当化するものを提供するだけです :-)
実際には、オープン/クローズド原則は、単に私たちの古い友人である抽象化とポリモーフィズムをうまく利用することを意味します。共通のプロセスやアイデアを取り出すための抽象化。派生クラスが従う必要があるインターフェイスを作成するための継承。
------------------------------------------------ ----------------------------
契約による設計
契約による設計の考え方は、LSP と強く関連しています。契約は、相手方に何を期待するかを正式に表明したものです。この場合、コントラクトはコード間の部分にあります。オブジェクトやメソッドは、それが X を行うと述べており、それを信じる必要があります。たとえば、オブジェクトの体積を尋ねると、それが得られるはずです。また、体積は物の検証可能な属性であるため、一連のチェックを実行して、体積が正しいこと、つまり契約を満たしていることを検証できます。
エッフェルのような言語では、実際には言語の一部である事前条件文と事後条件文によって契約が強制されます。他の言語では、少し信仰が必要です。
言語ベースの検証メカニズムと組み合わせた契約による設計は、非常に強力なアイデアです。これにより、プログラミングは仕様に定められた部品を組み立てるようになります。
------------------------------------------------ ----------------------------
その他の杂项
この一部には、さまざまなさまざまな内容が含まれています
必要な数値だけを使用するため、浮遊量を使用する必要はありません。用 = または =>
プログラム自動化ツールを使用する必要はありません。優れたプログラム形式を実現する主要な人物は、プログラム自身、特に、事前に準備された
コード、計算法設計のプログラムで、プログラム自動化器のみを使用します。慣例に従ってプログラムを修正することができるため、空白や空白に対する注意が非常に必要な場合には、これは実現不可能です。ある関数は、ある数値やファイルを完成させるために使用されます (言い換えると、これらの直接的な定義は、プログラムが自動的に実行するものではなく、計画的なものであり、プログラムが自動的に認識できるものではありません)。当初のメマイザーはソースコードを解析する必要があるプログラムであり、複雑なメマイザーではそのような利点を得ることができず、全体的なメッセージを生成するのに最適です。コンピューター構築（機械生成）形式コード。 ... }
プログラムはここで真のものですか？一般的にはよくありますが、通常はそうではありません。これはこのような混乱を引き起こすことを避けますか？和式の判断、推論の方法は、実行前に実行されます:
$abool= $bbool;
if ($abool) { ... }
-------------------------------------------------- ------------------------
外部コード ブロックにコメントするには if (0) を使用します
テストの大部分をコメントする必要がある場合があります簡単な方法は if (0) ブロックを使用することです:
function example()
{
見栄えの良いコード
if (0) {
たくさんのコード
}
その他のコード
}
コメントの中にコメントを含めることはできないため、/**/ は使用できませんが、プログラムの大部分にはコメントを含めることができます。
------------------------------------------------ ----------------------------
さまざまなアクセサー スタイル
アクセサーを使用する理由
アクセス メソッドは物理属性または論理属性へのアクセスを提供します。オブジェクトの依存関係を解消するために、属性への直接アクセスを禁止しています。これは、属性に直接アクセスすると、オブジェクトの実装の詳細が公開される理由を自問してください:
物理的な包含以外の方法で属性を提供するにはどうすればよいでしょうか?
その属性をデータベースで検索する必要がある場合はどうなるでしょうか?
上記の変更されたコードのいずれかが壊れる場合はどうなりますか?オブジェクトは、特定の属性へのアクセスを提供するためにユーザーと契約を結びます。物理属性へのアクセスは、そのような約束をするものではありません。アクセサーの作成には 3 つの主要な慣用句があります。
Get/Set
class
}
1 つのメソッド名
class ;
}
Get/Set と似ていますが、
Attributes としての属性を使用しない場合は、このアプローチを使用します。オブジェクトとして
class X
{
function Age() { return $mAge; }
function Name() { return mName; ) { return &$mName; }
var $mAge;
var $mName;
}
X $x;
$x->rName()= "test";
上記の 2 つの属性例は、オブジェクトとしての属性アプローチの長所と短所を示しています。
実際のオブジェクトではない rAge() を使用する場合、オブジェクトは値のチェックを行わないため、変数が直接設定されます。ただし、多くの単純な属性の場合、これらはひどい制限ではありません
----------------------------- ------------------------ ------------------------
レイヤリング
レイヤ化は、システムの複雑さを軽減するための主要な手法です。レイヤは、明確に定義されたインターフェイスを使用して、隣接するレイヤ間で通信する必要があります。レイヤが隣接しないレイヤを使用すると、レイヤ化違反が発生します。
レイヤ化違反とは、明確に定義されたインターフェイスによって制御されないレイヤ間の依存関係があることを意味します。レイヤの 1 つが変更されるとコードが壊れる可能性があるため、レイヤは他の隣接するレイヤとのみ動作する必要があります。
パフォーマンス上の理由からレイヤーをジャンプする必要がある場合がありますが、これは問題ありませんが、それを行っていることを理解し、適切に文書化する必要があります。 --------------------- ---------------------------- -------
コード レビュー
もしあなたが正式なコード レビューを機能させることができるなら、私はそのことに脱帽します。また、疑わしい見返りのために多くの人の時間を奪う傾向があります
なんてことだ、彼はエンジニアではありません
そうではありません、それはコードレビューの形式と、それが通常は遅れて混沌としている状況にどのように適合するかです。問題はプロジェクトです
まず、コード レビューはあまりにも遅すぎて、有益なことは何もできません。レビューする必要があるのは要件と設計です
関係者全員を集めてください。前者が適切であり、後者が満たされるまで、クラスの設計と要件を検討します。すべての関係者が部屋にいるため、質問や問題がすぐに解決されるため、このプロセスは非常に実りあるものになります。通常、そのような会議は数回だけ必要です
上記のプロセスが適切に行われていれば、コードレビューで問題が見つかった場合、通常できる最善の方法は、誰かが沈んだ後に書き直すことです。コードを「機能」させるには膨大な時間と労力がかかります
コードレビューを実行したい場合は、オフラインで実行してください。信頼できる数人に問題のコードを読んでもらい、プログラマにコメントを書いてもらいます。その後、プログラマとレビュー担当者が問題を話し合って解決することができます。電子メールや簡単な論点の議論は効果的です。このアプローチは目標を達成しており、6 人がかかる時間はかかりません。
------------------------------------------------ ----------------------------
頻繁ではなく早期にソース コード管理システムを作成する
一般的なビルド システムとソース コード管理システムは、プロジェクトのライフサイクルのできるだけ早い段階で、できればコーディングを開始する前に導入する必要があります。ソース コード管理は、プロジェクトを結合する構造的な接着剤です。プログラマーがお互いの製品を簡単に使用できない場合、再現性の高いビルドを作成することはできず、人々は多くの時間を無駄にするでしょう。また、不正なビルド環境を標準システムに変換するのは地獄です。しかし、完全に正しく動作することは決してない独自のカスタム環境を構築することは、すべてのプロジェクトにとっての通過点であるように思えます。
留意すべきいくつかの問題:
CVS のような共有ソース環境は、通常、大規模なプロジェクトで最適に機能します。
CVS を使用する場合は、参照ツリーのアプローチを使用します。このアプローチでは、さまざまなビルドのマスター ビルド ツリーが保持されます。プログラマーは、作業中のビルドに対してソースをチェックアウトします。 make システムはローカルに見つからないものに対してビルドを使用するため、必要なものだけをチェックアウトします。 -I フラグと -L フラグを使用すると、このシステムのセットアップが簡単になります。ファイルとライブラリをローカルで検索してから、リファレンス ビルド内で検索します。このアプローチにより、ディスク容量とビルド時間が節約されます。
ディスク容量を多く確保します。ディスク容量がこれほど安いのであれば、大量のビルドを保持しない理由はありません。
シンプルなものをシンプルに。非常にシンプルで、以下の方法について十分に文書化されている必要があります:
ビルドするモジュールをチェックアウトする
ファイルを変更する方法
新しいモジュールをシステムに追加する方法
モジュールとファイルを削除する方法
変更をチェックインする方法
利用可能なライブラリとインクルードファイルは何ですか
すべてのコンパイラやその他のツールを含むビルド環境を取得する方法
Webページやドキュメントなどを作成します。新しいプログラマは、古いプログラマにビルドの秘密を懇願する必要はありません。
チェックイン時のログコメントが役立つはずです。これらのコメントは毎晩収集され、関係者に送信される必要があります。
出典
お金があるなら、多くのプロジェクトが Clear Case が良いシステムだと考えています。完璧に動作するシステムは、GNU make と CVS 上に構築されています。 CVS は、RCS 上に構築されたフリーウェア ビルド環境です。 RCS との主な違いは、ソフトウェアを構築するための共有ファイル モデルをサポートしていることです。
------------------------------------------------ ----------------------------
バグ追跡システムは早期に作成し、頻繁には作成しないでください
早い人ほどバグの使用に慣れます追跡システムがあればあるほど良い。プロジェクトが 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("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(); }
else if (THEY_DIDNT_PAY == $foo) { 無限ループ(); }
else { happy_days_i_know_why_im_here(); }
现在不是变得更好了么?
-------------------------------------- ----------------------------------------
OOの約束
OOが宣伝されましたそれが世界の飢餓を解決し、世界平和の新時代をもたらすとあなたが思う限り。ない！ OO はアプローチであり哲学であり、盲目的に従うことで品質が得られるレシピではありません。
Robert Martin は OO を大局的に捉えています:
OO は、適切に使用するとソフトウェアの再利用性を高めます。ただし、そのためには複雑さと設計時間が犠牲になります。再利用可能なコードはより複雑で、設計と実装に時間がかかります。さらに、わずかでも再利用可能なものを作成するには、2 回以上の試行が必要になることもよくあります。
OO を適切に使用すると、ソフトウェアの変化に対する回復力が強化されます。ただし、そのためには複雑さと設計時間が犠牲になります。このトレードオフは、ほとんどの場合勝利となりますが、時には受け入れがたいものもあります。
OO は必ずしも何かを理解しやすくするものではありません。ソフトウェアの概念とすべての人間の現実世界の地図の間には、魔法のようなマッピングは存在しません。人はそれぞれ異なります。ある人はシンプルでエレガントなデザインと認識しますが、別の人は複雑で不透明であると認識します。
チームが上記のポイント 1 を適用して再利用可能なアイテムのリポジトリを作成できた場合、再利用により開発時間が大幅に短縮され始める可能性があります。
上記のポイント 2 を適用して、チームが変更に強いソフトウェアを作成できた場合、そのソフトウェアのメンテナンスははるかに簡単になり、エラーが発生しにくくなります。
------------------------------------------------ ----------------------------
Thin クラス インターフェイスと Fat クラス インターフェイス
オブジェクトにはメソッドがいくつ必要ですか?もちろん、正しい答えはちょうどいい量であり、これをゴルディロックス レベルと呼びます。しかし、ゴルディロックスのレベルとは何でしょうか?それは存在しません。状況に応じて正しい判断を下す必要があります。それがプログラマーの真の目的です :-)
2 つの極端は、シン クラスとシック クラスです。シン クラスは最小限のクラスです。シン クラスにはメソッドができるだけ少なくなります。ユーザーは必要なメソッドを追加してシン クラスから独自のクラスを派生させることが期待されます。
薄いクラスは「きれい」に見えるかもしれませんが、実際はそうではありません。薄いクラスでは多くのことはできません。その主な目的は、タイプを設定することです。シン クラスには機能が非常に少ないため、プロジェクト内の多くのプログラマは派生クラスを作成し、全員が基本的に同じメソッドを追加します。これはコードの重複やメンテナンスの問題につながりますが、これがそもそもオブジェクトを使用する理由の 1 つです。明らかな解決策は、メソッドを基本クラスにプッシュすることです。十分なメソッドを基本クラスにプッシュすると、厚いクラスが得られます。
厚いクラスにはたくさんのメソッドがあります。それを思いつくことができれば、厚いクラスにはそれがあります。なぜこれが問題になるのでしょうか?そうではないかもしれません。メソッドがクラスに直接関連している場合、それらを含むクラスに実際的な問題はありません。問題は、人々が怠けて、クラスに関連するメソッドを、柳のような方法でクラスに追加し始めることですが、別のクラスに取り込んだほうがよいでしょう。再び判断が問われます。
厚いクラスには別の問題があります。クラスの規模が大きくなると、理解が難しくなる可能性があります。また、インタラクションの予測が困難になるため、デバッグも困難になります。また、使用しない、またはコードを気にしないメソッドが変更された場合でも、コードを再テストして再リリースする必要があります。
------------------------------------------------- -------------------------
最近の変更点
2000-11-16。リリース
------------------------------------------------ ----------------------------著作権 1995-2000。トッド・ホフとフレドリック・クリスチャンセン。無断転載を禁じます。
------------------------------------------------- -------------------------
http://www.hooday.com/html/PHP%20Coding%20Standard_cn.htm
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
