Connect x Server-Side Kotlinで実現する！スキーマ駆動開発と品質改善の実践
- 市川 達裕さん (Sansan)
スキーマ駆動開発
知識ゼロのプロダクトにつくるテスト戦略
- massanさん (サイボウズ)
Java clientのテスト戦略
- kintoneのjava利用者向けのREST APIクライアント
- 仕様書なしでテスト戦略もなしユニットテストとE2Eはある
- 戦略策定
- 品質モデル(ISO 25010)を参考に戦略策定しスコープを定めた
- 機能テスト設計
- 探索 -> コードを読む -> エンジニアのレビュー
- 探索的テストをしていく
- コードを読んでテストするところしないところを判別
- clientの機能なのかその先のサーバの機能なのかとか
- エンジニア視点でいらないところを削ったり追加したり
- 自動テストとして実装できるかも聞く
- 相談しておくことでエンジニア側でもテストしやすくなる
- 運用しながらの改善
- 特性を見てテストを見直し
- 改修が少なく目立った不具合も少ない
- E2Eが過剰だったのでユニットテストに移したり
関数型プログラミングによるロバストなコード設計
- 豊田 優貴さん (Sansan)
副作用を意識した宣言的プログラミング
- ロバストナコード
- 副作用
- 関数の合成をするためには副作用があってはダメ
- 3つの分類わけをするといい
- Actions - 副作用あり
- Calculations - 純粋関数
- Data - 記録
- 宣言的プログラミング
- howではなくwhatを書く
- コンピネータ(filter/map/flatMapなど)を使うと良い
- 型駆動
- コードを考えるときに型から考える
- 型の誤りはコンパイルで気付ける
- どのように型遷移させるか
- 注文の状態ごとに型を用意するとか
- 例外も型で定義
- Result型
職能を超えたモブプログラミングが品質に与えた良い影響
- トニオさん (tonionagauzzi) (サイボウズ)
モブプログラミング
- 複数の作業者で同じ画面を見ながらコードを書いたりする
- 開発者とQAでモブプログラミングを始めた
- モブの流れ
- プランニングでタスク分割する
- 開発者は実装してQAはテスト仕様書作ってというのをスプリントの中でやっていく
- 以前は別軸で動いていた
- 開発終わって次に取り掛かった後にQAから指摘入ったりとかがあった
- 結果としてシフトレフトすることができた
