$30 off During Our Annual Pro Sale. View Details »

開発の生産性を高める事を考える

biwakonbu
November 12, 2023

 開発の生産性を高める事を考える

開発の生産性をどうやったら上げられるのかを考えつつ、以外とコストになっている事があるテストに焦点をあてて話をしています。

biwakonbu

November 12, 2023
Tweet

More Decks by biwakonbu

Other Decks in Technology

Transcript

  1. 自己紹介 1 株式会社 coroutine 東川 諒央 @biwakonbu 大学教員 ゲームバックエンド フリーランス

    経歴 Go Python 実績言語 Ruby 技術顧問 エンジニア教育 業務 設計 プログラミング インフラ etc… Rust Haskell TypeScript 趣味言語 Lisp
  2. 生産性の高い開発できていますか? 2 ❏ 高い生産性を実現する方法とは? ❏ なるべく人間を働かせない ❏ 仕様をシンプルにする ❏ 割り切るラインを作る

    ❏ プログラムが正しい仕事をする ❏ 人間の時間を取る程のことじゃないことはどんどん任せる ❏ PR レビュー時の小さな指摘、コードフォーマットの調整など ❏ API の仕様書はコードから生成する ❏ 自動テストを作る ❏ 組織、チームに知見を貯める ❏ 仕組み化する
  3. 生産性の高い開発できていますか? 2 ❏ 生産性と一口にいってもやっている事によって意味が異なる ❏ 例1) 受託開発の場合 ❏ 短期 ~

    中期の仕事が多い場合は早く形にし、顧客の合意を取る事が正義 ❏ 設計や自動化に凝りすぎるとコスト高に ❏ こだわるべきは毎回の PJ 立ち上げ~納品までで発生する繰り返し作業の省略 ❏ 例2) 長期運用サービスの場合 ❏ サービスの成長に伴いカオス化する仕様との戦い ❏ 品質維持コストが二次曲線になる ❏ 歴史的経緯で変わった仕様によってデッドコードの発生と管理コストの増大 ❏ こだわるべきはメンバーの新規参入時の障壁の除去と 品質維持のための活動の低減
  4. プログラムが正しい仕事をする 3 ❏ プログラムがするべき正しい仕事とは? ❏ 人の仕事を奪う ❏ リントの導入は仕事を奪ってるか? ❏ フォーマッタは?

    ❏ 静的型解析は? ❏ 自動テストをやってちゃんと奪われましたか? ❏ ツールや仕組みを導入するという事は仕事を増やすという事 ❏ つまり...... 仕事を増やした結果、仕事の総量が減る事が重要
  5. プログラムが正しい仕事をする 3 ❏ コストの掛け方を間違えるとどうなるか? ❏ 例えば自動テストの場合 ❏ 損益分岐点を越えないのであれば極論不要 ❏ 開発3日で納品するものには多分不要ですよね?

    ❏ このケースで問題なのは、自動テストの性質 ❏ 人間が作業しないと作れないのが問題 ❏ 実行は機械だけど、作成は人間という構図 ❏ ただ、完全に不要という話ではないので注意 ❏ ややこしい内容にはテストが必要 ❏ テストを書く部分を見極めようという話 引用: ソフトウェアのテスト自動化とは?メリットや留意 点、実行方法、ツールなどを紹介 | Sqripts
  6. テストって面倒で大変な仕事 4 ❏ テストコードの作成は非常に大変でコストが嵩み (かさ*み) がち ❏ 状況によっては書かないという選択を取るような場合も ❏ さらにテストがあってもなお不安でもある

    ❏ そこで最近話題の「Property Based Testing (PBT)」に着目する ❏ Property とは、”特性” の事を指す ❏ 「特定の入力が与えられると出力として期待される特性」をテストするもの 
 ❏ ランダム値を特性の幅に合わせて縮小させながら繰り返し入力テストを行うのが本筋 
 ❏ 要するに、テストコードを書く量を本質的に減らせる筈 (不要になるとは言わない) 

  7. Python ではどうやるのか? 5 ❏ Hypothesis というライブラリを使う 通常の "自動化された "ソフトウェアテストは、驚くほど手作業だ。コンピューターが実行す るすべてのシナリオを、誰かが手作業で書かなければならないのだ。仮説はこれを解決

    できる。 Hypothesisは、テストプロセスを自動化する新世代のツールです。問題領域に対する人 間の理解と機械知能を組み合わせ、テストを書く時間を減らしながらテストプロセスの質を 向上させます。 (Google 日本語訳)
  8. 使用感 5 ❏ 慣れが必要な部分は結構ありそう ❏ ランダム生成がベースにあり、全てを網羅する事は必ず保証される訳ではない ❏ 必ずテストして欲しい「入力値」は設定できる ❏ テストで落ちた内容を

    Redis などで共有できるのは便利そう ❏ 書いてみてどうか? ❏ 大量にテストデータを書いてソースを汚すのは確かになさそう ❏ Copilot と相性が良くてほぼ書かなくても大体やりたい事ができた ❏ 今回はいっしょくたにテストを書いたけど、従来通りわけた方が良さそう ❏ 労力は削減できそうか? ❏ 慣れに依存する所は大きそうだけど、慣れるとめちゃくちゃ楽だと思う ❏ 単体テストも統合テストも入力値を大量に試せるのは嬉しい
  9. まとめ 6 ❏ 仕事の削減を実現するためにプロパティベースドテストを Python で試してみた ❏ テストコードを少なく大量のケースを担保できるのはスクリプト言語と相性が良さそう ❏ 自動的なテスト生成なのでテストケースのノウハウがあまり必要にならないのが良い

    ❏ 100%抜けを見つけるというより、 10%の労力で80%の精度を担保するくらいのイメージ ❏ 詳細なケースは都度ケース指定で足して育てていくのが正解っぽい ❏ 今回は時間の都合で紹介しなかったけど、 schemathesis というのもある ❏ OpenAPI / GraphQL のスキーマを利用して API を PBT するツール ❏ API テストの入力を大量自動化できるのは嬉しい ❏ Django REST Framework や FastAPI で導入できると作業とテストの効率が良さそう ❏ 開発 -> スキーマ自動生成 -> スキーマを利用したテスト自動化の流れは強い ❏ Python は静的型解析 + PBT で省力で健全な開発環境を構築できそうな未来が見えてきた