Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
DRY原則を誤った結果生まれた技術的負債
Search
Tech Leverages
June 30, 2023
Technology
0
6.5k
DRY原則を誤った結果生まれた技術的負債
DRY原則を誤った結果生まれた技術的負債
Tech Leverages
June 30, 2023
Tweet
Share
More Decks by Tech Leverages
See All by Tech Leverages
ハッカソンから社内プロダクトへ AIエージェント ko☆shi 開発で学んだ4つの重要要素
leveragestech
0
130
2025年のデザインシステムとAI 活用を振り返る
leveragestech
0
200
ディメンショナルモデリングを採用してない組織がモデリング本を通じて得られたこと
leveragestech
0
200
レバレジーズのLangfuse活用事例
leveragestech
0
140
CloudComposerによる大規模ETL 「制御と実行の分離」の実践
leveragestech
0
470
「ELT職人」から卒業!Fivetranでデータパイプラインの構築・運用から解放され、 本来の価値創造に集中できる ようになった事例
leveragestech
0
140
SpecKitでどこまでできる? コストはどれくらい?
leveragestech
2
3.8k
未来を拓くAI技術〜エージェント開発とAI駆動開発〜
leveragestech
2
290
コンテキストエンジニアリングで変わるAI活用 リファクタリングワークフローの実践から学んだ形式知
leveragestech
0
180
Other Decks in Technology
See All in Technology
普段使ってるClaude Skillsの紹介(by Notebooklm)
zerebom
8
2.1k
Lookerで実現するセキュアな外部データ提供
zozotech
PRO
0
200
Introduce marp-ai-slide-generator
itarutomy
0
110
Knowledge Work の AI Backend
kworkdev
PRO
0
230
JEDAI認定プログラム JEDAI Order 2026 エントリーのご案内 / JEDAI Order 2026 Entry
databricksjapan
0
180
AgentCore BrowserとClaude Codeスキルを活用した 『初手AI』を実現する業務自動化AIエージェント基盤
ruzia
7
1.4k
事業の財務責任に向き合うリクルートデータプラットフォームのFinOps
recruitengineers
PRO
2
200
202512_AIoT.pdf
iotcomjpadmin
0
140
Claude Codeを使った情報整理術
knishioka
6
3.8k
2025-12-27 Claude CodeでPRレビュー対応を効率化する@機械学習社会実装勉強会第54回
nakamasato
3
650
Oracle Database@Azure:サービス概要のご紹介
oracle4engineer
PRO
2
200
Bedrock AgentCore Evaluationsで学ぶLLM as a judge入門
shichijoyuhi
2
240
Featured
See All Featured
Digital Ethics as a Driver of Design Innovation
axbom
PRO
0
130
BBQ
matthewcrist
89
9.9k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
7.9k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
54k
Exploring anti-patterns in Rails
aemeredith
2
200
Keith and Marios Guide to Fast Websites
keithpitt
413
23k
Git: the NoSQL Database
bkeepers
PRO
432
66k
Bioeconomy Workshop: Dr. Julius Ecuru, Opportunities for a Bioeconomy in West Africa
akademiya2063
PRO
0
31
Raft: Consensus for Rubyists
vanstee
141
7.3k
The SEO Collaboration Effect
kristinabergwall1
0
310
How to make the Groovebox
asonas
2
1.8k
sira's awesome portfolio website redesign presentation
elsirapls
0
89
Transcript
DRY原則を誤った結果 生まれた技術的負債
TL;DR DRYかどうかの前に単一責務かどうか考えて
これは本当にあった怖い話です
teratailにはこんなコンポーネントが存在します
teratailにはこんなコンポーネントが存在します 違い、分かりますか?
<a>タグ <button>タグ
HTMLタグの種類が違うだけなのに 同じスタイルを都度定義するの、面倒だな ...
そうだ!propsにhrefがあるかどうかで 出し分けるように実装しよう! DRY原則の適用だ!
None
None
最初はこれでも問題なかった 最初だけね...
- 内部コンポーネントを制御するためのPropsが際限なく追加される - 内部で利用しているコンポーネントの機能を制御する必要が出てきた - 制御変数が多くなりすぎて内部実装が複雑になる - 他のライブラリ(ReactHookForm等)との組み込みがしづらくなる - 誰も手をつけられない神ボタンコンポーネントの☆完☆成☆
生まれた問題点
None
結局何がいけなかったの? - DRY(Don’t Repeat Yourself) 原則の適用を間違えた - 似て非なるものを同一視してしまった - SRP(Single
Responsibility Principle)に違反した
どうすればよかったの? - 各コンポーネントを責務という観点で独立させる - <a>タグはHTMLにおいて他のリソースへの参照を示す - <button>は文書上のフォームのコントロールや単純なボタンとしての機 能を提供する
TL;DR DRYかどうかの前に単一責務かどうか考えて