PHPプログラミングの世界には多くの傾向があります。 一部の人々は（書籍やWebサイトで）それらを「現代のPHP」として積極的に宣伝しますが、他のアプローチではそれらを陳腐化、愚か、または単に不正として公開します。



これらの人々は皆、疲れを知らずに、全員が適切であるとプログラムするように努めているようです。 この記事は、PHPプログラミングに関する実用的な展望を共有するために書かれています。 人気の傾向、理論、または学問的な教義ではなく、経験と実際的な意味によって決定される外観。 PHPサイトに掲載されている資料-The Wrong Wayは 、新しい情報が利用可能になると更新されます。 私たちは誰もがこれに参加することを勧めます。

過激主義の危険

ルールとプログラミングガイドには1つの問題があります。これらは多くの場合、特定の条件でのみ意味をなします。 これらの条件を超えると、良いルールはひどいものに変わります。 実際、極端にとられた良いルールはすべて悪くなります。



これを理解することは重要です。なぜなら、プログラミングの過激派は、時々登場し、異なる人々によって提供されたソフトウェア開発の原則と規則の多くを誤って使用したからです。



経験から、基本的なガイドラインとルールの誤用はプロジェクトを常に複雑にし、安全性を低下させ、誤った、時には壊滅的な結果をもたらすことが示唆されています。



「Keep It Simple、Stupid」と解釈されるKISSの原則は 、非常に賢明で正しいものです。経験豊富な人は、それに従うことをお勧めします。 しかし、KISSでさえも、不条理に追い込まれれば、プロジェクトにとって脅威になり得ます。 私たちの場合、機能性の欠如につながる、過度の単純性などがあります。



間違った方法：規則とガイドラインに従っている。

フレームワークの継続的な使用

すべての汎用PHPフレームワークはダメです！

ラスマス・ラードルフ

PHPコミュニティでは、本当に悪い傾向がWebアプリケーション開発の事実上の標準になりました。 一般的な汎用フレームワークを使用することです。



この現象は広く広がっています。 その理由は、開発結果の改善と、テクノロジーとアーキテクチャの観点からの特定の操作の誤った実行ではありません。 フレームワークの一部の作者が、アプリケーションをゼロから構築することに反対する論争の助けを借りて、開発者コミュニティを追い払っただけです。 特徴的なスローガンは、「車輪を再発明しないでください！」と「すべてを自分でやらないでください。経験豊富な人がすでにこれを処理しています」。



今日のプログラマーの多くは、通常のプログラミングの基本原則を完全に無視し、多くの時間を費やして新しいレイヤーや難易度レベルを空想し、仲間よりも賢くクールになっています。



これらの人々は他の人を魅了し、PHPコミュニティの元のリーダーになり、誰もが新鮮で「トレンドの」オープンソースツールを使用するように説得することを好みます。 汎用フレームワークは、工場で建てられた家と比較できます。 このようなフレームワークを使用してアプリケーションを構築すると、構築済みの家を構築することで大工になるのと同じ程度に、コーダーまたはプログラマーになります。



この記事では、次の基準に従ってフレームワークとライブラリを区別します。

• ライブラリは、再利用可能なコードのコレクションです。 たとえば、標準のCまたはGoライブラリ。 ライブラリコードは、プロジェクトに埋め込まれた制限なしで簡単に作成できます。 それは小さな断片で構成されており、それぞれに特定の機能があります。
• フレームワークは、単に再利用可能なコードのコレクションではありません。フレームワークから一部を切り取ってプロジェクトに貼り付けることはできません。 このシステムはソフトウェアの作成に役立ちますが、同時にフレームワーク自体に固有の制限がユーザーに課せられます。 さらに、フレームワークには多くの相互依存する機能があります。1つの部分は他の部分なしでは機能しません。

PythonとRubyの世界では、ウェブサイトをゼロから構築するのは退屈な作業です。これらの言語はウェブサイトの構築を目的としていないためです。 その結果、 DjangoやRuby on Railsなどの汎用フレームワークは、PythonおよびRubyでのサイト構築専用にすぐに人気を博しました。



また、PHP Rasmus Lerdorfは最初はCで記述されたツールセットとして作成されたため、ダイナミックHTMLを迅速かつ簡単に開発できます。 PHPはこのように考え、そのようにとどまりました。 それはフレームワークそのものです。



