IRT 1 — PHP
traitについて
-
いつ使う・使わない
-
テストで使いました
- 認証が必要なテストで、認証コードとテストデータだけtrait化
-
プロダクトコードではオブジェクトの委譲のほうがうまくいった
- 特定のメソッドだけmockしたいときに、無名クラスを普通に注入したほうがうまくいった
-
cf. mockeryだとすべてのメソッドがモックされてしまう
- partial mock使えばいいよ！
-
-
interface (-able)を実装するために使ってます
- 多重継承ができないため
- interfaceとtraitとclass 3つ見ないといけないのつらい
-
PHPのtrait、機能が十分でない説
-
interfaceのように、抽象化機構として使いたいが、使えない
- Scalaなどではある
- RFC: Traits with interfaces (却下)
-
-
traitがないころのPHPで、継承しまくりコードを触っている。つらい
- 「xxできるooクラス」を表現するためにTemplate Method Patternが4重くらいになったクラス
- 垂直ではなく水平に逃がすためのtrait
-
そもそもtraitってなに
-
処理をまとまった単位で切り出すためのもの
- あるクラスに直接処理を記述すると、その処理はそのクラスと密結合になってしまう
-
ヘルパに近い
- 委譲は大げさなケース
- まさにテストでの使い方
- AOPをTraitで実現できる
-
-
ところでAOPってなんですか
- メソッドの前後に処理を挟むやつ
-
例
- トランザクション
- ログ
- ベンチマーク
-
traitのアンチパターン
-
依存の向きがおかしい
- traitがtraitをuseしているクラスに依存している
-
IRT 2 — PHP
型について
- PHPでジェネリクスしたいけどできない(ぼく)
-
ジェネリクスが欲しくなる例
-
Maybe<T>とか-
[成否,データ]の積集合データにしたくない- 補完も効かないし…
-
-
(Maybeの説明が面倒だったので)
Collection<T>とか- これも補完が効かなくて困ることがある
-
-
どうしてる？
- 特殊化した型を毎回作ってます
-
やりません
-
郷に入っては郷に従え
- ジェネリクス？ないものは、ない！
-
「動いちゃう」のが魅力なのでは
- 参入障壁が低い
- 厳格に型で縛るとしたら、PHPである必要ないのでは
-
チームの制約で縛る
- コレクションに関しては、異なる型が混じっているのはアンチパターン
-
-
Fail-First
-
早期にエラーで止まってくれたほうが嬉しい
- 止まるのが遅いと追うのが大変
-
-
2016 t_wadaさん PHPで堅牢なプログラミング
-
契約プログラミング
- 事前条件が整っていることを引数型で担保する
- メソッド内のバリデーション不要に
-
-
strict(type=1)論争-
後から付けると既存のコードが動かなくなる
- 暗黙の型変換等
-
-
タイプヒンティング
- 「あえて書かない」はある
- 「書けないから書かない」はやばい
- 実装コストと相談しながら定義しましょう！
IRT 3 — PHP
5000行くらいあるメソッドを見つけたらどうしたらいいか
-
スクレイピングで多発
- 「小説」
-
消していいか聞く
- 消せたら幸せ
-
まずif文で分割してみて！
- if文の中身に名前を付ける
-
みんなで解読
-
漫画を見るようなノリ
- 楽しげ
-
真剣に読まない
- まず全部読む
-
-
変更を加えずにすめば一番良い
- 製品の寿命によっては、解決しなくてもビジネスドメインごと消滅してくれることも
- どうしても変更を加えなければならない場合は、加害者にならないように
- 仕様を再定義して作り直したほうがよいことも
- ボーイスカウトルールを実践しようとしたが、ゴミだらけで「どれを拾えばいいのかわからない」
辞書攻撃対策
- 共通: throttleかける
-
nginxで制限
-
403 Forbiddenとかにする
- アプリケーションコードに改修不要
- DOS detectとかをslackに流す
-
-
アプリケーションで制限
- 特定のIPからのアクセスを制限する
-
特定のIPに対してthrottleをかけづらい例
- 大きなお客
- bastion