システム開発の世界において「技術的負債（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 と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開
質とスピード（2020春版） 2020/02/13 @ デブサミ2020
質とスピード（2022春版、質疑応答用資料付き）
このブログエントリでは、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化（Semantic Diffusion）とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私（和田）はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正
はじめに スタンフォード大学の John Ousterhout 教授が執筆された “A Philosophy of Software Design”(以下 APoSD と略す) という書籍をご存じでしょうか？ 書籍のタイトルを直訳すると、「ソフトウェア設計の哲学」となります。書籍の内容はまさに、ソフトウェア設計について扱っています。 本書籍をベースに、「A Philosophy of Software Design を30分でざっと理解する」というお題で社内ランチ勉強会が開催されました。本記事執筆者である岩瀬(@iwashi86)が発表者であり、勉強会資料は以下のとおりです。 スライド P.4 に記載したとおり、本書籍は John Ousterhout 教授の意見が強く反映されており、ソフトウェアエンジニアであれば、議論を呼ぶ箇所があります。実際、勉強会の実況Slackでは、「これはどうな
PHPerKaigi 2022 2022/04/10 10:40〜 Track A レギュラートーク（40分） PHP はバージョンを追う毎に型宣言、例外、表明、列挙型などの機能が大幅に強化され、堅牢なコードを書くための機能が充実してきました。それらの機能はどう使うと効果的なのでしょうか。 …
この文章の背景 この文章はプライベートメソッドのテストを書くべきか否かに関する knsmr さんのご質問に対して 2013/03/13 に QA＠IT で回答したものです。残念ながらQA＠IT のサービス終了（2020/02/28）と共にアクセスできなくなってしまったため、運営を行っていたアイティメディア株式会社様、開発を行っていた永和システムマネジメント様、そして質問をされた knsmr さんに許可とご協力をいただき、当時の回答をサルベージしてブログに転載する運びとなりました。 プライベートメソッドのテストはよく議論になるテーマですので、当時の回答を再編集し、knsmr さんのご質問も含め、ご利用いただきやすいライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で公開いたします。 目次 この文章の背景 目次 knsmr さんのご質問 私の回
質とスピード（2020秋100分拡大版） 2020/11/20 @ JaSST'20 Kyushu
はじめに 和田さん（@t_wada）の講演が素晴らしく良かったのでメモを残しておきたいと思います。和田さんと言えば... t_wada ですね！本講演では、「技術の学び方を学ぶ」ことを目的として二部構成で論が展開されました。「技術の学び方の学び」とは、メタレベルの学びのことを指しています。すなわち、効率的に新しい技術を学ぶためにはどのように学べば良いのかという話です。内容は以下の通りです。 第一部 四半期ごとに技術書を読む 手を動かしながら学ぶ 毎年少なくとも一つの言語を学ぶ 身の回りをプログラミング対象にする アウトプットを行う 第二部 毎日コードを書く 年下から学ぶ 過去から未来を見る 人のつくる渦を見る 大事なことに集中する いずれも非常に興味深い内容だったのですが、細かい事項については2017年の講演メモのエントリーがありましたので、ぜひそちらをご覧いただければと思います。（記事へ
2022年度リクルート エンジニアコース新人研修の講義資料です
品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（前編）。デブサミ2020 ソフトウェア開発のプロジェクトにおいて、リリースに間に合わせるために開発スピードを優先させ、ひとまず質には目をつぶろう、という判断がしばしば行われることがあります。 はたしてその判断は正しいのでしょうか。2020年2月13日と14日の2日間、都内で行われたイベント「Developers Summit 2020」（デブサミ2020）」の和田卓人氏のセッション「質とスピード」は、これを深く考察したものでした。 この記事では、会場に立ち見がでるほど大人気だった本セッションの内容をダイジェストで紹介します。本記事は前編と後編に分かれています。いまお読みの記事は前編です。
2020年度リクルート新人ブートキャンプ エンジニアコースの講義資料です
2024/01/15(月) 12:00 〜 13:00 t-wadaさんが後世に残したい、実録レガシーコード改善 https://findy.connpass.com/event/304101/ テストコードが無いコードを引き継いだところからはじまる、実際に2018年に行った受託開発案件のエ…
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版（Gihyo Digital Publishing、Amazon Kindle）をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ
2021年度リクルート エンジニアコース新人研修の講義資料です
『テスト駆動開発』や『SQLアンチパターン』をはじめとする技術書の翻訳者、さまざまなIT企業をわたり歩く技術顧問、さらに最近ではエンジニアリング文化を伝える講演者としても活躍されている和田卓人さん(https://twitter.com/t_wada)。 そのソフトウェアエンジニアとしての素顔を株式会社一休CTOの伊藤直也さん(https://twitter.com/naoya_ito)が聞き出す対談の前編では、一線を画すエンジニアであり続けるために自らのプロジェクトで意識的にコードを書いているという和田さんの姿勢に始まり、ベテランとして「技術のらせん」を読み解くケーススタディとしてDDD（Domain-Driven Design）を題材に話を伺います。 ・伊藤 直也さん / 株式会社 一休 執行役員 CTO 新卒入社したニフティ株式会社でブログサービス「ココログ」を立ち上げ、CTOを務め
Developers Summit 2021 Summer［A-1］アジリティを支える品質特性 講演日時: 2021年07月30日（金） 10:00 ～ 10:45 概要: ビジネスにとってITは、「あると便利」から「有効」、「不可欠」を経て「中核そのもの」になりつつあり、柔軟かつ俊敏に…
日本におけるテスト駆動開発の著名人といえば誰か？ この問いを投げかけられたとき、多くのエンジニアが思い浮かべる人物がいます。ITコンサルタント・ソフトウェアエンジニアの和田卓人（@t_wada）さんです。和田さんは日本のテスト駆動開発の第一人者として、長年、この分野の実践や講演・執筆などの普及活動を続けてきました。 こう書くと、読者のなかには「和田さんはもともとテストが好きだったから、テスト駆動開発の第一人者になれたのでは」と思われた方もいるかもしれません。しかし、その答えはNOです。むしろ和田さんは、テストが嫌いなエンジニアだったといいます。ある出来事をきっかけとして、嫌いだったテストを好きになれる方法を見つけたのです。 読者の方々にも「自分には○○なんて向いていない」という印象を抱いている技術領域があるかもしれません。ですが、そんな領域にこそ、あなたの新たな可能性が詰まっているかもしれ
はじめに 本記事は前回の記事である「ソフトウェア設計について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 テストの構造化とリファクタリングの説明
アジャイル型の開発が導入されていない現場であっても、そして一人であっても、実践可能なアジャイルに関するプラクティスは存在します。 例えば、自動テストや、テストファースト、テスト駆動開発（TDD：Test Driven Development）です。ユニットテストフレームワークを使ってテストコードを書いて開発しながらテストを実行する「自動テスト」、実装の前にそのテストコードを書く「テストファースト」、テストと実装を繰り返しながらインクリメンタルに設計・開発を行うのが「TDD」。これらプラクティスのなかで、はじめの一歩となるのが自動テストですが、1人で実践するには、どこからはじめるか、どうテストを組み立てればよいのか、あるいは自分のテスト方法は適切なのか、不安を持つこともあるでしょう。 そこで本稿では、さまざまなチームや組織へのテスト手法の導入を支援し、精力的に講演や執筆などを行ってきたこの分
2022年9月9日 日本科学技術連盟 ソフトウェア品質シンポジウム2022（SQiP2022）
プログラマ、テスト駆動開発者 和田卓人 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。『プログラマが知るべき97のこと』（オライリージャパン、2010）監修。『SQLアンチパターン』（オライリージャパン、2013）監訳。『テスト駆動開発』（オーム社、2017）翻訳。『事業をエンジニアリングする技術者たち』（ラムダノート、2022）編者。テストライブラリ power-assert-js 作者。 講演や執筆などを通じ、日本におけるテスト駆動開発のエバンジェリストとして知られる和田卓人さん。 TDDとは何かを改めて言語化してもらった前回の記事では、「テストを書かずに進むのが合理的といえるときはある。でも、後からテストを書くのって難しいしつらい」とのお話がありました。 テストが書かれないまま
和田 卓人さん（t_wadaさん）に「予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント」を社内で講演いただきました！ こんにちは、ウォンテッドリーDev Branch VPoE 室長の髙橋です。 ウォンテッドリーの開発組織であるDev Branchでは、外部から有識者を招いて勉強会を開催したり、技術顧問として知見を取り入れるなど、プロダクト開発により強い組織となるためにさまざまな施策を行っています。 今回、「テスト書いてないとかお前それ @t_wada の前でも同じ事言えんの」 でおなじみのt_wadaさん（和田 卓人さん、以下和田さん）に「予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント」をウォンテッドリー向けにカスタマイズして講演いただきました。 このストーリーでは、今回の講演の経緯から社内の反応・Q&Aまで、講演に関する詳細をご紹介いたします。 社内講演のきっ
YAPC::Hiroshima 2024
本イベントでは「実録レガシーコード改善」というタイトルで、実際にt-wadaさんがテストの全くないシステムを引き継いだところからスタートする実話をお話していただきます。 イベントページ： https://findy.connpass.com/event/304101/
品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（後編）。デブサミ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/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人へのインタビューに補足解説を添え
TDDワークショップの開催 こんにちは。EC事業部エンジニアの@symmondsです。 2021年の10月に入社しEC事業部のCREチームで活動しています。詳しい活動内容については以前に記事を書いたので、興味がある方はぜひ読んでみてください。 GMO ペパボ(以下、ペパボ)では2021年に引き続き、今年も日本のTest Driven Development(TDD) の第一人者である @t_wada さんをお招きしてワークショップを開催しました。 「なぜTDDワークショップを開催したのか？」については、去年のTDDワークショップの記事で詳しく説明していますので、こちらをご覧ください。 研修内容 ここからはホスティング事業部の@matsusukeがご説明します。 2022年の3月にペパボに中途入社しました。最近はFall Guysにはまっていますが未だに一位が取れず、夜しか眠れません。 今回
自動テストに期待することはいくつかありますが、「失敗することで、テスト対象の動きが予期せず変わったことをプログラマーに教えてくれる」という役割は特に重要です。 この観点における期待外れの自動テストは2つ考えられます。失敗すべきでないときに失敗するテストと、失敗すべきときに失敗しないテストです。 失敗すべきでないときに失敗してしまうことを「偽陽性」（false positive）と言います。失敗すべきときに失敗してくれないことを「偽陰性」（false negative）と言います。今回はこの2つを整理します。 4象限で整理する 偽陽性と偽陰性は4象限で整理すると理解しやすくなります。プロダクトコードの正しさ、自動テストの実行結果（成功／失敗）という2つの軸で整理すると、表1ができあがります。 表1 偽陽性と偽陰性 偽陽性とは、プロダクトコードが正しいにもかかわらずテストが失敗してしまう
始めに リンクアンドモチベーションでQAエンジニアをしています、代慶と申します。 先日のレガシーコード改善のワークショップに引き続き、和田卓人（t_wada）さんにTDDに関してワークショップを開催してもらいました。 本記事では、t_wadaさんが研修の中で頻度高く発言していた言葉や名言と共に、当日の研修での学びの概要を伝えていきたいと思います！ 当日の流れ 当日は、10人のエンジニアが10時から16時まで研修を受講しました。 前半は、座学メインで、適宜質問にも答えていただきました。 後半は、実習メインで、TDDの実践を行い、t_wadaさんとの公開1on1の時間を設けていただきました。 ※今回の講義は、前もってTDD Boot Campの動画の視聴も行い、よりTDDの理解を深めることができました。 TDDの概要 TDD（テスト駆動開発）とは・・・Red ⇒ Green ⇒ Refacto
技術広報しゅーぞーです。 今日は24卒エンジニア新卒研修で行われた『プログラマが知るべき97のこと』読書会の模様をレポートします！ O'REILLY 『プログラマが知るべき97のこと』 この研修の目的 新卒研修だからこそ先人たちの経験から学び方を学び、それをベースに半年後の目標を考えてもらうことです。研修の最後に個々人が立てた目標を書いてシェアしてもらいます。 24卒エンジニアが書いた半年後の目標 監訳者@t_wadaと共読 今回の読書会は 『プログラマが知るべき97のこと』の監修者である @t_wadaさんと共に進めます。 『プログラマが知るべき97のこと』監修者 @t_wada @t_wadaさんはエンジニアなら誰もが目にする 『プログラマが知るべき97のこと』 『SQLアンチパターン』 『テスト駆動開発』 の監修者でもあります。 @t_wadaさんが監訳・監修した本たち @t_wad
こんにちは、今回からコラムを書かせていただく和田（t_wada）と申します。 現代のソフトウェア開発の対象領域は、広く複雑で不確実なものになりました。この連載では、自動テスト（Automated Test）に関わるトピックを中心に、ソフトウェア開発の荒野を生き抜いていくためのプログラミングやソフトウェアエンジニアリングの考え方を書いていきたいと考えています。 初回のテーマは、学習や調査が目的のテストコードを書くテクニック「学習用テスト」（Learning Test）です。では、よろしくお願いします。 二兎を追わない プログラミングのコツに、「一度に2つ以上のものを相手にしないこと」があります。 未知の技術を使って問題を解決するコードを書こうとするとき、私たちは2つのものと同時に戦うことになります。未知の技術そのものと、その技術を使った問題解決の2つです。2つ以上のものを同時に取り扱おう
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
「Rubyセミナー Online」 開催報告 下記のとおり「Rubyセミナー Online」を開催しました。 日時: 2024年3月12日(火) 14:00 〜 14:55 当日の映像を公開しました。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
