Fork me on GitHub

PHP

The Wrong Way

最終更新日: 2023-01-31
cartoon

概要

PHPプログラミングの世界では、ある一定のトレンドが「モダンPHP」として、一部の人によって (彼らの書籍やウェブサイト上で) 強烈に広められ、他のアプローチは、遅れていたり、愚かだったり、あるいは単に間違いだとみなされて、眉をひそめられています。

それらの人々は、彼らの物事のやり方を他人に追従させようと、飽くなき努力を続けているように見えます。

このウェブサイトは、PHP プログラミングに関する現実的な見解を示すために作られました。流行りのトレンド、理論、学問的な教示ではなく、経験と実践の帰着を書き記した視点です。

ウェブサイト PHP - The Wrong Way は生きたドキュメントですので、より多くの情報が明らかになるにしたがって更新され続けます。

お気軽にコントリビュートしてください。

翻訳

過激主義の危険性

プログラミングルールとガイドラインに関する問題のひとつに、それらがしばしば特定のコンテキスト内の目的にしか役に立たないことが挙げられます。コンテキストから逸脱すると、良いルールは恐ろしいルールになりえます。じっさいに、すべての良いルールは行き過ぎると悪いものになります。

なぜかを理解するうえで重要なのは、時間の経過とともに開発され、多くの異なる人々によって提示されたソフトウェア開発の原則やルールの大多数は、しばしば過激派の手によって誤用されたということです。

一般的なルールやガイドラインの誤用はつねに、合併症、セキュリティの欠如、エラーの発生しやすさ、場合によっては、完全かつ純然たる災害をもたらすと、経験が教えています。

“Keep It Simple, Stupid” の頭文字である KISS 原則 は、非常に賢明で優れた原則であり、一般に経験豊かな人々が従うべき非常に良いアドバイスとみなされますが、この大きな原則さえも、極端に取られるとプロジェクトにとって危険です。「あまりの単純さ」は、必要な機能の不足をもたらすことがあります。

間違った方法: ルールとガイドラインの宗教的な遵守。 だめ

常にフレームワークを使うこと

すべての汎用 PHP フレームワークはクソ!

ラスマス・ラードフ

PHP コミュニティにおいて、実に良くないトレンドが、Web アプリケーションを開発するためのデファクトスタンダードになってしまいました。流行っている汎用フレームワークを使う方法です。

このトレンドは、それがとにかく開発プロセスの結果を向上させるからでも、技術と構造的視点から行うことが正しいからでもありません。このトレンドが大衆化したのは、いくらかのフレームワーク開発者が、「車輪の再発明をするな!」「自分でするな、他者のほうがあなたより熟練している!」といったお決まりの文句に立脚して、プログラミングを論じる輩の排除に成功したためです。

今日のプログラマの多くは、健全なプログラミングの基本原則を完全に無視し、彼らは、よりクレバーに、よりクールに、仲間とみなしたどんな人にもより受け入れやすく見えるよう、新たな複雑さの層を幻想的にするがために多くの時間を費やしています。

こういった人々は、他の人が自分たちの「やり方」に従うこと、PHP コミュニティのリーダーか何かになること、そして彼らの最新版の「イケてる」オープンソースツールを他の人に使ってもらうことに夢中になり、彼らが提供している助言が健全かつ堅実であるか確かめるのを忘れているようです。

ソフトウェア業界では、汎用フレームワークを、建造済みの家で比喩することができます。建造済みの家をまとめるだけでは大工になれないように、汎用フレームワークを使ってソフトウェアを構築しても、コーダーやプログラマーにはなれません。

このウェブサイトでは、フレームワークとライブラリを次のように区別します:

Python と Ruby の世界では、当初から Python も Ruby もウェブサイトを構築するために作られていなかったため、ウェブサイトを構築するのは面倒でした。その結果、DjangoRuby on Rails などの汎用フレームワークが、これらの言語でウェブサイトを構築するために急速に普及しました。

いっぽう PHP は当初から、ラスマス・ラードフによって C 言語で書かれた一連のツールとして、動的 HTML を簡単かつ迅速に開発してもらえるようにと作成されました。今なおそうなのですが、そのような PHP は、それ自体がフレームワーク でした。

PHP はそれからずいぶん進化していて、今日、PHP は HTML やウェブサイトを構築する以外にも使用できるとはいえ、PHP 自体を一種のフレームワークとみなすことは間違いではありません。PHP は生まれつき、もっぱら手続き型の C 言語で書かれていた Web アプリケーション開発のための抽象化層です。

