PHPカンファレンス関西2018 C05 2枠目の発表で使用したスライドです。

1. すばやく実装するための戦略と
テクニック
2018.07.14 PHPカンファレンス関西
@77web

2. ・@77web
・フリーランス（9年ぐらい）→カルテットコミュニケーションズ（4年）
・名古屋
・2児の母
・日本Symfonyユーザー会
・CoderDojo名古屋 初代チャンピオン（諸事情あって引退…）
・I♥PHP

3. ・運用型広告業界をホワイトにする仕組みを作ってます
・仲間募集中！（フルリモート、パートタイム、もちろんフ
ルタイム正社員も歓迎）

4. 速さは力

6. 速いと何が嬉しい？

7. 速いと何が嬉しい？
• 間違っても修正する時間がある

8. 速いと何が嬉しい？
• 間違っても修正する時間がある
• 心と身体の余裕

9. 速いと何が嬉しい？
• 間違っても修正する時間がある
• 心と身体の余裕
• 次のことを勉強する時間ができる

10. 速いと何が嬉しい？
• 間違っても修正する時間がある
• 心と身体の余裕
• 次のことを勉強する時間ができる
• （おまけ）新機能にアサインされやすい

11. 速さを妨げるものはなにか？

12. 速さを妨げるものはなにか？

13. 速さを妨げるもの=わからなさ
• フレームワークやライブラリの使い方がわからない
• どういう処理を書いたら仕様を実現できるかわからない
• 実装にどれぐらい時間がかかるかわからない
• 処理のボトルネックがどこになるかわからない
• 求められる仕様がわからない・決まってない

14. わからなさを減らせば倒しやすい＝速くできる

15. 戦略：分割統治法

16. 分割統治法とは？
• divide-and-conquer method
• そのままでは実装が難しい大きな問題を小さな問題に分割することで実装しやすくする方法（プ
ログラム用語）
• わからなさを削りながら実装していく

17. 分割統治法実践テクニック
• 表をイメージして裏から作る
• 争いのないものから作る

18. 表をイメージして裏から作る

19. 表をイメージして裏から作る
• interfaceを活用
• 表から裏に対してやってほしいこと（何を受け取って何を返してほしいか）だけを定義する
UI
app
domain
infra(DB/External API)

20. 争いのない部分から作る

21. 争いのない部分から作る
• プロジェクト全体としてわからない部分を少しでも減らしていくために、わかっている部分か
らコードにしていく
• 実装開始時点で仕様が決まっていない部分は、後でガラッと変わるかもしれない
• 外的要因
• 内的要因
• あとで変わるかもしれないものをベースにしない

22. 実際にやってみましょう

23. 要件
• 顧客電話帳アプリ
• 項目は電話番号、会社名、担当者名、自社の担当者名、案件名、メモ
• 電話番号とキーワードで検索
• 電話番号は前方一致
• キーワードは部分一致
• メモ以外のテキスト項目を検索
• データ保存形態は未定（どれでも対応できるように）

24. 要件
• 顧客電話帳アプリ
• 項目は電話番号、会社名、担当者名、自社の担当者名、案件名、メモ
• 電話番号とキーワードで検索
• 電話番号は前方一致
• キーワードは部分一致
• メモ以外のテキスト項目を検索
• データ保存形態は未定（どれでも対応できるように）

25. step1. 表のイメージ
表をイメージして裏から作る

26. step2.分け方を考える
検索条件ビルダ
顧客検索
表をイメージして裏から作る

27. step3. 表イメージをあるべき姿へ修正
顧客検索アプリ 表をイメージして裏から作る

28. step3. 外側のイメージをあるべき姿へ修正
1つのファイルの責務を1つにしたらだいたいOK
表をイメージして裏から作る

29. step4. interfaceで表からの利用イメージをそのまま書いてみる
良さそうですね
表をイメージして裏から作る

30. 今回の場合は揺れ動きそうなのは検索の仕様。
なら、$_GETから$customerCriteriaを作るCriteriaBuilderから作る。
争いのないものから作る
step5. 争いのない部品を作る

31. step6.争いのある部品を作る
CustomerSearch::search()のイメージを考える。
RDBだとSQL1個書いてPDOにつっこむだけだから楽ですね。
でも対象が配列やCSVだと…？
顧客データソース
表をイメージして裏から作る

