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
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
まりも
September 26, 2024
Programming
120
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
よい設計のプログラムを作るには
アジャイルが当然の時代になり、プログラムの作り方も変わってきています。昔と変わったところもあり、それでいて共通するところもあります。その変化について解説してみました。
まりも
September 26, 2024
More Decks by まりも
See All by まりも
オブジェクトモデルと関係モデルの設計
hrmstrsmgs
0
43
メンタルモデルから見るオブジェクト設計
hrmstrsmgs
0
360
技術的負債
hrmstrsmgs
1
370
歴史から理解するJavaScript
hrmstrsmgs
0
96
論理的な考え方
hrmstrsmgs
0
110
論理的な話し合いはなぜ必要か
hrmstrsmgs
0
69
腕のある技術者はなぜ
hrmstrsmgs
0
140
疑似乱数の生成
hrmstrsmgs
0
68
構造化プログラミング
hrmstrsmgs
0
210
Other Decks in Programming
See All in Programming
【やさしく解説 設計編 #0】DDDのコード、読めるのに分からない人へ
panda728
PRO
1
230
Observability in Practice:Grafana 與 Edge Device SRE 的那些事
blueswen
0
190
吝嗇家のためのAI活用 / AI development for miser - ChatGPT + Issue Driven Development
tooppoo
0
180
OSINT for SRE: 学術論文とポストモーテムから探る システム障害の共通パターン / SRE NEXT 2026
tomoyk
1
2.4k
Snowflake Summitでの新機能 CoCo / CoWork / snowflake-summit-2026-overall-what-new-coco
tatsuhiro
1
220
その問い、本当に正しいですか?AI時代のエンジニアに必要な哲学と認知科学 / ai-philosophy-cognitive-science
minodriven
14
6.7k
LaravelLive Japan の裏方のすべて — 第188回 PHP勉強会@東京 (2026-06-24)
suguruooki
2
150
Hatena Engineer Seminar #37「言語モデルの活用に関する研究」
slashnephy
0
500
Generative UI & AI-Assistants for Your Angular Solutions
manfredsteyer
PRO
0
140
壊れたパーサから始める関数型設計と構成的なパーサ #fp_matsuri
raiga0310
2
170
TypeScript+Orvalで実現する型安全かつ堅牢でスケーラブルなマルチチャネル通知基盤 / TSKaigi Night talks ~after conference~
d0riven
0
390
AI駆動開発を妨げる技術的負債の解消アプローチ / ai-refactoring-approach
minodriven
17
8.7k
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Evolving SEO for Evolving Search Engines
ryanjones
0
240
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.8k
How Software Deployment tools have changed in the past 20 years
geshan
0
34k
Measuring Dark Social's Impact On Conversion and Attribution
stephenakadiri
2
230
職位にかかわらず全員がリーダーシップを発揮するチーム作り / Building a team where everyone can demonstrate leadership regardless of position
madoxten
63
55k
How to optimise 3,500 product descriptions for ecommerce in one day using ChatGPT
katarinadahlin
PRO
1
3.7k
The AI Revolution Will Not Be Monopolized: How open-source beats economies of scale, even for LLMs
inesmontani
PRO
3
3.5k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.3k
The Mindset for Success: Future Career Progression
greggifford
PRO
0
410
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
The Spectacular Lies of Maps
axbom
PRO
1
850
Transcript
良い設計のプログラムを作 るには アジャイル時代に必要とされる設計
アジャイルの時代
アジャイル時代に必要とされる設計 目指すところはそんなに変 わらないですけどね。
アジャイル時代に必要とされる設計 ただ途中経過は結構違っ ているかもしれない。
アジャイルでプログラムはどう変わったか 少々の手戻りはどんとこい 変更はいつでも修正できる
アジャイルでプログラムはどう変わったか そもそも理想的な設計は 一つに決まらない
アジャイルでプログラムはどう変わったか 機能が変更されれば最適な設計も変わる
アジャイルでプログラムはどう変わったか テスト駆動開発では、内部 設計はリファクタリング時 に行う。 常にゴールが変 わる中で、常に 最適を保つ。
設計方針
DRY DRY Don't repeat yourself 絶対に二度書かない
DRY 本当に同じこ とは絶対に二 度書くな! 別に2回書く のが面倒だか らじゃないか ら。 影響範囲調べ る必要がない
コートにする。
DRY 厳密に絶対かと言えばさすがにそうじゃないけど。 たまたま同じ書き方になっているだけで違う意味の場合。 どう工夫してもその言語では絶対共通化できない場合。 無理やり共通化したほうが明らかに読みにくくなっている場合。
YAGNI YAGNI You ain't gonna need it いずれ必要にならない
YAGNI 必要にならなくても存在する以上は必ずコストがかかる。 必要になった時に当初想像していた仕様で問題ないことは少ない。 後で追加がよほど面倒な時はさすがに話が別だが。
オブジェクト指向設計 昔からの「正しい設 計」に近づけていく
抽象化 人間に対してプログラムを書く char*ではなく string型を使う “YYYYMMDD”では なくDate型を使う
識別子には適切な名前を付ける 解読しやすい 読めば分かるので解読する必要もない numberOfPeopleOnTheUSOlympicTeam maximumNumberOfPointsInModernOlympics checkTotal currentDate linesPerPage
識別子には適切な名前を付ける 辞書や類語辞典を使う 語順は正しい文法で 現在分詞や過去分詞をつかう 手を抜くな!!
推敲 門を推すというか敲くというか一晩考える。 もちろん文法は全部使えるのが当然です。 日本語の文章を推敲するのと全く同じ作業。