読者です 読者をやめる 読者になる 読者になる

by shigemk2

当面は技術的なことしか書かない

CakePHP2を美味しく食すためのあれこれ #phpstudy

第63回PHP勉強会@東京

GMOリサーチの人
infoQを運営している
ボードゲーム翻訳
CakeBookの翻訳
TEDの翻訳

翻訳とプログラム

CakePHP2実践入門

MVCの本質
ロジックはどこに書けばいいのか
なんちゃってテストファーストのすすめ

CakePHP2実践入門

素晴しいところ

CakePHPをやりたい場合は、この本を読め!!

MVCの話

怖い話

たった2画面しかないのに2000行にのぼるController

  • 依存関係が見えない
  • 処理全体が密結合になってる
  • 依存が多すぎてテスト書けない

checkboxの値を復元するのに
100行にわたってロジックが書いてあるview
画面変更のたびにロジックが邪魔
画面変更のたびにロジックが壊れる

Controllerの仕事を代行しているModel
意味がない
依存関係が分からない
テストが大変

結合テストにてテストする」宣言
テストできるの?

CakePHP導入しただけではMVCは理解できない。

MVCの理想
Model テストしやすく最適化
View 画面を見ながら変更したい
Controller 依存呼び出しの最適化

MVCを理解する鍵は疎結合
プログラムを分けて責任範囲を小さくしたい!!
テストのしやすさ、変更のしやすさを求めたのがMVC

ここを見失わければ
MVCも見失わない。

Model データ処理
View 画面
Controller すべてを知っている司令塔(テストしづらい)

Modelであるべきすがた

DBなど外部依存するメソッドはシンプルに。
ロジックは外部に依存しないように
ロジックは積極的にユニットテストを書く。
どこまで画面から独立できるかが鍵。

ユニットテストのしやすさに向かって最適化。

View

画面で動作チェックしてデザインを変更しやすく。
ソースコードの見やすさは最大限の配慮を。

画面見ながらの変更しやすさに最適化。

Controller

外部依存は必ずnewせずcomponent化する(テストしやすさのため)
画面に強すぎる依存があるロジックは別メソッドか、
意味的に束ねられそうならModelに切り出す。

依存呼び出しの管理しやすさに最適化。

なんちゃってテストファーストのすすめ

CakePHPテストファーストのしやすい作りになっている。
が、正面からテストファーストを実践しようとすると玉砕しやすい。

テストファーストのターゲットになるのはModelになるロジックである。
ifが何度か登場するようなやつを対象にしてみる。

依存に気付いた場合
1. モックを書く
2. 別メソッドにする

2が楽そう。

  1. 実装しながらでは気付きづらい依存の強度に気付く
  2. 使いやすさ(理想の形)を先に考えて書く
  3. ユニットテストが出来上がっている
  4. ユニットテストが使用例になっている

質疑応答

基本的にはカバレージ100%を目指すが、
切り捨てる部分とやる部分をある程度は分けてる
しかし、テストファーストはうまく設計しないとうまくいかない。

テストする文化を根付かせるには、
テストするとパフォーマンスが上がるところを確認することが重要である。