PHPはその存在を通じて積極的に開発されてきましたが、今日ではHTMLやWebサイトの構築よりもはるかに多様なタスクに使用できます。 しかし、PHPをフレームワークとして扱うのは間違っています。 本質的に、完全に手続き型Cで記述されたWebアプリケーション開発用の抽象化レイヤーです。



プロジェクトでライブラリを使用することは完全に自然です。 PHPには、コードを拡張できる一連のライブラリが付属しています。 たとえば、PDOは、PHPのデータベースにアクセスするための一貫したインターフェイスを提供する小さなライブラリです。



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



この場合、もともと参照点として作成された別の抽象化レイヤーの上に抽象化レイヤーを追加します。 フレームワークが提供する追加のレイヤーは、コードを事前に定義されたテンプレートに単純に整理できます。 または、数百または数千のクラスとメソッドを地獄のような依存関係に絡み合わせて複雑さを増すことができます。 しかし、いずれにしても、完全に不要な新しいレベルの複雑さをコードに追加します！



経験を積むことは、インターフェースから始まります。 インターフェースは、基本技術と一定数の抽象化レベルの結果です。 使用する抽象度が高いほど、インターフェイスの効果が低くなり、アプリケーションに追加されるエラーが多くなります。 抽象度が高いほど、細部と効率が失われます。



明確に理解してください。 コードはできる限りクリーンで読みやすくなるように、プロジェクト内のコードの行数はできるだけ少なくする必要があります。

汎用フレームワークは必要ありません。 誰も共通の問題はありません。誰もが非常に具体的な問題を解決しようとしています。

ラスマス・ラードルフ

また、一部の企業は、PHPフレームワークのh騒に巻き込まれ、プロジェクトでそれらを使用し始め、最終的に災害につながります。 企業は、汎用フレームワークが特定の問題をうまく解決するのに役立たないという事実に直面しており、さらに、非常にゆっくりと動作します。 フレームワークはスケーリングすることができず、多くの企業は、当初必要とされていなかった作業を行うという絶望的な希望で、フレームワークから断片を引き出そうとしています。



次のような実用的なアプローチを常に使用します。

アクションまたはポリシーは、理論やドグマではなく、実際の直接的な結果を考慮して決定されます。

コリンズ英語辞書完全版第12版2014

間違った方法：常にPHPの上にフレームワークを使用します。

設計パターンの継続的な使用

私は離婚したプロジェクトとデザインパターンに非常にアレルギーがあります。 Peter Norwigは、デザインパターンがプログラミング言語の単なる欠陥であるという良い記事を書きました。 より良い言語に切り替えます。 そして彼は絶対に正しい。 誰もがパターンを崇拝し、「ええ、パターンXを使用します」と考えているだけです。

ブレンダン・アイヒ。 仕事中のコーダー-プログラミングの技術に関する考察

設計パターンは、アプリケーションアーキテクチャの一般的な問題に対する再利用可能なソリューションです。 テンプレートは、コードに直接変換できる完全なプロジェクトではありません。 これは、さまざまな状況で使用するための単なる説明であり、問​​題を解決する方法のアイデアです。 オブジェクト指向テンプレートは通常、アプリケーションの最終的なクラスまたはオブジェクトを定義せずに、クラスまたはオブジェクト間の関係と相互作用を示します。



PHPは、命令型、オブジェクト指向、手続き型、および反射型のパラダイムをサポートしています。 PHPは、1つだけでなく、さまざまな問題をさまざまな方法で解決できる巨大なツールボックスです。 PHPは自由で、高速でスケーラブルなソリューションです。



自分自身、特にコードを改善しようとすると、実際に考えることを忘れながら、特定のパターンやアイデアの哲学にとらわれることがあります。

私のプログラムでパターンを見たとき、私にとってそれはトラブルの合図です。 プログラム構造は、解決される問題のみを反映する必要があります。 コード内の他のパタ​​ーンは、（少なくとも私には）十分に強くない抽象化を使用していることを示しています。 たとえば、作成する必要があるマクロ拡張機能を手動で生成します。

ポール・グラハム

