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
3ヶ月で20万行を消すためにやったこと
Search
Naoto Sato
June 29, 2019
Technology
17
17k
3ヶ月で20万行を消すためにやったこと
Naoto Sato
June 29, 2019
Tweet
Share
More Decks by Naoto Sato
See All by Naoto Sato
新米エンジニアをTech Leadに任命する ー 成長を支える挑戦的な人と組織のマネジメント
naopr
1
430
メガベンチャーのEMから スタートアップの1人目EMになって 変わったこと、変わらないこと
naopr
0
400
ドキュメンテーションを はじめよう
naopr
6
1.6k
「推測するな、計測せよ」 〜小さく始める生産性可視化と分析〜
naopr
46
22k
メルカリ・メルカリShopsのCRE
naopr
0
720
Technique to delete unused codes
naopr
0
1.7k
Other Decks in Technology
See All in Technology
社内外から"使ってもらえる"データ基盤を支えるアーキテクチャの秘訣/登壇資料(飯塚 大地・高橋 一貴)
hacobu
PRO
0
7.7k
変わるもの、変わらないもの :OSSアーキテクチャで実現する持続可能なシステム
gree_tech
PRO
0
1k
その意思決定、まだ続けるんですか? ~痛みを超えて未来を作る、AI時代の撤退とピボットの技術~
applism118
42
24k
AIで加速する次世代のBill Oneアーキテクチャ〜成長の先にある軌道修正〜
sansantech
PRO
1
130
.NET 10のASP. NET Core注目の新機能
tomokusaba
0
140
.NET 10のEntity Framework Coreの新機能
htkym
0
130
確実に伝えるHealth通知 〜半自動システムでほどよく漏れなく / JAWS-UG 神戸 #9 神戸へようこそ!LT会
genda
0
150
履歴テーブル、今回はこう作りました 〜 Delegated Types編 〜 / How We Built Our History Table This Time — With Delegated Types
moznion
1
1.4k
今すぐGoogle Antigravityを触りましょう
rfdnxbro
0
210
Bill One 開発エンジニア 紹介資料
sansan33
PRO
4
15k
Sansan Engineering Unit 紹介資料
sansan33
PRO
1
3.2k
リアーキテクティングのその先へ 〜品質と開発生産性の壁を越えるプラットフォーム戦略〜 / architecture-con2025
visional_engineering_and_design
0
7.8k
Featured
See All Featured
A designer walks into a library…
pauljervisheath
210
24k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
1.8k
The World Runs on Bad Software
bkeepers
PRO
72
12k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
54k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
253
22k
Building an army of robots
kneath
306
46k
Optimizing for Happiness
mojombo
379
70k
For a Future-Friendly Web
brad_frost
180
10k
Why Our Code Smells
bkeepers
PRO
340
57k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
118
20k
We Have a Design System, Now What?
morganepeng
54
7.9k
Transcript
3ヶ月で20万行を消すためにやったこと PHP Conference Fukuoka 2019 @naopr
@naopr • Backend Engineer of CSTool Team ◦ CSTool =
CS用管理ツール • Love ☗
メルカリと福岡 仙台 ・お問い合わせ返信 ・商品・コメント等の監 視 福岡 ・コールセンター ・開発拠点 東京 ・本社
・アプリ開発
メルカリとPHP • メルカリのAPIはPHPで書かれている! • モノリス→マイクロサービスへ移行中 ◦ PHPからGoへ ◦ 既存のAPIのふるまいを変えずに各サービスにブレークダウン中 ◦
MTC2018 - Mercari API: from Monolithic to Microservices
3ヶ月で20万行を消す ためにやったこと
アジェンダ • 不要コードを削除するメリット • メルカリで実際に行ったコード削除 ◦ どのようにコードを削除したのか ◦ 結果 •
まとめ
不要コードを削除するメリット • コードの複雑度の低下 ◦ 行数の削減 ◦ 循環的複雑度の低下 ◦ トランザクションの複雑度の低下 •
システムの高速化 ◦ レスポンスタイム ◦ CIの実行時間
メルカリで実際に行った コード削除
コード削除の手法 機能単位 API単位
コード削除の手法 機能単位 API単位 今回はこちらのお話
API単位でコードを削除するステップ 不要なAPIをリストアップする プロジェクトチームを作る コードを削除する 1 2 3
不要なAPIをリストアップする (1/3) 1. 直近アクセスのないAPIを抽出する a. BigQueryに保存しているアクセスログとPHPのAPI定義を突き合わせる b. 1ヶ月アクセスのないものを抽出する 2. 使われているものと使われていないものに分類する
a. ひたすらコードを読む b. `git blame` で開発者を見つけて聞く c. そのAPIに関する開発チケットを読む
None
不要なAPIをリストアップする (2/3)
不要なAPIをリストアップする (3/3) • 抽出されたAPI(526個) ◦ 別リージョンでのみ使われていたAPI i. メルカリでは元々全リージョン同一リポジトリだった ◦ どこからも呼び出されていないAPI
◦ 呼び出し元が既に使われていないAPI • 抽出されたが削除NGになったAPI(156個) ◦ 直近アクセスがないだけで使用されているAPI 526 - 156 = 370 個が削除対象
メルカリで不要API削除のために行ったステップ 不要なAPI群をリストアップする プロジェクトチームを作る コードを削除する 1 2 3
プロジェクトチームを作る (1/3) • 一緒にコード削除をやってくれる仲間を探す ◦ バックエンドエンジニア x 7 ◦ フロントエンドエンジニア
x 1 ◦ QAエンジニア x 1 • 削除手順を決める ◦ APIリストをどう管理するか ◦ どのようにQAを行うか
プロジェクトチームを作る (2/3) • 仲間探しについて ◦ 370個のAPIを1人で消すのは物理的にも精神的にも無理 ◦ 気が向いたときにやってくれるくらいのゆるい同士を募る ◦ チーム・部署横断でチームを作るのでキックオフをする
◦ タフなプロジェクトになるのでの力も借りる
プロジェクトチームを作る (3/3) • API管理シート アサイン欄が空のものを選んで ステータス欄とアサイン欄を更新 メモ欄で難易度と雰囲気を感じとる 好きな時に好きなAPIを消せる
メルカリで不要API削除のために行ったステップ 不要なAPI群をリストアップする プロジェクトチームを作る コードを削除する 1 2 3
コードを削除する (1/2) • 再度直近のアクセスログをチェックする ◦ リストを作ってから消すまでにタイムラグがあるため • Controllerを起点に再帰的に消す ◦ `git
grep` をひたすら叩く ◦ IDEのシンボルサーチも役に立つ ◦ Controller, Service, Exception, Entity, DB table, DB schema, test, etc… ◦ 中途半端に残すと後の混乱の種になるので徹底的に消す ▪ ただしリファクタはスコープが大きくなりすぎるのでほどほどに
コードを削除する (2/2) • 「デグレリスクが怖いです…」 ◦ 単体テストと結合テストがある程度書かれている前提 ◦ メルカリはテストが充実しているので思い切って削除できた ▪ 新機能実装時に必ずテストを書く文化
▪ QAチームによる自動e2eテストもある ◦ クリティカルな機能をさわった場合にはQAエンジニアにマニュアルのテストも お願いした ◦ 複雑度が高すぎるAPIは消さない判断もアリ
結果
結果サマリー • 349個のAPIを削除 ◦ 3ヶ月で20万行 • Reverted 9 PRs ◦
DBテーブルを削除したら別のサービスで使っていた ◦ 使われていたAPIを誤って消してしまい大量のエラーが発生 ◦ 突っ込んだ話はAsk the Speakerや懇親会でぜひ
まとめ
コード削除は難しい(だがやる価値がある) • 地道にコードを読み、わからなければ詳しいエンジニアに聞くべし • 一人でやるのは無理。チームを作るべし • アクセスログのチェックはしつこいくらいにやるべし • DBテーブルを消す時は他サービスへの影響をチェックすべし •
ストレスのたまる作業なので適宜ガス抜きをすべし ぜひ、みなさんのチームでも少しずつコード削除を始めてみてください
Let’s delete codes!