【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ
システム開発の世界において「技術的負債（Technical Debt）」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham （ウォード・カニンガム）です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました（"Shipping first time code is like going into debt"）。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
質とスピード 初演: 2019/10/31 @ EOF2019
質とスピード（2020春版） / Quality and Speed 2020 Spring Edition
質とスピード（2020春版） 2020/02/13 @ デブサミ2020
質とスピード（2022春版、質疑応答用資料付き） / Quality and Speed 2022 Spring Edition
質とスピード（2022春版、質疑応答用資料付き）
ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog
はじめに スタンフォード大学の John Ousterhout 教授が執筆された “A Philosophy of Software Design”(以下 APoSD と略す) という書籍をご存じでしょうか？ 書籍のタイトルを直訳すると、「ソフトウェア設計の哲学」となります。書籍の内容はまさに、ソフトウェア設計について扱っています。 本書籍をベースに、「A Philosophy of Software Design を30分でざっと理解する」というお題で社内ランチ勉強会が開催されました。本記事執筆者である岩瀬(@iwashi86)が発表者であり、勉強会資料は以下のとおりです。 スライド P.4 に記載したとおり、本書籍は John Ousterhout 教授の意見が強く反映されており、ソフトウェアエンジニアであれば、議論を呼ぶ箇所があります。実際、勉強会の実況Slackでは、「これはどうな
このブログエントリでは、テスト駆動開発（TDD: Test-Driven Development）の考案者 Kent Beck が TDD の定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化（Semantic Diffusion）とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私（和田）はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、T
予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント / Growing Reliable Code PHPerKaigi 2022
PHPerKaigi 2022 2022/04/10 10:40〜 Track A レギュラートーク（40分） PHP はバージョンを追う毎に型宣言、例外、表明、列挙型などの機能が大幅に強化され、堅牢なコードを書くための機能が充実してきました。それらの機能はどう使うと効果的なのでしょうか。 本講演では PHP 8.1 をベースにして、誤りを想定してチェックするのではなく、そもそも誤りにくい設計とはどのようなものか、つまり「予防」の観点を軸足に、堅牢なコードを導くための様々な設計のヒントをご紹介します。 Agenda - 型宣言 - 列挙型 - ドメインモデリング - 不変性と等価性 - 完全性 - レイヤーと責務
この文章の背景 この文章はプライベートメソッドのテストを書くべきか否かに関する knsmr さんのご質問に対して 2013/03/13 に QA＠IT で回答したものです。残念ながらQA＠IT のサービス終了（2020/02/28）と共にアクセスできなくなってしまったため、運営を行っていたアイティメディア株式会社様、開発を行っていた永和システムマネジメント様、そして質問をされた knsmr さんに許可とご協力をいただき、当時の回答をサルベージしてブログに転載する運びとなりました。 プライベートメソッドのテストはよく議論になるテーマですので、当時の回答を再編集し、knsmr さんのご質問も含め、ご利用いただきやすいライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で公開いたします。 目次 この文章の背景 目次 knsmr さんのご質問 私の回
質とスピード（2020秋100分拡大版） / Quality and Speed 2020 Autumn Edition
質とスピード（2020秋100分拡大版） 2020/11/20 @ JaSST'20 Kyushu
はじめに 和田さん（@t_wada）の講演が素晴らしく良かったのでメモを残しておきたいと思います。和田さんと言えば... t_wada ですね！本講演では、「技術の学び方を学ぶ」ことを目的として二部構成で論が展開されました。「技術の学び方の学び」とは、メタレベルの学びのことを指しています。すなわち、効率的に新しい技術を学ぶためにはどのように学べば良いのかという話です。内容は以下の通りです。 第一部 四半期ごとに技術書を読む 手を動かしながら学ぶ 毎年少なくとも一つの言語を学ぶ 身の回りをプログラミング対象にする アウトプットを行う 第二部 毎日コードを書く 年下から学ぶ 過去から未来を見る 人のつくる渦を見る 大事なことに集中する いずれも非常に興味深い内容だったのですが、細かい事項については2017年の講演メモのエントリーがありましたので、ぜひそちらをご覧いただければと思います。（記事へ
動作するきれいなコード: SeleniumConf Tokyo 2019 基調講演文字起こし+α - t-wadaのブログ
この文章は、2019年4月18日に開催された国際カンファレンス SeleniumConf Tokyo 2019 で行った基調講演の文字起こしを土台に加筆修正したものです。 当日の講演資料は speakerdeck で、動画は YouTube で公開されています。 Clean code that works - How can we go there? - Takuto Wada | SeleniumConf Tokyo 動作するきれいなコード - どうたどり着くか 本日の講演タイトルは「動作するきれいなコード - どうたどり着くか」です。動作するきれいなコードへ至る道の話をさせていただこうと思います。 資料は公開予定で、講演の写真撮影も問題ありません。ツイッター等での実況も大歓迎です。ハッシュタグは #SeConfTokyo です。 改めて自己紹介です。和田卓人（わだたくと）といいまして、
組織にテストを書く文化を根付かせる戦略と戦術（2019夏版） / Strategy and Tactics of Building Automated Testing Culture into Organization 2019 Summer Edition
デブサミ夏 【B-4】 2019/07/02 13:15 ～ 14:00 https://event.shoeisha.jp/devsumi/20190702/session/2077/
ソフトウェアエンジニアとしての姿勢と心構え / Software Engineer's Survival Guide
2022年度リクルート エンジニアコース新人研修の講義資料です
品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（前編）。デブサミ2020
品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（前編）。デブサミ2020 ソフトウェア開発のプロジェクトにおいて、リリースに間に合わせるために開発スピードを優先させ、ひとまず質には目をつぶろう、という判断がしばしば行われることがあります。 はたしてその判断は正しいのでしょうか。2020年2月13日と14日の2日間、都内で行われたイベント「Developers Summit 2020」（デブサミ2020）」の和田卓人氏のセッション「質とスピード」は、これを深く考察したものでした。 この記事では、会場に立ち見がでるほど大人気だった本セッションの内容をダイジェストで紹介します。本記事は前編と後編に分かれています。いまお読みの記事は前編です。
『スタディサプリ』における SLI/SLO の継続的改善 / Continuous improvement of SLI/SLO at StudySapuri
実録レガシーコード改善 / Working with Legacy Code: the True Record
2024/01/15(月) 12:00 〜 13:00 t-wadaさんが後世に残したい、実録レガシーコード改善 https://findy.connpass.com/event/304101/ テストコードが無いコードを引き継いだところからはじまる、実際に2018年に行った受託開発案件のエピソードとコードをプロダクトオーナー（引き継ぎ前のコードを書いた本人）の許可を得て使用しています。登場するコードは全て本物、登場するデータは講演用の架空のものです。
ソフトウェアエンジニアとしての姿勢と心構え / Software Engineer's Survival Guide
2021年度リクルート エンジニアコース新人研修の講義資料です
アジリティを支える品質特性 / Agility and Quality Characteristics Developers Summit 2021 Summer
Developers Summit 2021 Summer［A-1］アジリティを支える品質特性 講演日時: 2021年07月30日（金） 10:00 ～ 10:45 概要: ビジネスにとってITは、「あると便利」から「有効」、「不可欠」を経て「中核そのもの」になりつつあり、柔軟かつ俊敏にソフトウェアエンジニアリングを進める力は企業の競争力の源泉となりました。本セッションでは、そのような競争力あるソフトウェアを開発し続ける力を構成する要素を、品質特性等の側面から掘り下げていきたいと考えています。
【第1回・前編】 エンジニア和田卓人の今を形作る技術 | GeeklyMedia(ギークリーメディア) | Geekly（ギークリー） IT・Web・ゲーム業界専門の人材紹介会社
『テスト駆動開発』や『SQLアンチパターン』をはじめとする技術書の翻訳者、さまざまなIT企業をわたり歩く技術顧問、さらに最近ではエンジニアリング文化を伝える講演者としても活躍されている和田卓人さん(https://twitter.com/t_wada)。 そのソフトウェアエンジニアとしての素顔を株式会社一休CTOの伊藤直也さん(https://twitter.com/naoya_ito)が聞き出す対談の前編では、一線を画すエンジニアであり続けるために自らのプロジェクトで意識的にコードを書いているという和田さんの姿勢に始まり、ベテランとして「技術のらせん」を読み解くケーススタディとしてDDD（Domain-Driven Design）を題材に話を伺います。 ・伊藤 直也さん / 株式会社 一休 執行役員 CTO 新卒入社したニフティ株式会社でブログサービス「ココログ」を立ち上げ、CTOを務め
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版（Gihyo Digital Publishing、Amazon Kindle）をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ
「テスト書いてないとかお前それ〜」が私の代名詞になるまで。テスト駆動開発とともに歩んだキャリア - Findy Engineer Lab
日本におけるテスト駆動開発の著名人といえば誰か？ この問いを投げかけられたとき、多くのエンジニアが思い浮かべる人物がいます。ITコンサルタント・ソフトウェアエンジニアの和田卓人（@t_wada）さんです。和田さんは日本のテスト駆動開発の第一人者として、長年、この分野の実践や講演・執筆などの普及活動を続けてきました。 こう書くと、読者のなかには「和田さんはもともとテストが好きだったから、テスト駆動開発の第一人者になれたのでは」と思われた方もいるかもしれません。しかし、その答えはNOです。むしろ和田さんは、テストが嫌いなエンジニアだったといいます。ある出来事をきっかけとして、嫌いだったテストを好きになれる方法を見つけたのです。 読者の方々にも「自分には○○なんて向いていない」という印象を抱いている技術領域があるかもしれません。ですが、そんな領域にこそ、あなたの新たな可能性が詰まっているかもしれ
【続】ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog
はじめに 本記事は前回の記事である「ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog」の続編です。 前回の記事の内容がベースとなっていますので、「APoSD って何だっけ？」という場合はぜひ前回の記事をご覧になってから、以下にお進みください。 ということで、後編の対話パートにさっそく入っていきましょう！ Pull Complexity Downwards iwashi: APoSD では、複雑性を下に追いやる(Pull Complexity Downwards)という話が出てきます。何らかの処理が複雑になる場合、それを隠蔽してインターフェースを極力シンプルに保つ、というのがAPoSDの主張です。 こちらに関しても、社内勉強会中で
本編開始は 19:05 からです こちらのイベントのYoutubeLive配信のアーカイブです https://tddbc.connpass.com/event/183044/ チャプター 0:00:00 準備開始 0:19:05 講演開始 0:41:55 ライブコーディング開始 0:57:20 プログラミング開始 1:02:00 最初の RED ？ 1:19:00 fake it 1:26:50 最初のリファクタリングおわり 1:36:40 質問タイム 1:51:20 5の倍数に着手 1:53:40 前半のデモのまとめ 1:55:20 質問タイム2回目 1:56:45 リリースから3年後の世界（テストをメンテナンスしやすくする） 2:14:20 テストの構造化とリファクタリングの説明
テスト駆動開発のはじめの一歩｜t_wadaさんに聞く1人で始める自動テストのコツと考え方 - Agile Journey
アジャイル型の開発が導入されていない現場であっても、そして一人であっても、実践可能なアジャイルに関するプラクティスは存在します。 例えば、自動テストや、テストファースト、テスト駆動開発（TDD：Test Driven Development）です。ユニットテストフレームワークを使ってテストコードを書いて開発しながらテストを実行する「自動テスト」、実装の前にそのテストコードを書く「テストファースト」、テストと実装を繰り返しながらインクリメンタルに設計・開発を行うのが「TDD」。これらプラクティスのなかで、はじめの一歩となるのが自動テストですが、1人で実践するには、どこからはじめるか、どうテストを組み立てればよいのか、あるいは自分のテスト方法は適切なのか、不安を持つこともあるでしょう。 そこで本稿では、さまざまなチームや組織へのテスト手法の導入を支援し、精力的に講演や執筆などを行ってきたこの分
組織に自動テストを書く文化を根付かせる戦略（2022秋版） / Building Automated Test Culture 2022 Autumn Edition
2022年9月9日 日本科学技術連盟 ソフトウェア品質シンポジウム2022（SQiP2022）
和田 卓人さん（t_wadaさん）に「予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント」を社内で講演いただきました！ | Wantedly Engineer Blog
こんにちは、ウォンテッドリーDev Branch VPoE 室長の髙橋です。 ウォンテッドリーの開発組織であるDev Branchでは、外部から有識者を招いて勉強会を開催したり、技術顧問として知見を取り入れるなど、プロダクト開発により強い組織となるためにさまざまな施策を行っています。 今回、「テスト書いてないとかお前それ @t_wada の前でも同じ事言えんの」 でおなじみのt_wadaさん（和田 卓人さん、以下和田さん）に「予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント」をウォンテッドリー向けにカスタマイズして講演いただきました。 このストーリーでは、今回の講演の経緯から社内の反応・Q&Aまで、講演に関する詳細をご紹介いたします。 社内講演のきっかけ事の発端は、弊社のVPoEである要（X : @nory_kaname）より、外部エンジニアを招いて勉強会を開催する旨の問いかけ
変更容易性と理解容易性を支える自動テスト（2024/02版） / Automated Test Knowledge from Savanna 202402 YAPC::Hiroshima edition
YAPC::Hiroshima 2024
本イベントでは「実録レガシーコード改善」というタイトルで、実際にt-wadaさんがテストの全くないシステムを引き継いだところからスタートする実話をお話していただきます。 イベントページ： https://findy.connpass.com/event/304101/
Worse Is Better - 過去を知り、未来に備える。技術選定の審美眼 2019 edition / Worse Is Better - Understanding the Spiral of Technologies 2019 edition
2019年5月17日（金）@ Oracle Code Tokyo 2019 https://www.oracle.co.jp/events/code/2019/
品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（後編）。デブサミ2020
品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（後編）。デブサミ2020 ソフトウェア開発のプロジェクトにおいて、リリースに間に合わせるために開発スピードを優先させ、ひとまず質には目をつぶろう、という判断がしばしば行われることがあります。 はたしてその判断は正しいのでしょうか。2020年2月13日と14日の2日間、都内で行われたイベント「Developers Summit 2020」（デブサミ2020）」の和田卓人氏のセッション「質とスピード」は、これを深く考察したものでした。 本記事は前編と後編に分かれています。いまお読みの記事は後編です。 品質とコストのトレードオフ関係も一概 ここでちょっと視点を変えて、Philip Crosbyさんの「Quality is Free」を見てみたいと思います。 というのも、今日のテーマでは品質と開発ス
デブサミ2020の1日目、「質とスピード」というセッションが人気を集めた。2019年10月に開催されたEngineering Organization Festival 2019で評価の高かったセッションをアップデートして再演したものだ。登壇したのは、テスト駆動開発者として有名な、タワーズ・クエストの和田卓人氏。ライオンのアスキーアートといっしょに紹介されることが多いという。プロジェクトマネジメントにはQCD（Quality：品質、Cost：コスト、Delivery：納期）という概念があり、トレードオフの関係になると言われている。確かに開発の現場でも、「いまは大事な時期だから、品質を犠牲にしてスピードを優先しよう」といった判断が行われることは少なくない。しかし、和田氏は、ソフトウェア開発の文脈において、逆の効果をもたらすことを、多くの資料を引用して再構築してみせた。 タワーズ・クエスト株式
話したネタ 論理削除とはそもそも何か？ 物理削除とは？ なぜ、論理削除が生まれてくるのか？ SQLアンチパターン 幻の第26章「とりあえず削除フラグ」 理由1: 心理的なハードルの高さ、怖さがある 理由2: 削除したデータを検索対象に入れたい場合がある 理由3: ログとしての用途 理由4: 誤操作をすぐに戻したい アンチパターンとは何か？ なぜ、論理削除はアンチパターンとして捉えられるのか？ 全てのSQL文のWHERE句に削除フラグが必ず入る LIMIT 1などが蔓延していく 論理削除に気づくきっかけは何か？ テーブル設計や、規約から気づく 論理削除というアンチパターンをどのように解いていくか？ 論理削除という概念は世の中にまずなく、お客様は論理削除という言葉を使っていない 要件をどのように設計すればいいのか？ ORMの論理削除プラグインはあまり良くない 状態遷移として捉える方法 Soft
サバンナ便り〜自動テストに関する連載で得られた知見のまとめ（2023年5月版）〜 / Automated Test Knowledge from Savanna 202305 edition
2023/05/17(水) Qiita Conference 2023
サバンナ便り ～ソフトウェア開発の荒野を生き抜く～ 第7回テストコードの認知負荷 ～テストの名前、構造、情報量を工夫する～ 開発の現場では、既存のテストコードから仕様を読み解く機会がよく訪れます。そのようなとき、テスト対象の仕様やテストの意図を読み解きやすいテストとそうではないテストがあることに気付きます。今回はテストコードの読み解きやすさに寄与する要素を考えます。 認知資源と認知負荷 人間は何かを読み解くときに脳のリソース（脳内のワーキングメモリ）を使います。リソースの量は有限で、個人差があります。このような脳のリソースは「認知資源」と呼ばれています。 人間が何かを読み解くときに認知資源が何にどのくらい割かれているかという概念を「認知負荷」と言います。「どのくらい」は状況に左右されます。たとえば、読み解く対象を知っているかどうかで認知資源が割かれる量は変化します。「何に」も状
「ITエンジニア本大賞 2021」技術書部門大賞を受賞した『Engineers in VOYAGEー事業をエンジニアリングする技術者たち』。この書籍で紹介された技術的負債を返済するアプローチ手法であるリファクタリング、リアーキテクティング、リプレイスを、VOYAGE GROUPではどう実践してきたのか。そして、各システムの技術的負債に対し、どのように立ち向かってきたのか。同社のエンジニアが挑んできた課題や解決策を、実例を交えながら紹介する。 タワーズ・クエスト株式会社 プログラマ・テスト駆動開発者 和田卓人氏（左上）、株式会社fluct プログラマ 須藤洋一氏（右上）、株式会社VOYAGE MARKETING 福田剛広氏（左下）、元株式会社サポーターズ ねこや氏（右下） 技術的負債を返済するための3つのアプローチ まず和田卓人氏は、事業とシステムとの間の乖離から生まれる技術的負債を返済する
こちらは改訂前の旧版のページです。改訂改題版『事業をエンジニアリングする技術者たち ― フルサイクル開発者がつくるCartaの現場』の商品ページをご覧ください ウェブシステム＝ソフトウェア技術＋ビジネス 株式会社VOYAGE GROUP 監修、和田卓人 編 224ページ A5判 ISBN：978-4-908686-09-2 2020年8月7日 第1版第1刷 発行 株式会社VOYAGE GROUPによる紹介ページ 正誤および補足情報 ともすれば、互いに相反する関心を追っているとさえ捉えられる「ビジネス」と「ソフトウェアエンジニアリング」。しかし現実のウェブシステムで事業を成り立たせるためには、両者を分け隔てることなく、技術力と洞察力と調整力をもって課題に取り組む必要があります。 本書は、和田卓人氏による株式会社VOYAGE GROUPのソフトウェア技術者11人へのインタビューに補足解説を添え
プログラマでテスト駆動開発者の@t_wadaさんをお招きした社内勉強会での様子をお届け！＃メルカリな日々 | mercan (メルカン)
プログラマでテスト駆動開発者の@t_wadaさんをお招きした社内勉強会での様子をお届け！＃メルカリな日々 みなさん、こんにちは！メルカリのエンジニア組織の組織づくりや情報の可視化を担当しているEngineering Officeのaisakaです。 2019年12月18日に、プログラマでテスト駆動開発者の和田卓人（以下@t_wada）さんを社内にお招きし、社内勉強会を実施しました！ 内容は、先日行われたEOF2019 （Engineering Organization Festival）にメルカリの今の課題を取り入れ、アレンジしていただいたものです。EOF2019にて、メルカリから参加した@hidenorigotoさんと@jarinosukeさんの登壇記事はこちら！ 当日は120名以上のエンジニア、プロダクトマネージャー（PM）、コーポレートを含むメンバーが参加し、ランチを食べながらプロダ
TDDワークショップの開催 こんにちは。EC事業部エンジニアの@symmondsです。 2021年の10月に入社しEC事業部のCREチームで活動しています。詳しい活動内容については以前に記事を書いたので、興味がある方はぜひ読んでみてください。 GMO ペパボ(以下、ペパボ)では2021年に引き続き、今年も日本のTest Driven Development(TDD) の第一人者である @t_wada さんをお招きしてワークショップを開催しました。 「なぜTDDワークショップを開催したのか？」については、去年のTDDワークショップの記事で詳しく説明していますので、こちらをご覧ください。 研修内容 ここからはホスティング事業部の@matsusukeがご説明します。 2022年の3月にペパボに中途入社しました。最近はFall Guysにはまっていますが未だに一位が取れず、夜しか眠れません。 今回
始めに リンクアンドモチベーションでQAエンジニアをしています、代慶と申します。 先日のレガシーコード改善のワークショップに引き続き、和田卓人（t_wada）さんにTDDに関してワークショップを開催してもらいました。 本記事では、t_wadaさんが研修の中で頻度高く発言していた言葉や名言と共に、当日の研修での学びの概要を伝えていきたいと思います！ 当日の流れ 当日は、10人のエンジニアが10時から16時まで研修を受講しました。 前半は、座学メインで、適宜質問にも答えていただきました。 後半は、実習メインで、TDDの実践を行い、t_wadaさんとの公開1on1の時間を設けていただきました。 ※今回の講義は、前もってTDD Boot Campの動画の視聴も行い、よりTDDの理解を深めることができました。 TDDの概要 TDD（テスト駆動開発）とは・・・Red ⇒ Green ⇒ Refacto
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
![[t_wada氏×カミナシTori氏]ソフトウェアエンジニアと品質保証 SRE、QAの枠にとらわれない新しい視点 | Offers Magazine](https://cdn-ak-scissors.b.st-hatena.com/image/square/22d449c58c1eb5d9e28ee9350a10c50da3956732/height=288;version=1;width=512/https%3A%2F%2Fs3-ap-northeast-1.amazonaws.com%2Fassets.offers.jp%2Fmedia%2Fwp-content%2Fuploads%2F2023%2F12%2F27105156%2Freport_quality_assurance.png)
現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ
質とスピード / Quality and Speed
【翻訳】テスト駆動開発の定義 - t-wadaのブログ
プライベートメソッドのテストは書かないもの？ - t-wadaのブログ
t_wada さんの講演メモ ー 技術書の読み方を中心に - 冷めたコーヒー
エンジニアとして この先生きのこるために
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より | gihyo.jp
TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング
【アーカイブ動画】t-wadaさんが後世に残したい、実録レガシーコード改善
ソフトウェア開発の「品質vs.スピード」、本当は何を犠牲にしているのか【デブサミ2020】
27. 論理削除とは何か？どのような解法があるのか？ w/ twada | fukabori.fm
第7回 テストコードの認知負荷 ～テストの名前、構造、情報量を工夫する～ | gihyo.jp
技術的負債を返済するためのエンジニアリングとは？ VOYAGE GROUPの実践に学ぶ【デブサミ2021】
Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち（電子書籍のみ）
t_wadaさんによるTDDワークショップを開催しました - Pepabo Tech Portal
t_wadaさんによるTDD研修をワードクラウド・名言5選で振り返ってみた - Qiita
doumei-art-livedoor.blog.jp
news.yahoo.co.jp
ndlsearch.ndl.go.jp
newsdig.tbs.co.jp
www.excellentitem.com
kaigo40dai.hatenablog.com