特定のテンプレートやソリューションの背後にある哲学やアイデアのtrapに陥ることはできません。 私たちの主なタスクは、コードをできる限り理解しやすくすることです。つまり、安全で維持しやすいコードです。



また、アンチパターンの存在を忘れてはなりません。 これらのパターンは頻繁に使用できますが、効果がなく、逆効果にさえなります。

最初は、テンプレートは一般的な問題に対する認識できる最良の解決策だったと思います。 しかし、しばらくすると、人々は読んだすべてのテンプレートを詰め込もうとしていたため、アプリケーションが必要以上に10倍複雑になっていることがわかりました（「テンプレートが読み込まれているため、私のアプリケーションは熟考されています」）。 そのため、テンプレートの価値についての私の考えは変わりました。

ポール・ウィートン。 邪悪なデザインパターン

次のような実用的なアプローチを常に使用します。

アクションまたはポリシーは、理論やドグマではなく、実際の直接的な結果を考慮して決定されます。

コリンズ英語辞書完全版第12版2014

間違った方法：問題を解決するためのテンプレートを探します。

オブジェクト指向プログラミングの継続的な使用

OO言語の問題は、暗黙の環境すべてに沿ってドラッグすることです。 あなたはバナナが欲しかったのですが、同時にバナナを入れたゴリラとすべてのジャングルを手に入れました。

ジョー・アームストロング 仕事中のコーダー。 プログラミングの技術に関する考察

抽象化は力です。 そして、本当に私をオフにし、1990年代に話したのは、CORBA、COM、DCOM、オブジェクト指向ナンセンスです。 当時、すべてのスタートアップは何かおかしなものを提供していましたが、起動すると、20万のメソッドが呼び出され、「Hello world」が表示されました。 これはパロディです！ プログラマーとして、あなたはそのようなものに自分自身を関連付ける必要はありません。

ブレンダン・アイヒ。 仕事中のコーダー。 プログラミングの技術に関する考察

今日、多くの開発者や企業は、OOPが開発の唯一の合理的な方法であると考えています。 そして、これに異議を唱える人々は、彼らが業界の「一般に認められた意見」に反していることをすぐに認識します。



プログラミングのブログとフォーラムには、標準の定義はありませんが、話していることを理解していると確信しているOOP支持者がたくさんいます。



しかし、実際には、いわゆるオブジェクト指向プログラミングは複雑すぎることがよくあります！



私たちコンピューター科学者とプログラマーは、偏見を捨てて、特定の問題に対する最善の解決策を探さなければなりません。



今日、PHPの主な利点の1つは、命令的、機能的、オブジェクト指向、手続き型、および反射型のパラダイムのサポートです。 PHPは、 1つだけでなく 、さまざまな方法でさまざまな問題を解決できる巨大なツールボックスです。



1つの特定のプログラミングパラダイムを使用してアプリケーション内のさまざまな問題を解決しようとすると、創造的な思考をやめ、効果的に機能します。

少し歴史的なレッスン

プログラミングパラダイムを理解するための最良の方法の1つは、それがどのように発生したかを確認することです。 その理由は何ですか？ 他のパラダイムのどの問題に新しいアプローチが必要ですか？ 問題は実用的または学術的でしたか？ そして、パラダイムの作成からどのくらい時間が経過しましたか？



Xが何を言っているのか、Yが何を定義しているのかは関係ありません。

アプリケーションアーキテクチャを開発するには、2つの方法があります。 1つ目は、 明らかにシンプルにすることで、 明らかに欠陥はありません。 2つ目は、 明らかな欠陥がないように複雑にすることです。

チャールズアンソニーリチャードホアー

以前は、1950年代の終わり頃のOOPの出現前でさえ、非構造化プログラミングに重点を置いて多くのプログラムを作成するために言語が使用されていました。 これらは、第1世代および第2世代の言語と呼ばれることもあります。 非構造化プログラミングは歴史的に最初のパラダイムになりました。 彼女はスパゲッティコードに対して積極的に批判されました。



