David Bernstein : Five Development Practices for Building Software with Scrum

Regional Scrum Gathering Tokyo 2023 Keynote
https://confengine.com/conferences/regional-scrum-gathering-tokyo-2023/schedule

Transcript

1. Integrate Continuously David Bernstein – To Be Agile (http://ToBeAgile.com) http://ToBeAgile.com info@ToBeAgile.com © Copyright 2022 To Be Agile DB20221109 Five Development Practices for Building Software with Scrum スクラムでソフトウェアを構築するための 5 つの開発プラクティス
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 デビッドスコットバーンスタイン
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 デビッドスコットバーンスタイン
4. 4 Book – Beyond Legacy Code http://ToBeAgile.com info@ToBeAgile.com 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. 本：レガシーコードからの脱却
5. 5 Book – Beyond Legacy Code http://ToBeAgile.com info@ToBeAgile.com http://BeyondLegacyCode.com  健全なコードを設計・構築する ための9つのプラクティスと、レ ガシーコードを扱う際のヒント を紹介します。  技術的プラクティスの価値とそ の理由を説明することで、マネ ージャーとチームが同じレベル で話し合うことができるように なります。  「How To」ではなく、「Why To 」の本です。 本：レガシーコードからの脱却
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 ? あなたへの質問
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 ? あなたへの質問
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. 9 1. やり方より先に目的、理由、誰のためかを伝える。プロダクトオーナーが次に作るべき最も重 要な機能を定義することで、要求を事前に揃えておく必要性をなくします。 2. 小さなバッチで作る。段階的に構築することで、フィードバックが増え、複雑なシステムの構 築を簡素化し、リスクを低減することができます。 3. 継続的に統合する。インクリメンタルな開発のためのインフラストラクチャを構築します。 4. 協力しあう。ペアリング、モビング、スパイク、スウォーミングなど、チームとして問題解決 に取り組み、組織全体に知識を広めます。 5. 「CLEAN」なコードを作る。ソフトウェアを構築する標準とプラクティスを共有します。テ ストしやすい高品質なコードを生み出します。 6. まずテストを書く。ソフトウェアの構築と維持にかかるコストを劇的に削減します。 7. テストふるまいを明示する。テストを用いて振る舞いを定義し、文書化します。 8. 設計は最後に行う：技術的負債の返済を行えば、長期だけでなく、短気にも利益を得ることが できます。 9. レガシーコードをリファクタリングする。学習を取り入れ、技術的負債を返済します。 Nine Essential Practices ９つの基本プラクティス
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 - 継続的に統合する
11. 11 Practice 3 - Integrate Continuously  統合は大変な作業であるため、プロジェクト終了まで先延ばしに してしまうチームがあります。よりよい方法は、システムに少し でも機能が追加されるたびに、継続的に統合することです。  私の友人にXPの職場で働いている人がいるのですが、営業時間外 に私を案内してくれたときのことを思い出します。 「誰かがビルドを壊したらどうなるか見せてあげようか」。彼が コンソールで数行タイプすると、突然フロアの蛍光灯がすべて消 え、赤いランプが点滅し始め、サイレンが鳴り響いたんです。  「ビルドを壊すとこうなるんだ。ここでは壊れたビルドは許さな いんだ 」と彼は言いました。彼らの文化には、ビルドが通ってい ることの重要性がそれほど根付いていました。 プラクティス3 - 継続的に統合する
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. プロジェクトのハートビート(鼓動)
13. 13 The Heartbeat of a Project  CIを行うことで、開発のダイナミズムが変わります。ビルド可能なシステム が常にあるので、自分の立ち位置を正確に把握することができます。  数分前に行ったことが原因で不具合が発生した場合、開発者はすぐにフィー ドバックを得ることができ、素早く簡単にその変更を取り消すことができま す。  しかし、シンプルで小さな不具合でも何日も何週間も気づかれないままにな ると、追跡して修正するのに何時間も、いや何日もかかることになります。  継続的インテグレーションからのフィードバックは、私たちのコーディング 方法を改善するための貴重な洞察を得るために使用することができます。  一度セットアップすれば、継続的インテグレーションは開発者にとって豊富 なフィードバックの源となります。 プロジェクトのハートビート(鼓動)
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(完成)には三種類ある
15. 15 Three Kinds of Done  ここでは、Done(完成)の定義を3つ紹介します。 – Done: その機能を書いた開発者の、自分のコンピュータで動作する。 – Done-Done: その機能はビルドに統合され、動作している。 – Done-Done-Done: その機能はビルドに統合され、クリーンアップさ れて、保守可能になっている。  私たちは、各機能をできるだけ早くDone-Done-Doneにするよう 努力し、より迅速なフィードバックを得て、仕掛かり品を少なく したいと考えています。 Done(完成)には三種類ある
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. 継続的にデプロイ可能であること
17. 17 Continuous Deployability  継続的デリバリーは、継続的にデプロイするという意味ではあり ません。いつでも好きなときにデプロイできるという意味です。  いつデプロイするかは、製品サイクルや保守契約などに基づいて ビジネス上の決定がなされます。継続的なデプロイが可能という ことは、ビジネスが望むタイミングでデプロイできるということ です。  システムに統合された各機能を見ることができ、開発者が機能を 構築する際にフィードバックを得られるため、機能構築のリスク を低減することができます。  ビルドスクリプト、ストアドプロシージャ、データベースレイア ウトなど、ビルドが依存するものすべてをバージョンアップする ようにしましょう。 継続的にデプロイできる状態
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. ビルドを自動化する
19. 19 Automate the Build  ビルドが高速に（数秒以内に）実行され、簡単に（ワンクリック で）起動できることを確認してください。  ビルドが遅くなる主な原因は、テストの遅さです。必要なものだ けをテストし、依存関係をモック化することで、テストを高速化 しましょう。  ビルドによって、依存関係や良いアーキテクチャを持っているか どうかが明らかになります。  もしビルドが壊れたら、すぐに修正しましょう。 ビルドを自動化する
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. 早めに、頻繁に統合する
21. 21 Integrate Early and Often  私たちは、コードを常に、一日に何度も統合したいと考えていま す。  少しずつ機能を統合していきます。書かれたコードが意図通り、 システムの他の部分と連動することを確認します。  ボタンを一つクリックするだけで、システムが今も機能している ことを証明できる。このことは、一杯のエスプレッソのように、 私に活力を与えてくれます。 早めに、頻繁に統合する
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.  --- 最初の一歩を踏み出す
23. 23 Take the First Step  継続的インテグレーションは、ソフトウェアを構築する上で最も価値 のあるプラクティスであり、多くの場合、簡単に実施できるプラクテ ィスです。  継続的インテグレーションは、他の技術的実践のためのインフラスト ラクチャを提供します。セットアップに多少の手間がかかるかもしれ ませんが、プロジェクトの期間中に何度も元を取ることができます。  多くのチームにとって、最も価値がある次のステップは継続的デリバ リー(CD) です。CDをすでに行っているチームも、さらに良くするこ とができます。もっと頻繁に統合するのです。  私の知り合いの開発者は、開発しながら20秒ごとにローカルビルドを 実行します。これにより膨大な量のフィードバックを得ています。 最初の一歩を踏み出す
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 - コラボレーション
25. 25 Practice 4 - Collaborate  コラボレーションは常に起こるものではありません。コラボレー ションを成功させるにはスキルと適切な環境が必要です。私たち はこれらのスキルを身につけることで、コラボレーションを成功 させるための準備をすることができます。  私たちはお互いから学ぶことができますし、そのために使えるテ クニックもあります。  私がIBMで契約社員だったころ、私たちは大きな部屋に放り込ま れ、机を互いにぶつけ合っていました。それを “ブルペン ”と呼ん でいました。IBMの社員は自分のオフィス(部屋)を持っていました が、私たちの仕事ぶりにはいつも驚かされていました。その理由 は、私たちは密接に連携していたからです。 プラクティス4 - コラボレーション
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 エクストリームプログラミング
27. 27 Extreme Programming  ケント・ベックは、ウォード・カニンガム、ロン・ジェフリーズ とともに、クライスラーの包括的補償システムに取り組んでいた ときにエクストリームプログラミングを開発しました。  この写真のワークエリアはオープンで、壁にはたくさんのホワイ トボードスペースがあり、各コンピューターにはペアリング・ス テーションが設置されていることに注目してください。  オフィスの中で人を孤立させることはコラボレーションを促進す る最善の方法ではないかもしれません。オープンなワークスペー スは効果的です。  メンローイノベーションズは駐車場を改造し、複数の開発チーム が一緒に仕事ができるように大きなオープンワークスペースにし ました。 エクストリームプログラミング
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. コミュニケーションとコラボレーション
29. 29 Communicate and Collaborate  企業のソフトウェア開発は、社会活動です。  私たちは、ソフトウェア開発の目標とアプローチについて、共通 の理解を持っていなければなりません。私たちは、「品質」と「 いつ終わるか」について、共通の定義を持っていなければなりま せん。  ソフトウェアを開発することは、協調作業です。  私たちオタクはコミュニケーションが下手だと言われますが、私 はそう思いません。私たちはちょっとした雑談は好きではないか もしれませんが、広帯域の(情報量の多い)コミュニケーションは 大好きです。それが私たちの仕事です。 コミュニケーションとコラボレーション
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. ペアプログラミング
31. 31 Pair Program  ペアプログラミングは、最も価値のあるプラクティスのひとつですが、 私はマネージャーと開発者の両方から最も抵抗を受けています。しかし 、ペアプログラミングとは、コンピュータを交代で使うことではなく、2 つの頭脳を駆使して難問に取り組むことなのです。  ペアを組めば、問題はより早く、より少ないコードで、より少ないエラ ーで解決され、開発時間は15％増で済みます。ペアリングは、チーム全 体にスキルを浸透させる最速の方法です。ペアリングをする人は、中断 されることが少なく、タスクに集中し、正しいことをするためにお互い をサポートし合い、常に学習しているのです。  私はペアリングの一日を終えると、疲れながらも最高の満足感を味わう ことができます。だからこそ、マネージャーはペアリングを支持すべき なのです。 ペアプログラミング
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. バディ・プログラミング
33. 33 Buddy Program  ペアプログラミングを成功させるには、特別なスキルが必要です。ドラ イバーはキーボードに向かい、ナビゲーターは次を考えあす。  チームの全員とランダムにペアを組みます。5〜20分おきに、あるいは相 手が飽きたら、ドライバーとナビゲーターを交代します。  ペアを組むことに納得できないチームには、バディ・プログラミングを 提案することもあります。バディプログラミングは、ペアプログラミン グほどエクストリーム（極端）ではありません。  バディプログラミングでは、開発者は一日の大半を一人で作業し、最後 の一時間に「バディ」と一緒にその日の作業をコードレビューします。 ペアリングと同じように、毎日、イテレーションごとに異なるバディを 持つなど、混ぜ合わせるとよいでしょう。 バディ・プログラミング
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. スパイク、スウォーム、モブ
35. 35 Spike, Swarm, and Mob  スパイクとは、1人または数人の人が、特定の質問に答えるために 、一定の時間枠の中で未知のものを研究することです。  スウォーミングは、チーム全体が同じ問題を解決するために協力 することです。  モビングは、チーム全体が同じストーリーに取り組むことです。  これはMobProgramming.orgで見ることができるビデオの静止画 で、1日8時間働くチームのモビングを5分に圧縮したものです。 一日中、みんなが夢中になっているのがわかります。彼らは、あ る種のタスクについて、モビングで大きな進歩を遂げました。 スパイク、スウォーム、モブ
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. 未知のものを調べるタイムボックス
37. 37 Time Box Unknowns  未知のものを調べるとき、既知のものと未知のものを明確に区別 できるような質問を考えましょう。そして、次の作業をします: – ある一定の期間（1時間、1日、1週間など）、質問の答えを調べる  タイムボックスが終了したら、自分の目標を再確認しましょう。 質問の答えは得られましたか？新たな質問が湧いてきましたか？ さらに別のタイムボックスが必要でしょうか？  この方法は、未知のものを既知のものへと畳み込むのに役立ちま すし、少なくとも、未知のものをカプセル化して、後で対処しや すくできます。 未知のものを調べるタイムボックス
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. コードレビュー、レトロスペクティブ
39. 39 Code Reviews, Retrospectives  コードレビューは重要です。たとえペアプログラミングをしてい ても。  コードレビューでは、チームの他のメンバーがあなたのコードを 見ることができます。  ただやっていることを語るのではなく、設計上の選択、その理由 を説明することに注力しましょう。  定期的にふりかえりを行い、フィードバックを集め、改善策をみ つけます。一度に大きな改善をするよりも、1年を通して小さな改 善を積み重ねていくほうがよいでしょう。 コードレビュー、レトロスペクティブ
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. 学びを増やす
41. 41 Amplify Learning  一番良い従業員とは、人を助ける人です。これが今日の、雇用を 保障するものです。専門的な知識を持つことではありません。  チームメンバーは職能横断的であるべきです。  チームは、全員がコードのどの部分でも作業できるように、コー ドの共同所有を実践する必要があります。  ペアリングとモビングは、チーム全体に新しいスキルを伝播させ る最も効果的な方法です。 学びを増やす
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. メンタリングし、メンタリングを受ける
43. 43 Be Mentoring and Mentored  私のメンターであるスコット・ベインはこう言っています。"常に 誰かを指導し、誰かから指導されるように努力しなさい"。  私自身、約半世紀以上にわたって教師をしてきたので、教えるこ とは学ぶための最良の方法の一つであると言えます。  私が知る限り、最も成功しているチームは、ペアリングを文化の 中核に据え、全員が何をしているかを知るために時間をかけてい ます。 メンタリングし、メンタリングを受ける
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なコードを書く
45. 45 Practice 5 – Create CLEAN Code  私たちは、5つの主要なコードの品質を通じて、優れた開発原則と 実践を推し量ることができます。 – 凝集性が高い – 疎結合である – カプセル化されている – 断定的(アサーティブ)である – 冗長性がない  この5つのコードの品質とテスト容易性の関係は、すべての優れた 開発者の原則と実践の根底にあります。私たちは、この5つの品質 から、正しいことを推測することができます。 プラクティス5 – CLEANなコードを書く
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. 高品質なコードは凝集性が高い
47. 47 Quality Code is Cohesive  高品質なコードは凝集性があります。つまり、1つのことについて書かれ ているのです。  凝集性のあるクラスとメソッドは単一責任原則に従い、存在する理由は ただ一つであり、したがって変更する理由もただ一つです。  私の尊敬するDaniel Rawsthorne博士が言うように、「分裂病的なクラス はない」のです。アル・シャロウェイは、「神オブジェクトはなしで」 と言っています。スコット・ベインは、「エンティティを単一化せよ 」 と言っています。  では、複雑なものをどのようにモデル化すればよいでしょうか？その答 えは、単純なクラスから複雑なクラスを構成することです。 高品質なコードは凝集性が高い
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. 高品質なコードは疎結合である
49. 49 Quality Code is Loosely Coupled  私たちは、システムの無結合化を目指しているわけではありません。結 合のないシステムは何もしないシステムです。私たちは、意図的な結合 は必要であり、意図しない結合は必要ないのです。  このため、私は、弱い結合と強い結合という用語ではなく、意図的な結 合と不慮の結合という用語を好んで使用します。  高品質のコードは意図的に結合され、具象クラスを直接呼び出すことは ありません。抽象化によって結合することで、コードを今テストし、後 で拡張することが容易になります。外部との依存関係はすべて疎結合に します。  結合は「二次的効果」であり、結合が悪いということは、他のコード品 質が欠けていることの表れです。 高品質なコードは疎結合である
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. 高品質なコードはカプセル化されている
51. 51 Quality Code is Encapsulated  高品質なコードはカプセル化されているため、その実装は隠されていま す。うまくカプセル化されたコードは、内側から外側へではなく、外側 から内側へ設計されています。  状態や振る舞いの他にも、シーケンス、カーディナリティ、選択などを カプセル化することができます。  カプセル化には多くの方法があり、インターフェイスの後ろに実装を隠 したり、抽象化の後ろに概念を隠したりすることができます。デザイン パターンは多くの異なるものをカプセル化します。  カプセル化とは、「どのように」を「何を」で隠すかということです。 優れた開発者であるための秘訣は、仕事を完了させながら、できるだけ 多くのことを隠し、後で簡単に変更できるようにすることです。 高品質なコードはカプセル化されている
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. 高品質なコードは断定的である
53. 53 Quality Code is Assertive  高品質のコードは断定的であり、自分の状態を自分で管理します 。  断定的なオブジェクトは、自分自身を管理することができます。  好奇心旺盛なオブジェクトは、自分の仕事をするために他のオブ ジェクトを呼び出さなければなりません。このため、ルールが分 散してしまい、追いかけるのが難しくなります。  責任の所在を明確にし、「状態を保持するオブジェクトが責任を 持つべき」であることを忘れないようにしましょう。 高品質なコードは断定的である
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. 高品質なコードは冗長でない
55. 55 Quality Code is Non-Redundant  高品質なコードは、冗長性がなく、同じことを繰り返さない。  高品質なコードは、冗長性がなく、同じことを繰り返さない。  意図しない冗長性は常にメンテナンス上の問題です。  冗長性は、単なる重複よりもはるかに微妙なものです。 – 非同一コードは冗長になり得るか？はい、forループとforeachループ が同じコレクションを繰り返し処理することを考えてみてください。 – 同じコードが冗長でないこともあるのか？名前のリストや数字のリス トにアクセスする「index++」を思い浮かべてください。  冗長性とは、同じことを2箇所以上で行おうとする意図のことです 。 高品質なコードは冗長でない
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. コード品質は私たちを導く
57. 57 Code Qualities Guide Us  コードがまとまっていれば、読みやすく、理解しやすく、バグを 発見しやすくなります。  コードが疎結合であれば、テストや拡張がより簡単になり、エン ティティ間の副作用も少なくなります。  コードがカプセル化されていれば、コードを変更したときの「波 及効果」が小さくなり、複雑さを管理しやすくなります。  コードが断定的であれば、そのデータとそれに作用するコードが 一緒になっています。  コードが冗長でなければ、コードの変更やバグの修正を一箇所で 行うだけでよいことになります。 コード品質は私たちを導く
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! …今日、 品質を上げる
59. 59 Increase Quality Today…  これらのコード品質は、いわゆる「品質要因」や「-ables」と呼ばれるも のとは異なります。例えば、“maintenance-able ”です。もし私が、あなた のソフトウェアはメンテナンス可能であるべきだ、と助言したとしても 、あまり助けにはならないでしょう。どうやってそれをやるかを教えて いないからです。  これらの品質は、実行可能で定量化可能です。あるコードがこの性質を 備えているかどうか、そしてどのように改善すればよいかを知ることが できるのです。  私が知っている高速化する唯一の方法は、CLEANにすることです。これ らのコードの品質は単純で、ほとんど些細なことのように見えますが、 無視するとすぐに「大きな泥だんご」になってしまいます。  もしあなたが明日、チームのベロシティを上げたいなら、今日、コード の品質を上げることです。銀の弾丸はないのです。 …今日、 品質を上げる
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 – まずテストを書く
61. 61 Practice 6 - Write the Test First  TDDは悪いコードを書かせるからダメだと言う人がいて、それは 正しいのですが、それはTDDのやり方を間違えているからなので す。  「テストによる損傷」は、ソフトウェアを「損傷」させるだけで なく、リファクタリングの妨げにもなる、多すぎるテストや実装 依存のテストを書くことから生じます。  しかし、正しく行えば、TDDは、より保守性の高いCLEANなコー ドを書くのに役立ちます。重要なのは、TDDが本当は何であるか を理解することです。 プラクティス6 – まずテストを書く
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. 私たちがテストと呼んでいるもの
63. 63 The Things We Call Tests  ソフトウェア開発において、「テスト」という言葉は様々なこと を表しています。 – 受け入れテストは顧客テストであり、顧客と開発者の間の会話を明確 にするのに役立ちます。 – ユニットテストは開発者のテストであり、開発者がテスト可能で作業 しやすいように機能を構築するのを助けます。 – その他のテストは品質保証テストであり、ソフトウェアにバグがない ことを確認するためのものです。  これらの活動は、それぞれ大きく異なります。 私たちがテストと呼んでいるもの
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)
65. 65 Quality Assurance  TDDはQAに取って代わるものではありませんが、助けになるもの です。  QAテストには多くの種類がありますが、ここでは2つのカテゴリ に分類して説明します。 – リリース候補の検証 – その他すべて  リリース候補の検証を完全に自動化し、人間の介入を不要としま す。QAは他の種類のテストに集中するようにしましょう。 品質保証(QA)
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. 良いテストを書く
67. 67 Write Good Tests  人々は、良いテストの書き方を知っていて、効果的にTDDを行う ことができると思い込んでいますが、そうであることはほとんど ありません。  テストは、あなたが作りたい動作の仕様書だと考えてください。 テストは重複のないものにし、テストに合格するのに十分な実装 だけを書きましょう。  テストする「単位」は、コードの単位ではなく、振る舞いの単位 です。設計を実装するためにリファクタリングするとき、テスト を増やす必要はありません。今あるテストで十分であり、リファ クタリングをサポートします。新しい振る舞いを追加するときだ け、テストを追加すればいいのです。 良いテストを書く
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は迅速なフィードバックを提供
69. 69 TDD Gives Rapid Feedback  バグが早く見つかれば見つかるほど、その修正コストは安くなります。  良いテストはリグレッションを提供し、常にシステムに対するフィード バックの源となります。  開発者が常にテストを実行することで、何が機能し、何が問題を引き起 こすかについての迅速なフィードバックが得られます。何日もかけて見 つけた問題を、数分で解決することができるのです。  刺激と反応が一緒になったとき、開発者は習慣を変え、より質の高いコ ードを書くようになります。  私が知っている一流の開発者は、1分間に3回ほどフィードバックを受け ています。 TDDは迅速なフィードバックを提供
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はリファクタリングを助ける
71. 71 TDD Supports Refactoring  マーティン・ファウラー氏は、「リファクタリング―既存のコー ドを安全に改善する」という本を出版し、リファクタリングを学 問として確立させました。  リファクタリングとは、振る舞いを変えずにコードを変更するこ とです。なぜリファクタリングをする必要があるのでしょうか？  リファクタリングによって、開発者は自分の設計をきれいにし、 将来的にコードを扱いやすくする機会を再び得ることができます 。  機能を追加する場合、最初にリファクタリングしてコードをきれ いにする方が簡単なことが多いのです。“ディナーの準備をする前 にキッチンをきれいにする" TDDはリファクタリングを助ける
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. テスト可能なコードを書く
73. 73 Write Testable Code  TDDを実践しているかどうかにかかわらず、常にテスト可能なコ ードを書くべきです。  もし私が何かのテストを書くことができれば、通常はそれをコー ディングするのに十分なほど理解していることになります。もし できないなら、コーディングする前にもっと考える必要がありま す。  TDDを行うことで、私は前進し続けることができます。TDDは、 私の理解を確認し、適切なタイミングで適切なことに集中できる ようにします。  私はほぼ、どんな状態でも、 TDDならできます。半分寝ながらで も。 テスト可能なコードを書く
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は失敗する可能性があります
75. 75 But TDD Can Fail  TDDは素晴らしいものですが、私は成功するよりも失敗することの方が 多いと思っています。  スクラムコミュニティの約10%がエクストリームプログラミングを実践 しているが、そのほとんどはうまくいっていません。  開発者があまりにも多くのテストや実装に依存したテストを書くと、リ ファクタリングをサポートするどころか、むしろ妨げてしまうのです。  「飽きるまでテスト 」してはいけません。テストを書くときに、QA の 帽子をかぶらないようにしましょう。書きたい振る舞いを実現するのに 十分な量のテストだけを書きましょう。  TDDは、実装の詳細をテストするためではなく、振る舞いを指定するた めに使います。 しかしTDDは失敗する可能性があります
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をチームに導入する
77. 77 Introducing TDD to a Team  TDDを定着させるためには、チームがTDDを試したい、TDDに価 値を見出したいと思わなければなりません。トレーニングや立ち 上げの時間なしに、経営陣がTDDをチームに要求することは、ほ とんどうまくいきません。  TDDを成功させるためには、3つのことを知っておく必要がありま す。 – TDDを、構築したい振る舞いを指定する方法として理解すること。 – テスト不可能なコードをテスト可能にするための様々なテクニック。 – テストファーストでソフトウェアを構築する経験。 TDDをチームに導入する
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.” テストに感染する
79. 79 Become ‘Test Infected’  Eric Gamma氏は、開発者がTDDを行うことに感じる情熱を表現す るために、「テストに感染する」というフレーズを作りました。  私はテストに感染しているので、TDDでないプロジェクトで働く ために、十分な報酬をいただくわけにはいきません。それくらい 、私はTDDに価値を感じているのです。  開発者がTDDを行うと、要求の解釈やデバッグといった好きでも ないことに費やす時間が大幅に減り、私たちが最も楽しんでいる コードを書くことに多くの時間を費やすことができます。  TDDは、より質の高いコードを書く方法を教えてくれますし、将 来的な拡張もより簡単にできます。 “Warning: Promiscuous pairing can lead to becoming test infected.” テストに感染する
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 - レガシーコードをリファクタリングする
81. 81 Practice 9 - Refactor Legacy Code  リファクタリングとは、コードの外部動作を変えずに内部構造を 変更することです。チーム全体でイテレーションをとってコード をリファクタリングするように上司に頼んだとき、それをどのよ うに正当化すればいいのでしょうか？開発者はリファクタリング の重要性を理解していますが、それをビジネスに対してうまく表 現できないことがよくあります。  リファクタリングは4つのコストを下げます。 – コードを理解するのが遅くなる – ユニットテストを追加する – 新機能に対応する – さらにリファクタリングを行う プラクティス9 - レガシーコードをリファクタリングする
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. 投資か借金か？
83. 83 Investment or Debt?  高価な車を買って、高いお金を払ったから、絶対に修理に出さな いと言い張りますか？  技術的な負債は、金融負債と同じように、早く返済すればするほ ど、その費用は少なくなります。  もしあなたが技術的負債に対処しないなら、誰かがコードに触れ るたびに、コードを理解し修正するためにお金を払うことになり ます。  技術的負債は、開発の原則とプラクティスに注意を払っていても 、より多くを学び、設計を変更する必要があるため、蓄積される 可能性があります。 投資か借金か？
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. 「怠け者」になる
85. 85 Become a “Deadbeat”  私は毎月必ずクレジットカードを全額返済しています。  クレジットカード会社は私のような客を「怠け者」 と呼びます。 私たちから利益を稼ぐことはできないからです。  クレジットカードで17,000ドル借りていた友人は、毎月最低限の 支払いを続けると、返済するのに93年と184,000ドルが必要にな ると言われました。  技術的負債は「技術的怠け者」になって、できるだけ早く返済し ます。それが一番安上がりな方法です。 「怠け者」になる
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! コードの変更が必要なとき
87. 87 When Code Needs to Change  もし、レガシーコードが期待通り機能していて、拡張する必要がないの であれば、リファクタリングしてきれいにする必要はありません。  リファクタリングにはコストがかかるので、「壊れていないなら直さな い」のです。  コードを変更する必要があるときだけ、リファクタリングにこだわる必 要があるのです。  レガシーコードのリファクタリングでは、簡単なリファクタリングでコ ードの「継ぎ目」を作り、より複雑なリファクタリングに対応するため のテストを追加するようにします。  コードのリファクタリングは、開発者が最初にその種の誤りを避けるこ とを教え、より良いコードを書くのに役立ちます。 コードの変更が必要なとき
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. リファクタリング技法
89. 89 Refactoring Techniques  いくつかのリファクタリング戦略やテクニックを紹介します。 – テストを固定する。テストなしでコードをリファクタリングするのは危険で す。まず、エンドツーエンドの大きなテストをひとつ追加します。これは、現 在の挙動を突き止めるための「ピンニングテスト」と呼ばれることもあります 。テストの固定は頻繁に実行しましょう。 – 依存性注入。ファクトリーでオブジェクトを構築し、必要に応じて注入するこ とで、使用と生成を切り離します。 – システムのストラングリング(締め付けて壊死させる)。古いインターフェイス から呼び出される新しい実装を作成することで、動作中のコンポーネントを置 き換えることができる。新しい呼び出し元には新しいインターフェイスを使わ せ、古いクライアントを徐々に新しいインターフェイスにリファクタリングす る。 – 抽象化によるブランチ。フィーチャーフラグを使用して機能を切り替え、バ ージョン管理によるブランチを回避して、すべての開発をトランクから行うよ うにします。 リファクタリング技法
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 変化に対応するためのリファクタリング
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 変化に対応するためのリファクタリング
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. オープン・クローズドのためのリファクタリング
93. 93 Refactor to the Open-Closed  これは、既存のソフトウェアに機能を追加するための手法です。 – 機能を追加する前に、その新機能に対応できるようにソフトウェアを リファクタリングする。例えば、抽象化レイヤーを追加する。 – システムをリファクタリングして、既存のコードをあまり変更せずに 新しい機能を簡単に追加できるようにしたら、新しい機能に対するテ ストを書いて、それが失敗するのを見て、TDDスタイルでそれを成功 させる。  多くの開発者は、この2つのステップを同時に行おうとして、結局 は労力とリスクを高めてしまうのです。  新機能に対応するプロセスと実際に追加するプロセスを切り離す ことで、コードに加える変更はよりリスクが少なく、シンプルに 行うことができるのです。 オープン・クローズドのためのリファクタリング
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. リファクタリングで変更しやすさを確保する
95. 95 Refactor to Support Changeability  ソフトウェアの変更しやすさが偶然生まれることはありません。 良い開発の原則とプラクティスに従う必要があります。  変更可能性をサポートするには、コードの品質に注意を払い、適 切な抽象化機能を使用し、正確にモデリングすることが含まれま す。  優れたソフトウェア開発は、価値があることが証明されている特 定のパターンとシーケンスに従っています。  TDDは、私たちが変更可能なソフトウェアを書くことを支援し、 実装を変更したときに、コードがまだ動作することを教えてくれ ることで、私たちを支援してくれます。 リファクタリングで変更しやすさを確保する
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. 二度目に正しくやる
97. 97 Do it Right the Second Time  １つの例から抽象化するのは難しいので、私は2つ以上の例を持っ てから抽象化したり、一般化したアルゴリズムを書いたりしてい ます。  これは三角測量と呼ばれる手法で、天体航法からきています。水 平線上の点を複数の基準点によってより正確に計算できるように 、複数の具体例があれば、より簡単に一般化したものを見ること ができることが多いのです。  このような方法でリファクタリングや新しい設計を行うことは、 高品質のソフトウェアを構築する上で非常に効率的かつ効果的で す。 二度目に正しくやる
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? 真のアジャイル精神
99. 99 The True Spirit of Agile  アジャイルマニフェストの起草者は皆ソフトウェア開発者です。  私にとって、アジャイルソフトウェア開発は、アジャイルマニフ ェストの第一原則に最もよく集約されています。 – “顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供します。"  ソフトウェア開発を成功させるには、製造業を成功させるのとは 異なるスキルが必要です。それは、作成と維持にかかるコストが 少ない、独立して検証可能なふるまいを構築することです。  プラクティスを実行するだけでは十分ではありません。プラクテ ィスをうまく適用するためには、なぜそのプラクティスに価値が あるのかを理解する必要があります。 Why? 真のアジャイル精神
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 ありがとうございました！
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 をご覧ください。 ありがとうございました！
102. 102 https://www.jp.agilergo.com/ online-csd-bernstein-202302