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
Bugless Code
Search
Yunosuke Yamada
October 16, 2022
Programming
0
120
Bugless Code
Yunosuke Yamada
October 16, 2022
Tweet
Share
More Decks by Yunosuke Yamada
See All by Yunosuke Yamada
ChatGPTのアルゴリズム
yunosukey
0
350
React and XSS
yunosukey
0
280
DB Tree Algorithms
yunosukey
0
89
Tests in Go
yunosukey
1
100
圏論とコンピュータサイエンス / Category Theory and Theoretical Computer Science
yunosukey
0
250
Other Decks in Programming
See All in Programming
Formの複雑さに立ち向かう
bmthd
1
940
楽しく向き合う例外対応
okutsu
0
700
SwiftUI移行のためのインプレッショントラッキング基盤の構築
kokihirokawa
0
150
「個人開発マネタイズ大全」が教えてくれたこと
bani24884
1
240
新宿駅構内を三人称視点で探索してみる
satoshi7190
2
120
生成AIで加速するテスト実装 - ロリポップ for Gamersの事例と 生成AIエディタの活用
kinosuke01
0
130
Learning Kotlin with detekt
inouehi
1
140
Unity Android XR入門
sakutama_11
0
180
XStateを用いた堅牢なReact Components設計~複雑なClient Stateをシンプルに~ @React Tokyo ミートアップ #2
kfurusho
1
990
CloudNativePGを布教したい
nnaka2992
0
120
コードを読んで理解するko build
bells17
1
110
データベースのオペレーターであるCloudNativePGがStatefulSetを使わない理由に迫る
nnaka2992
0
240
Featured
See All Featured
Building Applications with DynamoDB
mza
93
6.2k
Code Review Best Practice
trishagee
67
18k
Scaling GitHub
holman
459
140k
The World Runs on Bad Software
bkeepers
PRO
67
11k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
430
Documentation Writing (for coders)
carmenintech
67
4.6k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
4
380
How to Think Like a Performance Engineer
csswizardry
22
1.4k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Typedesign – Prime Four
hannesfritz
40
2.5k
Transcript
バグを生みにくい実装 2022/09/16 山田悠之介
目次 1. バグを未然に防ぐ 2. 読みやすいコードを書く 2
1. バグを未然に防ぐ 3
バグには種類がある バグはその発生原因によって分類ができます。 『組込みソフトウェア開発における品質向上の勧め バグ管理手法編』 は IPA による組込みソフトウェアについての文献ですが、 Web アプリケーションにも共通する部分が多いです。 この文献には「バグの区分」があります。
今回は実装について触れます。 4
バグの区分(実装区分の一部) ロジックの誤り 条件の誤り、演算の誤り、など インターフェースの誤り non null な引数に null を渡す、呼び出す関数を間違える、など タイミングの誤り
処理を書く場所が違う エラーチェックの誤り エラーチェックをしない、後処理が適切でない 機能の欠如 仕様と実装が異なる 5
バグの区分(実装区分の一部) 防ぎやすいものと防ぎづらいものがあります 機能の欠如 実装者が既存仕様や既存実装、新規仕様を正確に理解する タイミングの誤り 理解した処理の流れを正確にコードに落とし込む これらを防ぐのは属人的で、比較的難しいです。 インターフェースの誤り 例えば関数の型を厳密に付けることで、 自分やその関数を利用する他の実装者もバグを防げます。
6
型について any は論外です ライブラリの型が any を含む場合そのまま使わない string は改善の余地があります 日付 →
Date URL → URL 種類が有限 → Literal types 種類は有限ではないが規則がある → Template literal types number も同様です 7
「エラーチェックの誤り」 JavaScript の例外は非検査例外なので例外処理を忘れがちです。 例外を投げるのはやめましょう。 以下のようにすることでエラーチェックを強制できます。 type Data = | {
value: Value; error: undefined; } | { value: undefined; error: Error; }; 8
「ロジックの誤り」 簡単に防げるものもあります。 == , != ではなく === , !== を使う
isNaN() ではなく Number.isNaN() を使う if 文の {} を省略しない デフォルトパラメータを使う x ?? y のような処理を何回も書くのは良くない 返り値の型を書く コンポーネントは JSX スタイルで使う 9
正規表現を避ける 正規表現は強力ですが問題も多いです。 正しいか分かりづらい パフォーマンスが悪くなることがある 別の方法がある場合は避けたほうが良いです。 数値形式の場合 isNaN() を使えないか 日付形式の場合は Date
、 URL 形式は URL のコンストラクタでパースする startsWith , includes , endsWith などで代用できないか 10
Falsy に注意する 特に "" に注意が必要です。 新フォーム定義では Falsy な値によるバグがいくつか出ました。 if(str) ではなく
if(str !== undefined) や if(str !== "") ではないか考え直しましょう。 number の場合も NaN はダメだが 0 は OK か、など考えましょう。 11
2. 読みやすいコードを書く 12
どんなに気をつけてもバグは生まれる 1 人でどんなに気をつけてもバグる時はバグります。 もし、あなたのコードがバグっていたとしても読みやすいコード、 読みやすい PR ならレビューで発覚する可能性があります。 もし、発覚せずにマージされたとしても読みやすければ将来調査、 修正がしやすいです。 もし、バグっていなかったとしても、今後何回も読まれます。
読みやすければ将来の自分や他の開発者の生産性を上げます。 (逆にそうでない場合、他人の生産性を下げることになります) 13
読みやすいコードを書く 読みやすい名前を付ける 例えば id は分かりづらい コメントを書く オプショナル引数はどういう時に必要なのか 処理の場合、なぜそうしたのか、 逆になぜ別の方法にしなかったのか書く 関数を分ける
一度に 1 つのことをする pure な関数はテストしやすい 14
読みやすいコードを書く 読みやすいテストを書く テストは振る舞いの説明です コミットを分ける 一度に 1 つのことをする これらの多くは『リーダブルコード』にも書かれています。 15
無駄な処理をしない 不必要な処理をしていると、それを読んだ人は 「もっと簡単な方法があるのになぜそうしないのだろう」 と考えてしまいます。 必要十分な処理を書きましょう。 三項演算子を減らす 返り値を使わない場合 map ではなく forEach
useState , useEffect を減らす state と effect は React のライフサイクルで特別なもの 16
ネストしない ネストしたコードは読みづらいです。 early return する 必要なら関数に切り出す 三項演算子を使わない if 文のネストのほうがマシです コールバックを使わない
then ではなく async , await を使いましょう 17
正解はない 読みやすいコードを書くためのポイントは限りがないです。 どのようなコードが読みやすいか、 どうしたら自分のコードが分かりやすくなるか 考える続ける必要があります。 例えば PR を出す前にもっと良いやり方がないか何回も (1 回ではない)考えましょう。
18
参考 『組込みソフトウェア開発における品質向上の勧め バグ管理手法編』 https://www.ipa.go.jp/sec/publish/tn12-005.html 『リーダブルコード』 『Airbnb JavaScript Style Guide』 https://github.com/airbnb/javascript
19