非構造化プログラミングを使用する高レベル言語と低レベル言語の両方があります。 たとえば、BASIC、COBOL、MUMPS、JOSS、FOCAL、TELCOMP、マシンコード、初期のアセンブラーシステム（手続き型メタ演算子なし）、多数のスクリプト言語。 通常、非構造化言語プログラムは、通常1行に1つずつ、順番に配置されたコマンドまたは式で構成されます。 行には番号が付けられているか、スレッドが任意の行にジャンプできるラベルが含まれている場合があります（人気のないGOTO式など）。 Edsger Dijkstraの有名な手紙Go Toステートメントが有害と見なされたおかげで、構造プログラミングは1960年代に登場しました。



構造プログラミングは、ルーチン、ブロック構造、およびループを介して、清浄度、品質、および開発プロセスを改善するパラダイムです。 これは、単にGOTO式を飛び越えることとは対照的です。



その後、手続き型は構造化プログラミングから生まれました。 「プロシージャコール」の概念に基づいています。 これは「関数呼び出し」の別名です。 プロシージャは、ルーチンまたはメソッドとしても知られています。 これは基本的に、実行する必要がある一連の計算です。 任意のプロシージャは、プログラムの実行中にいつでも他のプロシージャによって、または独立して呼び出すことができます。



最初は、プログラムのどの部分でもすべての手順がグローバルデータとして利用可能でした。 小さなプログラムではこれは問題になりませんが、プログラムがより複雑で大きくなるにつれて、ある部分の小さな変更が他の多くの部分に強く影響し始めました。 プロシージャに小さな変更を加えると、それに依存する他の多くのプロシージャでカスケードエラーが発生する可能性があります。



データをさまざまな可視領域に分離できる新しい手法「オブジェクト」が登場しました。 同じデータは、同じスコープに属する特定のプロシージャによってのみアクセスできます。 これは、データ隠蔽またはカプセル化と呼ばれます。 その結果、コードをより良く整理することができました。



当初、オブジェクトはオブジェクトとは呼ばれず、単に別々の領域と見なされていました。 その後、これらの領域内の変数間の依存関係と関係が減少すると、それらは孤立したセグメントと見なされ始め、最終的に「オブジェクト」と「オブジェクト指向プログラミング」の概念が生まれました。



その後、主にJavaの出現により、新しいファッショナブルな用語が登場し、「プロシージャ」または「関数」は、別のスコープに属するときに「メソッド」に名前が変更されました。 変数は、別のスコープに属する場合、「属性」に名前が変更されます。



そのため、実際にはオブジェクトは、メソッドと属性と呼ばれる関数と変数の単なるコレクションです。



メソッドと属性は、「クラス」を使用して別のスコープ内で分離されます。 そして、クラスのインスタンスが作成されるとき、それはオブジェクトと呼ばれます。



オブジェクトは相互に参照することができ、これにより、オブジェクト内のメソッド（関数）も相互に「相互作用」します。 また、オブジェクトは他のオブジェクトからメソッドを「継承」でき、それによってそれらを拡張できます。これは「継承」と呼ばれます。 これは、パブリッククラスとインターフェイスを介して独立したアプリケーション拡張機能を作成できるようにするコードを再利用する方法です。 オブジェクト間の関係により、階層が作成されました。 継承は、1967年にSimula 67の言語用に作成されました。



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



異なる言語では、これらのアイデアは非常に異なる方法で実装されます。



オブジェクト指向プログラミングは、コードを編成する別の方法です。 これは、データの隠蔽（カプセル化）とグローバルスコープの回避に関連する手続き型プログラミングの拡張機能です。 これは、元のコード（継承）に影響を与えることなく、図面を「借用」することによる機能の拡張です。 そして、これは元のコードに影響を与えない関数の再定義です（多態性）。

OOPモデルにより、降着（降着）によってプログラムを簡単に作成できます。 実際には、これはしばしば、スパゲッティコードを記述する構造化された方法であることを意味します。

ポール・グラハム ANSI Common Lisp

間違った方法：常にオブジェクト指向プログラミングを使用します。

他人のコードを恐れる

フレームワークの使用を正当化する一般的な議論の1つは、他の人が書いたコードの断片から作成されたコードベースを扱うことに人々が気が進まないことです。



主にWeb開発者に特徴的なこのやや奇妙な考え方は、プロ意識と経験の欠如を示しています。



