?
最近、非常に洞察力に富んだ記事を読んだので、それを共有したいと思います。
まだ次の現象が発生する場合は、まだ PHP 初心者です。
1.コードに適切に注釈を付けるために phpDoc ツールなどを使用しないでください。
2. Zend Studio や Eclipse PDT などの優れた統合開発環境には目をつぶってください。
3. いかなる形式のバージョン管理システムも使用しないでください。 as Subclipse;
4. 特定のコーディングおよび命名標準、および一般的な規則を採用せず、プロジェクト開発サイクル全体にわたってそれらを実装できません。
6.一部の入力または SQL クエリ文字列を変換 (または) しないでください (PHP 関連関数を参照)。
8. テスト駆動開発を使用しないでください。 ;
9. エラーを有効にしてテストしないでください。
11. コードをリファクタリングしないでください。プログラムの異なる層を分離するための MVC;
13. KISS、DRY、MVC、OOP、REST の概念を理解していない。
14. コンテンツを返す代わりに、コンテンツを直接出力 (エコー/出力)。関数またはクラス;
15. 単体テストまたは一般的なテストの利点には目をつぶってください。
16. 常にハードコードされた HTML を返します。
17. 「メッセージ」と「構成パラメータ」を常にハードコーディングします。
18. SQL クエリ ステートメントを最適化しないでください。
19. __autoload を使用しないでください。
20. インテリジェントなエラー処理を許可しないでください。
21.破壊的な転送操作を行うには、$_POST の代わりに $_GET を使用します。
23. SQL インジェクションまたはクロスサイト スクリプティングについては聞いたことがありません。構成は許可されず、クラスの構築も許可されません。関数はパラメータの転送を受け入れ、実行時に set/get メソッドまたは定数定義を実行します。
25. オブジェクト指向プログラミング (OOP) の長所と短所を理解していません。 ;
26. 状況の規模に関係なく OOP を悪用する
27. コードを OOP に準拠させる必要があると考える。
29. 単一の構成ファイルは使用しません。
30 ファイルのソースコードを公開したくないが、.php の代わりに .inc を使用します。
>32. DRY スタイルを維持できない、つまり、常にコピーアンドペーストしている場合は、設計が不十分であることを示しています。
33. 1 つのことだけを行うクラス/メソッド。組み合わせて使用することはできません。
34. 抽象化クラス、インターフェイス、継承、アクセス制御修飾子などの OOP の利点を試さないでください。既存の設計パターンを使用してプログラムのシステム設計を最適化します。
36. 多数のファイルまたはディレクトリがある場合は、ユーザーに操作を許可しません。必要に応じて、名前空間を定義します。
37.共通の文字列を使用したライブラリ関数。
39. 既存の PHP 開発フレームワークに注意を払わない。実際、そこには高度な開発コンセプトと素晴らしいコードが含まれています。
まだ次の現象が発生する場合は、まだ PHP 初心者です。
1.コードに適切に注釈を付けるために phpDoc ツールなどを使用しないでください。
2. Zend Studio や Eclipse PDT などの優れた統合開発環境には目をつぶってください。
3. いかなる形式のバージョン管理システムも使用しないでください。 as Subclipse;
4. 特定のコーディングおよび命名標準、および一般的な規則を採用せず、プロジェクト開発サイクル全体にわたってそれらを実装できません。
6.一部の入力または SQL クエリ文字列を変換 (または) しないでください (PHP 関連関数を参照)。
8. テスト駆動開発を使用しないでください。 ;
9. エラーを有効にしてテストしないでください。
11. コードをリファクタリングしないでください。プログラムの異なる層を分離するための MVC;
13. KISS、DRY、MVC、OOP、REST の概念を理解していない。
14. コンテンツを返す代わりに、コンテンツを直接出力 (エコー/出力)。関数またはクラス;
15. 単体テストまたは一般的なテストの利点には目をつぶってください。
16. 常にハードコードされた HTML を返します。
17. 「メッセージ」と「構成パラメータ」を常にハードコーディングします。
18. SQL クエリ ステートメントを最適化しないでください。
19. __autoload を使用しないでください。
20. インテリジェントなエラー処理を許可しないでください。
21.破壊的な転送操作を行うには、$_POST の代わりに $_GET を使用します。
23. SQL インジェクションまたはクロスサイト スクリプティングについては聞いたことがありません。構成は許可されず、クラスの構築も許可されません。関数はパラメータの転送を受け入れ、実行時に set/get メソッドまたは定数定義を実行します。
25. オブジェクト指向プログラミング (OOP) の長所と短所を理解していません。 ;
26. 状況の規模に関係なく OOP を悪用する
27. コードを OOP に準拠させる必要があると考える。
29. 単一の構成ファイルは使用しません。
30 ファイルのソースコードを公開したくないが、.php の代わりに .inc を使用します。
>32. DRY スタイルを維持できない、つまり、常にコピーアンドペーストしている場合は、設計が不十分であることを示しています。
33. 1 つのことだけを行うクラス/メソッド。組み合わせて使用することはできません。
34. 抽象化クラス、インターフェイス、継承、アクセス制御修飾子などの OOP の利点を試さないでください。既存の設計パターンを使用してプログラムのシステム設計を最適化します。
36. 多数のファイルまたはディレクトリがある場合は、ユーザーに操作を許可しません。必要に応じて、名前空間を定義します。
37.共通の文字列を使用したライブラリ関数。
39. 既存の PHP 開発フレームワークに注意を払わない。実際、そこには高度な開発コンセプトと素晴らしいコードが含まれています。
