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
Creative Pair
kawaguti
PRO
1
160
Women in Agile
kawaguti
PRO
4
200
I could be Wrong!! - Learning from Agile Experts
kawaguti
PRO
7
4.4k
Replit Agent
kawaguti
PRO
2
680
Mobbing Practices
kawaguti
PRO
3
490
RSGT Walk Through
kawaguti
PRO
6
1.8k
XP matsuri 2024 - 銀河英雄伝説に学ぶ
kawaguti
PRO
3
920
1Q86
kawaguti
PRO
2
470
Shinagile 2024
kawaguti
PRO
3
200
Other Decks in Programming
See All in Programming
コミュニティ駆動 AWS CDK ライブラリ「Open Constructs Library」 / community-cdk-library
gotok365
2
140
GAEログのコスト削減
mot_techtalk
0
120
Amazon Bedrock Multi Agentsを試してきた
tm2
1
290
PHPカンファレンス名古屋2025 タスク分解の試行錯誤〜レビュー負荷を下げるために〜
soichi
1
210
なぜイベント駆動が必要なのか - CQRS/ESで解く複雑系システムの課題 -
j5ik2o
12
4k
Honoのおもしろいミドルウェアをみてみよう
yusukebe
1
210
密集、ドキュメントのコロケーション with AWS Lambda
satoshi256kbyte
0
190
苦しいTiDBへの移行を乗り越えて快適な運用を目指す
leveragestech
0
630
JavaScriptツール群「UnJS」を5分で一気に駆け巡る!
k1tikurisu
9
1.8k
さいきょうのレイヤードアーキテクチャについて考えてみた
yahiru
3
750
昭和の職場からアジャイルの世界へ
kumagoro95
1
380
1年目の私に伝えたい!テストコードを怖がらなくなるためのヒント/Tips for not being afraid of test code
push_gawa
0
200
Featured
See All Featured
Raft: Consensus for Rubyists
vanstee
137
6.8k
Designing on Purpose - Digital PM Summit 2013
jponch
117
7.1k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
550
Practical Orchestrator
shlominoach
186
10k
Navigating Team Friction
lara
183
15k
Side Projects
sachag
452
42k
Designing Experiences People Love
moore
140
23k
Speed Design
sergeychernyshev
27
790
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
27
1.9k
Unsuck your backbone
ammeep
669
57k
Making the Leap to Tech Lead
cromwellryan
133
9.1k
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/ 重要なポイントは、顧客から 今開発中のそのバージョンを、 すぐに本番環境にデプロイし ろ と言われたときに対応でき るかどうか、そして誰もパ ニックに陥らずに済むかどう かということだ。