アプリケーションを作成し、他の人が書いたコードを操作するのはまったく普通のことです。 これはプロのプログラマーの日々の仕事の一部であり、それを恐れる必要はありません。



専門家は、自分の仕事が従業員コードに完全に依存していることをうなずすことはありません。従業員コードはおそらく会社やプロジェクトとは関係ありませんが、この従業員がフレームワークAまたはフレームワークBを使用すると、1日の作業を節約できます。



専門家はそうは思わない。 単一ではありません。



おそらく、PHP Web開発に参入するための低いしきい値は、そのような考え方の普及に重要な役割を果たしています。 しかし、いずれにしても、これはその人が間違った道をたどっていることを示唆しています。



プログラミングには、主に他人のコードを使用して人々と対話することが含まれます。 これは仕事の一部です。既存のコードベースを改善しようとすることです。場合によっては完全に書き直す必要があります。 仕事中のCodersでプログラミングウィザードが言っていることを読んでください。 プログラミングの技術に関する考察 。



世界で最大かつ最も成功したコードベースのいくつかは、一度も会ったことのない何百人もの人々によって開発されてきました。 これらのデータベースは、フレームワークを使用せずに、手続き型パラダイムのみを使用する手続き型プログラミング言語でのみ作成されました。 そして、誰もそうすることを夢見てさえいませんでした。



Linuxカーネルには、手続き型プログラミングのみで記述された2,000万行を超えるコードが含まれています。 その作成には14,000人が参加しましたが、フレームワークはありません。 さまざまなBSD機能とLinux GNUユーザーランドのほとんどは、フレームワークを使用せずに手続き型プログラミングのみを使用して記述されています。



同じことは、世界中の何百ものオープンソースプロジェクトで、他の経験豊富なプログラマーによってのみ取り上げられるように作者によって放棄されたと言えます。 これらのプロジェクトの多くには、ドキュメントがほとんどない（またはまったくない）、コードにコメントがない、マニュアルやその他の種類の支援がありません。



はい、それは何ですか-PHPコードベース全体が、フレームワークなしで手続き型言語であるCで書かれています。



PHPでクラスを定義するとき、またはお気に入りのPHPフレームワークを実行するとき、あなたは他の誰かの手続き的な仕事をしています！



もちろん、恐らく元々何らかの方法で設計されていないか、何度も成長したひどいコードがありますが、クライアントはそれを書き直したくありませんでした。 コードベースはひどいため、目的を見つけることができません。 しかし、このような状況からあなたを保護するフレームワークは1つではありません。 これは通常、通常のプログラム成長の段階です。 最終的には、フレームワークは単純にバラバラになります。



もちろん、悪夢のようなスパゲッティコードがありますが、誰も意図的にそれを書いていません。 これは経験不足の結果である場合があり、多くの場合、開発の途中で顧客が何度も仕様を変更するという欠点があります。 ただし、どちらの場合でも、フレームワークを使用している場合でも、スパゲッティコードを取得できます。 オブジェクト指向のパラダイムをどれだけ集中的に適用し始めても、結果は同じです。



プログラマーとして、私たちはそのような状況を防ぐ必要がありますが 、 これは正常であり 、これはプログラミングの技術であり 、これはプログラマーと呼ばれるものの一部です！



間違った方法：他人が書いたコードを恐れる。

PHP-FIG標準に従う

FIGは、Framework Interoperability Groupの略です。



PHP-FIGは、2009年のphp | tek会議でフレームワーク開発者によって作成されました。 それ以来、構成は5人から20人に増加しました。



PHP-FIGをめぐる多くの論争があります。 これは、PHP自体の出現以来、これがPHPコミュニティの最高のイニシアチブであると考えています。 他の人は、このグループの存在をできるだけ早く忘れることが一般に価値があると確信しています。



問題の1つは、PHP-FIGがFAQでどのように位置付けられているかです。

私たちのグループの仕事は、参加者が私たちのプロジェクトの共通点について話し合い、協力する方法を見つけられるようにすることです。 私たちの聴衆は私たち自身ですが、PHPコミュニティの残りの部分が私たちを見ていることをよく知っています。 他の人が私たちがしていることを受け入れたいと思ったら喜んでいますが、これ自体が目的ではありません。 私たちのグループの誰も、アプリケーションの作成方法を教えてくれません。

