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