Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Refactoring
Search
Yasunobu Kawaguchi
PRO
June 10, 2021
Programming
0
130
Refactoring
Yasunobu Kawaguchi
PRO
June 10, 2021
Tweet
Share
More Decks by Yasunobu Kawaguchi
See All by Yasunobu Kawaguchi
DevOpsDays History and my DevOps story
kawaguti
PRO
9
2.5k
Hybrid Conferences made by Small Teams
kawaguti
PRO
0
110
My journey from Fearless Change to Psychological Safety
kawaguti
PRO
11
3.4k
Agile PBL Approach: Seamlessly Onboarding New Grads to Teams
kawaguti
PRO
1
440
Agile and Iterative Development: Lessons from 20 Years of Ninja-style Testing
kawaguti
PRO
20
5.4k
User Story Mapping in CEDEC23
kawaguti
PRO
1
350
Scrum and Knowledge Creation
kawaguti
PRO
6
2.5k
Backlog and Velocity
kawaguti
PRO
2
490
Trial PBL Wrapup
kawaguti
PRO
1
180
Other Decks in Programming
See All in Programming
dbtのドメイン分割による データ基盤の改善とDigdagとの連携
sakama
0
340
Random\Randomizer クラスで日常のあれこれを解決しよう! / Random\Randomizer class solves familiar trouble
cocoeyes02
0
250
try! Swift Tokyo 初参加報告LT
hinakko2
0
220
GitHub Copilotのススメ
marcy731
1
200
見た目から始める生産性向上
ikumatadokoro
7
840
Code Reviews
bkuhlmann
4
890
Behind VS Code Extensions for JavaScript / TypeScript Linnting and Formatting
unvalley
5
920
GraphQLサーバの構成要素を整理する #ハッカー鮨 #tsukijigraphql / graphql server technology selection
izumin5210
4
840
スキーマ駆動開発による品質とスピードの両立 - 私達は何故、スキーマを書くのか
kentaroutakeda
0
170
ゆるい個人開発のススメ
kuroppe1819
10
990
Rubyでたのしむクリエイティブコーディング/Enjoy Creative coding with Ruby
chobishiba
1
180
PHPはいつから死んでいるかの調査
chiroruxx
1
400
Featured
See All Featured
Stop Working from a Prison Cell
hatefulcrawdad
266
19k
The Mythical Team-Month
searls
216
42k
Creatively Recalculating Your Daily Design Routine
revolveconf
210
11k
What's new in Ruby 2.0
geeforr
337
31k
VelocityConf: Rendering Performance Case Studies
addyosmani
320
23k
Writing Fast Ruby
sferik
621
60k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
18
6.9k
The Cult of Friendly URLs
andyhume
74
5.7k
4 Signs Your Business is Dying
shpigford
175
21k
Automating Front-end Workflow
addyosmani
1356
200k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
25
2.3k
A Tale of Four Properties
chriscoyier
151
22k
Transcript
リファクタリング について 考えてみて もらいたいスライド
https://bliki-ja.github.io/CodeOwnership/
https://bliki-ja.github.io/CodeOwnership/ コードの所有には、私が 今まで見てきたものだけ でも、いくつかの形があ る。ここでは大きく3つの カテゴリに分けてみた。
https://bliki-ja.github.io/CodeOwnership/ 強いコードの所有では、コードはモ ジュール(クラス、関数、ファイ ル)などに分かれており、それぞれ が一人の開発者に割り当てられてい る。開発者は自分のモジュールだけ を変更することができる。他の開発 者のモジュールを変更したい場合は、 モジュールの所有者に頼んで変更し てもらうことになる。または、パッ
チを書いて送りつける方法もある。
https://bliki-ja.github.io/CodeOwnership/ 弱いコードの所有では、上記と同様、 モジュールが各開発者に割り当てら れているが、他の人のモジュールも 変更してもよいという点で異なる。 モジュールの所有者は割り当てられ たモジュールに責任を持ち、他の人 によって変更が加えられることに気 を配る必要がある。他の人のモ ジュールに大幅な変更を加える場合
は、きちんとそのモジュール所有者 に断りを入れるのがよいだろう。
https://bliki-ja.github.io/CodeOwnership/ コードの共同所有では、モジュール の割り当てそのものを行わない。 コードはチームの所有物であり、誰 もがどのコードにも変更を加えるこ とができる。コードの所有という考 えがが無いと考えてよい。ただ、 コードの共同所有を提唱する者たち は、個人ではなく「チームに」所有 されていることを強調している
(チームによる共同所有は、エクス トリーム・プログラミングからきて いる。2版では「Shared Code」と呼 ばれている。)。
https://www.ketancho.net/entry/2018/02/22/080000 デイブは僕のチームにいる重要 な知識の塔だった。他の誰も追 いつけない、深い技術知識を 持っている人物だ。 (中略) デイブが2週間の休暇でいなく なるたび、僕が不眠になったの も仕方がない。
https://bliki-ja.github.io/
https://bliki-ja.github.io/CodeOwnership/ :リファクタリング(名詞):外 部から見たときの振る舞いを保 ちつつ、理解や修正が簡単にな るように、ソフトウェアの内部 構造を変更させること。 :リファクタリング(動詞):一 連のリファクタリングを行って、 外部から見た振る舞いの変更な しに、ソフトウェアを再構築す
ること。
https://bliki-ja.github.io/CodeOwnership/ :リファクタリング(名詞):外 部から見たときの振る舞いを保 ちつつ、理解や修正が簡単にな るように、ソフトウェアの内部 構造を変更させること。 :リファクタリング(動詞):一 連のリファクタリングを行って、 外部から見た振る舞いの変更な しに、ソフトウェアを再構築す
ること。 プロダクトバックログの観点 =内容(要件)が変わらないこと インターフェースの観点 =提供するふるまい(Behavior)が 変わらないこと
https://bliki- ja.github.io/IsHighQualitySoftwareWorthTheCost/
https://bliki- ja.github.io/IsHighQualitySoftwareWorthTheCost/ 顧客はこのソースコードを見る ことはなく、アプリの動作に影 響を与えないので、レベッカの ソフトウェアに余分な4ドルを支 払う人はいるのでしょうか? もっと一般的に言えば、より高 い内部品質のためにもっとお金 を払う価値がないことを意味し
ているはずです。
https://bliki- ja.github.io/IsHighQualitySoftwareWorthTheCost/ 内部品質の主な特徴の1つは、ア プリケーションがどのように動 作するかを簡単に把握できるよ うにして、どのように機能を追 加するかを容易に確認できるよ うにすることです。
https://bliki- ja.github.io/IsHighQualitySoftwareWorthTheCost/ ここでなぜ内部品質がユーザー や顧客にとって重要なのか、そ のヒントが見えてきます。内部 品質が良ければ、新機能の追加 が容易になり、その結果より速 くより安価になります。
https://bliki- ja.github.io/IsHighQualitySoftwareWorthTheCost/ • 内部品質を疎かにすると急速にクラ フトが蓄積されていく • このクラフトが機能開発を遅らせる • 優れたチームであってもクラフトを 発生させるが、内部の品質を高く保
つことによってそれを制御すること ができる • 内部品質が高いとクラフトが最小限 に抑えられ、チームはより少ない労 力、時間、コストで機能を追加する ことができる
内部品質が高いソフトウェアとは?? • 読みやすい(適切な名前、役割の分割) • 開発者に理解されている(コードの共同所有) • 変更しやすい • テストされている、テストしやすい •
変更の影響が限定的である • 変更しなくても変化に対応できる
たとえば? 1. まずは最低限動くコードを書く 2. 変数やメソッドの名前を気にする 3. 変数のスコープを気にする 4. If文をクラスで実現して減らしていく (デザインパターン)
5. 単一責任の原則を気にする 6. DI(依存性注入)を考える 7. データはデータベースに入れてコードの変更 を不要にする
https://bliki-ja.github.io/RollerSkateImplementation/ アジャイル開発の重要な特性として、 小さな機能サブセットに分割してシ ステムを稼動させる方法をあれこれ 考える、というものがある。 我々 は、ソフトウェアがもたらすビジネ ス価値のためにソフトウェアを構築 するのである。 システムの稼動が
早ければ、それだけそのビジネス価 値(の少なくとも幾分か)を早く手 に入れることができる。
https://bliki-ja.github.io/ContinuousDelivery/ 重要なポイントは、顧客から 今開発中のそのバージョンを、 すぐに本番環境にデプロイし ろ と言われたときに対応でき るかどうか、そして誰もパ ニックに陥らずに済むかどう かということだ。