ただし、グループの複数のメンバーの作業を見ると、実際の目標が述べられた内容と完全に反対であることが明らかになります。 このグループは、PHP-FIGを元の名前である 「PHP標準のグループ」に変えるために最善を尽くしています。 グループメンバーの本、Webサイト、ブログ、フォーラムなどでは、PHP-FIGの作業は現代のPHPと呼ばれ、他のアプローチはすべて廃止されています。



PHP-FIGの問題は、多くのフレームワークとオープンソースプロジェクトが多くのグループ標準を実装しているにもかかわらず、これらの標準自体が主に「フレームワークの観点から」問題を解決するように設計されているため、多くの実用的な状況で役に立たないことです。



多くの開発者は、非常に効果的で、安全で、収益性の高いソフトウェアを作成し、購入して使用したいと考えています。 彼らは、フレームワークの狂信者のニーズを満たす必要がある標準に気を取られることはできません。 これは、ビジネスにとって災害になります。



何らかのグループが必要な場合、その標準は、フレームワークとオープンソースCMSプロジェクトの開発者だけでなく、PHPコミュニティ全体の利益を反映する必要があります。 そのようなグループは、はるかに多くの参加者と投票で、PHP言語の開発者自身を表す必要があります。



PHP-FIG標準に従うことにした場合、それらの一部（たとえば、PSR-0およびPSR-4オートローダー標準など）がソフトウェアコードの記述方法に直接影響することを理解する必要があります。



多くの分野で、PHP-FIG標準に従えば作成するのは不可能な、非常にスケーラブルでランタイムクリティカルで費用対効果の高いソフトウェアが必要です。



間違った方法： PSR-1とPSR-2を除き、PHP-FIG標準に従います。

セキュリティの怠慢

プログラマーには1つの問題があります。手遅れになるまでプログラマーが何をするのか決してわかりません。

シーモアクレイ。 defprogramming.com

安全なコードは、他のプログラムと同様に、悪意のあるユーザーや楽しみによる攻撃に耐えるプログラムを作成する方法です。 安全なコードは、データを盗難や損傷から保護します。 安全でないコードは、攻撃者にサーバーまたはユーザーの資格情報を制御する可能性があります。 結果-何千人ものユーザーのサービスおよびハッキングシステムの障害まで。



各プログラムは攻撃の潜在的な標的です。 攻撃者は、アプリケーションの脆弱性を見つけて、それらを使用して重要な情報を盗み、プログラムとデータの整合性を侵害し、サーバーとネットワークを制御しようとします。 あなたの顧客の財産と評判は危機にatしています。



アプリにセキュリティを追加することはできません！



安全でないアプリケーションを安全にするには、大幅に再設計する必要があります。 ソフトウェアに対する脅威の発生源を特定し、最初から安全なコード技術を実装し、アプリケーションの計画と開発全体を通してそれらを遵守する必要があります。



攻撃の主なベクトルは着実にアプリケーションレベルに移行しているため、重要なソフトウェアリソースのセキュリティはかつてないほど重要になっています。 2009年のSANSの調査によると、Webアプリケーションに対する攻撃は、インターネットで記録されたすべての攻撃の60％以上を占めています。



PHPの特性は、プログラミング言語およびWebフレームワークでもあることです。 多くのWeb関数が言語に組み込まれているため、安全でないコードを非常に簡単に記述できます。

デフォルトのセキュリティ

複雑さは殺します。 開発者の命を奪い、製品の計画、製品の作成とテストを複雑にし、セキュリティの課題をもたらし、エンドユーザーと管理者を疲れさせます。

レイ・オジー

適切なセキュリティ要件を備えたアプリケーションを開発するには、安全なコード記述テクニックを使用し、日常業務、考え、侵入者の可能性のあるプロセスのリスクに注意を払う必要があります。



間違った方法：デフォルトで安全なアプリケーションを開発しないでください。

よくある質問

上記のすべては誤解されやすい-何かを明確にしましょう。



あなたのサイトの目的は何ですか、そしてなぜあなたは潮に逆らって泳いでいるのですか？

目標は、最新の技術と極端な視点についての議論を開始することです。



