Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
アカツキLT_2022_02_24..pdf
akatsukinewgrad
May 19, 2022
0
290
アカツキLT_2022_02_24..pdf
akatsukinewgrad
May 19, 2022
Tweet
Share
More Decks by akatsukinewgrad
See All by akatsukinewgrad
Bitcoinだけでスマートコントラクト.pdf
akatsukinewgrad
0
220
齋田.pdf
akatsukinewgrad
0
290
_美馬さん_入門_ビット演算.pdf
akatsukinewgrad
0
290
_Gunso_AktskGeekLive_LT会資料_20220224_スライド用.pptx.pdf
akatsukinewgrad
0
290
2月下旬開催_エンジニア職LT会_なかひこくん_.pdf
akatsukinewgrad
0
290
GeekLive_長期運用_安定リリースのための自動実機テスト__1_.pptx.pdf
akatsukinewgrad
0
300
WebExtensions の力で_不満を解消したい!_Google Cloud編
akatsukinewgrad
0
450
インターンでハチナイのAPIを高速化しました!
akatsukinewgrad
0
440
Railsのrenderをちょっと速くしました
akatsukinewgrad
0
440
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
85
3.9k
GraphQLとの向き合い方2022年版
quramy
16
8.2k
A designer walks into a library…
pauljervisheath
196
16k
Pencils Down: Stop Designing & Start Developing
hursman
112
9.8k
Building Applications with DynamoDB
mza
83
4.7k
Thoughts on Productivity
jonyablonski
43
2.3k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
349
27k
Design by the Numbers
sachag
271
17k
Learning to Love Humans: Emotional Interface Design
aarron
261
37k
What's new in Ruby 2.0
geeforr
336
30k
What's in a price? How to price your products and services
michaelherold
229
9.4k
No one is an island. Learnings from fostering a developers community.
thoeni
9
1.1k
Transcript
[初心者向け]破滅的なコードを書かない ために意識したい3つのこと +α さとう/sakastudio
自己紹介 北海道情報大学3年 23卒アカツキ内定 Twitter @sakastudio_ オープンソースで工業ゲーを開発中
意識したい3つのこと + α ・一つのクラスは150行以内に収める ・循環参照はしない ・継承はしない ・テストコードを書こう
同じ内容をQiitaで書いてます こっちの方が詳しい説明があるので、興味があれば是非 そのまんまだとアレなので+αします
一つのクラスは150行以内に収める 1000行クラス、書いてないですか? ・1000行あると単純に読みづらい ・様々な関数や変数が相互作用してて処理を追いづらい ・一箇所直すと他の場所がバグるなんてことも… →そんなら行数で制限しちゃった方が楽
150行以内だと何がいい? ・単一責任の原則を割と楽に守ることができる ・単一責任の原則を守るとそのクラスのやることが明 確になり、読みやすくなる →単一責任の原則を守るようなコードを書こ う!
単一責任とはなんぞや? 単一責任の原則とは (クラスを)変更するための理由が、一つのクラスに 対して二つ以上あってはならない
単一責任とはなんぞや? ....なるほど?
単一責任とはなんぞや? つまり… 一回の仕様変更に対してクラスを変更して いいのは一回まで
単一責任とはなんぞや? 無料版はここまでです。 これ以降は記事を読んでください。 (本当は説明したいけど時間が時間なので)
循環参照はしない 循環参照をすると… •循環参照によって処理が追いづらくなる •再利用性が失われ、拡張性が失われる •特別な仕様に対応しづらくなる
よくある循環参照
何がダメか? 新たな仕様に柔軟に対応できない ・通常ステージの他に、ボーナステージを実装する必要が出 てきた ・ボーナスステージにPlayerManagerは必要ない →循環参照があるとどうなるか?
何がダメか? 破滅的なコードの温床となる
循環参照の解決方法 delgateやeventなどの言語機能を使いましょう
循環参照の解決方法 無料版はここまでです。 これ以降は記事を読んでください。 (本当は説明したいけど時間が(ry )
継承はしない •継承をすると親クラスに処理が集中する •子クラス用の処理やバグ回避処理が親クラスにでき親 クラスの複雑度が増す
継承はしない 継承がダメな理由として、ミノ駆動さんの動画は 非常にわかりやすいです
継承の解決方法 ・継承ではなく合成を使う ・処理を別クラスに記述し、そのクラスに処理を転送
継承の解決方法 無料版はここまでです。 これ以降は記事を読んでください。 (本当は説明(ry )
テストコードを書こう というかTDDをしよう
テストコードを書きTDDをすると •必然的にユニットテストを書きやすい設計≒良い設計 ができ るようになる •バグの早期発見、早期修正ができる •テストは基本ずっと使えるのでデグレを減らせる •モジュールの品質を高めることができる •自分が書いたコードに対して自信を持てる
TDDの良くないところ •変更に時間がかかる •コードを書く量が大体2倍になる •クライアント側のテストは意外と大変