楽しみのために、RushドラマーのNeil Peartを見てみましょう。 彼のドラムキットは次のとおりです。
1979年にロサンゼルスで行われた公演でのブラックフラッグは次のとおりです。
ブラックフラッググループ全体は、ニールピアートのドラムキットが占める領域に収まります。 そして、彼らは素晴らしいものを実行し続け、完全に点灯します。
過去数年にわたって、PHPの精神は明らかにニールピアトの道を辿ってきました。 膨大な数の賢い人々によって行われた膨大な量の仕事が、複雑で冗長な決定に変わりました。 ファイルの束、ネストされたディレクトリの束、ルールの束。 次のようなPHPライブラリ/コンポーネントがよく見られます。
<?php chdir(dirname(__DIR__)); require_once (getenv('ZF2_PATH') ?: 'vendor/ZendFramework/library') . '/Zend/Loader/AutoloaderFactory.php'; Zend\Loader\AutoloaderFactory::factory(array('Zend\Loader\StandardAutoloader' => array())); $appConfig = include 'config/application.config.php'; $listenerOptions = new Zend\Module\Listener\ListenerOptions($appConfig['module_listener_options']); $defaultListeners = new Zend\Module\Listener\DefaultListenerAggregate($listenerOptions); $defaultListeners->getConfigListener()->addConfigGlobPath('config/autoload/*.config.php'); $moduleManager = new Zend\Module\Manager($appConfig['modules']); $moduleManager->events()->attachAggregate($defaultListeners); $moduleManager->loadModules(); // Create application, bootstrap, and run $bootstrap = new Zend\Mvc\Bootstrap($defaultListeners->getConfigListener()->getMergedConfig()); $application = new Zend\Mvc\Application; $bootstrap->bootstrap($application); $application->run()->send();
そして、これらはすべて、アプリケーションを起動するためだけです。
これは、このアプローチ自体が悪いことを意味するものではありません。 しかし、これを見ると、本能的な否定的な反応があります。 私の脳は叫ぶ：
性交。
あれ。
シット。
（ 最高の単語を見つけることができませんでした-約翻訳者 ）
これはできません。 これは欲しくありません。 そして、あらゆる種類のクールなものを作成するような方法でそれを行うべきではないと思います。
私が最近練習しているアプローチは、可能な限り軽いベースから始め、マイクロフレームワークで始めることです。
PHPの世界では、それらはSlim 、 Epiphany 、 Breeze 、 Limonadeなどによって表されます。 機能を追加するために、問題の解決に役立つ軽量ライブラリを使用します。 明快さと簡潔さは、私が最初に注意を払うことです。
他の誰かのコードを使用するときに私が見るもう一つの重要な詳細は義務です。 通常、ライブラリコードを完全に監査する時間がないため、ここでは、このコードを書いた人をある程度信頼する必要があります。 そして、新しい依存関係ごとに、信頼する必要があるコードの量が増えています。 エラーと脆弱性の存在、およびそれらの処理方法について知る必要があります。 メーリングリストに発表がありますか？ 修正にはどれくらい時間がかかりますか？また、下位互換性が損なわれることはありませんか？ PHPの次のバージョンにアップグレードする場合、すべての依存関係を更新する必要がありますか。 これはすべて、著者がこれらのエラーを修正する時間と希望を持っているという仮定に基づいています。 そうでない場合は、大量の技術的負債をコードに追加しただけです。
多くの依存関係を引き出さない軽量ライブラリを見つけることは、本来あるべきよりもはるかに困難です。 基本的に、これは開発者が特定のフレームワーク用の開発により興味を持っているという事実によると思います。 成熟したフレームワークのモノリシックを緩和するためにいくつかの作業が行われました。多くのTwitter開発者は、オプションとしてSymfonyコンポーネントを試すことを推奨しています。 残念ながら、明るさについてはあまりにも異なるアイデアがあります。
symfony2 HTTPカーネルコンポーネントリポジトリのクローンのcloc出力は次のとおりです。
Mon Dec 26 19:42:23 EST 2011 coj@PsychoMantis ~/Sites > cloc HttpKernel 94 text files. 93 unique files. 12 files ignored. http://cloc.sourceforge.net v 1.53 T=0.5 s (164.0 files/s, 18736.0 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- PHP 72 1175 3440 4290 Bourne Shell 10 56 155 252 ------------------------------------------------------------------------------- SUM: 82 1231 3595 4542 -------------------------------------------------------------------------------
Slimフレームワークの場合も同じです：
Mon Dec 26 19:42:27 EST 2011 coj@PsychoMantis ~/Sites > cloc Slim 54 text files. 51 unique files. 13 files ignored. http://cloc.sourceforge.net v 1.53 T=0.5 s (82.0 files/s, 17752.0 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- PHP 31 660 4473 3280 Bourne Shell 10 56 155 252 ------------------------------------------------------------------------------- SUM: 41 716 4628 3532 -------------------------------------------------------------------------------
また、Epiphanyフレームワークの場合：
Mon Dec 26 19:42:30 EST 2011 coj@PsychoMantis ~/Sites > cloc Epiphany 83 text files. 70 unique files. 31 files ignored. http://cloc.sourceforge.net v 1.53 T=0.5 s (102.0 files/s, 5246.0 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- PHP 40 218 309 1632 Bourne Shell 10 56 155 252 HTML 1 0 0 1 ------------------------------------------------------------------------------- SUM: 51 274 464 1885 -------------------------------------------------------------------------------
基本的なフレームワーク全体よりも多くのファイルとコード行がコンポーネントにある場合、それを軽量と呼ぶことはできません。
これは悪いことを意味するものではありません。 これは、これが間違ったアプローチであることを意味するものではありません。 しかし、私にとってはもちろん、このアプローチは間違っています。 そして、私は私だけではないと思います。
私はプログレッシブのロックスターになりたくはありません。 パンクロックバンドでドロップデッドクールなコードを演奏して、ステージのない家でショーを行い、あなたをロックして、自分だけのバンドを作りたいです。 このようなエンコーダになりたいです。
ニールピアートになりたくない。 グレッグジーニーになりたい。
だから私はこれを書いた。 必要であれば、このような「マイクロPHPマニフェスト」。 これをPHP開発のガイドとして使用する予定です。 おそらくあなたもこれで役に立つものを見つけるでしょう。
私はPHP開発者です
- 私はZend FrameworkやSymfonyやCakePHPの開発者ではありません
- PHPはかなり複雑だと思います
私はささいなことをするのが好き
- 私は単純な目標で小さなことをするのが好きです。
- 私は問題を解決することをするのが好きです。
- 大きな問題を解決するために一緒に働く小さなことをするのが好きです。
より多くではなく、より少ないコードを書きたい
- より多くではなく、より少ないコードを書きたい
- より多くのコードではなく、より少ないコードを管理したい
- より少ないコードをサポートしたい
- プロジェクトに含めるすべてのコードを正当化する必要があります
シンプルで読みやすいコードが好きです。
- 明確なコードを書きたい
- 簡単に検証可能なコードが欲しい
マニフェストサイト： microphp.org
マニフェスト作成者について： funkatron.com/about.html
翻訳へのコメントと修正を歓迎します。