プロジェクト内でライブラリを使用するのは当然です。PHP 自体には、独自のコードを拡張するために使用できる一連のライブラリがバンドルされています。例えば、PDO は PHP でデータベースにアクセスするための一貫したインターフェースを提供する軽量ライブラリです。

それに対して PHP の上でフレームワークを使用することは、まったく別の問題です。

PHP でフレームワークを使用すると、抽象レイヤーを別の抽象レイヤーの上に追加してしまいます。一方は最初から使えるよう用意されているのに。フレームワークから提供される抽象概念の追加レイヤーが与えてくれるのは、コードをあらかじめ決められた一定のパターンに編成することか、あるいは、何百何千ものクラスとメソッドを依存関係の悪夢に絡み合わせて過剰な複雑さを追加することか、どちらにしても、コードに複雑なレイヤーを追加することになり、不要です!

すべての経験はインターフェースから始まります。インターフェースの経験は、基盤技術と抽象レイヤの量の結果です。使用した抽象が多くなれば、インターフェースの効率が低下し、アプリケーションはエラーが発生しやすくなります。抽象度が高いほど、詳細と効率が失われます。

はっきりと理解すること: どんなプロジェクトでも、コードの理想は、可能な限り少ない行数で、可能な限り明確かつ可読であること!

誰も必要としていないのは、万能なフレームワークです。みんながみんな一般的な問題を抱えているわけではなく、みな非常に特殊な問題を抱え解決しようと試みています。

ラスマス・ラードフ

ある企業は、PHP フレームワークに関する誇大宣伝を耳にして、そういった流行っている汎用フレームワークのひとつを使って次のプロジェクトを開始しましたが、災害に終わっただけでした。汎用フレームワークは、彼らの非常に特別なニーズを解決するにあたって本当に悪いものだと発見しただけでなく、それは稼働中も究極的に遅かったのです。スケール不可能で、その結果、彼らは本当に必要のないものすべてを抜き出すために、絶望的な試みのなか、フレームワークを切断分割し始めました。

常に実用的なアプローチを使用すること:

行動や方針は、理論や教義ではなく、直接的な実践的結果を考慮して、決定される。

– コリンズ英語辞典, Complete and Unabridged, 第 12 版 2014

間違った方法: PHP 上で常にフレームワークを使うこと。 だめ

常にデザインパターンを使用すること

私には、象牙の塔のデザインとデザインパターンへの、強いアレルギーがあります。ピーター・ノーヴィグは、ハーレクインにいたとき、デザインパターンが現実にはプログラム言語の欠陥であるという点に関して、論文を出しました。より良いプログラミング言語を手に入れましょう。彼は絶対に正しい。パターンの崇拝、「ああ、私はパターン X を使います」の考察。

– ブレンダン・アイク Coders at work - Reflections on the Craft of Programming

ソフトウェア・エンジニアリングでは、デザインパターンは、ソフトウェア設計における一般的な問題に対する、再利用可能なソリューションです。 デザインパターンは、コードに直接変換できる最終設計ではありません。これは、さまざまな状況で使用できる、問題を解決する方法の説明またはアイデアです。オブジェクト指向のデザインパターンは、通常、関連する最終アプリケーションクラスまたはオブジェクトを決定づけるのではなく、クラスまたはオブジェクト間の関係および相互作用を示します。

PHP は、命令型、関数型、オブジェクト指向、手続き型、およびリフレクティブなパラダイムをサポートしています。PHP は、さまざまな方法で多くの問題を解決することを可能とする、異種混合なツールを備えた巨大な道具箱です。

PHPはすべて自由で、高速でスケーラブルなソリューションであり、さまざまな方法で問題を処理します。

私たちは、自身を改善しようとすると、この場合具体的にはコードをですが、ときどき、特定のパターンの哲学や思想に縛られ、実際に考えることを忘れる傾向があります。

私は、自分のプログラムでパターンを見かけると、それを不具合の兆候と考えます。プログラムの形は、解決の必要がある問題のみを反映するべきです。コードにあるその他の規則性は、少なくとも私には、自分が不十分で貧弱な抽象を使用していることを示すサインで、私はよく、記述しないといけないマクロの拡張を手作業で生成しています。

ポール・グレアム

