Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
Refactoring
Yasunobu Kawaguchi
PRO
June 10, 2021
Programming
0
77
Refactoring
Yasunobu Kawaguchi
PRO
June 10, 2021
Tweet
Share
More Decks by Yasunobu Kawaguchi
See All by Yasunobu Kawaguchi
Revisit the DevOps Origin: 10+ Deploys Per Day by Flickr
kawaguti
PRO
0
210
ソフトウェア開発って なにか?を学ぶ勉強会
kawaguti
PRO
5
2.9k
AntiCovid19
kawaguti
PRO
0
240
Roots of Scrum 2005
kawaguti
PRO
4
4.7k
Scaling up Excellence
kawaguti
PRO
4
1k
10 min de Scrum 2021
kawaguti
PRO
0
650
Age of Agile Development 3
kawaguti
PRO
7
1.3k
Scrum Gaiyo 2
kawaguti
PRO
1
440
ScrumGaiyo
kawaguti
PRO
1
240
Other Decks in Programming
See All in Programming
WindowsコンテナDojo : 第1回 Visual StudioでWindowsコンテナアプリ作成
oniak3ibm
PRO
0
320
ebpfとWASMに思いを馳せる2022 / techfeed-conference-2022-ebpf-wasm-amsy810
masayaaoyama
0
490
New Relicを使った Observabilityの実現方法と活用例 / gocon 2022 spring after talk
budougumi0617
0
960
Where and how to run UI tests (Droidcon London, 2021)
nonews
0
210
2022 FrontEnd Training
mixi_engineers
1
120
TechFeed Conference 2022 - Kotlin Experimental
jmatsu
0
580
Improve Build Times in Less Time
zacsweers
6
2.8k
Jakarta EE 10 is Coming Your Way
ivargrimstad
0
2.1k
Reactでアプリケーションを構築する多様化
sakito
4
3.1k
実録mruby組み込み体験
coe401_
0
100
Managing gRPC with Wire
oldergod
2
150
Node.js 最新動向 TFCon 2022
yosuke_furukawa
PRO
5
2.6k
Featured
See All Featured
Design by the Numbers
sachag
271
17k
Raft: Consensus for Rubyists
vanstee
126
5.4k
Stop Working from a Prison Cell
hatefulcrawdad
261
17k
Art Directing for the Web. Five minutes with CSS Template Areas
malarkey
196
9.4k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
119
28k
Put a Button on it: Removing Barriers to Going Fast.
kastner
56
2.3k
Rails Girls Zürich Keynote
gr2m
86
12k
The Straight Up "How To Draw Better" Workshop
denniskardys
225
120k
Designing with Data
zakiwarfel
91
3.9k
The Cult of Friendly URLs
andyhume
68
4.7k
We Have a Design System, Now What?
morganepeng
35
2.9k
How to name files
jennybc
39
58k
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/ 重要なポイントは、顧客から 今開発中のそのバージョンを、 すぐに本番環境にデプロイし ろ と言われたときに対応でき るかどうか、そして誰もパ ニックに陥らずに済むかどう かということだ。