32. step7. 争いのある部品のイメージをinterfaceで書いてみる
検索の仕様が変わったらここだけ変えれば良い
※本当はこの辺もうちょっと分割したい
表をイメージして裏から作る

33. step8. 争いのある部品で使うための部品を作る
とりあえずArrayのDataSourceを書いた

34. step9. 部品が ったので組み立てて動かしてみる

35. search.php
CustomerSearchApp
CustomerSearch
infra(DB/External API)
CustomerDataSource
CustomerCriteriaBuilder
CustomerCriteria
表
裏

36. demo

37. step10. 応用編: データ保存先がRDBに変わったとき
あれだけ一生懸命書いたCustomerSearchの絞り込み処理は捨てました

38. その他速度を上げるテクニック
1. 良い道具を使う
1-1. こわれにくい
1-2. 間違えにくい
1-3. 手数が少ない
1-4. 動作が速い
2. 自分の速度を上げる
2-1. 決断を速く
2-2. 思考を速く
2-3. ベンチタイムの有
効活用

39. 1.良い道具を使う
• 良い＝開発速度が上がる

40. 1-1. こわれにくい道具

41. 1-1. こわれにくい道具
• 急いで、雑に扱っても大丈夫
• キーボード
• 芯の折れやすいシャーペンより鉛筆
• オプションを1つ間違っても壊れないコマンド
• ボタンを1つ押し間違ってももとに戻せる

42. 1-2. 間違えにくい道具

43. 2-2. 間違えにくい道具
• 操作を間違いにくい
• ショートカットキーより直感的なボタン操作が優れていることがある
• コーディング自体を間違いにくい
• エディタのコード補完をちゃんと使う
• typo指摘してくれて専門用語の辞書を設定できるエディタを使う

44. 1-3. 手数が少ない道具
・たくさんあれこれ調整する
・途中で洗い→脱水→すすぎ→脱水と手で移動させる
・「スタート」ボタン1個押せば洗濯できる
・ボタン1つで乾燥までできる

45. 1-3. 手数が少ない道具
• 人間がやらないといけないことを減らして、自動化できるものを選ぶ
• 手数が減るとミスも減る
• CI
• cs-fixer

46. 1-4. 動きが速い道具

47. 1-4. 動きが速い道具
• 良いCI（札束で殴る）
• 良いスペックのPC
• キーボード
• 無線より有線
• マウス
• ゲーミングマウスは反応が良いのでオススメ

48. 2. 自分の速度を上げる

49. 2-1. 決断を速く

50. 2-1. 決断を速く
• 悩んだり調査したりする（コーディング以外の）時間の限度を決める
• Googleは10分間ルール（※要出典）
• 私は1時間ルール
• 死なないものならまずやってみる
• 案ずるより産むが易し

51. 2-2. 思考を速く

52. 3-2. 思考を速く
• トレーニングする。手っ取り早いのは速聴
• 高価な機器はいらない、カセットテープ再生機やyoutubeの倍速再生とかで十分効果がある
• やりすぎると話し言葉も早口になっちゃうので人間関係に注意…

53. 2-3. ベンチタイムの有効活用
あと30分

54. 2-3. ベンチタイムの有効活用
• テスト実行中、CI実行中、レビュー待ち
• 2タスク（以上）並列せよ
• まったく別のプロジェクトを並列するのが理想
• プロジェクトが1つしかない場合はgitのブランチを使ってタスクごとに完全に分ける
• 次に何をするかはコミットログに覚えさせる（脳内に覚えることはできるだけ少なく）
• プルリクも分割統治しておく
• 後工程があるものを先に作業
A実装
B実装
直
し
テスト
テスト CI レビュー
テスト
レビュー
CI レビュー仕様確認
レビューXさん作業
仕様確認

55. まとめ
• 戦略：分割統治法＝わからなさを削りながら実装する
• 表をイメージして裏から作る
• 争いのないものから作る
• 良い道具を使う
• 自分自身の速度を上げる

56. Happy coding! ありがとうございました！

57. サンプルコード：https://github.com/77web/phpkansai2018-hellopage