特定のパターンやソリューションの背後にある哲学や思想を、キャッチアップする必要はありません。私たちの主な関心事は、コードを、可能な限りナビゲートしやすくかつ理解しやすく保ち、その結果、保守が容易で安全性を保ちやすくすることです。

私たちはまた、アンチパターンのようなものが存在することを覚えておく必要があります。これは、一般的に使用されうるけれども、実際には効果的でなく、かつ/または非生産的であるパターンのことです。

私は、パターンとは、一般的に認識された最適な解決策として、共通した問題のために始まったと思います。しかし、しばらく彼らの側にいたところ、人々が自分の読んだことがあるすべてのパターンを詰め込もうとしたために (「私のアプリケーションはよく構成されているぞ、なぜならパターンをともなってアゴの贅肉にロードされるからな」) アプリケーションがあるべき姿の 10 倍以上複雑になってしまった経験があって、パターンの価値について、私の印象は少し下がりました。

– ポール・ウィートン Evil Design Patterns

常に実用的なアプローチを使用すること:

行動や方針は、理論や教義ではなく、直接的な実践的結果を考慮して、決定される。

– コリンズ英語辞典, Complete and Unabridged, 第 12 版 2014

間違った方法: 問題を解決できるパターンを探すこと。 だめ

常にオブジェクト指向プログラミングを使うこと

オブジェクト指向言語の問題は、これらの暗黙の環境をすべて持ち歩いていることです。あなたはバナナを欲しましたが、あなたが得たものはバナナを抱えたゴリラとジャングル全体でした。

– ジョー・アームストロング in Coders at work - Reflections on the Craft of Programming

抽象化は強力ですね。私が本当にアレルギーを持つもの、そして 90 年代に反応したのは、ありとあらゆる CORBA、COM、DCOM、オブジェクト指向ナンセンスでした。当時のスタートアップには、起動して “Hello world” を印刷するために 200,000 回のメソッド呼び出しが必要だといった、なんだか狂ったことがありました。残念です! その種のことに関わるプログラマーになりたくはないですよね。

– ブレンダン・アイク in Coders at work - Reflections on the Craft of Programming

今日、多くのソフトウェア開発者や多くの企業は、オブジェクト指向プログラミングだけが、ソフトウェアを開発する合理的な方法だと感じています。オブジェクト指向プログラミングに反対する人は、彼らが業界の「伝統的な知性」に反対しているんじゃないかと、すぐに萎縮してしまいます。

プログラミングのブログやフォーラムでは、とても多くの人がオブジェクト指向プログラミングを擁護し、何について話しているか自分でわかっていると確信しています。標準の定義が不足しているにもかかわらずですよ!

実際のところ、オブジェクト指向プログラミングと呼ばれるようなものは、しばしば不必要な複雑さの重い負担を強います。

コンピュータ科学者やプログラマとして、私たちは、こだわりを脇において、与えられた問題に対する最良の解決策を見つける、ということを学ぶ必要があります。

今日、PHP の主な強みのひとつは、命令型、関数型、オブジェクト指向、手続き型、およびリフレクティブの全パラダイムのサポートです。PHP はさまざまなツールを備えた巨大なツールボックスであり、さまざまな方法で多くの問題を解決することができます - たったひとつの方法ではなく!

アプリケーション内のさまざまな問題を単一の特定のプログラミングパラダイムに強制しようとすると、あっという間に、私たちは創造的に思考しなくなり、効率的に作業しなくなります !

ちょっと歴史の授業

特定のプログラミングパラダイムを理解するのに良い方法のひとつは、それが最初にどのように進化したかに着目することです。その開発の理由は何? 新しい考え方が必要だった他のプログラミングパラダイムには、どんな問題があった? それは現実世界の問題か単に学問的な問題だったか? そして以来どのように進化してきたか?

X という人が何を言っているのか、Y という人が何を定義しているのかは関係ありません。パラダイムの中で重要なのは、それらを作った歴史です。

ソフトウェア設計を構築するには、2 つの方法があります。ひとつの方法は、シンプルにすることで、明らかに欠点がないようにすることです。そしてもう一つの方法は、非常に複雑にして、明らかな欠陥がないようにすることです。

C.A.R. ホーア

