Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
よい設計のプログラムを作るには
Search
まりも
September 26, 2024
Programming
140
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
62
メンタルモデルから見るオブジェクト設計
hrmstrsmgs
0
420
技術的負債
hrmstrsmgs
1
450
歴史から理解するJavaScript
hrmstrsmgs
0
100
論理的な考え方
hrmstrsmgs
0
120
論理的な話し合いはなぜ必要か
hrmstrsmgs
0
83
腕のある技術者はなぜ
hrmstrsmgs
0
160
疑似乱数の生成
hrmstrsmgs
0
80
構造化プログラミング
hrmstrsmgs
0
230
Other Decks in Programming
See All in Programming
iOSDC Japan 2026 - Swiftで作って学ぼう!データベース自作入門
kaseken
2
420
IBM Bob Dojo #1 仕様駆動開発入門
oniak3ibm
PRO
0
320
ソニーのクラウド共通基盤の変遷とAI時代の開発スタイルに合わせた進化 / The Journey of Sony’s Common Cloud Platform and Its Evolution for AI-Native Development
kenjiyoneyama
0
200
re:Inventに行く前に知っておきたい現地参加のノウハウ
nokomoro3
0
290
巨大モノリシックアプリ モダン化大作戦
ktcryomm
1
1.2k
選挙速報を多くのユーザーへ 届ける Live Activities 設計
hamayokokuririn
0
190
モバイル交通系ICへのチャージ実例から考える、クロスプラットフォーム開発におけるiOS実機テスト設計とCI運用
yusuga
1
570
TiDB Cloudのカスタムコントローラーによるオートスケール対応
takaidohigasi
0
140
App Storeの外へ──日本のiOSサイドローディング入門 for iOSDC Japan 2026
yuukiw00w
0
280
パズルゲームの作り方 / how to make puzzle games
kaityo256
PRO
2
260
Augmenting AI with the Power of Jakarta EE
ivargrimstad
0
380
AHC070解法紹介
eijirou
0
150
Featured
See All Featured
The innovator’s Mindset - Leading Through an Era of Exponential Change - McGill University 2025
jdejongh
PRO
1
350
Side Projects
sachag
456
43k
How to Ace a Technical Interview
jacobian
280
24k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
35k
Designing for Performance
lara
611
70k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
508
140k
The Director’s Chair: Orchestrating AI for Truly Effective Learning
tmiket
1
310
Why You Should Never Use an ORM
jnunemaker
PRO
61
10k
Agile Leadership in an Agile Organization
kimpetersen
PRO
0
260
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
2.4k
ラッコキーワード サービス紹介資料
rakko
1
5.1M
Code Review Best Practice
trishagee
74
20k
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
識別子には適切な名前を付ける 辞書や類語辞典を使う 語順は正しい文法で 現在分詞や過去分詞をつかう 手を抜くな!!
推敲 門を推すというか敲くというか一晩考える。 もちろん文法は全部使えるのが当然です。 日本語の文章を推敲するのと全く同じ作業。