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
アカツキLT_2022_02_24..pdf
Search
akatsukinewgrad
May 19, 2022
0
800
アカツキLT_2022_02_24..pdf
akatsukinewgrad
May 19, 2022
Tweet
Share
More Decks by akatsukinewgrad
See All by akatsukinewgrad
2023/1/25_QAテスター meet up!
akatsukinewgrad
0
110
成果発表資料.pdf
akatsukinewgrad
0
1.9k
広大なフィールドを気持ちよく駆け抜けるための技術.pdf
akatsukinewgrad
0
480
正規表現とReDoS.pdf
akatsukinewgrad
0
470
Unityで大量のオブジェクト_を吹き飛ばしたい.pdf
akatsukinewgrad
0
500
新卒2年目が思う1年目の学び.pdf
akatsukinewgrad
0
450
障害訓練の取り組みについて.pdf
akatsukinewgrad
0
580
7分でわかるアカツキゲームス
akatsukinewgrad
0
490
Bitcoinだけでスマートコントラクト.pdf
akatsukinewgrad
1
760
Featured
See All Featured
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
28
4.4k
Fashionably flexible responsive web design (full day workshop)
malarkey
405
66k
Speed Design
sergeychernyshev
25
670
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
169
50k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
GitHub's CSS Performance
jonrohan
1030
460k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
10
810
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
111
49k
Imperfection Machines: The Place of Print at Facebook
scottboms
266
13k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
Scaling GitHub
holman
458
140k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Transcript
[初心者向け]破滅的なコードを書かない ために意識したい3つのこと +α さとう/sakastudio
自己紹介 北海道情報大学3年 23卒アカツキ内定 Twitter @sakastudio_ オープンソースで工業ゲーを開発中
意識したい3つのこと + α ・一つのクラスは150行以内に収める ・循環参照はしない ・継承はしない ・テストコードを書こう
同じ内容をQiitaで書いてます こっちの方が詳しい説明があるので、興味があれば是非 そのまんまだとアレなので+αします
一つのクラスは150行以内に収める 1000行クラス、書いてないですか? ・1000行あると単純に読みづらい ・様々な関数や変数が相互作用してて処理を追いづらい ・一箇所直すと他の場所がバグるなんてことも… →そんなら行数で制限しちゃった方が楽
150行以内だと何がいい? ・単一責任の原則を割と楽に守ることができる ・単一責任の原則を守るとそのクラスのやることが明 確になり、読みやすくなる →単一責任の原則を守るようなコードを書こ う!
単一責任とはなんぞや? 単一責任の原則とは (クラスを)変更するための理由が、一つのクラスに 対して二つ以上あってはならない
単一責任とはなんぞや? ....なるほど?
単一責任とはなんぞや? つまり… 一回の仕様変更に対してクラスを変更して いいのは一回まで
単一責任とはなんぞや? 無料版はここまでです。 これ以降は記事を読んでください。 (本当は説明したいけど時間が時間なので)
循環参照はしない 循環参照をすると… •循環参照によって処理が追いづらくなる •再利用性が失われ、拡張性が失われる •特別な仕様に対応しづらくなる
よくある循環参照
何がダメか? 新たな仕様に柔軟に対応できない ・通常ステージの他に、ボーナステージを実装する必要が出 てきた ・ボーナスステージにPlayerManagerは必要ない →循環参照があるとどうなるか?
何がダメか? 破滅的なコードの温床となる
循環参照の解決方法 delgateやeventなどの言語機能を使いましょう
循環参照の解決方法 無料版はここまでです。 これ以降は記事を読んでください。 (本当は説明したいけど時間が(ry )
継承はしない •継承をすると親クラスに処理が集中する •子クラス用の処理やバグ回避処理が親クラスにでき親 クラスの複雑度が増す
継承はしない 継承がダメな理由として、ミノ駆動さんの動画は 非常にわかりやすいです
継承の解決方法 ・継承ではなく合成を使う ・処理を別クラスに記述し、そのクラスに処理を転送
継承の解決方法 無料版はここまでです。 これ以降は記事を読んでください。 (本当は説明(ry )
テストコードを書こう というかTDDをしよう
テストコードを書きTDDをすると •必然的にユニットテストを書きやすい設計≒良い設計 ができ るようになる •バグの早期発見、早期修正ができる •テストは基本ずっと使えるのでデグレを減らせる •モジュールの品質を高めることができる •自分が書いたコードに対して自信を持てる
TDDの良くないところ •変更に時間がかかる •コードを書く量が大体2倍になる •クライアント側のテストは意外と大変