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
210
I could be Wrong!! - Learning from Agile Experts
kawaguti
PRO
7
4.5k
Replit Agent
kawaguti
PRO
2
700
Mobbing Practices
kawaguti
PRO
3
490
RSGT Walk Through
kawaguti
PRO
6
1.8k
XP matsuri 2024 - 銀河英雄伝説に学ぶ
kawaguti
PRO
3
930
1Q86
kawaguti
PRO
2
470
Shinagile 2024
kawaguti
PRO
3
210
Other Decks in Programming
See All in Programming
データの整合性を保つ非同期処理アーキテクチャパターン / Async Architecture Patterns
mokuo
53
18k
Amazon S3 TablesとAmazon S3 Metadataを触ってみた / 20250201-jawsug-tochigi-s3tables-s3metadata
kasacchiful
0
180
第3回 Snowflake 中部ユーザ会- dbt × Snowflake ハンズオン
hoto17296
4
380
DROBEの生成AI活用事例 with AWS
ippey
0
140
Pythonでもちょっとリッチな見た目のアプリを設計してみる
ueponx
1
590
Conform を推す - Advocating for Conform
mizoguchicoji
3
700
color-scheme: light dark; を完全に理解する
uhyo
6
460
How mixi2 Uses TiDB for SNS Scalability and Performance
kanmo
40
15k
AIの力でお手軽Chrome拡張機能作り
taiseiue
0
180
バックエンドのためのアプリ内課金入門 (サブスク編)
qnighy
8
1.8k
苦しいTiDBへの移行を乗り越えて快適な運用を目指す
leveragestech
0
790
密集、ドキュメントのコロケーション with AWS Lambda
satoshi256kbyte
1
200
Featured
See All Featured
Fontdeck: Realign not Redesign
paulrobertlloyd
83
5.4k
GraphQLとの向き合い方2022年版
quramy
44
13k
A designer walks into a library…
pauljervisheath
205
24k
Designing on Purpose - Digital PM Summit 2013
jponch
117
7.1k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
The World Runs on Bad Software
bkeepers
PRO
67
11k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
120k
Measuring & Analyzing Core Web Vitals
bluesmoon
6
250
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
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/ 重要なポイントは、顧客から 今開発中のそのバージョンを、 すぐに本番環境にデプロイし ろ と言われたときに対応でき るかどうか、そして誰もパ ニックに陥らずに済むかどう かということだ。