IRT1 PHP Track

自分の職場はテストを書く文化がないんですが、テストやCIといったツールを会社に広めて導入につなげていったような体験談とか、うかがってみたいです。

(より一般に)「新しい文化」を広めるために皆さんどうしていますか？
自動テストを書かない理由
- 慣れるまで大変だから
- 工数に関する心配があるから
  - 工数をかけた割に意味がなかったら…？
  - 「(仕様の)変更が多いから工数がかさむのでテスト書かない」
    - 変更が多いからこそ書くのでは？
  - すぐにリターンがあるわけではない
    - 【補】Economics of Test Automation (xUnit Test Patterns)
書く理由
- バグを防ぐため
  - その場合、テストをpushする必要ある？
    - 自分用ローカルで良いのでは
    - 他人を巻き込むと学習コスト、スイッチングコストが生じる
      - 「なんで今までのやり方から変えなきゃいけないの」
- プロダクションコードと同じバージョン管理下の「動く仕様書」として
  - テストがテストであることはたまたま、副次的なもの
  - とはいえ技術者じゃないと読めないよね
    - 【所感】非技術者でも読み書きできるようにBDDフレームワークが生まれたはず
      - 実際どんなものかは使ったことがないのでわからない…
- 開発のサイクルを快適に回すため
  - 【所感】進捗のバロメータとしてのテスト、ということかな
- 安心感をもたらすため
  - 言語やフレームワークのバージョンアップ等、影響範囲が甚大な変更
    - テストがないと怖くて無理
  - 仕様どおり作れている
    - 手戻りが少なくなり、結局工数を圧縮できることが多い(経験則)
  - 【補】バグ埋め込みを恐れずに変更・掃除できる
導入失敗事例: 勝手に新しい文化を導入したら評価(査定)が下がった話
- テストやCI、静的型付け等
- 「技術に寄りすぎ」 by エンジニアの2番目に偉い人
- 上の人が何を求めているかをまず知り、その人向けにカスタマイズした説得を
  - 根本的な考え方にすれ違いがあったりするもの
- こっそり進めて、外堀を埋めてから上の人を説得すべきだった
  - 同僚が上司についてしまった…
導入成功事例: Cake2 -> Laravelに載せ替えた際にCI・自動テストを導入した話
- 抵抗勢力がなかったのが救い
  - 「慣れるための時間をくれればいいよ」
  - 「余計の工数は心配だけれど、上司が許してくれるなら安心」
説得材料
- 数字
  - 例
    - バグ発生率
    - 長い目で見て工数がどれくらい減る
      - xUnit本の最初のほうに「長い目で効いてくる」というグラフが載っていたりはする
        
        【補】Economics of Test Automation (xUnit Test Patterns)
  - とはいえ難しい
    - その組織でうまくいくかどうかは、結局導入してみて比較してみないとわからない
    - 「よそはよそ、うちはうち」
- コスパの良いテストから提案する
  - 例
    - SPAでREST APIのスキーマを担保するだけのテスト
  - 分類
    - 単体テスト、機能テスト等
    - GoogleのTest Sizes
- 説明して説得するよりも「まず書いてみろ」
  - 【所感】xUnitよりはBDDフレームワークのほうがハードル低そう

IRT2 Laravel Track

みんなが思うlaravelのいい！こと、うーん？なところ

いい！
- 機能が多い、便利
- DIのしくみが強い
- bladeが便利
- Contract
  - 「わかってる人」が乗っかると強い
  - ドキュメントに載せるくらい重要視しているのがLaravelのえらいところ
- 使う中で設計原則が学べる
- 初動が速い
  - ビルトインサーバーでサクッと動かせる