かつて、オブジェクト指向プログラミングの登場以前、50 年代の終わり頃、多くのソフトウェアは、第 1 世代および第 2 世代の言語と呼ばれる、しいて言えば非構造化プログラミングと言われるプログラミング言語を使用して、開発されました。非構造化プログラミング (または構造化なしプログラミング) は、歴史上最も初期のプログラミングパラダイムです。それは「スパゲッティ」コードを作成すると強く批判されました。

非構造化プログラミングを使用する言語には、高レベルなものも低レベルなものもあります。これらには、初期バージョンの BASIC、COBOL、MUMPS、JOSS、FOCAL、TELCOMP、機械語、初期アセンブラシステム (プロシージャー疑似命令のないもの)、およびいくらかのスクリプト言語が含まれます。

非構造化言語のプログラムは、通常は各行に1つずつの順番に並んだ命令あるいはステートメントで、通常構成されます。行は通常、番号付けされるかラベルを持ち、実行フローがプログラム内の任意の行に (不人気な GOTO 文のように) ジャンプできるようになっています。

そして、60 年代には、構造化プログラミングが浮上しました - 主に、エドガー・W・ダイクストラ の有名な手紙 Go To statements considered harmful のおかげで。

後に、手続き型プログラミングが構造化プログラミングから派生しました。手続き型プログラミングは「プロシージャ呼び出し」という概念に基づいています。「プロシージャ呼び出し」は、単に「関数呼び出し」の別名です。プロシージャは、ルーチン、サブルーチンまたはメソッドとも呼ばれます。プロシージャは、一連の計算ステップを含んでいるにすぎません。定義された任意のプロシージャは、他のプロシージャまたはそれ自体を含み、プログラムの実行中の任意の時点で呼び出されます。

最初は、すべてのプロシージャがプログラムのどの部分でもグローバルデータとして利用可能でした。これは小さなプログラムでは問題はありませんが、状況が複雑になり、プログラムのサイズが成長すると、プログラムの一部の小さな変更が、他の多くの部分に大きく影響しました。

誰もプログラムの変更を計画しておらず、多くの依存関係が存在していました。ひとつのプロシージャへの小さな変更が、元のコードに依存する他の多くのプロシージャで、エラーのカスケードを発生させます。

新しい技術は、データを「オブジェクト」と呼ばれる分離したスコープに分割することができるよう進化させました。同じスコープに属する特定のプロシージャだけが同じデータにアクセスできます。これは、データ隠蔽またはカプセル化と呼ばれます。その結果、より整理されたコードが得られました。

最初はオブジェクトがオブジェクトと呼ばれず、それらは別のスコープと見られました。後で依存関係が縮小され、これらのスコープ内のプロシージャーと変数の間の接続が分離されたセグメントと見られるようになって、その結果が「オブジェクト」および「オブジェクト指向プログラミング」という概念を生み出しました。

後に、主に Java の開発のために、ある「バズワード」が発生し、「プロシージャ」または「関数」はもはや関数と呼ばれなくなり、分離スコープ内に存在するときは「メソッド」に改名されました。変数はもはや「変数」と呼ばれなくなり、分離スコープ内に存在するときは「属性」に名前が変更されました。

なので、オブジェクトは本質的に、単なる関数と変数の集合が現在「メソッドと属性」と呼ばれるようになっただけです。

メソッドと属性を分離スコープの中に隔離して保持する方法とは、「クラス」を使うことです。クラスは、インスタンス化されると、オブジェクトと呼ばれます。

オブジェクトはお互いを参照することができ、そのような参照によって、中にあるメソッド (関数) は互いに「通信」することができます。オブジェクトは他のオブジェクトからメソッドを「継承して」拡張することもでき、これは「インヘリタンス」と呼ばれます。これは、コードを再利用し、パブリッククラスとインタフェースを介して、ソフトウェアの独立した拡張を可能にする方法です。オブジェクトの関係によって階層が生じます。継承は 1967 年にプログラミング言語 Simula 67 のために発明されました。

オブジェクトは、他のオブジェクトからメソッドを継承し、追加または変更された機能でこれらを「オーバーライド」することもできます。これは「ポリモーフィズム」と呼ばれます。

これらのさまざまなアイデアがどのように実装されているかは、プログラミング言語のピンからキリまでで大きく異なります。

オブジェクト指向プログラミングとは、これまでとは別の方法でコードを整理することです。それは手続き型プログラミングの拡張であり、データの隠蔽 (カプセル化) とグローバルスコープを回避することです。実際には元のコードに影響を与えずに青写真の「借用」によって機能を拡張すること (インヘリタンス) です。そして、元のコードに影響を与えずに関数をオーバーライドすること (ポリモーフィズム) です。

