$30 off During Our Annual Pro Sale. View Details »
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
990
アカツキ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
140
成果発表資料.pdf
akatsukinewgrad
0
2.1k
広大なフィールドを気持ちよく駆け抜けるための技術.pdf
akatsukinewgrad
0
600
正規表現とReDoS.pdf
akatsukinewgrad
0
580
Unityで大量のオブジェクト_を吹き飛ばしたい.pdf
akatsukinewgrad
0
630
新卒2年目が思う1年目の学び.pdf
akatsukinewgrad
0
550
障害訓練の取り組みについて.pdf
akatsukinewgrad
0
720
7分でわかるアカツキゲームス
akatsukinewgrad
0
590
Bitcoinだけでスマートコントラクト.pdf
akatsukinewgrad
1
980
Featured
See All Featured
Site-Speed That Sticks
csswizardry
13
980
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
A Modern Web Designer's Workflow
chriscoyier
697
190k
The Language of Interfaces
destraynor
162
25k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
9
990
Statistics for Hackers
jakevdp
799
230k
Agile that works and the tools we love
rasmusluckow
331
21k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
359
30k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.5k
Unsuck your backbone
ammeep
671
58k
RailsConf 2023
tenderlove
30
1.3k
Bash Introduction
62gerente
615
210k
Transcript
[初心者向け]破滅的なコードを書かない ために意識したい3つのこと +α さとう/sakastudio
自己紹介 北海道情報大学3年 23卒アカツキ内定 Twitter @sakastudio_ オープンソースで工業ゲーを開発中
意識したい3つのこと + α ・一つのクラスは150行以内に収める ・循環参照はしない ・継承はしない ・テストコードを書こう
同じ内容をQiitaで書いてます こっちの方が詳しい説明があるので、興味があれば是非 そのまんまだとアレなので+αします
一つのクラスは150行以内に収める 1000行クラス、書いてないですか? ・1000行あると単純に読みづらい ・様々な関数や変数が相互作用してて処理を追いづらい ・一箇所直すと他の場所がバグるなんてことも… →そんなら行数で制限しちゃった方が楽
150行以内だと何がいい? ・単一責任の原則を割と楽に守ることができる ・単一責任の原則を守るとそのクラスのやることが明 確になり、読みやすくなる →単一責任の原則を守るようなコードを書こ う!
単一責任とはなんぞや? 単一責任の原則とは (クラスを)変更するための理由が、一つのクラスに 対して二つ以上あってはならない
単一責任とはなんぞや? ....なるほど?
単一責任とはなんぞや? つまり… 一回の仕様変更に対してクラスを変更して いいのは一回まで
単一責任とはなんぞや? 無料版はここまでです。 これ以降は記事を読んでください。 (本当は説明したいけど時間が時間なので)
循環参照はしない 循環参照をすると… •循環参照によって処理が追いづらくなる •再利用性が失われ、拡張性が失われる •特別な仕様に対応しづらくなる
よくある循環参照
何がダメか? 新たな仕様に柔軟に対応できない ・通常ステージの他に、ボーナステージを実装する必要が出 てきた ・ボーナスステージにPlayerManagerは必要ない →循環参照があるとどうなるか?
何がダメか? 破滅的なコードの温床となる
循環参照の解決方法 delgateやeventなどの言語機能を使いましょう
循環参照の解決方法 無料版はここまでです。 これ以降は記事を読んでください。 (本当は説明したいけど時間が(ry )
継承はしない •継承をすると親クラスに処理が集中する •子クラス用の処理やバグ回避処理が親クラスにでき親 クラスの複雑度が増す
継承はしない 継承がダメな理由として、ミノ駆動さんの動画は 非常にわかりやすいです
継承の解決方法 ・継承ではなく合成を使う ・処理を別クラスに記述し、そのクラスに処理を転送
継承の解決方法 無料版はここまでです。 これ以降は記事を読んでください。 (本当は説明(ry )
テストコードを書こう というかTDDをしよう
テストコードを書きTDDをすると •必然的にユニットテストを書きやすい設計≒良い設計 ができ るようになる •バグの早期発見、早期修正ができる •テストは基本ずっと使えるのでデグレを減らせる •モジュールの品質を高めることができる •自分が書いたコードに対して自信を持てる
TDDの良くないところ •変更に時間がかかる •コードを書く量が大体2倍になる •クライアント側のテストは意外と大変