PHP開発で
効率を上げるために
やってきたこと

2015-11-24      PHP BLT #1

GMOリサーチ 寺田渉

facebook: 寺田渉
github:   waterada
twitter:  @wa_terada

自己紹介 (会社)

- PHP (CakePHP) を主に使って開発

- 継続的インテグレーション

github + git flow で運用

- PHPUnit で カバレッジ 100%

- Behat (Selenium Driver 経由の画面テスト) 利用

- vagrant で開発環境構築

自己紹介 (趣味)

CakePHP 公式ドキュメント 翻訳

自己紹介 (趣味)

ボードゲーム 翻訳

自己紹介 (趣味)

TED 翻訳

自己紹介

プログラミング & 翻訳

大好き人間です

伝えたいこと!

  1. vagrant 
  2. プロジェクトの setup シェル
  3. ソースコードの自動生成(bake)
  4. 単体テストで仕様の門番
  5. 他にも (Fabricate, composer,
    gitフロー, PHPStorm)

開発効率 を上げた以下の施策

1.  vagrant

効果

  • 初期構築 時間 短縮 (およそ5分)
  • 環境依存 で動かない問題が無くなる

1.  vagrant

特別にしたこと

  • 前の box から新しい box へと
    DB 等のデータを移行するためのシェルを用意。
  • ソースやログなどはマウントしたディレクトリで管理。

1.  vagrant

  • Vagrantfile は下記の2段構え:
  • まっさらな box に chef を使って環境構築し、
    chef 済の box を作るため のもの。
  • 上記の box を使って 各自が開発するため のもの。
  • box が 稀に壊れる ので下記対策(PCの強制終了等で):

2.  プロジェクトの setup シェル

プロジェクト単位の開発環境構築シェル
そのプロジェクトを開発するために
必要な手続きが 全て 書かれている。

効果

  • 数分でとりあえず、
    他プロジェクトの支援 ができるようになる。

2.  プロジェクトの setup シェル

特別にしたこと

2.  プロジェクトの setup シェル

  • setup.sh 1つで
    サンプルデータ入り で 画面が出る
    ところまでいくように。
  • README.md でなく setup.sh に書く。
  • setup.sh は 何度でも実行可能(初期状態に戻る)。

3.  ソースコードの自動生成

DBのテーブル定義を元に
一覧(検索)/追加/削除/変更画面
を自動で生成する。

 

このような一覧画面は
新人の登竜門的な存在(=単純開発)で、
ボリュームもそこそこあった。

効果

  • 単純な開発から解放され、
    より 差別化できる機能に集中 できる。
  • コマンド実行後、
    3分でリリース可能 状態の
    ソースが出力される。
  • 新人は生成されたものを見て 学べる

3.  ソースコードの自動生成

特別にしたこと

3.  ソースコードの自動生成

いっぱいやった:

  1. 基本は CakePHP の bake を使う。
  2. インタラクティブ部分は削除
    (細かい選び方を教えるのも面倒。出力してソース直す。)
  3. 一覧に 検索機能 が最初から入るように。
  4. 画面デザイン(レイアウトやアイコン)が弊社仕様になるように。
  5. テストカバレッジ は100%
  6. 全ての文言は 日英中の翻訳 を用意しておく。
  7. モデル名/列名の翻訳(.po)ファイルの入れ物を用意しておく。
  8. よく使うプラグイン をあらかじめ入れておく。
  9. PHPStorm の 補完 が利くようにコメント入れておく。

4.  単体テストが仕様の門番

効果

  1. 回帰テスト の工数を削減
  2. 火の消えない デグレ地獄 を防止
  3. 2週間に1度 のリリースを実現
  4. リファクタが自由に できる

4.  単体テストが仕様の門番

特別にしたこと

4.  単体テストが仕様の門番

ソースをテストするのでなく、
仕様をテストする

それは、 仕様を守る門番 を配置するということ。
誰かが仕様と異なる使い方をしたらアラート出るように。

仕様を守るテストとはどんなものなのか。

4.  単体テストが仕様の門番

例えば計算機的なシステムでいうならば:

誤) event に "NUM" がセットされていたら
        backupRegisterにその数字をセットする

正) 数字ボタンを入力したら画面にその数字が表示される

 

前者は、具体的に内部実装に 踏み込み過ぎている

イケてないコードを リファクタしただけでテストが落ちる

 

無駄) イケてないコードを書く→それにあわせてテスト書く

理想) 仕様に合わせて メソッドの枠やテスト項目をまず書く。

→自然と 疎結合 になる

5.  他にも

5.  他にも - Fabricate

単体テストで Fabricate
    説明:
        - DBのテスト用のデータ生成を行いやすくするプラグイン。
        - テストで 使う列の値だけ を指定すればよい。
          (それ以外は自動生成される。)


    効果:
        - テストの 可読性 が著しく上がる。
        - テストの メンテ がしやすくなる。

 

    特別にしたこと:
        - DBのデータを複数メソッドで 共有するのをやめて
          テストメソッドごとにデータを生成するようにする。

5.  他にも - composer

composer
    効果:
        - 依存モジュールの見える化。
          (構築手順が圧倒的に少なくなる。)
        - 依存モジュールの適用が composer install だけに。
          (ブランチごとに依存が変わっても対応可能。)


    特別にしたこと:
        - composer install
          composer update xxx/xxx
          の使い分けの徹底(composer update は絶対に禁止)。
        - composer.json と composer.lock を git 管理。
          これで皆がほぼ同じ環境を維持できる。

 

5.  他にも - gitフロー、PHPStorm

gitフロー
    効果:
        - 同時での複数機能開発
           ソースレビューが圧倒的に楽になった。

 

 

PHPStorm
    効果:
        - 型チェック してくれる。

        - 静的解析して結構 賢く警告/補完 してくれる。
        - 差分確認 が楽。

facebook: 寺田渉
github:   waterada
twitter:  @wa_terada

以上です! 

詳細に興味がありましたら、ぜひお声がけください。

  1. vagrant 
  2. プロジェクトの setup シェル
  3. ソースコードの自動生成(bake)
  4. 単体テストで仕様の門番
  5. 他にも (Fabricate, composergitフロー, PHPStorm)
  1. ご静聴ありがとうございました!
Made with Slides.com