勉強日記

チラ裏

はじめてのPHPプロフェッショナル開発 ch2

PHP 勉強メモ

www.shuwasystem.co.jp

Chapter02 PHPのエコシステム

Section01 モダンなPHPを支えるコミュニティの力

  • 先人の作った資産を使おう、という話
  • Composer
  • PSR: PHP Standards Recommendations
    • ライブラリの使用を定めるもの
    • これに準拠したものを選択すると相互利用性が高まる
      • 他プロジェクトに移植しやすい
      • 似た別のものに乗り換える時に学習コスト低くてすむ

Section02 PHP-FIGとPSR

PHP-FIGとは

PHP Standards GroupとPHP-FIGの誕生

  • php.standards
  • PSR-0 (オートローディング規約)
    • 0 = 最重要
    • オートローダーの相互利用性を確保するための必須要件(具体的な原則)
    • PSR-4で置き換えられた
  • 2011, PHP-FIG: PHP Framework Interop Groupになる
    • 「PHP本体の標準ではなく、その上に乗るソフトウェア開発を支援するための標準」
  • PSR-1 (基本コーディング規約)
  • PSR-2 (コーディングスタイルガイド)
  • PSR-4

PHP-FIGの活動について

  • 非公式だけどコミュニティ代表
  • 有名な人いっぱい

PSRについて

Sectoin03 PHPのパッケージ管理

現在のデファクトスタンダードとしてのComposer

  • PEAR: PHP Extension and Application Repository
    • 長らく使われてきた
    • システムワイドにパッケージを配置する
      • 全部globalインストールする感じ
  • Composer
    • 特長
      • 単一バイナリファイルの設置だけでパッケージマネージャの導入が完了
      • composer.jsonファイルを用いた依存性管理
        • 簡単
        • プロジェクト単位
        • 現代のスピード感に即している
      • composer.lockファイル
        • 孫以降の依存パッケージ
        • 実際に使われているバージョン
      • packagist
        • 手軽なパッケージ公開
        • 公開パッケージの充実
      • PSR-4ベースのオートロード対応

Section04 PHPのアプリケーションフレームワーク

  • うまく選ばないと
    • 過不足
    • かえって非効率
  • とりあえず乗っかってみる、も良い(著者所感)

フルスタック型: Laravel, CakePHP

  • 本書ではCakePHP触ってく
  • 最初の学習コスト高し
  • 学習コストを支払ってしまえば
    • 生産性大きく向上
    • コードの規律
      • 設計思想の影響が大きい
      • ちゃんと理解できれば読み書きしやすい
      • チーム間のコード統一
      • 【所感】フルスタックでもちゃんと勉強する人が集まらないと統一性は失われます

マイクロフレームワーク型: Slim, Lumen

  • フルスタックの機能全部は使わない
  • 本当に必須な部分に機能を絞る
    • その他は自分で用意してね
  • 自律が必要
    • コード統一性が失われやすい

コンポーネント志向: Aura for PHP, BEAR.Sunday

  • 再利用可能なコンポーネントの作成や選択
  • 「なんでもサーバーでやる」ではなくなってきている
    • 例: フロントでSPAしたらサーバーはWebページのroutingから開放される
    • 解釈しやすいシンプルな情報を、高速かつ軽量に返答すること

どのようにWebフレームワークを選ぶか？

  • アプリケーションの目的
    • 必要な機能は？
    • リリースまでに使える期間
      • 短期決戦？
      • じっくり設計？
    • 全体規模
      • 要件にフィットした設計を行いながらドキュメントも充実させていく？
      • 極小だからコードで十分？
  • チームメンバーの現状
    • レベルが十分でない場合
      • 規約、制約に縛ってもらう
        • CoC (Convention over Configuration)
      • 統制とりやすい
    • レベル高い人が居る
      • 独立的な構造の導入も選択肢
        • F/W依存を高めすぎない
  • そもF/Wとは
    • 本質: 背骨となる設計思想
    • 狭義: 「よくやる処理」の再利用
  • たいていは開発効率 > ささいなパフォーマンスのオーバーヘッド(著者所感を要約)