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
hiro_shi
September 22, 2024
1
14
勘所を押さえて良いコードを書く
hiro_shi
September 22, 2024
Tweet
Share
Featured
See All Featured
Rebuilding a faster, lazier Slack
samanthasiow
79
8.7k
Automating Front-end Workflow
addyosmani
1366
200k
The Invisible Side of Design
smashingmag
298
50k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Designing on Purpose - Digital PM Summit 2013
jponch
115
7k
Designing for humans not robots
tammielis
250
25k
Agile that works and the tools we love
rasmusluckow
327
21k
The Art of Programming - Codeland 2020
erikaheidi
52
13k
Fashionably flexible responsive web design (full day workshop)
malarkey
405
65k
Optimising Largest Contentful Paint
csswizardry
33
2.9k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
10
720
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
93
16k
Transcript
勘所を押さえて良いコードを書く 2024-09-21 #GENKI.dev ヒロ氏
自己紹介
お話すること • オブジェクト指向ベースの話 • 読みやすさというより設計ベースの話 • 0 -> 1よりも1 ->
10寄りの話 • バックエンド寄りの話 • PHPベースでお話する
https://gihyo.jp/book/2022/978-4-297-12783-1 https://www.shoeisha.co.jp/book/detail/9784798150727
良いコードってなんやろか
読みやすい? 理解しやすい? それもあるが
プロダクトは作って終わりではない • 改修することがある • 運用もある • 新しく人も入ってくるしコードは読むし書くし
プロダクトは作って終わりではない • 改修することがある • 運用もある • 新しく人も入ってくるしコードは読むし書くし 変更に強い設計であったほうが、 多くのコストを支払わずにスケールすることができる
変更に弱いあるある • 影響範囲わからん。一箇所変更したら他がこわれた。 • 改修前の調査が大変 • 想定していたより時間がかかる • などなど
良いコードって 変更に強いということ (もちろん他にも定義はあると思っていて) (例えば認知負荷が低いとか)
変更に強い設計の勘所 責務 凝集度 単一責任原則 疎結合 目的 etc…
変更に強い設計の勘所 責務 凝集度 単一責任原則 疎結合 目的 etc…
凝集度 ~common.php~
凝集度 ~common.php~
凝集度 ~common.php~ • Commonという名のもとに なんでもかんでも放り込まれてしまう • ~~Managerとかも然り • 本来クラスはデータとロジックの 関連性が高ければ変更に強い
• なので関連するデータとロジックは クラス単位でまとめるべきである • データアクセスはインスタンス変数を使 う(凝集度を高める意味で)
凝集度 ~世直し(本来であればファイルも分ける)~
凝集度 ~世直し(本来であればファイルも分ける)~ • コード全体の見渡しがよくなる • データとロジックが関連することで 車輪の再発明のリスクも減らせる 番外編 • 本当は条件式も変数やインスタンスの
状態を見ないようにすべき • booleanを返す判定用のメソッドをつくる のが好ましい • 「尋ねるな、命じろ」
凝集度 ~世直し(本来であればファイルも分ける)~ • コード全体の見渡しがよくなる • データとロジックが関連することで 車輪の再発明のリスクも減らせる 番外編 • 本当は条件式も変数やインスタンスの
状態を見ないようにすべき • booleanを返す判定用のメソッドをつくる のが好ましい • 「尋ねるな、命じろ」
ソフトウェアにおける責務とは 「ある関心事について、正常に動作するよう制御する責任」 ソフトウェアはいろんな関心事を扱う DB操作、ドメインに対する操作、アプリケーションサービス、 UI層、、、、山程あるな。 で、今回はアプリケーションの設計の話なので。 責務について
• クラスは単一の責任を持つという考え方 • クラスに多くの責任がのしかかると、 それだけでバグのリスクを負う。 ◦ 変更に弱い ◦ 再利用性の低下 ◦
テストカバレッジの低下 • なのでクラスは一つの責任・機能に集中すべき 単一責任原則を結局話す
単一責任原則を結局話す
単一責任原則を結局話す
番外編
コメントアウト
https://twitter.com/t_wada/status/904916106153828352 コメントアウト
おこなっている処理よりも なぜそうしたか?の文脈がわかるほうが改修コストがかからない 例) // 浮動小数点をフロントに返したら表示がバグるので、 // 丸め処理をしている コメントアウト
Early Return
Early Return
ありがとうございました