オブジェクト指向モデルは付け加えによってプログラムの構築を簡単にします。実際には、多くの場合、スパゲッティコードを書くための構造的手法を提供するという意味なのですが。

– ポール・グレアム in Ansi Common Lisp

間違った方法: 常にオブジェクト指向プログラミングを使うこと。 だめ

他人のコードを恐れること

フレームワークの使い方についてしばしば表明される議論は、他人がスクラッチで書いたコードベースを扱いたいとは思う人はいない、ということです。

しかし、これは奇妙な考え方で、主に PHP コミュニティの Web 開発者が遭遇します。それはプロフェッショナリズムと経験の不足を滲出させるものです。

ソフトウェアを書くことと他人のコードを扱うことは普通のことです。それはプロのプログラマーの毎日の仕事の一部です。恐れるべきことではありません。

プロのプログラマーで他人のコードを見ない者は、もう会社やプロジェクトに在籍していないであろう前任のプログラマーの完全な慈悲にどうやってすがろうか、そして以前のプログラマーがフレームワーク A またはフレームワーク B を使っていたら人日が節約できたのにと、泣き言を言いだします。

これはプロのプログラマーのメンタリティではありません。こんなこと誰もしません。

おそらく、PHP の Web 開発の参入障壁の低さが、この種のメンタリティの一部にひと役買っています。そんなこと関係ありません、それは間違った作業ラインにいる人の兆候です。

プログラミングの大部分は、他人のコードで仕事する必要がある人を扱います。既存のコードベースの改善に挑むことは、時には完全なリライトでの改善となっても、仕事の一部です。

プログラミングの偉大な巨匠に習いましょう、Coders at work - Reflections on the Craft of Programming という本を読んでください。

世界で最も大きく成功したコードベースのいくつかは、お互いに会ったことのない何百人もの人々によって開発されたコードベース、あらゆる種類のフレームワークを使用せずに開発されたコードベース、手続き型パラダイム以外のものを使わずに完全に手続き型プログラミング言語で行われたコードベース、であり、それが違ったやり方をすることを夢見るなんてことはありません。

Linux カーネル は、あらゆる種類のフレームワークを使用せずに14,000 人以上の参加者によって、すべて手続き型プログラミングを使用して書かれた 2,000 万行以上のコードで構成されています。

さまざまな BSD フレーバーと Linux GNU ユーザランド のほとんどは、あらゆる種類のフレームワークを使用せずに、すべて手続き型プログラミングを使用して書かれています。

元のプログラマーに最終的に放棄された、世界中の何百ものオープンソースプロジェクトは、他の熟練したプログラマーに拾われています。これらのプロジェクトの多くには、ごくわずかなドキュメント (もしあるなら) しかなく、コードベースにはコメントがなく、ガイドラインやヘルプも提供されていませんでした。

PHP のコードベース全体は、純粋な手続き型プログラミング言語である C 言語で行われ、フレームワークをまったく使用することはありません。

PHP でクラスを定義するたび、お気に入りの PHP フレームワークを起動するたびに、他の誰かの純粋な手続き型の作業を実行しているのです!

確かに、恐ろしいコード、おそらくはじめから設計されていなかったコード、またはクライアントが書き直しを選択したくなくて何度も自己成長しているであろうコード、といったものは存在し、コードが悪すぎてもうあなたには手に負えないとしても、どんなフレームワークもこのような状況を防いでくれはしません。これはよくあるプログラムの自然な成長プロセスです。とにかく、どんな種類のフレームワークも結局は断片化してしまいます。

恐ろしいスパゲッティコードが存在することは確かですが、誰も恐ろしいスパゲッティコードを意図的に作りはしません。場合によっては経験不足の結果かもしれませんし、クライアントのせいで開発の途中で何度か仕様を変更したというのはしょっちゅうですが、その両方のいずれの場合でも、フレームワークを使用したところで結果はスパゲッティコードになります。また、どれだけオブジェクト指向のパラダイムが使用されても、結果はやはりスパゲッティコードになります。

プログラマとして、私たちがみな回避しようとするこのような状況ですが、これは普通のことで、これは プログラミングの芸術 で、これは プログラマであること が意味するもののひとつなのです!

