Page 1
公開版
staticおじさんになろう
War on Dynamics
カンファレンス関西
2017-07-15 PHP 2017 LT
staticおじさんになろう 公開版
公開日:
スライドテキスト
Page 2
このスライドは2017年7月15日に 開催されたPHPカンファレンス関 西2017で当日募集された本篇LT にて話したスライドに調整および 加筆を施したものです。口頭で補 足したもの、文字だけではわかり にくいものを補ったほか、後半部
分に文章の追加があります。
Page 3
お前誰よ
うさみけんた (@tadsan) / Zonu.EXE
- GitHub/Packagistでは id:zonuexe
- ピクシブ株式会社でひたすらPHPやってる p(ixi)v
- フレームワークなき道にフレームを作るおしごと
- Qiitaに記事を書いたり変なコメントしてるよ
- 最近やってること
- 万難が排されつつあるのでPHP7 移行
- えいやえいやとテスト書いたり直したりしてる
Page 4
そろそろ10年になる Webサービスを開発
Page 5
注意
Page 6
このLTは特定のアーキ
テクチャの導入を
勧誘するものではなく、 その是非については自分
で判断してください。
Page 7
対処が難しかった事例を
寄せ集めただけで、
特定の実装の話ではない
Page 8
オチは特にない
Page 9
あと特定の会社の
回し者ではない
Page 10
さて
Page 11
あるメソッドの
API(引数・返り値)を 変更したいとします
Page 12
リファクタリング
できますか？
Page 13
そのメソッドの
呼び出し箇所を列挙
できますか？
Page 14
そうですね
Page 15
git grep '\->setName('
Page 16
本当にそれで 全部ですか？
Page 17
$obj = new FugaClass; $f = [$obj, 'setName']; call_user_func($f, $n);
Page 18
🙃
Page 19
$obj = new FugaClass;
$obj->setName($v);
//
↑探したいのはこっち
$obj2 = new HogeClass; $obj->setName($x, $y);
// ↑同名の関係ないメソッド
Page 20
誤爆
Page 21
結果を絞ろう
Page 22
# new setName
の次行に がある前提
git grep -a1 'new FugaClass' |
grep '\->setName('
Page 23
これで完璧
Page 24
//
DIコンテナ
$app['fuga']->setName($n);
Page 25
🙃
Page 26
こんなことが続くと
人間は無気力になる
(学習性無力感)
Page 27
(そのあとも動的な性質 による悩みは絶えない)
Page 28
ソリューション
Page 29
new staticおじさんedition
class FugaClass { private $name;
private function __construct(){}
public static function setName( ) {
FugaClass $that, $name
$that->name = $name;
}
// ...
Page 30
git grep
'FugaClass::setName'
Page 31
これでいいのか
Page 32
😇
Page 33
書きにくくなった
だけでは…
Page 34
staticおじさんをやめよう
Beat “evil” static methods
カンファレンス関西
2017-07-15 PHP 2017 LT
Page 35
特効薬
Page 36
Photoshop
Page 37
PhpStorm
Page 38
FindUsage
と
Refactor
機能
最強説
Page 39
型
Page 40
型が推測できなく なるような複雑な
書き方をしない
Page 41
型を確定できないと ころは地道にPHPDoc
で型をつけていく
Page 42
http://nico.ms/kn1774
Page 43
これだけ覚えて帰ってね
タグ名 意味 例
@param 引数を定義
@param int $n1
@return 返り値を定義
@return int[]
@var 変数/プロパティを定義
@var int
@property マジックプロパティを定義
@property int $id
Page 44
DI/IoC
コンテナは？
Page 45
(日本語での説明、ただしサンプルコードが旧形式)
PhpStorm の PHPSTORM_META でサービスロケーター
とかを入力補完 - ngyukiの日記
http://ngyuki.hatenablog.com/entry/2015/02/20/134239
(公式資料・新形式のコード例が載ってる)
PhpStorm Advanced Metadata
https://confluence.jetbrains.com/display/PhpStorm/
PhpStorm+Advanced+Metadata#PhpStormAdvancedMetadata-Factorymethods
Page 46
某社の回し者ではないの で、PhpStorm以外に良 いツールあれば知りたい！
Page 47
そもそも
staticおじさんになっ た理由はコレジャナイ
Page 48
なれる！staticおじさん
I wanna be a clever static uncle
カンファレンス関西
2017-07-15 PHP 2017 LT
Page 49
Webサービスを作る人間
＝
オブジェクト指向の達人
Page 50
ではない
Page 51
素朴に作られたクラス は余計な状態を抱えこ んで渾沌が肥大化する
Page 52
多すぎる引数…
謎のメソッド…
不要なプロパティ…
Page 53
それでもコードは動き、 今の自分たちを生かし てくれてる (=収益源)
Page 54
作られた当時は
理由があった
(たぶん)
Page 55
動いてきたコードへの
リスペクトを
見失ってはならない
Page 56
それでもサービスを成長さ
せる足枷にならないように リファクタリングしていく
Page 57
混沌としたクラスから
staticおじさんに
身を堕としたのは
カオスを収束させるため
Page 58
カオスを収束させた後な
らば、未来に向かって
「あるべき姿」を再定義
することができる
Page 59
カオスを収束させずに夢を見 てアーキテクチャの再設計を 試みると理想と現実のギャッ プと物量に圧し潰されて氏ぬ
Page 60
重要な事実：
オブジェクト指向を多少かじっ た程度では、ベターなOO設計 ができる大先生にはなれない
Page 61
設計のエキスパートではなく ても多くのパタンに触れてい けば現在の身のたけに合った ものを選びとることはできる
Page 62
オブジェクト指向プログラミングに
基いたリファクタリングが常に
最適解ではなくて、手続き型なら
手続き型としてのやりかたはある。
(staticおじさんの再肯定)
Page 63
設計に失敗したらやり直 しが利くように疎結合に
していくことも大事。
Page 64
(疎結合にする試みそのものが
負債を生むこと往々にしてある。 一足飛ばしで変更しすぎるのもよ
くない)
Page 65
現実を直視して分析し、 自分たちに合った現実解
を地道に適用していく
Page 66
どんなことにも長所と短所がある。 世の中ではオブジェクト指向が先 進的、手続き型はレガシーのよう な風潮もあるが、手続き型がベター
と結論することもある。
Page 67
しかし｢オブジェクト指向はわかり にくい｣｢インスタンスを作るとリ ファクタリングしにくい｣といった 風評はPhpStormなどのIDEで解決 できる。ツールを知ることでサー ビスの成長改善につなげられる。
Page 68
良いツールを知らないと「リ ファクタリング対象をリスト アップするときにgrepコマン ドでテキスト検索するしかな
い」といった事態に陥る。
(最初の問題提起)
Page 69
スタートアップ期のコードでは設 計に悩み留まって製品をリリース できないことは賢明ではない。リ リースされた後も機能追加に注力 すべきだが、機能追加と既存機能 の安定性を両立しようとすると、
どこかで決断の時は来る。
Page 70
きちんと設計して
未来に行こう