「Sansan VS サイボウズ - 品質向上Tips冬祭り」に参加してきました

• 2024/12/9
• https://sansan.connpass.com/event/335070/

Connect x Server-Side Kotlinで実現する！スキーマ駆動開発と品質改善の実践

• 市川 達裕さん (Sansan)

スキーマ駆動開発

• 技術スタック
  • Kotlin/Kator/goも
  • Google Cloud
• 体制
  • LeSS Hugeをベースに
• チームの動き方
  • 着手のタイミングでEventStormingやドメインやAPIの設計
  • BE/FEは同一チームで
• 課題
  • BE/FEのAPIスキーマのやりとり問題
  • リクエストのバリデーションを都度実装
  • 実装済みのAPI仕様を知るのにコードを読み解かないといけない
• スキーマ駆動
  • Connect
    • gRPC五感のHTTP APIを実装するためのフレームワーク
    • HTTP1.1でProxy不要
    • Protocol BuffersでAPI定義
    • Kotlinはクライアントしかサポートしてない
  • KotlinとConnect
    • Ktorのプラグインを作って対応した
    • Protobufのserializeができればいい
    • 既存のREST APIと共存させながら移行できた
  • protovalidateでバリデーション

知識ゼロのプロダクトにつくるテスト戦略

• 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から指摘入ったりとかがあった
• 結果としてシフトレフトすることができた