間違った方法: 他人のコードを恐れること。 だめ

宗教的に PHP-FIG 標準に従うこと

FIG とは「フレームワーク相互運用性グループ」のことです。

PHP-FIG は、2009 年に php|tek の多数のフレームワーク開発者によって作成されました。それ以来、様々な他のメンバーが応募して採択され、グループのサイズを最初の 5 から 20 以上に増やしました。

PHP-FIG に関しては多くの論争が存在します。一部の人々は、PHP そのものに由来して PHP コミュニティに起こった最善のことと考えていますが、他は最善の何かを忘れてしまったグループとみなしています。

PHP-FIG にまつわる問題のひとつは、彼らの FAQ にあるこの部分のように自己紹介していることです:

グループの背後にある発想は、プロジェクト代表者たちが、プロジェクト間の共通点について話し合って、共同で作業する方法を見つけることです。私たちの主なオーディエンスはお互いですが、残りの PHP コミュニティが見ていることはとても意識しています。他の人々が私たちがやっていることを採用したいなら、やるのは歓迎ですが、採用してもらうことが目的というわけではありません。グループの誰も、プログラマーとして、あなたのアプリケーションを構築する方法を教えたいとは思っていません。

しかし、グループのいくつかのメンバーの作業を見ると、その目的が上記の宣言とはまったく反対であることが明確に分かります。これらのメンバーは、PHP-FIG が、このグループのもともとの名称でもある 信頼された「PHP 標準グループ」になるよう、飽くなき努力をしています。彼らのやりかたは、自分の書籍、ウェブサイト、ブログ投稿、フォーラムなどで PHP-FIG の作業を「モダン PHP」と分類し、他の方法を逆に分類することです。

PHP-FIG にまつわる問題のひとつは、多くのフレームワークとオープンソースプロジェクトがいくつかの標準を採用しているにもかかわらず、これらの標準は主に「フレームワークの視点」からの問題に対処しているため、多くの現実の業界の状況で実に使いづらくなっています。

多くの人々が、非常に効率的で、安全で、費用対効果の高い、顧客が購入して使いたいと思うような、産業向けのソフトウェアを開発しています。彼らは、フレームワーク狂信者のニーズに合致するべきだという標準に悩まされることはありません。彼らがそうしようとすると、ビジネスの災害になるでしょう。

何らかの標準グループを作成する必要がある場合、フレームワークとオープンソースの CMS プロジェクト開発者だけでなく、PHP コミュニティ全体の利益を反映する必要があります。それは、PHP プログラミング言語そのものの開発者によって表されなければならず、投票権を持つはるかに大きなメンバーシップによって表明されなければなりません。

PHP-FIG によって開発された標準 - オートローダー標準 PSR-0 と PSR-4 およびその他標準のいくつか - を採用すると選択した場合、あなたがソフトウェアをどうコーディングするかに直接影響します。

多くの産業で求められる、スケーラビリティがあり、ランタイムクリティカルで、コスト効率の高いソフトウェアは、単純に言って、これらの PHP-FIG の標準を使用して開発することはできません。

間違った方法: 宗教的に PHP-FIG に従うこと。 だめ

セキュリティをサボる

プログラマーにまつわるトラブルとは、手遅れになるまで、プログラマーが何をしているのかを決して伝えないことです。

– シーモア・クレイ on defprogramming.com

セキュアコーディングは、悪意や意地悪心のある人、他のプログラムによる攻撃に対して、耐性のあるプログラムを書くことです。セキュアコーディングは、盗難や破損からデータを保護するのに役立ちます。さらに、安全でないプログラムは、攻撃者にサーバーの制御やユーザーの身元情報の取得へのアクセスを提供し、サービス妨害(DoS)から単ユーザーまでのあらゆるもので、情報漏えい、サービスダウン、または数千人のユーザーのシステムへのダメージまでをもたらします。

すべてのコンピュータプログラムは、セキュリティ攻撃の可能性のあるターゲットです。攻撃者は、アプリケーションのセキュリティ上の脆弱性を発見しようとします。彼らは、これらの脆弱性を利用して秘密を盗み、プログラムやデータを破壊し、サーバーやネットワークを制御しようとします。あなたの顧客の財産とあなたの評判は危険にさらされています。

セキュリティはソフトウェアに後付けできる何かではありません!

