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

David Bernstein : Five Development Practices for Building Software with Scrum

David Bernstein : Five Development Practices for Building Software with Scrum

Yasunobu Kawaguchi
PRO

January 11, 2023
Tweet

More Decks by Yasunobu Kawaguchi

Other Decks in Technology

Transcript

  1. Integrate Continuously
    David Bernstein – To Be Agile (http://ToBeAgile.com)
    http://ToBeAgile.com
    [email protected] © Copyright 2022 To Be Agile DB20221109
    Five Development Practices for Building Software with Scrum
    スクラムでソフトウェアを構築するための 5 つの開発プラクティス

    View Slide

  2. 2
    David Scott Bernstein
     Software developer since 1980
     Trained 10,000 developers since 1990
     Author of the book Beyond Legacy
    Code: Nine Practices to Extend the Life
    (and Value) of Your Software
    Website: http://ToBeAgile.com
    Twitter: @ToBeAgile
    デビッドスコットバーンスタイン

    View Slide

  3. 3
    David Scott Bernstein
     1980年からソフトウェア開発者
     1990年から10,000人の開発者を育成
     「Beyond Legacy Code Nine Practices
    to Extend the Life (and Value) of Your
    Software 」(邦訳:レガシーコードから
    の脱却) の著者
    Website: http://ToBeAgile.com
    Twitter: @ToBeAgile
    デビッドスコットバーンスタイン

    View Slide

  4. 4
    Book – Beyond Legacy Code
    http://ToBeAgile.com
    [email protected]
    http://BeyondLegacyCode.com
     Nine practices to design and build
    healthy code, plus some tips on
    dealing with legacy code.
     Discusses the value and reasoning
    behind the technical practices, so
    both managers and the team can get
    on the same page as to their value.
     It’s not a “How To” book, it’s a
    “Why To” book.
    本:レガシーコードからの脱却

    View Slide

  5. 5
    Book – Beyond Legacy Code
    http://ToBeAgile.com
    [email protected]
    http://BeyondLegacyCode.com
     健全なコードを設計・構築する
    ための9つのプラクティスと、レ
    ガシーコードを扱う際のヒント
    を紹介します。
     技術的プラクティスの価値とそ
    の理由を説明することで、マネ
    ージャーとチームが同じレベル
    で話し合うことができるように
    なります。
     「How To」ではなく、「Why To
    」の本です。
    本:レガシーコードからの脱却

    View Slide

  6. 6
    Some Questions for You
    • How many of your teams are doing
    Scrum?
    • More than a year? Two? Five? Seven?
    • How many of your teams are doing XP?
    • More than a year? Two? Five? Seven?
    • Which technical practices?
    • CI, TDD, refactoring, pairing?
    “This book shows readers how to use SCRUM,
    an Agile software development process, to quickly
    and seamlessly implement XP in their shop-while still
    producing actual software. Using SCRUM and the Agile
    process can virtually eliminate all downtime during an
    XP implementation.”
    “Agile Software Development with Scrum”
    -- Ken Schwaber and Mike Beedle
    ?
    あなたへの質問

    View Slide

  7. 7
    Some Questions for You
    • あなたのチームはスクラムをどれくらい
    やっていますか?
    • 1年以上ですか?2年?5年?7年?
    • XPはどれくらいやっていますか?
    • 1年以上ですか?2年?5年?7年?
    • 技術プラクティスはどれを?
    • CI、TDD、リファクタリング、ペアリン
    グ?
    「本書は、読者が実際のソフトウェアを生産しながら、
    SCRUMとアジャイルソフトウェア開発プロセスを使用して、
    XPを素早くシームレスに導入する方法を紹介します。
    SCRUMとアジャイルプロセスを使うことで、
    XP導入時のダウンタイムを実質的にすべてなくすことができます。」
    Agile Software Development with Scrum”
    -- Ken Schwaber and Mike Beedle
    ?
    あなたへの質問

    View Slide

  8. 8
    1. Say What, Why, and for Whom before How: With a Product Owner defining the next most
    important features to build, the need for upfront requirements goes away.
    2. Build in Small Batches: Building incrementally increases feedback, helps simplify the
    construction of complex systems, and reduces risks.
    3. Integrate Continuously: Sets up the infrastructure for incremental development.
    4. Collaborate: Pairing, mobbing, spiking, and swarming as a team to solve problems and radiate
    knowledge throughout an organization.
    5. Create CLEAN Code: Share standards and practices for building software with code qualities
    that support testability.
    6. Write the Test First: Drops the cost of building and maintaining software dramatically.
    7. Specify Behaviors with Tests: Uses tests to define and document behaviors.
    8. Implement the Design Last: Paying technical debt can pay back dividends in the short term as
    well as the long term.
    9. Refactor Legacy Code: Incorporate learning and pay off technical debt.
    Nine Essential Practices
    9つの基本プラクティス

    View Slide

  9. 9
    1. やり方より先に目的、理由、誰のためかを伝える。プロダクトオーナーが次に作るべき最も重
    要な機能を定義することで、要求を事前に揃えておく必要性をなくします。
    2. 小さなバッチで作る。段階的に構築することで、フィードバックが増え、複雑なシステムの構
    築を簡素化し、リスクを低減することができます。
    3. 継続的に統合する。インクリメンタルな開発のためのインフラストラクチャを構築します。
    4. 協力しあう。ペアリング、モビング、スパイク、スウォーミングなど、チームとして問題解決
    に取り組み、組織全体に知識を広めます。
    5. 「CLEAN」なコードを作る。ソフトウェアを構築する標準とプラクティスを共有します。テ
    ストしやすい高品質なコードを生み出します。
    6. まずテストを書く。ソフトウェアの構築と維持にかかるコストを劇的に削減します。
    7. テストふるまいを明示する。テストを用いて振る舞いを定義し、文書化します。
    8. 設計は最後に行う:技術的負債の返済を行えば、長期だけでなく、短気にも利益を得ることが
    できます。
    9. レガシーコードをリファクタリングする。学習を取り入れ、技術的負債を返済します。
    Nine Essential Practices
    9つの基本プラクティス

    View Slide

  10. 10
    Practice 3 - Integrate Continuously
     Integration can be painful so teams put it off to the end of a project.
    A better alternative is to integrate continuously, whenever even the
    smallest bit of functionality is added to the system.
     I have a friend who works in an XP shop and I remember when he
    took me on a tour after hours. He said, “Let me show you what
    happens if someone breaks the build.” He typed a few lines at the
    console and suddenly all the florescent lights on the floor when out
    and a red light started flashing and sirens went off.
     He said, ”This is what happens when you break the build. We don’t
    allow broken builds in this shop.” That’s how ingrained a working
    build is in their culture.
    プラクティス3 - 継続的に統合する

    View Slide

  11. 11
    Practice 3 - Integrate Continuously
     統合は大変な作業であるため、プロジェクト終了まで先延ばしに
    してしまうチームがあります。よりよい方法は、システムに少し
    でも機能が追加されるたびに、継続的に統合することです。
     私の友人にXPの職場で働いている人がいるのですが、営業時間外
    に私を案内してくれたときのことを思い出します。
    「誰かがビルドを壊したらどうなるか見せてあげようか」。彼が
    コンソールで数行タイプすると、突然フロアの蛍光灯がすべて消
    え、赤いランプが点滅し始め、サイレンが鳴り響いたんです。
     「ビルドを壊すとこうなるんだ。ここでは壊れたビルドは許さな
    いんだ 」と彼は言いました。彼らの文化には、ビルドが通ってい
    ることの重要性がそれほど根付いていました。
    プラクティス3 - 継続的に統合する

    View Slide

  12. 12
    The Heartbeat of a Project
     Doing CI changes the dynamic of development. You always have
    a buildable system so you know exactly where you stand.
     When developers get instant feedback if something they did during
    the last few minutes caused a defect then they can quickly and
    easily back out those changes.
     But when a simple little defect goes unnoticed for days or even
    weeks then it can take hours, if not days to track down and fix.
     We can use the feedback from continuous integration to gain
    valuable insights into improving how we code.
     Once set up, continuous integration becomes a source of rich
    feedback for developers.
    プロジェクトのハートビート(鼓動)

    View Slide

  13. 13
    The Heartbeat of a Project
     CIを行うことで、開発のダイナミズムが変わります。ビルド可能なシステム
    が常にあるので、自分の立ち位置を正確に把握することができます。
     数分前に行ったことが原因で不具合が発生した場合、開発者はすぐにフィー
    ドバックを得ることができ、素早く簡単にその変更を取り消すことができま
    す。
     しかし、シンプルで小さな不具合でも何日も何週間も気づかれないままにな
    ると、追跡して修正するのに何時間も、いや何日もかかることになります。
     継続的インテグレーションからのフィードバックは、私たちのコーディング
    方法を改善するための貴重な洞察を得るために使用することができます。
     一度セットアップすれば、継続的インテグレーションは開発者にとって豊富
    なフィードバックの源となります。
    プロジェクトのハートビート(鼓動)

    View Slide

  14. 14
    Three Kinds of Done
     Here are three definitions of done:
    – Done: The developer who wrote the feature got it to work on their
    computer.
    – Done-Done: The feature is integrated into the build and is working.
    – Done-Done-Done: The feature is integrated into the build, is cleaned
    up and made supportable.
     We want to strive to get each feature to done-done-done as soon
    as possible so we get faster feedback and have less work-in-
    progress.
    Done(完成)には三種類ある

    View Slide

  15. 15
    Three Kinds of Done
     ここでは、Done(完成)の定義を3つ紹介します。
    – Done: その機能を書いた開発者の、自分のコンピュータで動作する。
    – Done-Done: その機能はビルドに統合され、動作している。
    – Done-Done-Done: その機能はビルドに統合され、クリーンアップさ
    れて、保守可能になっている。
     私たちは、各機能をできるだけ早くDone-Done-Doneにするよう
    努力し、より迅速なフィードバックを得て、仕掛かり品を少なく
    したいと考えています。
    Done(完成)には三種類ある

    View Slide

  16. 16
    Continuous Deployability
     Continuous deployability doesn’t mean we continuously deploy. It
    means you can deploy whenever you want to.
     When you deploy is a business decision based on product cycles,
    maintenance contracts, etc. Continuous deployability means you
    could deploy at any time that the business desires.
     This drops the risk of building features because you can see each
    feature integrated into the system and it gives developers
    feedback as they build features.
     Make sure you version everything your build depends on including
    build scripts, stored procedures, database layouts, etc.
    継続的にデプロイ可能であること

    View Slide

  17. 17
    Continuous Deployability
     継続的デリバリーは、継続的にデプロイするという意味ではあり
    ません。いつでも好きなときにデプロイできるという意味です。
     いつデプロイするかは、製品サイクルや保守契約などに基づいて
    ビジネス上の決定がなされます。継続的なデプロイが可能という
    ことは、ビジネスが望むタイミングでデプロイできるということ
    です。
     システムに統合された各機能を見ることができ、開発者が機能を
    構築する際にフィードバックを得られるため、機能構築のリスク
    を低減することができます。
     ビルドスクリプト、ストアドプロシージャ、データベースレイア
    ウトなど、ビルドが依存するものすべてをバージョンアップする
    ようにしましょう。
    継続的にデプロイできる状態

    View Slide

  18. 18
    Automate the Build
     Make sure the build runs fast (within a few seconds) and is easy to
    invoke (with a single click).
     Slow tests are the main reason for slow builds. Speed up tests by
    only testing what’s needed and mocking out dependencies.
     Your build will reveal your dependencies and whether you have a
    good architecture or not.
     If the build breaks, then fix it immediately.
    ビルドを自動化する

    View Slide

  19. 19
    Automate the Build
     ビルドが高速に(数秒以内に)実行され、簡単に(ワンクリック
    で)起動できることを確認してください。
     ビルドが遅くなる主な原因は、テストの遅さです。必要なものだ
    けをテストし、依存関係をモック化することで、テストを高速化
    しましょう。
     ビルドによって、依存関係や良いアーキテクチャを持っているか
    どうかが明らかになります。
     もしビルドが壊れたら、すぐに修正しましょう。
    ビルドを自動化する

    View Slide

  20. 20
    Integrate Early and Often
     We want to integrate code all the time, several times a day.
     Integrating each little bit of functionality as it is written to be sure
    the code works with the rest of the system.
     Being able to prove the system is still working with the click of a
    button is like a shot of espresso, it energizes me.
    早めに、頻繁に統合する

    View Slide

  21. 21
    Integrate Early and Often
     私たちは、コードを常に、一日に何度も統合したいと考えていま
    す。
     少しずつ機能を統合していきます。書かれたコードが意図通り、
    システムの他の部分と連動することを確認します。
     ボタンを一つクリックするだけで、システムが今も機能している
    ことを証明できる。このことは、一杯のエスプレッソのように、
    私に活力を与えてくれます。
    早めに、頻繁に統合する

    View Slide

  22. 22
    Take the First Step
     Continuous integration is the most valuable practice for building
    software and is often an easy practice to implement.
     Continuous integration provides the infrastructure for the other
    technical practices. It may take some work up front to set up but it
    pays for itself many times over during the life of a project.
     For a lot of teams, CD is the next most valuable step. Even teams
    that are doing it can do it better, and by better I mean integrate
    more frequently.
     I know developers who run their local build every 20 seconds when
    developing. That’s a huge amount of feedback they get.
     ---
    最初の一歩を踏み出す

    View Slide

  23. 23
    Take the First Step
     継続的インテグレーションは、ソフトウェアを構築する上で最も価値
    のあるプラクティスであり、多くの場合、簡単に実施できるプラクテ
    ィスです。
     継続的インテグレーションは、他の技術的実践のためのインフラスト
    ラクチャを提供します。セットアップに多少の手間がかかるかもしれ
    ませんが、プロジェクトの期間中に何度も元を取ることができます。
     多くのチームにとって、最も価値がある次のステップは継続的デリバ
    リー(CD) です。CDをすでに行っているチームも、さらに良くするこ
    とができます。もっと頻繁に統合するのです。
     私の知り合いの開発者は、開発しながら20秒ごとにローカルビルドを
    実行します。これにより膨大な量のフィードバックを得ています。
    最初の一歩を踏み出す

    View Slide

  24. 24
    Practice 4 - Collaborate
     Collaboration doesn’t always just happen. It requires skills and the
    right environment to flourish. We can set ourselves up for
    successful collaboration by learning these skills.
     We can learn from each other and there’re techniques we can use
    to help us.
     When I was a contractor at IBM, we were thrown into a big room
    with desks smashed up against each other. They called it the “bull
    pen.” IBM Employees got their own offices but they were always
    amazed at how much we got done. This was partly due to working
    so closely together.
    プラクティス4 - コラボレーション

    View Slide

  25. 25
    Practice 4 - Collaborate
     コラボレーションは常に起こるものではありません。コラボレー
    ションを成功させるにはスキルと適切な環境が必要です。私たち
    はこれらのスキルを身につけることで、コラボレーションを成功
    させるための準備をすることができます。
     私たちはお互いから学ぶことができますし、そのために使えるテ
    クニックもあります。
     私がIBMで契約社員だったころ、私たちは大きな部屋に放り込ま
    れ、机を互いにぶつけ合っていました。それを “ブルペン ”と呼ん
    でいました。IBMの社員は自分のオフィス(部屋)を持っていました
    が、私たちの仕事ぶりにはいつも驚かされていました。その理由
    は、私たちは密接に連携していたからです。
    プラクティス4 - コラボレーション

    View Slide

  26. 26
    Extreme Programming
     Kent Beck along with Ward Cunningham and Ron Jeffries
    developed Extreme Programming while working on the Chrysler
    Comprehensive Compensation System.
     Notice how the work area in the photo is open with lots of
    whiteboard space on the walls and pairing stations at every
    computer.
     Isolating people in offices may not be the best way to encourage
    collaboration. Open workspaces work well.
     Menlo Innovations converted a parking garage into a large open
    workspace where several development teams can work together
    エクストリームプログラミング

    View Slide

  27. 27
    Extreme Programming
     ケント・ベックは、ウォード・カニンガム、ロン・ジェフリーズ
    とともに、クライスラーの包括的補償システムに取り組んでいた
    ときにエクストリームプログラミングを開発しました。
     この写真のワークエリアはオープンで、壁にはたくさんのホワイ
    トボードスペースがあり、各コンピューターにはペアリング・ス
    テーションが設置されていることに注目してください。
     オフィスの中で人を孤立させることはコラボレーションを促進す
    る最善の方法ではないかもしれません。オープンなワークスペー
    スは効果的です。
     メンローイノベーションズは駐車場を改造し、複数の開発チーム
    が一緒に仕事ができるように大きなオープンワークスペースにし
    ました。
    エクストリームプログラミング

    View Slide

  28. 28
    Communicate and Collaborate
     Enterprise software development is a social activity.
     We must have a shared understanding of our goals and
    approaches to developing software. We must have a shared
    definition of “quality” and of when we will be “done.”
     Developing software is a collaborative act.
     People say us nerds are bad communicators. I disagree. We may
    not always like small talk but we love high-bandwidth
    communication and we’re good at it, it’s part of our job.
    コミュニケーションとコラボレーション

    View Slide

  29. 29
    Communicate and Collaborate
     企業のソフトウェア開発は、社会活動です。
     私たちは、ソフトウェア開発の目標とアプローチについて、共通
    の理解を持っていなければなりません。私たちは、「品質」と「
    いつ終わるか」について、共通の定義を持っていなければなりま
    せん。
     ソフトウェアを開発することは、協調作業です。
     私たちオタクはコミュニケーションが下手だと言われますが、私
    はそう思いません。私たちはちょっとした雑談は好きではないか
    もしれませんが、広帯域の(情報量の多い)コミュニケーションは
    大好きです。それが私たちの仕事です。
    コミュニケーションとコラボレーション

    View Slide

  30. 30
    Pair Program
     Pair programming is one of the most valuable practices that I get
    the most resistance from both managers and developers.
    Managers tell me they don’t want to loose half their “resources” but
    pair programming isn’t taking turns at the computer, it’s bringing
    two minds to bare on tough problems.
     When pairing, problems are solved faster, with less code, fewer
    errors, and costs only 15% more dev time. Pairing is the fastest
    way to propagate skills across a team. People who pair are less
    likely to be interrupted, stay on task, support each other in doing
    the right things, and are constantly learning.
     When I finish a day of pairing I’m exhausted yet supremely
    satisfied. And this is why you managers should support it.
    ペアプログラミング

    View Slide

  31. 31
    Pair Program
     ペアプログラミングは、最も価値のあるプラクティスのひとつですが、
    私はマネージャーと開発者の両方から最も抵抗を受けています。しかし
    、ペアプログラミングとは、コンピュータを交代で使うことではなく、2
    つの頭脳を駆使して難問に取り組むことなのです。
     ペアを組めば、問題はより早く、より少ないコードで、より少ないエラ
    ーで解決され、開発時間は15%増で済みます。ペアリングは、チーム全
    体にスキルを浸透させる最速の方法です。ペアリングをする人は、中断
    されることが少なく、タスクに集中し、正しいことをするためにお互い
    をサポートし合い、常に学習しているのです。
     私はペアリングの一日を終えると、疲れながらも最高の満足感を味わう
    ことができます。だからこそ、マネージャーはペアリングを支持すべき
    なのです。
    ペアプログラミング

    View Slide

  32. 32
    Buddy Program
     Successful pair programming requires special skills. The driver is
    at the keyboard, the navigator is thinking about what’s next.
     Pair randomly with everyone on the team. Switch driver and
    navigator every 5-20 minutes or when the other person is bored.
     Sometimes I can’t convince a team to try pairing so I suggest
    buddy programming. Buddy programming is less extreme than pair
    programming.
     In buddy programming, developers work alone for most of the day
    then get together with their “buddy” for the last hour of the day to
    code review the day’s work. As with pairing, it’s good to mix it up
    and have a different buddy daily, at each iteration, etc.
    バディ・プログラミング

    View Slide

  33. 33
    Buddy Program
     ペアプログラミングを成功させるには、特別なスキルが必要です。ドラ
    イバーはキーボードに向かい、ナビゲーターは次を考えあす。
     チームの全員とランダムにペアを組みます。5〜20分おきに、あるいは相
    手が飽きたら、ドライバーとナビゲーターを交代します。
     ペアを組むことに納得できないチームには、バディ・プログラミングを
    提案することもあります。バディプログラミングは、ペアプログラミン
    グほどエクストリーム(極端)ではありません。
     バディプログラミングでは、開発者は一日の大半を一人で作業し、最後
    の一時間に「バディ」と一緒にその日の作業をコードレビューします。
    ペアリングと同じように、毎日、イテレーションごとに異なるバディを
    持つなど、混ぜ合わせるとよいでしょう。
    バディ・プログラミング

    View Slide

  34. 34
    Spike, Swarm, and Mob
     Spiking is when one or a few people research unknowns in a fixed
    time box, usually to answer specific questions.
     Swarming is when the whole team works together to solve the
    same problem.
     Mobbing is when the whole team works together on the same
    story.
     This is a still from a video you can watch at MobProgramming.org
    where an 8-hour workday of a team mobbing is compressed down
    to 5 minutes. You’ll see everyone engaged the whole day. They
    made great progress on certain kinds of task with mobbing.
    スパイク、スウォーム、モブ

    View Slide

  35. 35
    Spike, Swarm, and Mob
     スパイクとは、1人または数人の人が、特定の質問に答えるために
    、一定の時間枠の中で未知のものを研究することです。
     スウォーミングは、チーム全体が同じ問題を解決するために協力
    することです。
     モビングは、チーム全体が同じストーリーに取り組むことです。
     これはMobProgramming.orgで見ることができるビデオの静止画
    で、1日8時間働くチームのモビングを5分に圧縮したものです。
    一日中、みんなが夢中になっているのがわかります。彼らは、あ
    る種のタスクについて、モビングで大きな進歩を遂げました。
    スパイク、スウォーム、モブ

    View Slide

  36. 36
    Time Box Unknowns
     When researching unknowns, try to phrase questions so they
    clearly identify what is known from what is unknown. Do this by:
    – For a specific period of time (an hour, day, week, etc.), research
    answers to your questions.
     At the end of the time box, reassess your goals. Did you get
    answers to your questions? Do you have new questions? Do you
    need another time box?
     This approach helps you shrink the unknown into the known or, at
    the very least, you can encapsulate what you don’t know so you
    can easily deal with it later.
    未知のものを調べるタイムボックス

    View Slide

  37. 37
    Time Box Unknowns
     未知のものを調べるとき、既知のものと未知のものを明確に区別
    できるような質問を考えましょう。そして、次の作業をします:
    – ある一定の期間(1時間、1日、1週間など)、質問の答えを調べる
     タイムボックスが終了したら、自分の目標を再確認しましょう。
    質問の答えは得られましたか?新たな質問が湧いてきましたか?
    さらに別のタイムボックスが必要でしょうか?
     この方法は、未知のものを既知のものへと畳み込むのに役立ちま
    すし、少なくとも、未知のものをカプセル化して、後で対処しや
    すくできます。
    未知のものを調べるタイムボックス

    View Slide

  38. 38
    Code Reviews, Retrospectives
     Code reviews are still important, even if you do pair programming.
     Code reviews let the rest of the team see your code.
     Focus on describing the reasoning for your design choices rather
    than just saying what you’re doing.
     Retrospect regularly to gather feedback and find ways of
    improving. It’s better to make many small improvements
    throughout the year than to try to make a lot of big improvements
    at once.
    コードレビュー、レトロスペクティブ

    View Slide

  39. 39
    Code Reviews, Retrospectives
     コードレビューは重要です。たとえペアプログラミングをしてい
    ても。
     コードレビューでは、チームの他のメンバーがあなたのコードを
    見ることができます。
     ただやっていることを語るのではなく、設計上の選択、その理由
    を説明することに注力しましょう。
     定期的にふりかえりを行い、フィードバックを集め、改善策をみ
    つけます。一度に大きな改善をするよりも、1年を通して小さな改
    善を積み重ねていくほうがよいでしょう。
    コードレビュー、レトロスペクティブ

    View Slide

  40. 40
    Amplify Learning
     The best workers are ones who help others. That’s job security
    today, not by having specialized knowledge.
     Team members should be cross-functional.
     Teams should practice collective code ownership so everyone can
    work on any part of the code.
     Pairing and mobbing are the most effective ways of propagating
    new skills across a team.
    学びを増やす

    View Slide

  41. 41
    Amplify Learning
     一番良い従業員とは、人を助ける人です。これが今日の、雇用を
    保障するものです。専門的な知識を持つことではありません。
     チームメンバーは職能横断的であるべきです。
     チームは、全員がコードのどの部分でも作業できるように、コー
    ドの共同所有を実践する必要があります。
     ペアリングとモビングは、チーム全体に新しいスキルを伝播させ
    る最も効果的な方法です。
    学びを増やす

    View Slide

  42. 42
    Be Mentoring and Mentored
     My mentor, Scott Bain, says. “Always strive to be mentoring
    someone and to be mentored by someone.”
     As a teacher myself for over nearly half a century I can say that
    teaching is one of the best way to learn.
     The most successful teams I know have pairing at the core of their
    culture and take time to know what everyone is doing.
    メンタリングし、メンタリングを受ける

    View Slide

  43. 43
    Be Mentoring and Mentored
     私のメンターであるスコット・ベインはこう言っています。"常に
    誰かを指導し、誰かから指導されるように努力しなさい"。
     私自身、約半世紀以上にわたって教師をしてきたので、教えるこ
    とは学ぶための最良の方法の一つであると言えます。
     私が知る限り、最も成功しているチームは、ペアリングを文化の
    中核に据え、全員が何をしているかを知るために時間をかけてい
    ます。
    メンタリングし、メンタリングを受ける

    View Slide

  44. 44
    Practice 5 – Create CLEAN Code
     We can infer good development principles and practices through
    five key code qualities:
    – Cohesive
    – Loosely Coupled
    – Encapsulated
    – Assertive
    – Nonredundant
     These five code qualities and their relationship to testability
    underlie all good developer principles and practices. We can infer
    the right things to do from these five qualities.
    プラクティス5 – CLEANなコードを書く

    View Slide

  45. 45
    Practice 5 – Create CLEAN Code
     私たちは、5つの主要なコードの品質を通じて、優れた開発原則と
    実践を推し量ることができます。
    – 凝集性が高い
    – 疎結合である
    – カプセル化されている
    – 断定的(アサーティブ)である
    – 冗長性がない
     この5つのコードの品質とテスト容易性の関係は、すべての優れた
    開発者の原則と実践の根底にあります。私たちは、この5つの品質
    から、正しいことを推測することができます。
    プラクティス5 – CLEANなコードを書く

    View Slide

  46. 46
    Quality Code is Cohesive
     High quality code is cohesive, meaning it’s about one thing.
     Cohesive classes and method follow the Single Responsibility
    Principle and have only one reason to exist and therefore one
    reason to change.
     As my esteemed colleague Dr. Daniel Rawsthorne says, “No
    schizophrenic classes.” Al Shallow says, “No God objects.” Scott
    Bain says, “Keep entities single-minded.”
     So then how do we model complex things? The answer is to
    compose complex classes from simple classes.
    高品質なコードは凝集性が高い

    View Slide

  47. 47
    Quality Code is Cohesive
     高品質なコードは凝集性があります。つまり、1つのことについて書かれ
    ているのです。
     凝集性のあるクラスとメソッドは単一責任原則に従い、存在する理由は
    ただ一つであり、したがって変更する理由もただ一つです。
     私の尊敬するDaniel Rawsthorne博士が言うように、「分裂病的なクラス
    はない」のです。アル・シャロウェイは、「神オブジェクトはなしで」
    と言っています。スコット・ベインは、「エンティティを単一化せよ 」
    と言っています。
     では、複雑なものをどのようにモデル化すればよいでしょうか?その答
    えは、単純なクラスから複雑なクラスを構成することです。
    高品質なコードは凝集性が高い

    View Slide

  48. 48
    Quality Code is Loosely Coupled
     We’re not striving for no coupling in a system. A system with no
    coupling is a system that does nothing. We want coupling were we
    intend it to be and no coupling where we don’t intend it to be.
     For this reason, I prefer the terms: intentional versus accidental
    coupling instead of the terms loose coupling versus tight coupling.
     High quality code is intentionally coupled so it doesn’t call concrete
    classes directly. Coupling through abstractions makes code easier
    to test now and extend later. Keep all external dependencies
    loosely coupled.
     Coupling is a “second-order effect” so poor coupling is a sign that
    the other code qualities are missing.
    高品質なコードは疎結合である

    View Slide

  49. 49
    Quality Code is Loosely Coupled
     私たちは、システムの無結合化を目指しているわけではありません。結
    合のないシステムは何もしないシステムです。私たちは、意図的な結合
    は必要であり、意図しない結合は必要ないのです。
     このため、私は、弱い結合と強い結合という用語ではなく、意図的な結
    合と不慮の結合という用語を好んで使用します。
     高品質のコードは意図的に結合され、具象クラスを直接呼び出すことは
    ありません。抽象化によって結合することで、コードを今テストし、後
    で拡張することが容易になります。外部との依存関係はすべて疎結合に
    します。
     結合は「二次的効果」であり、結合が悪いということは、他のコード品
    質が欠けていることの表れです。
    高品質なコードは疎結合である

    View Slide

  50. 50
    Quality Code is Encapsulated
     High quality code is encapsulated so it’s implementation is hidden.
    Well-encapsulated code is designed from the outside-in rather
    than inside-out.
     We can encapsulate much more than state and behavior, we can
    encapsulate sequence, cardinality, selection, etc.
     There are many ways to encapsulate things, we can hide an
    implementation behind an interface, we can hide a concept behind
    an abstraction. Design patterns encapsulate many different things.
     Encapsulation means hiding the how with the what. The art of
    being a great developer is to hide as much as possible while still
    getting the job done so you can easily change things later.
    高品質なコードはカプセル化されている

    View Slide

  51. 51
    Quality Code is Encapsulated
     高品質なコードはカプセル化されているため、その実装は隠されていま
    す。うまくカプセル化されたコードは、内側から外側へではなく、外側
    から内側へ設計されています。
     状態や振る舞いの他にも、シーケンス、カーディナリティ、選択などを
    カプセル化することができます。
     カプセル化には多くの方法があり、インターフェイスの後ろに実装を隠
    したり、抽象化の後ろに概念を隠したりすることができます。デザイン
    パターンは多くの異なるものをカプセル化します。
     カプセル化とは、「どのように」を「何を」で隠すかということです。
    優れた開発者であるための秘訣は、仕事を完了させながら、できるだけ
    多くのことを隠し、後で簡単に変更できるようにすることです。
    高品質なコードはカプセル化されている

    View Slide

  52. 52
    Quality Code is Assertive
     High quality code is assertive, it manages its own state.
     Assertive objects are be in charge of themselves.
     Inquisitive objects must query other objects to do their work. This
    cause rules to be spread out and they become difficult to follow.
     Keep responsibilities well defined and remember, he who has the
    state should have the responsibility.
    高品質なコードは断定的である

    View Slide

  53. 53
    Quality Code is Assertive
     高品質のコードは断定的であり、自分の状態を自分で管理します

     断定的なオブジェクトは、自分自身を管理することができます。
     好奇心旺盛なオブジェクトは、自分の仕事をするために他のオブ
    ジェクトを呼び出さなければなりません。このため、ルールが分
    散してしまい、追いかけるのが難しくなります。
     責任の所在を明確にし、「状態を保持するオブジェクトが責任を
    持つべき」であることを忘れないようにしましょう。
    高品質なコードは断定的である

    View Slide

  54. 54
    Quality Code is Non-Redundant
     High quality code is nonredundant, it doesn’t repeat itself.
     High quality code is nonredundant, it doesn’t repeat itself.
     Unintentional redundancy is always a maintenance issue.
     Redundancy is far more subtle than just duplication.
    – Can non-identical code be redundant? Yes, think of a for loop and
    foreach loop iterating through the same collection.
    – Can identical code be non-redundant? Yes, think of “index++”
    accessing a list of names or a list of numbers.
     Redundancy is about intent—trying to do the same thing in more
    than one place.
    高品質なコードは冗長でない

    View Slide

  55. 55
    Quality Code is Non-Redundant
     高品質なコードは、冗長性がなく、同じことを繰り返さない。
     高品質なコードは、冗長性がなく、同じことを繰り返さない。
     意図しない冗長性は常にメンテナンス上の問題です。
     冗長性は、単なる重複よりもはるかに微妙なものです。
    – 非同一コードは冗長になり得るか?はい、forループとforeachループ
    が同じコレクションを繰り返し処理することを考えてみてください。
    – 同じコードが冗長でないこともあるのか?名前のリストや数字のリス
    トにアクセスする「index++」を思い浮かべてください。
     冗長性とは、同じことを2箇所以上で行おうとする意図のことです

    高品質なコードは冗長でない

    View Slide

  56. 56
    Code Qualities Guide Us
     When code is cohesive it’s easier to read, understand, and find
    bugs because each entity is dealing with only one thing.
     When code is loosely coupled code is more straightforward to test
    and extend and we see fewer side effects between entities.
     When code is encapsulated it reduces the “ripple effect” when
    changing code and helps us manage complexity.
     When code is assertive its data and the code that act on it are
    together.
     When code is nonredundant it means we only have to deal with
    changing code or fixing bugs in one place.
    コード品質は私たちを導く

    View Slide

  57. 57
    Code Qualities Guide Us
     コードがまとまっていれば、読みやすく、理解しやすく、バグを
    発見しやすくなります。
     コードが疎結合であれば、テストや拡張がより簡単になり、エン
    ティティ間の副作用も少なくなります。
     コードがカプセル化されていれば、コードを変更したときの「波
    及効果」が小さくなり、複雑さを管理しやすくなります。
     コードが断定的であれば、そのデータとそれに作用するコードが
    一緒になっています。
     コードが冗長でなければ、コードの変更やバグの修正を一箇所で
    行うだけでよいことになります。
    コード品質は私たちを導く

    View Slide

  58. 58
    Increase Quality Today…
     These code qualities are unlike the so called “quality factors” or the
    “-ables” as I call them. For example, “maintain-able.” If I tell you
    your software should be maintainable I haven’t helped you much. I
    haven’t told you how to do what I’ve told you to do.
     These qualities are actionable and quantifiable. You can see if a
    piece of code has them or not and how to improve them.
     The only way I know to go fast is to go CLEAN. These code
    qualities seem simple, almost trivial but when ignored we quickly
    end up with at “big ball of mud.”
     If you want to increase your team’s velocity tomorrow you must
    increase your code quality today. There are no silver bullets!
    …今日、 品質を上げる

    View Slide

  59. 59
    Increase Quality Today…
     これらのコード品質は、いわゆる「品質要因」や「-ables」と呼ばれるも
    のとは異なります。例えば、“maintenance-able ”です。もし私が、あなた
    のソフトウェアはメンテナンス可能であるべきだ、と助言したとしても
    、あまり助けにはならないでしょう。どうやってそれをやるかを教えて
    いないからです。
     これらの品質は、実行可能で定量化可能です。あるコードがこの性質を
    備えているかどうか、そしてどのように改善すればよいかを知ることが
    できるのです。
     私が知っている高速化する唯一の方法は、CLEANにすることです。これ
    らのコードの品質は単純で、ほとんど些細なことのように見えますが、
    無視するとすぐに「大きな泥だんご」になってしまいます。
     もしあなたが明日、チームのベロシティを上げたいなら、今日、コード
    の品質を上げることです。銀の弾丸はないのです。
    …今日、 品質を上げる

    View Slide

  60. 60
    Practice 6 - Write the Test First
     Some people say TDD is dead because it forces you to write bad
    code and they’re right but that’s because they’re doing TDD wrong.
     “Test-induced damage” comes from writing too many tests and
    implementation dependent tests that not only “damage” software,
    they also impedes refactoring.
     But when done correctly, TDD helps us write CLEAN code that’s
    more maintainable. The key is understanding what TDD really is.
    プラクティス6 – まずテストを書く

    View Slide

  61. 61
    Practice 6 - Write the Test First
     TDDは悪いコードを書かせるからダメだと言う人がいて、それは
    正しいのですが、それはTDDのやり方を間違えているからなので
    す。
     「テストによる損傷」は、ソフトウェアを「損傷」させるだけで
    なく、リファクタリングの妨げにもなる、多すぎるテストや実装
    依存のテストを書くことから生じます。
     しかし、正しく行えば、TDDは、より保守性の高いCLEANなコー
    ドを書くのに役立ちます。重要なのは、TDDが本当は何であるか
    を理解することです。
    プラクティス6 – まずテストを書く

    View Slide

  62. 62
    The Things We Call Tests
     The word “test” represents many things in software development:
    • Acceptance tests are customer tests, they help clarify the
    conversation between the customer and developers.
    • Unit tests are developer tests, they help developers build out features
    so they’re testable and easy to work with.
    • Other tests are quality assurance tests, they help verify the software
    is bug free.
    • Each of these activities are very different from each other.
    私たちがテストと呼んでいるもの

    View Slide

  63. 63
    The Things We Call Tests
     ソフトウェア開発において、「テスト」という言葉は様々なこと
    を表しています。
    – 受け入れテストは顧客テストであり、顧客と開発者の間の会話を明確
    にするのに役立ちます。
    – ユニットテストは開発者のテストであり、開発者がテスト可能で作業
    しやすいように機能を構築するのを助けます。
    – その他のテストは品質保証テストであり、ソフトウェアにバグがない
    ことを確認するためのものです。
     これらの活動は、それぞれ大きく異なります。
    私たちがテストと呼んでいるもの

    View Slide

  64. 64
    Quality Assurance
     TDD doesn’t replace QA but it can help.
     There are many kinds of QA testing but for our purposes let’s
    break it out into two categories:
    – Release candidate validation
    – Everything else
     Make release candidate validation fully automated so it requires no
    human intervention. Let QA focus on other kinds of testing.
    品質保証(QA)

    View Slide

  65. 65
    Quality Assurance
     TDDはQAに取って代わるものではありませんが、助けになるもの
    です。
     QAテストには多くの種類がありますが、ここでは2つのカテゴリ
    に分類して説明します。
    – リリース候補の検証
    – その他すべて
     リリース候補の検証を完全に自動化し、人間の介入を不要としま
    す。QAは他の種類のテストに集中するようにしましょう。
    品質保証(QA)

    View Slide

  66. 66
    Write Good Tests
     People assume they know how to write a good test and do TDD
    effectively but that’s rarely the case.
     Think of tests as specifications for the behaviors that you want to
    create. Make tests unique and only write enough implementation
    to make your tests pass.
     The “units” we test are units of behavior, not units of code. When
    we refactor to implement our designs, we don’t need to add more
    tests, the ones we have are sufficient and support us in
    refactoring. Only when we add new behavior should we add tests.
    良いテストを書く

    View Slide

  67. 67
    Write Good Tests
     人々は、良いテストの書き方を知っていて、効果的にTDDを行う
    ことができると思い込んでいますが、そうであることはほとんど
    ありません。
     テストは、あなたが作りたい動作の仕様書だと考えてください。
    テストは重複のないものにし、テストに合格するのに十分な実装
    だけを書きましょう。
     テストする「単位」は、コードの単位ではなく、振る舞いの単位
    です。設計を実装するためにリファクタリングするとき、テスト
    を増やす必要はありません。今あるテストで十分であり、リファ
    クタリングをサポートします。新しい振る舞いを追加するときだ
    け、テストを追加すればいいのです。
    良いテストを書く

    View Slide

  68. 68
    TDD Gives Rapid Feedback
     The faster bugs are found the cheaper they are to fix.
     Good tests provide regression that is a constant source of
    feedback on the system.
     When developers run their tests all the time they get rapid
    feedback on what works and what causes problems. The same
    issues that could have taken days to find and fix can typically be
    resolve in a matter of minutes.
     When stimulus and response are brought together developers
    begin to change their habits and write higher quality code.
     The top developers I know get feedback about 3 times a minute.
    TDDは迅速なフィードバックを提供

    View Slide

  69. 69
    TDD Gives Rapid Feedback
     バグが早く見つかれば見つかるほど、その修正コストは安くなります。
     良いテストはリグレッションを提供し、常にシステムに対するフィード
    バックの源となります。
     開発者が常にテストを実行することで、何が機能し、何が問題を引き起
    こすかについての迅速なフィードバックが得られます。何日もかけて見
    つけた問題を、数分で解決することができるのです。
     刺激と反応が一緒になったとき、開発者は習慣を変え、より質の高いコ
    ードを書くようになります。
     私が知っている一流の開発者は、1分間に3回ほどフィードバックを受け
    ています。
    TDDは迅速なフィードバックを提供

    View Slide

  70. 70
    TDD Supports Refactoring
     Martin Fowler turned refactoring into a discipline when he
    published the book Refactoring: Improving the Design of Existing
    Code.
     Refactoring is changing the code without changing the behavior.
    Why should we do it?
     Refactoring lets developers have another chance to clean up their
    designs and make the code easier to work with in the future.
     When adding features it is often more straightforward to refactor
    and clean up the code first. “Clean the kitchen before preparing the
    dinner party.”
    TDDはリファクタリングを助ける

    View Slide

  71. 71
    TDD Supports Refactoring
     マーティン・ファウラー氏は、「リファクタリング―既存のコー
    ドを安全に改善する」という本を出版し、リファクタリングを学
    問として確立させました。
     リファクタリングとは、振る舞いを変えずにコードを変更するこ
    とです。なぜリファクタリングをする必要があるのでしょうか?
     リファクタリングによって、開発者は自分の設計をきれいにし、
    将来的にコードを扱いやすくする機会を再び得ることができます

     機能を追加する場合、最初にリファクタリングしてコードをきれ
    いにする方が簡単なことが多いのです。“ディナーの準備をする前
    にキッチンをきれいにする"
    TDDはリファクタリングを助ける

    View Slide

  72. 72
    Write Testable Code
     Regardless of whether you practice TDD or not, you should always
    write testable code.
     If I can write a test for something than typically I understand it
    enough to start coding it. If I can’t then I need to think more before
    coding.
     Doing TDD helps keep me moving forward. It validates my
    understanding and helps me focus on the right things at the right
    time.
     I can do TDD in almost any condition, even half-asleep.
    テスト可能なコードを書く

    View Slide

  73. 73
    Write Testable Code
     TDDを実践しているかどうかにかかわらず、常にテスト可能なコ
    ードを書くべきです。
     もし私が何かのテストを書くことができれば、通常はそれをコー
    ディングするのに十分なほど理解していることになります。もし
    できないなら、コーディングする前にもっと考える必要がありま
    す。
     TDDを行うことで、私は前進し続けることができます。TDDは、
    私の理解を確認し、適切なタイミングで適切なことに集中できる
    ようにします。
     私はほぼ、どんな状態でも、 TDDならできます。半分寝ながらで
    も。
    テスト可能なコードを書く

    View Slide

  74. 74
    But TDD Can Fail
     As great as TDD is, I’ve seen it fail more often then succeed.
     About 10% of the Scrum community are doing the Extreme
    Programming practices and most are doing it poorly.
     When developers write too many tests or implementation-
    dependent tests, they impede rather than support refactoring.
     Do not “test until bored.” Don’t put your QA hat on when writing
    tests. Write only enough tests to create the behavior you want to
    write.
     Use TDD to specify behaviors, not to test implementation details.
    しかしTDDは失敗する可能性があります

    View Slide

  75. 75
    But TDD Can Fail
     TDDは素晴らしいものですが、私は成功するよりも失敗することの方が
    多いと思っています。
     スクラムコミュニティの約10%がエクストリームプログラミングを実践
    しているが、そのほとんどはうまくいっていません。
     開発者があまりにも多くのテストや実装に依存したテストを書くと、リ
    ファクタリングをサポートするどころか、むしろ妨げてしまうのです。
     「飽きるまでテスト 」してはいけません。テストを書くときに、QA の
    帽子をかぶらないようにしましょう。書きたい振る舞いを実現するのに
    十分な量のテストだけを書きましょう。
     TDDは、実装の詳細をテストするためではなく、振る舞いを指定するた
    めに使います。
    しかしTDDは失敗する可能性があります

    View Slide

  76. 76
    Introducing TDD to a Team
     Teams must want to try it and find value in it in order for the
    practice to take root. It rarely works to have management impose
    TDD as a requirement to teams without training or ramp up time.
     To do TDD successfully you must know three things:
    – Understand TDD as a way of specifying behavior you want to build.
    – A variety of techniques to make untestable code testable.
    – An experience of building software test-first.
    TDDをチームに導入する

    View Slide

  77. 77
    Introducing TDD to a Team
     TDDを定着させるためには、チームがTDDを試したい、TDDに価
    値を見出したいと思わなければなりません。トレーニングや立ち
    上げの時間なしに、経営陣がTDDをチームに要求することは、ほ
    とんどうまくいきません。
     TDDを成功させるためには、3つのことを知っておく必要がありま
    す。
    – TDDを、構築したい振る舞いを指定する方法として理解すること。
    – テスト不可能なコードをテスト可能にするための様々なテクニック。
    – テストファーストでソフトウェアを構築する経験。
    TDDをチームに導入する

    View Slide

  78. 78
    Become ‘Test Infected’
     Eric Gamma coined the phrase “test infected” to describe the
    passion developers feel for doing TDD.
     I’m test infected, you couldn’t pay me enough to work on a non-
    TDD project. That’s how much I value TDD.
     When developers do TDD they spend far less time doing things
    they don’t love, like interpreting requirements and debugging, and
    spend far more time writing code, which we enjoy the most.
     TDD shows me how to write higher quality code that is more
    straightforward to extend in the future.
    “Warning:
    Promiscuous
    pairing can
    lead to
    becoming test
    infected.”
    テストに感染する

    View Slide

  79. 79
    Become ‘Test Infected’
     Eric Gamma氏は、開発者がTDDを行うことに感じる情熱を表現す
    るために、「テストに感染する」というフレーズを作りました。
     私はテストに感染しているので、TDDでないプロジェクトで働く
    ために、十分な報酬をいただくわけにはいきません。それくらい
    、私はTDDに価値を感じているのです。
     開発者がTDDを行うと、要求の解釈やデバッグといった好きでも
    ないことに費やす時間が大幅に減り、私たちが最も楽しんでいる
    コードを書くことに多くの時間を費やすことができます。
     TDDは、より質の高いコードを書く方法を教えてくれますし、将
    来的な拡張もより簡単にできます。
    “Warning:
    Promiscuous
    pairing can
    lead to
    becoming test
    infected.”
    テストに感染する

    View Slide

  80. 80
    Practice 9 - Refactor Legacy Code
     Refactoring is changing the internal structure of code without
    changing its external behavior. When I asked my manager to have
    the whole team take an iteration to refactor their code, how should
    I justify it? Developers understand the importance of refactoring
    but we often don’t express it well to the business.
     Refactoring drops the cost of four things:
    – Understanding the code later,
    – Adding unit tests,
    – Accommodating new features,
    – Doing further refactoring.
    プラクティス9 - レガシーコードをリファクタリングする

    View Slide

  81. 81
    Practice 9 - Refactor Legacy Code
     リファクタリングとは、コードの外部動作を変えずに内部構造を
    変更することです。チーム全体でイテレーションをとってコード
    をリファクタリングするように上司に頼んだとき、それをどのよ
    うに正当化すればいいのでしょうか?開発者はリファクタリング
    の重要性を理解していますが、それをビジネスに対してうまく表
    現できないことがよくあります。
     リファクタリングは4つのコストを下げます。
    – コードを理解するのが遅くなる
    – ユニットテストを追加する
    – 新機能に対応する
    – さらにリファクタリングを行う
    プラクティス9 - レガシーコードをリファクタリングする

    View Slide

  82. 82
    Investment or Debt?
     Would you buy an expensive car and, because you paid so much
    for it, insist on never taking it to the shop?
     Technical debt, like financial debt, is costs less the sooner you pay
    it off.
     If you don’t address technical debt then every time anyone goes
    into code they are paying to understand and modify the code.
     Technical debt can accumulate even when paying attention to
    principles and practices as we learn more and need to change our
    designs.
    投資か借金か?

    View Slide

  83. 83
    Investment or Debt?
     高価な車を買って、高いお金を払ったから、絶対に修理に出さな
    いと言い張りますか?
     技術的な負債は、金融負債と同じように、早く返済すればするほ
    ど、その費用は少なくなります。
     もしあなたが技術的負債に対処しないなら、誰かがコードに触れ
    るたびに、コードを理解し修正するためにお金を払うことになり
    ます。
     技術的負債は、開発の原則とプラクティスに注意を払っていても
    、より多くを学び、設計を変更する必要があるため、蓄積される
    可能性があります。
    投資か借金か?

    View Slide

  84. 84
    Become a “Deadbeat”
     I always pay my credit cards off in full each month.
     Credit card companies have a name for customers like me. We’re
    called “deadbeats” because they don’t make any money on us.
     A friend once owed $17,000 on a credit card and the notice said if
    he paid the minimum payment each month that at the end of 93
    years he would have paid $184,000.
     Become a “technical deadbeat” and pay off technical debt as soon
    as you can. It is the cheapest approach.
    「怠け者」になる

    View Slide

  85. 85
    Become a “Deadbeat”
     私は毎月必ずクレジットカードを全額返済しています。
     クレジットカード会社は私のような客を「怠け者」 と呼びます。
    私たちから利益を稼ぐことはできないからです。
     クレジットカードで17,000ドル借りていた友人は、毎月最低限の
    支払いを続けると、返済するのに93年と184,000ドルが必要にな
    ると言われました。
     技術的負債は「技術的怠け者」になって、できるだけ早く返済し
    ます。それが一番安上がりな方法です。
    「怠け者」になる

    View Slide

  86. 86
    When Code Needs to Change
     If legacy code does what we want and doesn’t need to be
    extended then there’s no reason to refactor and clean it up.
     Refactoring is expensive so, “if it ain’t broke, don’t fix it.”
     Only when code needs to change do we have to be concerned
    with refactoring.
     When refactoring legacy code, use the simple refactorings to
    introduce “seams” in code so you can add tests to support more
    complicated refactorings.
     Refactoring code teaches developers to avoid those kinds of
    mistakes in the first place, it helps you write better code!
    コードの変更が必要なとき

    View Slide

  87. 87
    When Code Needs to Change
     もし、レガシーコードが期待通り機能していて、拡張する必要がないの
    であれば、リファクタリングしてきれいにする必要はありません。
     リファクタリングにはコストがかかるので、「壊れていないなら直さな
    い」のです。
     コードを変更する必要があるときだけ、リファクタリングにこだわる必
    要があるのです。
     レガシーコードのリファクタリングでは、簡単なリファクタリングでコ
    ードの「継ぎ目」を作り、より複雑なリファクタリングに対応するため
    のテストを追加するようにします。
     コードのリファクタリングは、開発者が最初にその種の誤りを避けるこ
    とを教え、より良いコードを書くのに役立ちます。
    コードの変更が必要なとき

    View Slide

  88. 88
    Refactoring Techniques
     Here are a few refactoring strategies and techniques:
    – Pinning tests: Refactoring code without tests can be dangerous.
    First, add one big end-to-end test, sometimes called a “pinning test” to
    pin down the current behavior. Run pinning tests frequently.
    – Dependency injection: Separate use from creation by building
    objects in “factories” and inject them as needed.
    – System strangling: Lets you replace a component while it’s in
    operation by creating a new implementation that’s called from the old
    interface. Have new callers use a new interface and slowly refactor old
    clients to the new interface.
    – Branch by abstraction: Use feature flags to toggle features and
    avoid branches in version control so all development is off of trunk.
    リファクタリング技法

    View Slide

  89. 89
    Refactoring Techniques
     いくつかのリファクタリング戦略やテクニックを紹介します。
    – テストを固定する。テストなしでコードをリファクタリングするのは危険で
    す。まず、エンドツーエンドの大きなテストをひとつ追加します。これは、現
    在の挙動を突き止めるための「ピンニングテスト」と呼ばれることもあります
    。テストの固定は頻繁に実行しましょう。
    – 依存性注入。ファクトリーでオブジェクトを構築し、必要に応じて注入するこ
    とで、使用と生成を切り離します。
    – システムのストラングリング(締め付けて壊死させる)。古いインターフェイス
    から呼び出される新しい実装を作成することで、動作中のコンポーネントを置
    き換えることができる。新しい呼び出し元には新しいインターフェイスを使わ
    せ、古いクライアントを徐々に新しいインターフェイスにリファクタリングす
    る。
    – 抽象化によるブランチ。フィーチャーフラグを使用して機能を切り替え、バ
    ージョン管理によるブランチを回避して、すべての開発をトランクから行うよ
    うにします。
    リファクタリング技法

    View Slide

  90. 90
    Refactor to Accommodate Change
     There are many other refactoring techniques. It all boils down to
    this: clean up the code, make it easier to understand and work
    with, retrofit in tests to make code safe to work with and only then
    do more significant refactoring.
     Some of my favorite books on refactoring legacy code are:
    – Refactoring: Changing the Structure of Existing Code by Martin Fowler
    – Working Effectively with Legacy Code by Michael Feathers
    – Behead Your Legacy Beast: Refactor and Restructure Relentlessly
    with the Mikado Method by Daniel Brolund, Ola Ellnestram
    変化に対応するためのリファクタリング

    View Slide

  91. 91
    Refactor to Accommodate Change
     他にも多くのリファクタリング手法があります。結局のところ、
    コードをきれいにして、理解しやすく、作業しやすくし、テスト
    を追加してコードを安全に作業できるようにし、そして、より重
    要なリファクタリングを行う、ということです。
     レガシーコードのリファクタリングに関する私のお気に入りの本
    がいくつかあります。
    – リファクタリング:既存のコードを安全に改善する by Martin Fowler
    – レガシーコード改善ガイド by Michael Feathers
    – Behead Your Legacy Beast: Refactor and Restructure Relentlessly
    with the Mikado Method by Daniel Brolund, Ola Ellnestram
    変化に対応するためのリファクタリング

    View Slide

  92. 92
    Refactor to the Open-Closed
     This is a technique for adding features to existing software:
    – Before adding the feature, refactor the software to accommodate the
    new feature. For example, by adding abstractions.
    – Once the system has been refactored so the new feature can easily
    be added without changing much existing code, write a test for the
    new feature, watch it fail, and then make it pass TDD-style.
     Many developers try to do these two steps at the same time and
    end up raising their effort and risk.
     By separating the process of accommodating a new feature from
    actually adding it, the changes we make to code are less risky and
    simpler to do.
    オープン・クローズドのためのリファクタリング

    View Slide

  93. 93
    Refactor to the Open-Closed
     これは、既存のソフトウェアに機能を追加するための手法です。
    – 機能を追加する前に、その新機能に対応できるようにソフトウェアを
    リファクタリングする。例えば、抽象化レイヤーを追加する。
    – システムをリファクタリングして、既存のコードをあまり変更せずに
    新しい機能を簡単に追加できるようにしたら、新しい機能に対するテ
    ストを書いて、それが失敗するのを見て、TDDスタイルでそれを成功
    させる。
     多くの開発者は、この2つのステップを同時に行おうとして、結局
    は労力とリスクを高めてしまうのです。
     新機能に対応するプロセスと実際に追加するプロセスを切り離す
    ことで、コードに加える変更はよりリスクが少なく、シンプルに
    行うことができるのです。
    オープン・クローズドのためのリファクタリング

    View Slide

  94. 94
    Refactor to Support Changeability
     Changeability in software doesn’t just happen, we have to follow
    principles and practices that support it.
     Supporting changeability includes paying attention to code
    qualities, using the right abstractions, and modeling accurately.
     Good software development follows certain patterns and
    sequences that have proven valuable.
     TDD supports us in writing changeable software and it supports us
    as we change implementation by telling us the code still works.
    リファクタリングで変更しやすさを確保する

    View Slide

  95. 95
    Refactor to Support Changeability
     ソフトウェアの変更しやすさが偶然生まれることはありません。
    良い開発の原則とプラクティスに従う必要があります。
     変更可能性をサポートするには、コードの品質に注意を払い、適
    切な抽象化機能を使用し、正確にモデリングすることが含まれま
    す。
     優れたソフトウェア開発は、価値があることが証明されている特
    定のパターンとシーケンスに従っています。
     TDDは、私たちが変更可能なソフトウェアを書くことを支援し、
    実装を変更したときに、コードがまだ動作することを教えてくれ
    ることで、私たちを支援してくれます。
    リファクタリングで変更しやすさを確保する

    View Slide

  96. 96
    Do it Right the Second Time
     Because it’s difficult to abstract from a single example, I wait until I
    have two or more examples of something before creating
    abstractions or writing a generalized algorithm for something.
     This technique is called triangulation and comes from celestial
    navigation. Just like a point on the horizon can be calculated more
    accurately with more than one point of reference, we can often see
    generalizations more easily with multiple concrete examples.
     Refactoring and emerging designs in this way can a be highly
    efficient and effective to build quality software.
    二度目に正しくやる

    View Slide

  97. 97
    Do it Right the Second Time
     1つの例から抽象化するのは難しいので、私は2つ以上の例を持っ
    てから抽象化したり、一般化したアルゴリズムを書いたりしてい
    ます。
     これは三角測量と呼ばれる手法で、天体航法からきています。水
    平線上の点を複数の基準点によってより正確に計算できるように
    、複数の具体例があれば、より簡単に一般化したものを見ること
    ができることが多いのです。
     このような方法でリファクタリングや新しい設計を行うことは、
    高品質のソフトウェアを構築する上で非常に効率的かつ効果的で
    す。
    二度目に正しくやる

    View Slide

  98. 98
    The True Spirit of Agile
     Every author of the Agile Manifesto is a software developer.
     To me, Agile software development is summed up best in the first
    principle of the Agile Manifesto:
    – “Our highest priority is to satisfy the customer through early and
    continuous delivery of valuable software.”
     Successful software development requires a different set of skills
    than successful manufacturing. It’s about building independently
    verifiable behaviors that cost less to create and maintain.
     Just doing the practices is not enough. We must understand why
    the practices are valuable in order to apply them well.
    Why?
    真のアジャイル精神

    View Slide

  99. 99
    The True Spirit of Agile
     アジャイルマニフェストの起草者は皆ソフトウェア開発者です。
     私にとって、アジャイルソフトウェア開発は、アジャイルマニフ
    ェストの第一原則に最もよく集約されています。
    – “顧客満足を最優先し、
    価値のあるソフトウェアを早く継続的に提供します。"
     ソフトウェア開発を成功させるには、製造業を成功させるのとは
    異なるスキルが必要です。それは、作成と維持にかかるコストが
    少ない、独立して検証可能なふるまいを構築することです。
     プラクティスを実行するだけでは十分ではありません。プラクテ
    ィスをうまく適用するためには、なぜそのプラクティスに価値が
    あるのかを理解する必要があります。
    Why?
    真のアジャイル精神

    View Slide

  100. 100
    Thank You!
     We have just scratched the surface, to learn more:
    – Read my blog: http://ToBeAgile.com/blog
    – Sign up for my newsletter: http://ToBeAgile.com/signup
    – Follow me on Twitter (@ToBeAgile)
    – Read my book:
    – Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of
    Your Software (available from http://BeyondLegacyCode.com)
    – Attend my one of my Certified Scrum Developer trainings
    – See http://ToBeAgile.com/training for my public class schedule
    – Or contact https://www.agilergo.com/ to arrange a private class
    – Visit http://ToBeAgile.com for more information
    ありがとうございました!

    View Slide

  101. 101
    Thank You!
     この資料は表面をなぞっただけです。もっと学ぶにはこちら。
    – 私のブログを読む: http://ToBeAgile.com/blog
    – 私のニュースレターにサインアップする: http://ToBeAgile.com/signup
    – Twitterで私をフォローする (@ToBeAgile)
    – 私の本を読んでください。
    – レガシーコードを超えて。あなたのソフトウェアの寿命(と価値)を延ばす9つのプ
    ラクティス(http://BeyondLegacyCode.com から入手可能)。
    – 私の認定スクラム開発者トレーニングのいずれかに参加する。
    – 私の公開クラスのスケジュールは http://ToBeAgile.com/training をご覧ください。
    – または、あなたの組織のためにプライベートクラスを手配するために私に連絡して
    ください。
    – 詳細については、http://ToBeAgile.com をご覧ください。
    ありがとうございました!

    View Slide

  102. 102
    https://www.jp.agilergo.com/
    online-csd-bernstein-202302

    View Slide