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
なぜコードを書いてはいけないか
Search
Takato Fukui
May 23, 2024
Programming
0
92
なぜコードを書いてはいけないか
Takato Fukui
May 23, 2024
Tweet
Share
More Decks by Takato Fukui
See All by Takato Fukui
dd-trace-goのtrace context propagation実装
takatofukui
0
420
ソフトウェアテスト
takatofukui
0
59
リファクタリング
takatofukui
0
110
本番分析データベースを丸ごと削除した人の顔
takatofukui
0
100
Other Decks in Programming
See All in Programming
単体テストの始め方/作り方
toms74209200
0
510
ReadMoreTextView
fornewid
1
450
セキュリティマネジャー廃止とクラウドネイティブ型サンドボックス活用
kazumura
1
180
Effect の双対、Coeffect
yukikurage
5
1.4k
Cursor Meetup Tokyo ゲノミクスとCursor: 進化と制約のあいだ
koido
2
1k
GoのGenericsによるslice操作との付き合い方
syumai
2
660
Julia という言語について (FP in Julia « SIDE: F ») for 関数型まつり2025
antimon2
3
960
Team topologies and the microservice architecture: a synergistic relationship
cer
PRO
0
880
KotlinConf 2025 現地参加の土産話
n_takehata
0
100
Development of an App for Intuitive AI Learning - Blockly Summit 2025
teba_eleven
0
120
CursorはMCPを使った方が良いぞ
taigakono
0
120
A comprehensive view of refactoring
marabesi
0
810
Featured
See All Featured
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
A better future with KSS
kneath
239
17k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
GraphQLとの向き合い方2022年版
quramy
46
14k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.8k
Into the Great Unknown - MozCon
thekraken
39
1.8k
Navigating Team Friction
lara
187
15k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Unsuck your backbone
ammeep
671
58k
Transcript
なぜコードを書いてはいけないか 福井崇人
https://twitter.com/takano32/status/1345717252423733249
コードを書くと... -> 管理するコードが増える = コードが複雑になる “コードが増える”はこちらではなく こちらのような意味合い
管理するコードが増えるとどうなるか? • コードを読む時間がかかる a. エンジニアはコードは書くより読む時間に 9割かかると言われる • バグを生みやすくなる a. バグがないシステムはない
b. コード量に比例してバグが入り込む可能性が高くなる • 機能追加などに時間がかかりやすくなる a. コードが多いと修正の影響を受けやすくなり、その対応コストがかかりやすくなる b. コードが多いと修正するコード量も多くなりやすくなる
「管理するコードが増えるとどうなるか?」 -> それすなわち生産性が低くなる Frederick Phillips Brooks, Jr. (2015, April 15).
人月の神話. 丸善出版 (原著初版は1975) 指数関数的な伸びは 50年前から普遍的 『人月の神話』 ↓などについて言及している • 5人で2ヶ月かかる開発に+5人投入して 合計10人にしても1ヶ月では終わらない • 「遅れているソフトウェアプロジェクトへの 要員追加は、さらにプロジェクトを遅らせ る」 • 少人数チームによるコミュニケーション 負荷削減
Robert Cecil Martin. (2018, July 27). Clean Architecture 達人に学ぶソ フトウェアの構造と設計.
アスキードワンゴ コード行数はこれくらいしか増えてない のに... エンジニアはめっちゃ増えてる 参考
このようにコードを書くと負の部分が多く、 資産ではなく負債と扱われることが多い 資産 負債 🔥😠💦 頑張って書いたコードは資 産だと思いたいが... 実際にはこっち
また、多いコードはシステムにおける複雑性の1つ • システムの複雑性を成すもの ◦ 多いコード = 複雑なコード ← 今回はこの観点からの話 ◦
バラバラな使用技術 ▪ 「1つのシステムでawsとGCPのサービスをいいとこどりで組み合わせて使ってます」 ◦ 特別な仕組みの多さ ▪ (Webサイトで)「ページ表示速度遅いからここだけはバッチにしよう」 ▪ (Webサイトで)「ページ表示速度遅いからここだけキャッシュ入れよう」 ◦ バラバラな設計
でも負債とはいえコード書かないと何もできないのでは? じゃあコードを書く判断は? 管理するコード量 × 価値という観点で機能追加を例に考えてみる 価値 管理するコード量 100 200 今ここだとする
機能追加してコードが 2倍になっ たら、2倍良くなる? ?
コードを書かないためにはどうするか? • コードが複雑になる箇所の仕様を見直す a. コードが複雑になる箇所はどんな箇所 ? ▪ 複雑な条件 ▪ 多くの概念を扱っている箇所
• 「凄いユーザーは”優良ユーザー”として扱われるが、さらに凄いユーザーは ”優良ユー ザー 殿堂入り”として扱われる」 ▪ 個別最適 • 「口コミ一覧ページでは星 1の口コミは表示しないが、今回追加する ”口コミ平均値表示” では星1の口コミを含める」 • 「”オススメのレストラン ”カセットでは内観の1番優先度が高い画像を出すが、 ”近くのレ ストラン”カセットでは料理の一番優先度が高い画像を出す」 2倍良くならなさそうならコードは書かない方がいいかも
コードを書かないためにはどうするか? • ただただ機能追加を諦める • コードを書かずに価値提供する a. 運用でカバー的な 「最も読みやすいコードは、何も書かれていないコードだ。」 Dustin Boswell
& Trevor Foucher. (2019, September 24). リーダブルコード. 株式会社オライリー・ジャパン 2倍良くならなさそうならコードは書かない方がいいかも
• 特に競争になり得るコアドメインは価値に繋がりやすいし書いていいかも コアドメインの例 a. SNSにおける友達推測(「友達ですか?」) b. ECサイトにおける配送料計算 (割引とかがある) • “コアドメイン”ではないがサービスが大事にする品質特性の向上も価値に繋がりや
すいし書いていいかも a. スマホゲームのサクサク度 b. デザイン会社のホームページデザイン c. セキュリティ会社が提供するサービスのセキュリティ ← むしろこのためにコード書かないとダメ 2倍良くなりそうだったらコード書いてもいいかも
• ただ生産性という観点だと前にあげた指数関数的なグラフのように、管理するコー ドが多ければ多いほど生産性が下がる その生産性の下り幅を和らげるために設計が必要 これはエンジニアの腕の見せ所 2倍良くなりそうだったらコード書いてもいいかも 管理するコード 生産性 🔥😠💦 管理するコード
生産性
「なぜコードを書いてはいけないか」まとめ • 多いコードはシステムにおける複雑性の1つ • コードが多いと生産性が下がる • コードが生む価値と照らし合わせて書くかどうかを判断すべし • 「シンプルさ(ムダなく作れる量を最大限にすること)が本質です。」 アジャイル宣言の背後にある原則
. (n.d.). https://agilemanifesto.org/iso/ja/principles.html