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
APoSDは良いぞ!/aposd_is_great
Search
Ryo Tomidokoro
October 14, 2020
Programming
2
580
APoSDは良いぞ!/aposd_is_great
A Philosophy of Software Designは素晴らしいと言い続けるだけのスライドです。
Ryo Tomidokoro
October 14, 2020
Tweet
Share
More Decks by Ryo Tomidokoro
See All by Ryo Tomidokoro
フロントエンドがTypeScriptなら、バックエンドはPHPでもいいじゃない/php-is-not-bad
hanhan1978
8
13k
どうすると生き残れないのか/how-not-to-survive
hanhan1978
17
14k
100分で本番デプロイ!Laravelで作るWebアプリケーション作成/100min_web_app_cicd
hanhan1978
1
200
PHPerのための計算量入門/Complexity101 for PHPer
hanhan1978
8
3.1k
集中して作業する技術/how_to_work_deeply
hanhan1978
65
51k
PHPでデータベースを作ってみた/create-data-with-php
hanhan1978
11
11k
ADRを一年運用してみた/adr_after_a_year
hanhan1978
8
4.4k
B+木入門:PHPで理解する データベースインデックスの仕組み/b-plus-tree-101
hanhan1978
5
5.6k
ADRを一年運用してみた/our_story_about_adr
hanhan1978
5
2.4k
Other Decks in Programming
See All in Programming
Devoxx BE - Local Development in the AI Era
kdubois
0
130
Web Components で実現する Hotwire とフロントエンドフレームワークの橋渡し / Bridging with Web Components
da1chi
3
2.5k
アメ車でサンノゼを走ってきたよ!
s_shimotori
0
220
大規模アプリのDIフレームワーク刷新戦略 ~過去最大規模の並行開発を止めずにアプリ全体に導入するまで~
mot_techtalk
1
450
Swift Concurrency - 状態監視の罠
objectiveaudio
2
520
Cursorハンズオン実践!
eltociear
2
1.1k
タスクの特性や不確実性に応じた最適な作業スタイルの選択(ペアプロ・モブプロ・ソロプロ)と実践 / Optimal Work Style Selection: Pair, Mob, or Solo Programming.
honyanya
3
170
理論と実務のギャップを超える
eycjur
0
140
XP, Testing and ninja testing ZOZ5
m_seki
3
650
CSC509 Lecture 04
javiergs
PRO
0
300
『毎日の移動』を支えるGoバックエンド内製開発
yutautsugi
2
250
デミカツ切り抜きで面倒くさいことはPythonにやらせよう
aokswork3
0
230
Featured
See All Featured
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
14k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
The Language of Interfaces
destraynor
162
25k
How STYLIGHT went responsive
nonsquared
100
5.8k
Raft: Consensus for Rubyists
vanstee
140
7.1k
A better future with KSS
kneath
239
18k
Gamification - CAS2011
davidbonilla
81
5.5k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.5k
Embracing the Ebb and Flow
colly
88
4.8k
Making Projects Easy
brettharned
120
6.4k
How to Think Like a Performance Engineer
csswizardry
27
2k
Transcript
@hanhan1978 APoSD本は良いぞ! Fukuoka.php 2020/10/14
本日のテーマ 買って読んで。(洋書)
コードレビュー してますか?
会社のブログにも書いた https://tech.innovator.jp.net/entry/2019/10/16/151227
• 近年、GithubのPRにより形式化 • レビューを受けないとMerge不可 • レビューにより品質が向上??
トレンドチェック https://trends.google.com/trends/explore?date=all&geo=US&q=%22Pull%20Request%22 2009年くらいから認知され てきている
コードレビューの目的は何か?
他人の目を入れる • Aさんしか知らない実装を無くす => 属人性排除 • Bさんが知っている見地からコードを見ても らう => 設計の妥当性
コードレビューの結果は 指摘事項として現れる
1. 仕様からの乖離は無いか 2. 誤りのあるコード 3. より良い実装・設計の提案
1. 仕様からの乖離は無いか 2. 誤りのあるコード 3. より良い実装・設計の提案 明確
1. 仕様からの乖離は無いか 2. 誤りのあるコード 3. より良い実装・設計の提案 曖昧
私が抱えていた問題(1)
レビュー対象のソースコードに 「良くない臭い」を感じるが... • 上手く言語化できない • 説明が冗長になりコストがかかる
私が抱えていた問題(2)
レビュー&指摘修正後のゴール • そもそも何で指摘するのか? • より良い設計という目的は曖昧
結果として
忖度LGTM
「説明長くなりそうだし、明日リリースだから...ヨシッ!」 「今夜は用事がある。少し気になるけど...ヨシッ!」 「読みづらいけど、説明が難しいし、緊急対応だから...ヨシッ!」
ヨクナイ
しかし、設計思想や目的を言語化す るのは難しい。 一体どうしたら...
APoSD
APoSDの主題
ソフトウェアデザイン
特に注目しているポイント
複雑性 ソフトウェア開発を難しくする原因
複雑性 C = ΣCpTp • Cp => 部分の複雑性 • Tp
=> 部分開発にかかる時間 全体の複雑性は 部分ごとの複雑性の積算
欠けていたピースが見つかった
1. 仕様からの乖離は無いか 2. 誤りのあるコード 3. より良い実装・設計の提案 3. 複雑性を下げる実装・設計の提案
具体的な手法は 是非本を読んでほしい。
目次
著者のオススメ • コードレビュー時に参照 • チームでBetterなシステムデザインを目 指す
まとめ
• 複雑性という共通の敵が明らかに • レビューに活用、みんなで設計議論 • 気軽に使いたいから、誰か翻訳して!
A Philosophy of Software Design