あなたはオブジェクト指向プログラミングが悪いか良いと言うのですか？

いいえ、もちろん違います！ 理解するのはあなたです：オブジェクト指向のパラダイムだけですべての問題を解決すべきではありません。 すべてを白黒に分けることはできません。これは間違いです。 単一のアプリケーション内にはさまざまな問題が存在する可能性があり、特定の状況に応じて異なるパラダイムを使用することが最善の方法である場合があります。 そして、間違った方法を使用して問題を解決した場合、これは何の良い結果にもつながりません。



フレームワークは悪だと言いますか？

フレームワークを特に非難しません。 PHP上での継続的な使用のみを非難します。



フレームワークが私をすぐに開始して動作し続けるのに役立つなら、それは何が悪いのでしょうか？

状況と長期的な結果を分析し、「すぐに作業を開始して継続する」がこれまでに解決した唯一の問題であると理解している場合、問題はありません。 ただし、プログラミングやソフトウェア開発についてではなく、ポイントアンドクリックソリューションの使用についてです。



すぐに起動して作業を続けます-これはアプリケーションを作成するものではありません。 これは、問題を分析せず、選択の長期的な結果を認識しなかったことを意味します。



サードパーティのパッケージが悪いと言いたいですか？

いや サードパーティのライブラリを使用することをお勧めします。 簡単に制限なしでプロジェクトに実装できるコード。 これは素晴らしい機会です！



あなたは誰ですか？

私たちのサイトは、個人の昇進や名声の獲得ではなく、PHPコミュニティの過激主義と闘うという考えに専念しています。 名前を明らかにした場合、これはサイトで発生した問題から注意をそらすだけです。 気を散らさないようにしましょう。



ソフトウェア開発の経験はどうですか？

私たちのウェブサイトに反映されているアイデア、考え、解決策にたどり着くために、他の人が言うことを常にするなら、多くの経験は必要ありません。

推奨読書

1. PHP：Wrong Way-at Hacker News 。 私たちがサイトを立ち上げたとき、多くの価値ある議論を反映したHacker Newsに関する多くのコメントがありました。
   
   
   
   
2. OOPなしでプログラムする方法 。 新鮮で代替的な視点：ブライアンウィルは、OOPから始めてはならない3つのビデオについて説明しています。 最後に、非OOPコードの書き方に関するいくつかのメモで締めくくります。
   
   
   
   
3. 仕事中のコーダー。 プログラミング技術に関する考察 。 インタビューは、15人の優秀なプログラマーとコンピューター科学者との80時間近くの会話に基づいています。 ここでは、彼らがどのようにプログラミングを学んだか、どのように彼らのスキルを磨いたか、そして彼らはプログラミングの将来についてどう思うかについての多面的な物語を見つけるでしょう。
   
   
   
   
4. 資格のあるプログラマーの機能 。 能力とは、タスクを完了するのに十分な経験と知識を意味します。 スキル-この方法で何かをしている理由と、それが全体像にどのように適合するかを知る。 言い換えれば、資格のある開業医は常に有能な開業医ですが、その反対は必ずしも真実ではありません。
   
   
   
   
5. 安全なプログラミングガイド ソフトウェア開発ライフサイクルに組み込むことができるチェックリスト形式の一般的な安全なプログラミングテクニックのセットを含む、技術に依存しないドキュメント。 これらの手法を使用すると、最も一般的な脆弱性を回避できます。
   
   
   
   
6. 安全設計の原則 。 Webアプリケーションのセキュリティは、オープンソースアプリケーション、エンドツーエンドWebサービス、独自のビジネスサイトなど、成功するプロジェクトの重要なコンポーネントです。 ホスティング事業者は安全でないコードに当然注意し、ユーザーは安全でないサーバーに警戒します。 このガイドの目的は、企業、開発者、設計者、および意思決定者が安全なWebアプリケーションを作成できるようにすることです。 , , .
   
   
   
   
7. : PHP . - : , . , .
   
   
   
   
8. . . , , . . , , . 40 , , . . Java, -.
   
   
   
   
9. . , .
   
   
   
   
10. . , : , , . , , .
    
    
    
    
11. . — , . , : «» . « » , :
    
    
    
    
    • ,
    • ,
    • ,
    • .