うーん？
- 便利だけれど、FWのコードを掘っていくと設計がまずい
- 自由
  - CoCの逆な感じ
  - いい！ことと表裏一体ではある
  - Eloquent
    - 詳しい人がいないと危ない使い方ができてしまう
  - (rspecと比べて)テストの命名がバラバラ
    - test_*()とか/** @test */アノテーションとか
    - チームにより色が出てしまう
  - わかっていない人がContractに乗っからずに散らかした話(ぼくの前職)
    - AWS Cognitoを用いた独自認証
    - 謎のAuthLibを毎回呼ぶ。Auth::user()とか使えない
  - ロジックを分割しよう、となったときの分け方
    - どうディレクトリを切ってどこに置く？
  - 総論、牽引役がチームにしないと散らかる
- わかってない人が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気味かも…？
案件次第、組織次第
- issetはPHP固有だから、強制するのは忍びないところはある
  - デザイナーさんが関わるのはLaravelだけとは限らない
- その組織において、そのデザイナーが関わるのがずっとPHP/Laravelだけならば覚えてもらうはアリ

IRT3 Laravel Track

Laravel+ GitHub Travis使ってる人ってどれくらいいるのでしょう。

(TravisCI利用者はあまりいなかった)
CIサービスは多種多様なので
- ぶっちゃけ、CIのみならなんでもいい…
  - Jenkinsだろうが、自分で作ろうが構わない
  - 作ったことがあれば、特定のサービスを使ったことがなくてもちょっと調べればわかる
サービス別の色
- Travisは複数環境でのテストが容易でうれしい
- SSHを繋いでデバッグできると強い
- GitHub Actionsはmacosが使えるのが強い
CI環境付属のプロセス — RDBとか使ってますか？(ぼく質問)
- ランナーのlocalhostにMySQL 3306とかPostgres 5432とか生えてるやつ
- 便利なんだろうけれど、CI環境に依存してしまうので、本番環境で同様に動く保証がないですよね
  - 究極的には本番まで全部コンテナにしないと解決しない…

皆さん、現場ではどのようなスケジュールで仕事を回していますか？また、1画面作るのにどのくらい時間かかっていますか？

画　面　数　で　ガ　ン　ト　チ　ャ　ー　ト　引　く　な
- 画面じゃなくて機能で引け
Trivariate Estimates
- 【補】The Clean Coder
- 「見積もりは単一の値ではなく、分布である」という前提に基づく
- 確度1%以下の楽観的見積もり(O)、悲観的見積もり(P)、および最も見込みの高い見積もり(N)の3つの値を用意する
- 期待値μ = (O + 4N + P) / 6
- 標準偏差σ = (P - O) / 6
- 期待値μは、たいていNよりも悲観寄りになる
誰向けの見積もりなのかによっても変わってくる
- クライアント向け
- 内部向け
  - 開発を円滑に回すためのやつ
とはいえ、画面数で見積もるのがわかりやすいのは確か
- 営業に「機能で見積もれ」と言うのは酷
- でも、画面数で見積もると現場が回らなくなっちゃう
- 技術がわかる営業がいるか、に尽きる
- アーキテクトが機能ごとに見積もって、画面ごとにならして「それっぽい見積もりを出す」のが良い落とし所かも

環境変数のバージョン管理

(時間切れ)
【補】AWSマネージドサービス
- ECSでは「タスク定義」に環境変数を持たせてバージョン管理できる
- Lambdaも関数に環境変数を持たせてバージョン管理できる

D.Horiyama's output

Laravel Shibuya 6 IRTまとめ + 個人的所感・補足等

IRT1 PHP Track

自分の職場はテストを書く文化がないんですが、テストやCIといったツールを会社に広めて導入につなげていったような体験談とか、うかがってみたいです。

IRT2 Laravel Track

みんなが思うlaravelのいい！こと、うーん？なところ

bladeテンプレート内のロジックをヘルパモジュールに逃がしつつ、デザイナー(非プログラマ)と協業するには(ぼく質問)

【補】補足

議論

IRT3 Laravel Track

Laravel+ GitHub Travis使ってる人ってどれくらいいるのでしょう。

皆さん、現場ではどのようなスケジュールで仕事を回していますか？また、1画面作るのにどのくらい時間かかっていますか？

環境変数のバージョン管理