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
140
なぜコードを書いてはいけないか
takato fukui
May 23, 2024
Tweet
Share
More Decks by takato fukui
See All by takato fukui
関数の挙動書き換える
takatofukui
4
820
機関室の灯りは消えない
takatofukui
0
38
エンジニアリングの良い塩梅🧂🌸
takatofukui
0
59
dd-trace-goのtrace context propagation実装
takatofukui
0
500
ソフトウェアテスト
takatofukui
0
82
リファクタリング
takatofukui
0
140
本番分析データベースを丸ごと削除した人の顔
takatofukui
0
120
Other Decks in Programming
See All in Programming
メタプログラミングで実現する「コードを仕様にする」仕組み/nikkei-tech-talk43
nikkei_engineer_recruiting
0
160
守る「だけ」の優しいEMを抜けて、 事業とチームを両方見る視点を身につけた話
maroon8021
3
380
AI時代のソフトウェア開発でも「人が仕様を書く」から始めよう-医療IT現場での実践とこれから
koukimiura
0
140
今、アーキテクトとして 品質保証にどう関わるか
nealle
0
200
AI時代でも変わらない技術コミュニティの力~10年続く“ゆるい”つながりが生み出す価値
n_takehata
2
660
猫の手も借りたい!ので AIエージェント猫を作って社内に放した話 Claude Code × Container Lambda の Slack Bot "DevNeko"
naramomi7
0
250
CSC307 Lecture 12
javiergs
PRO
0
460
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
290
株式会社 Sun terras カンパニーデック
sunterras
0
2k
NOT A HOTEL - 建築や人と融合し、自由を創り出すソフトウェア
not_a_hokuts
2
590
Docコメントで始める簡単ガードレール
keisukeikeda
1
100
grapheme_strrev関数が採択されました(あと雑感)
youkidearitai
PRO
1
210
Featured
See All Featured
How to Talk to Developers About Accessibility
jct
2
150
brightonSEO & MeasureFest 2025 - Christian Goodrich - Winning strategies for Black Friday CRO & PPC
cargoodrich
3
120
Reality Check: Gamification 10 Years Later
codingconduct
0
2k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
2.8k
SEO for Brand Visibility & Recognition
aleyda
0
4.3k
We Have a Design System, Now What?
morganepeng
55
8k
The untapped power of vector embeddings
frankvandijk
2
1.6k
AI Search: Implications for SEO and How to Move Forward - #ShenzhenSEOConference
aleyda
1
1.1k
A Tale of Four Properties
chriscoyier
163
24k
Facilitating Awesome Meetings
lara
57
6.8k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.6k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
35k
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