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
Atsushi Okui
September 21, 2025
Programming
0
170
プログラミングどうやる? ~テスト駆動開発から学ぶ達人の型~
Atsushi Okui
September 21, 2025
Tweet
Share
More Decks by Atsushi Okui
See All by Atsushi Okui
(社内向け)『Accelerate State of DevOps Report 2022』翻訳とまとめ
a_okui
0
2.5k
コード品質がもたらすビジネスへの影響(社内向け翻訳、まとめ)
a_okui
0
350
(社内向け)『Accelerate State of DevOps Report 2021』翻訳とまとめ
a_okui
0
600
Other Decks in Programming
See All in Programming
メモリ不足との戦い〜大量データを扱うアプリでの実践例〜
kwzr
1
210
MCPでVibe Working。そして、結局はContext Eng(略)/ Working with Vibe on MCP And Context Eng
rkaga
5
2.4k
Refinementsのメソッド定義を4000倍速くした話
alpacatc
0
190
print("Hello, World")
eddie
2
540
FindyにおけるTakumi活用と脆弱性管理のこれから
rvirus0817
0
590
LLMとPlaywright/reg-suitを活用した jQueryリファクタリングの実際
kinocoboy2
0
160
AIを活用したレシート読み取り機能の開発から得られた実践知 / AI Receipt Scan Practice
rockname
1
660
ファインディ株式会社におけるMCP活用とサービス開発
starfish719
0
2.3k
Performance for Conversion! 分散トレーシングでボトルネックを 特定せよ
inetand
0
5.6k
実践AIチャットボットUI実装入門
syumai
2
570
Swiftビルド弾丸ツアー - Swift Buildが作る新しいエコシステム
giginet
PRO
0
240
麻雀点数計算問題生成タスクから学ぶ Single Agentの限界と Agentic Workflowの底力
po3rin
3
650
Featured
See All Featured
Docker and Python
trallard
46
3.6k
Git: the NoSQL Database
bkeepers
PRO
431
66k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.4k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.6k
A Tale of Four Properties
chriscoyier
160
23k
A designer walks into a library…
pauljervisheath
207
24k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Writing Fast Ruby
sferik
628
62k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.5k
Optimizing for Happiness
mojombo
379
70k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.1k
Context Engineering - Making Every Token Count
addyosmani
3
75
Transcript
プログラミングどうやる? テスト駆動開発から学ぶ達人の型
自己紹介 Atsushi Okui (@blue32a_jp) ソフトウェアエンジニア / Webアプリケーション エンジニア / PHPer
関心:設計、コード品質、リファクタリング、テス ト、モデリング
主題 プログラミングどうやる?
プログラミングで目指すゴール 『動作するきれいなコード』
「動作する」のゴール • ステークホルダーからの要求 • 仕様書、設計書 • Issue • etc.
「きれいな」のゴール • 『リーダブルコード』 • SOLID原則 • デザインパターン • **** アーキテクチャ
• etc.
動作するきれいなコード
ゴールの情報は様々あるが、 どうやって行くかの情報はあま り無かったりする
プログラミングどうやる? どうやってゴール(動作するきれいなコード) を目指す?
副題 テスト駆動開発から学ぶ達人の型
テスト駆動開発:? 達人:?👈 型:?
テスト駆動開発の考案者 Kent Beckさん
テスト駆動開発:? 達人:Kent Beckさん 型:?
テスト駆動開発:?👈 達人:Kent Beckさん 型:?
混同されやすい自動テスト関係の概念 ”テスト駆動開発(TDD:Test-Driven Development)という 名前は、現在では多くのエンジニアに広まっていますが、 そこにはやや混乱も見られます。「 TDD」という言葉が指し ているものが人によって異なるのです。自動テストを書くこ とをTDDと呼ぶ人もいれば、テストを先に書くこと(テスト ファースト)をTDDと呼ぶ人もいます。TDDの利点を説く人 の説明をよく読んでみると、自動テストの利点や、テスト
ファーストの利点のことを述べているような場面に出会うこ とも多々あります。” 保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発 、その全体像 https://gihyo.jp/article/2024/01/automated-test-and-tdd
テスト駆動開発の定義 ”Test-driven development is a programming workflow.” 訳)”テスト駆動開発(TDD: Test-Driven Development)はプログラミングのワークフロー
だ。” 【翻訳】テスト駆動開発の定義 https://t-wada.hatenablog.jp/entry/canon-tdd-by-kent-beck Canon TDD https://tidyfirst.substack.com/p/canon-tdd
テスト駆動開発:プログラミングのワークフロー 達人:Kent Beckさん 型:?
テスト駆動開発:プログラミングのワークフロー 達人:Kent Beckさん 型:?👈
「型」 我々が慣用的に使用する「型」という言葉に二つの異なる視 点が存在し、相反する概念を内包している。 • 物事の枠組みや分類方法としての型 • 叡智の表現・伝達方法としての型 「型」の再考 https://kyoto-up.or.jp/books/9784814003648.html
物事の枠組みや分類方法としての型 叡智の表現・伝達方法としての型
テスト駆動開発:プログラミングのワークフロー 達人:Kent Beckさん 型:達人の叡智
プログラミングのワークフローを通して、 Kent Beckさんの叡智を学ぶ
ワークフロー図解 Canon TDD https://tidyfirst.substack.com/p/canon-tdd
テスト駆動開発で見逃されたもの
テスト駆動開発とは何か ”テスト駆動開発(TDD)はテストファーストの利点を伸ば し、欠点を補うために生まれました。設計面でのテスト ファーストの強みを活かしつつ、保守性を上げるためにリ ファクタリングが組み込まれています。またやりすぎ、考え すぎ(スコープクリープ)を避けるために、イテレーティブな 開発手順とインクリメンタルな設計の要素が組み込まれま した。” 保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発 、その全体像
https://gihyo.jp/article/2024/01/automated-test-and-tdd
テスト駆動開発のステップ1 ”多くの人が、書籍『テスト駆動開発』の中に出てくるこのステップ1(*)を見逃しているよう だ。「TDDはいきなりコードを書き始める。いつ終わるのかも全然見通せない」という意 見は、全くの見当外れだ。” * ステップ1. テストリスト 【翻訳】テスト駆動開発の定義 https://t-wada.hatenablog.jp/entry/canon-tdd-by-kent-beck Canon
TDD https://tidyfirst.substack.com/p/canon-tdd
None
None
None
テスト駆動開発の”テスト”が注目され、 TODOリストは見逃されがち
テスト駆動開発のサイクル
Red Green Refactor
Red Green Refactor Pick one Done
小さなタスクの完了 を積み上げてゴールを目指す
型を取り込む
「型」の内在化と変化 ”学習者は創始者とは身体性も経験も異なる存在であること から、創始者が意図した叡知を全て完璧に内在化するという のは、ほぼ不可能であると言ってよい。” ”科学的な叡智が一意的に客体化されるが故に変化なく伝達 されるのに対して、「型」は主体による多義的な把握を認める ため、叡知伝達の過程で変化することがしばしばである。” 「型」の再考 https://kyoto-up.or.jp/books/9784814003648.html
守破離 守:型を忠実に守る 破:型を発展させ、自分の型を模索する 離:既存の型から離れて、独自の型を生み出す
達人たちの型
Kent Beck さんのテスト駆動開発 https://shop.ohmsha.co.jp/shopdetail/000000004967/ • 仮実装 • 明白な実装 • 三角測量
• 歩幅の調整 • 実装を導くテスト
t-wadaさんのテスト駆動開発 https://www.youtube.com/live/Q-FJ3XmFlT8?t=1145s • タスクの分解 • 優先順位の付け方 • 検証→実行→準備
ボブおじさんのテスト駆動開発 https://blog.cleancoder.com/uncle-bob/2013/05/27/TheTransformationPriorityPremise.html • TDDは複式簿記 • 変換の優先順位説
達人の「型」から 自分の「型」へ
ふつうの人のテスト駆動開発 https://qiita.com/blue32a/items/2084c9e5cff97980a1c7
まとめ プログラミングのゴール(完成形)について様々な情報はあるが、その過程についての 情報は少ない テスト駆動開発を「プログラミングの型」と捉えることで、「達人のやり方」を自身に取り込 む 型を学び、自分のプログラミング スタイルを作り上げる(テスト駆動開発でなくても良い)
スライドの目的 このスライドの目的は「正しい/真のテスト駆動開発」を明らかにすることではなく、テスト 駆動開発を「プログラミングの型」として捉えることで、達人たちのプログラミングの叡知 を学ぶことです。
完