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
150
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
なぜコードを書いてはいけないか
takato fukui
May 23, 2024
More Decks by takato fukui
See All by takato fukui
関数の挙動書き換える
takatofukui
4
880
機関室の灯りは消えない
takatofukui
0
47
エンジニアリングの良い塩梅🧂🌸
takatofukui
0
77
dd-trace-goのtrace context propagation実装
takatofukui
0
570
ソフトウェアテスト
takatofukui
0
91
リファクタリング
takatofukui
0
150
本番分析データベースを丸ごと削除した人の顔
takatofukui
0
130
Other Decks in Programming
See All in Programming
AIを活用したE2Eテスト実装効率化のあゆみ / ebisu-mobile-14-kotetu
kotetuco
0
170
Hatena Engineer Seminar #37「言語モデルの活用に関する研究」
slashnephy
0
510
Welcome to the "Parametricity" 🏙️ − Generic だけど Specific な世界 −
guvalif
PRO
1
150
「なぜそう決めたのか」を残し続ける仕組み ― Notion AI カスタムエージェント × Slack連携による設計判断の自動記録 - NIKKEI Tech Talk #47
niftycorp
PRO
0
260
AI時代の仕事技芸論〜ソフトウェア開発で「遊ぶように働く」職人的熟達のすすめ(スクフェス仙台 2026バージョン)
kuranuki
0
600
SLOをサービス品質の共通言語にするために 取り組んできたこと
wakana0222
0
480
コンテキストの使い捨てをやめる — ビジネスルール駆動開発と miko —
ioki
0
270
SREの積み重ねがAI駆動開発のガードレールになった ― 7つの実践/SRE Guardrails The 7
tomoyakitaura
8
3.9k
分散システム、なんですぐ死んでしまうん?耐障害性を高めたいあなたのためのレジリエンスパターン入門
mshibuya
7
5.7k
ローカルLLMでどこまでコードが書けるか -拡張版 / How much code can be written on a local LLM Extended
kishida
12
4.7k
過去最大のMCPアップデート! 2026-07-28 RC版の謎に迫る
licux
6
460
「正の参照」と 「負の導出」で組む ハーネスエンジニアリング
cottpan
1
140
Featured
See All Featured
4 Signs Your Business is Dying
shpigford
187
22k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
880
The agentic SEO stack - context over prompts
schlessera
0
840
The Power of CSS Pseudo Elements
geoffreycrofte
82
6.3k
Redefining SEO in the New Era of Traffic Generation
szymonslowik
1
360
How to audit for AI Accessibility on your Front & Back End
davetheseo
0
460
What Being in a Rock Band Can Teach Us About Real World SEO
427marketing
0
1k
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
610
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
Scaling GitHub
holman
464
140k
Test your architecture with Archunit
thirion
1
2.3k
The untapped power of vector embeddings
frankvandijk
2
1.8k
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