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
150
Refactoring
Yasunobu Kawaguchi
PRO
June 10, 2021
Tweet
Share
More Decks by Yasunobu Kawaguchi
See All by Yasunobu Kawaguchi
Agile PBL at New Grads Trainings
kawaguti
PRO
1
450
Last 2 Weeks on PBL
kawaguti
PRO
1
60
Bridging gaps between skills and ideas
kawaguti
PRO
1
63
Definition of Done
kawaguti
PRO
6
570
Nonaka Sensei
kawaguti
PRO
4
1.4k
Ninno LT
kawaguti
PRO
1
180
大人の学び - マイクの持ち方について
kawaguti
PRO
6
970
User Story Mapping + Inclusive Team
kawaguti
PRO
4
900
Creative Pair
kawaguti
PRO
1
230
Other Decks in Programming
See All in Programming
@Environment(\.keyPath)那么好我不允许你们不知道! / atEnvironment keyPath is so good and you should know it!
lovee
0
130
「待たせ上手」なスケルトンスクリーン、 そのUXの裏側
teamlab
PRO
0
570
「手軽で便利」に潜む罠。 Popover API を WCAG 2.2の視点で安全に使うには
taitotnk
0
870
Azure SRE Agentで運用は楽になるのか?
kkamegawa
0
2.5k
基礎から学ぶ大画面対応(Learning Large-Screen Support from the Ground Up)
tomoya0x00
0
4.3k
アプリの "かわいい" を支えるアニメーションツールRiveについて
uetyo
0
280
Navigating Dependency Injection with Metro
zacsweers
3
3.5k
請來的 AI Agent 同事們在寫程式時,怎麼用 pytest 去除各種幻想與盲點
keitheis
0
130
1から理解するWeb Push
dora1998
7
1.9k
Introducing ReActionView: A new ActionView-compatible ERB Engine @ Rails World 2025, Amsterdam
marcoroth
0
710
Kiroで始めるAI-DLC
kaonash
2
630
Ruby×iOSアプリ開発 ~共に歩んだエコシステムの物語~
temoki
0
350
Featured
See All Featured
Why Our Code Smells
bkeepers
PRO
339
57k
It's Worth the Effort
3n
187
28k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Music & Morning Musume
bryan
46
6.8k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
For a Future-Friendly Web
brad_frost
180
9.9k
Being A Developer After 40
akosma
90
590k
Raft: Consensus for Rubyists
vanstee
140
7.1k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
A designer walks into a library…
pauljervisheath
207
24k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
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/ 重要なポイントは、顧客から 今開発中のそのバージョンを、 すぐに本番環境にデプロイし ろ と言われたときに対応でき るかどうか、そして誰もパ ニックに陥らずに済むかどう かということだ。