Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
開発の生産性を高める事を考える
Search
biwakonbu
November 12, 2023
Technology
0
110
開発の生産性を高める事を考える
開発の生産性をどうやったら上げられるのかを考えつつ、以外とコストになっている事があるテストに焦点をあてて話をしています。
biwakonbu
November 12, 2023
Tweet
Share
More Decks by biwakonbu
See All by biwakonbu
Django を使い続ける理由
biwakonbu
0
68
爆速なPythonフレームワーク
biwakonbu
0
91
HTMX触ってみた
biwakonbu
0
98
スタートアップの技術顧問を3年間続けて発生した事と気付き
biwakonbu
0
270
プログラミングを体系的に学べる言語 Python を推したい
biwakonbu
0
95
プログラミング言語F#を学びはじめました
biwakonbu
0
160
「プログラミングを習得する」を考えてみた
biwakonbu
0
57
Python の型事情について
biwakonbu
0
60
ESLint使ってますか?
biwakonbu
0
86
Other Decks in Technology
See All in Technology
プロダクト開発の貢献をアピールするための目標設計や認知活動 / Goal design and recognition activities to promote product development contributions.
oomatomo
2
410
令和最新版 Perlコーディングガイド
anatofuz
4
3.5k
クレジットカードを製造する技術
yutadayo
81
46k
kube-vipとkube-proxy置き換えCiliumを積んだ究極のK3sクラスタを建てる
logica0419
4
210
Webセキュリティのあるきかた
akiym
31
9.6k
How CERN serves 1EB of data via FUSE
ennael
PRO
0
16k
成果のためのコミュニケーション - 語彙を育てよう -/communication-for-good-outcome-developing-vocabulary
hassaku63
4
160
Case Study: Concurrent Counting
ennael
PRO
0
100
Pythonを活用したLLMによる構造的データ生成の手法と実践
brainpadpr
3
320
LeSSはスクラムではない!?LeSSにおけるスクラムマスターの振る舞い方とは / Scrum Master Behavior in LeSS
toma_sm
0
170
ドメインと向き合う - 旅行予約編
hidenorigoto
4
560
ドキュメントとの付き合い方を考える
leveragestech
1
120
Featured
See All Featured
Making Projects Easy
brettharned
115
5.8k
How to name files
jennybc
77
99k
RailsConf 2023
tenderlove
28
840
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
24
1.7k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.8k
Bootstrapping a Software Product
garrettdimon
PRO
304
110k
A Tale of Four Properties
chriscoyier
156
22k
A better future with KSS
kneath
237
17k
BBQ
matthewcrist
85
9.2k
We Have a Design System, Now What?
morganepeng
49
7.2k
Robots, Beer and Maslow
schacon
PRO
157
8.2k
Code Review Best Practice
trishagee
62
16k
Transcript
開発の生産性を高める事を考える 株式会社coroutine 東川 諒央
自己紹介 1 プログラムが正しい仕事をする 3 テストって面倒で大変な仕事 4 生産性の高い開発できていますか? 2 5 Python
ではどうやるのか? 6 まとめ
自己紹介 1 株式会社 coroutine 東川 諒央 @biwakonbu 大学教員 ゲームバックエンド フリーランス
経歴 Go Python 実績言語 Ruby 技術顧問 エンジニア教育 業務 設計 プログラミング インフラ etc… Rust Haskell TypeScript 趣味言語 Lisp
> 生産性の高い開発できていますか? ※自分への問いかけです
生産性の高い開発できていますか? 2 ❏ 高い生産性を実現する方法とは? ❏ なるべく人間を働かせない ❏ 仕様をシンプルにする ❏ 割り切るラインを作る
❏ プログラムが正しい仕事をする ❏ 人間の時間を取る程のことじゃないことはどんどん任せる ❏ PR レビュー時の小さな指摘、コードフォーマットの調整など ❏ API の仕様書はコードから生成する ❏ 自動テストを作る ❏ 組織、チームに知見を貯める ❏ 仕組み化する
生産性の高い開発できていますか? 2 ❏ 生産性と一口にいってもやっている事によって意味が異なる ❏ 例1) 受託開発の場合 ❏ 短期 ~
中期の仕事が多い場合は早く形にし、顧客の合意を取る事が正義 ❏ 設計や自動化に凝りすぎるとコスト高に ❏ こだわるべきは毎回の PJ 立ち上げ~納品までで発生する繰り返し作業の省略 ❏ 例2) 長期運用サービスの場合 ❏ サービスの成長に伴いカオス化する仕様との戦い ❏ 品質維持コストが二次曲線になる ❏ 歴史的経緯で変わった仕様によってデッドコードの発生と管理コストの増大 ❏ こだわるべきはメンバーの新規参入時の障壁の除去と 品質維持のための活動の低減
> プログラムが正しい仕事をする
プログラムが正しい仕事をする 3 ❏ プログラムがするべき正しい仕事とは? ❏ 人の仕事を奪う ❏ リントの導入は仕事を奪ってるか? ❏ フォーマッタは?
❏ 静的型解析は? ❏ 自動テストをやってちゃんと奪われましたか? ❏ ツールや仕組みを導入するという事は仕事を増やすという事 ❏ つまり...... 仕事を増やした結果、仕事の総量が減る事が重要
プログラムが正しい仕事をする 3 ❏ コストの掛け方を間違えるとどうなるか? ❏ 例えば自動テストの場合 ❏ 損益分岐点を越えないのであれば極論不要 ❏ 開発3日で納品するものには多分不要ですよね?
❏ このケースで問題なのは、自動テストの性質 ❏ 人間が作業しないと作れないのが問題 ❏ 実行は機械だけど、作成は人間という構図 ❏ ただ、完全に不要という話ではないので注意 ❏ ややこしい内容にはテストが必要 ❏ テストを書く部分を見極めようという話 引用: ソフトウェアのテスト自動化とは?メリットや留意 点、実行方法、ツールなどを紹介 | Sqripts
> 今日はテストの話をします
テストって面倒で大変な仕事 4 ❏ テストコードの作成は非常に大変でコストが嵩み (かさ*み) がち ❏ 状況によっては書かないという選択を取るような場合も ❏ さらにテストがあってもなお不安でもある
❏ そこで最近話題の「Property Based Testing (PBT)」に着目する ❏ Property とは、”特性” の事を指す ❏ 「特定の入力が与えられると出力として期待される特性」をテストするもの ❏ ランダム値を特性の幅に合わせて縮小させながら繰り返し入力テストを行うのが本筋 ❏ 要するに、テストコードを書く量を本質的に減らせる筈 (不要になるとは言わない)
> Python ではどうやるのか?
Python ではどうやるのか? 5 ❏ Hypothesis というライブラリを使う
Python ではどうやるのか? 5 ❏ Hypothesis というライブラリを使う 通常の "自動化された "ソフトウェアテストは、驚くほど手作業だ。コンピューターが実行す るすべてのシナリオを、誰かが手作業で書かなければならないのだ。仮説はこれを解決
できる。 Hypothesisは、テストプロセスを自動化する新世代のツールです。問題領域に対する人 間の理解と機械知能を組み合わせ、テストを書く時間を減らしながらテストプロセスの質を 向上させます。 (Google 日本語訳)
Python ではどうやるのか? 5
Python ではどうやるのか? 5
Python ではどうやるのか? 5
Python ではどうやるのか? 5
Python ではどうやるのか? 5
Python ではどうやるのか? 5
使用感 5 ❏ 慣れが必要な部分は結構ありそう ❏ ランダム生成がベースにあり、全てを網羅する事は必ず保証される訳ではない ❏ 必ずテストして欲しい「入力値」は設定できる ❏ テストで落ちた内容を
Redis などで共有できるのは便利そう ❏ 書いてみてどうか? ❏ 大量にテストデータを書いてソースを汚すのは確かになさそう ❏ Copilot と相性が良くてほぼ書かなくても大体やりたい事ができた ❏ 今回はいっしょくたにテストを書いたけど、従来通りわけた方が良さそう ❏ 労力は削減できそうか? ❏ 慣れに依存する所は大きそうだけど、慣れるとめちゃくちゃ楽だと思う ❏ 単体テストも統合テストも入力値を大量に試せるのは嬉しい
> まとめ
まとめ 6 ❏ 仕事の削減を実現するためにプロパティベースドテストを Python で試してみた ❏ テストコードを少なく大量のケースを担保できるのはスクリプト言語と相性が良さそう ❏ 自動的なテスト生成なのでテストケースのノウハウがあまり必要にならないのが良い
❏ 100%抜けを見つけるというより、 10%の労力で80%の精度を担保するくらいのイメージ ❏ 詳細なケースは都度ケース指定で足して育てていくのが正解っぽい ❏ 今回は時間の都合で紹介しなかったけど、 schemathesis というのもある ❏ OpenAPI / GraphQL のスキーマを利用して API を PBT するツール ❏ API テストの入力を大量自動化できるのは嬉しい ❏ Django REST Framework や FastAPI で導入できると作業とテストの効率が良さそう ❏ 開発 -> スキーマ自動生成 -> スキーマを利用したテスト自動化の流れは強い ❏ Python は静的型解析 + PBT で省力で健全な開発環境を構築できそうな未来が見えてきた
まとめ 6 ❏ プロパティベーステスト本の発売に触発されて今回の内容にしました
P.S. 大阪プログラミングコミュニティ始めました エンジニアのための学習・交流を行うコミュニティスペースを作っています 勉強したい人や人と繋がりたい人に向けてサービス提供していきます 色々なご相談にも対応します ・就活・キャリアアップ相談 ・業務に関する相談 ・個人的な学習の相談 大阪でのエンジニアコミュニティを応援します ・勉強会場として無料で場所貸し
・むしろ開催応援のギフト券なども考えています ・長く続く開発者コミュニティ作りを実行します
おわり