安全でないアプリケーションでは、セキュリティを確保するために大幅な再設計が必要になることがあります。ソフトウェアの脅威の本質を特定し、アプリケーションの計画と開発の最初から、セキュアコーディングのプラクティスを組み込む必要があります。

攻撃者の関心が着実にアプリケーション層に向かっているため、重要なソフトウェアリソースをセキュアにすることは、かつてないほど重要です。2009 年の SANS 調査によると、Web アプリケーションに対する攻撃は、インターネット上で観測された攻撃の合計攻撃の 60% 以上を占めています。

PHP は、プログラミング言語でもあり Web フレームワークでもあるという点で、ちょっと変わっています。つまり PHP には、言語に組み込まれた多くの Web 機能があって、安全でないコードを書くのが非常に簡単なのです。

デフォルトで安全に

複雑さが殺す。それは開発者から命を吸い取り、製品の計画、構築、テストを難しくし、セキュリティ上の課題を生じさせ、エンドユーザーや管理者の不満を生みます。

レイ・オジー

アプリケーションが適切なセキュリティ要件で設計/実装されるようにするには、セキュアコーディングのプラクティスとセキュリティリスクへの集中を、日々の運用、思想、開発プロセス自体に、統合する必要があります。

一般に、ソフトウェアパッケージが完成した後にセキュリティ問題を修正するよりも、安全なソフトウェアを構築する方がはるかに安価です。セキュリティ違反と付き合うコストは言うまでもありません。

間違った方法: デフォルトで安全なソフトウェアを開発しないこと。 だめ

FAQ

記述された文書は誤解されやすいのでいくつかの問題を明確にしましょう。

Q: このサイトのポイントは何ですか? なぜ対立的なアプローチなのですか?

A: 議論を作り、現在のプラクティスと極端な視点について考えるためです。

Q: あなたはオブジェクト指向プログラミングが悪いとか間違っているとか言っていますか?

A: いいえ、もちろん違います! 問題を解決するために、常にオブジェクト指向のパラダイムだけを考慮し使用することが、悪だと言っています。白か黒かだけで考えると、それは間違っています。

単一のアプリケーション内であっても、異なる問題が存在します。マルチパラダイムが最適な解決策になることもあり、それはすべて、あなたが解決しようとしている問題によります。

特定の問題を不適切な解決策に強制的に送り込むと、かならず悪いことが起こります。

Q: すべてのフレームワークが悪だと言っているのですか?

A: 特定のフレームワークを判断しようとしているわけではありません。私たちは PHP 上で常にフレームワークを使用することの問題を扱っています。

Q: フレームワークでさっさとやってすぐ動かせるのなら、どうしてそんなに悪いのですか?

A: 状況や長期的な影響を分析して、「さっさとやってすぐ実行」が、あなたが対処しなければならない唯一の問題であることがわかったのなら悪くないですが、我々はプログラミングやソフトウェア開発を重点的に扱っていて、我々はだいたいポイントアンドクリックソリューションを扱っています。

さっさとやってすぐに実行することは、ソフトウェアを設計することではなく、あなたが直面している問題を分析しておらず、あなたが選択したことの長期的な意味を理解していないということです。

Q: サードパーティのパッケージは悪だと言っていますか?

A: いいえ。サードパーティのライブラリの使用は促進しています。上限や制約を強制することなく、自分のプロジェクトに簡単に統合できるコード。それらは素晴らしいです!

Q: あんた誰?

A: このウェブサイトは、PHP コミュニティの発想と過激化に対抗するものであり、個人的な名声や認識ではありません。人に名前を持たせると、ウェブサイト上に置かれた問題から、問題にまつわる人に焦点を移すだけです。発想に集中してください。

Q: ソフトウェア開発におけるあなたの経験は何ですか?

A: 他人がそう言っているから常に何かあることをする、という主題に集中してもらえれば、このウェブサイトに掲載されている発想、思考、結論に至るのに経験はそれほど必要ありません。

お勧めの読み物

PHP The Wrong Way on Hacker News

Why bad scientific code beats code following “best practices”

How to program without OOP

Coders at work - Reflections on the Craft of Programming

The traits of a proficient programmer

OWASP Secure Coding Guidelines

Security by Design Principles

Survive The Deep End: PHP Security

Refactoring Improving the Design of Existing Code

The Practice of Programming

The pragmatic programmer

Understanding programming languages

コントリビュートするには

GitHub でコントリビュートします。