Laravel Shibuya 6 IRTまとめ + 個人的所感・補足等
Laravel.shibuya #6 無事に終わりました！ご参加して頂いた皆様ありがとうございました！
— Futoshi Endo 🎮 (@Fendo181) 2020年1月24日
会場提供して頂いた株式会社オールアバウト様もありがとうございました！
次回はLaravelJpConfで出張IRTがある為、5月に開催予定です！
また語りましょう！🍻#laravelshibuya pic.twitter.com/lKqxbT2b80
- 行動規範が追加された
- 株式会社オールアバウト
IRT1 PHP Track
自分の職場はテストを書く文化がないんですが、テストやCIといったツールを会社に広めて導入につなげていったような体験談とか、うかがってみたいです。
- (より一般に)「新しい文化」を広めるために皆さんどうしていますか？
- 自動テストを書かない理由
- 書く理由
- 導入失敗事例: 勝手に新しい文化を導入したら評価(査定)が下がった話
- テストやCI、静的型付け等
- 「技術に寄りすぎ」 by エンジニアの2番目に偉い人
- 上の人が何を求めているかをまず知り、その人向けにカスタマイズした説得を
- 根本的な考え方にすれ違いがあったりするもの
- こっそり進めて、外堀を埋めてから上の人を説得すべきだった
- 同僚が上司についてしまった…
- 導入成功事例: Cake2 -> Laravelに載せ替えた際にCI・自動テストを導入した話
- 説得材料
- 数字
- 例
- バグ発生率
- 長い目で見て工数がどれくらい減る
- xUnit本の最初のほうに「長い目で効いてくる」というグラフが載っていたりはする
- 【補】Economics of Test Automation (xUnit Test Patterns)
- xUnit本の最初のほうに「長い目で効いてくる」というグラフが載っていたりはする
- とはいえ難しい
- その組織でうまくいくかどうかは、結局導入してみて比較してみないとわからない
- 「よそはよそ、うちはうち」
- 例
- コスパの良いテストから提案する
- 例
- 分類
- 単体テスト、機能テスト等
- GoogleのTest Sizes
- 説明して説得するよりも「まず書いてみろ」
- 【所感】xUnitよりはBDDフレームワークのほうがハードル低そう
- 数字
IRT2 Laravel Track
みんなが思うlaravelのいい！こと、うーん？なところ
- いい！
- 機能が多い、便利
- DIのしくみが強い
- bladeが便利
- Contract
- 「わかってる人」が乗っかると強い
- ドキュメントに載せるくらい重要視しているのがLaravelのえらいところ
- 使う中で設計原則が学べる
- 初動が速い
- ビルトインサーバーでサクッと動かせる
- うーん？
- 便利だけれど、FWのコードを掘っていくと設計がまずい
- 自由
- わかってない人がContractに乗っからずに散らかすとつらい
bladeテンプレート内のロジックをヘルパモジュールに逃がしつつ、デザイナー(非プログラマ)と協業するには(ぼく質問)
【補】補足
index.blade.php
...
@isset($someInfo)
<p>
<ul>
@foreach($someInfo as $id => $line)
<li>{{ $line }}</li>
@endforeach
</ul>
</p>
@else
<p>
情報がありません
<\p>
@endisset
...
isset等の制御構造がbladeに書かれている- デザイナー「あたしHTMLとCSSしかわからないんですぅ〜」となりがち
index.blade.php
...
{{ $someHelper->showInfo() }}
...
- かといって↑こうするとデザイナーが触れなくなる
- ので、最近はbladeを小分けにしている
parts/info.blade.php
<p>
<ul>
@foreach($someInfo as $id => $line)
<li>{{ $line }}</li>
@endforeach
</ul>
</p>
parts/noinfo.blade.php
<p> 情報がありません <\p>
SomeHelper.php
...
public function showInfo(): HtmlString
{
if(!$this->hasInfo()) {
return new HtmlString(
view('path/to/parts/noinfo')->toHtml()
);
}
$someInfo = $this->someInfo;
return new HtmlString(
view('path/to/parts/info', compact('someInfo'))->toHtml()
);
}
- 皆様どうされてますか…？という質問
議論
- 自分もblade小分けにしてます派
- 逆意見
- 今時、デザイナーだからといって「if文とかわからないです…」では生き残れない
- AngularだとうとReactだろうと必ず直面する
ifやforくらい慣れてくれ- Laravelに限らず、他の言語他のフレームワークでも活かせる
else,switchはfat気味かも…？
- 案件次第、組織次第
IRT3 Laravel Track
Laravel+ GitHub Travis使ってる人ってどれくらいいるのでしょう。
- (TravisCI利用者はあまりいなかった)
- CIサービスは多種多様なので
- ぶっちゃけ、CIのみならなんでもいい…
- Jenkinsだろうが、自分で作ろうが構わない
- 作ったことがあれば、特定のサービスを使ったことがなくてもちょっと調べればわかる
- ぶっちゃけ、CIのみならなんでもいい…
- サービス別の色
- CI環境付属のプロセス -- RDBとか使ってますか？(ぼく質問)
皆さん、現場ではどのようなスケジュールで仕事を回していますか？また、1画面作るのにどのくらい時間かかっていますか？
- 画 面 数 で ガ ン ト チ ャ ー ト 引 く な
- 画面じゃなくて機能で引け
- Trivariate Estimates
- 【補】The Clean Coder
- 「見積もりは単一の値ではなく、分布である」という前提に基づく
- 確度1%以下の楽観的見積もり(
O)、悲観的見積もり(P)、および最も見込みの高い見積もり(N)の3つの値を用意する - 期待値
μ = (O + 4N + P) / 6 - 標準偏差
σ = (P - O) / 6 - 期待値
μは、たいていNよりも悲観寄りになる
- 誰向けの見積もりなのかによっても変わってくる
- クライアント向け
- 内部向け
- 開発を円滑に回すためのやつ
- とはいえ、画面数で見積もるのがわかりやすいのは確か
- 営業に「機能で見積もれ」と言うのは酷
- でも、画面数で見積もると現場が回らなくなっちゃう
- 技術がわかる営業がいるか、に尽きる
- アーキテクトが機能ごとに見積もって、画面ごとにならして「それっぽい見積もりを出す」のが良い落とし所かも
