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
270
DB Tree Algorithms
yunosukey
0
88
Tests in Go
yunosukey
1
100
圏論とコンピュータサイエンス / Category Theory and Theoretical Computer Science
yunosukey
0
240
Other Decks in Programming
See All in Programming
PHPUnitしか使ってこなかった 一般PHPerがPestに乗り換えた実録
mashirou1234
0
410
php-conference-japan-2024
tasuku43
0
420
令和7年版 あなたが使ってよいフロントエンド機能とは
mugi_uno
7
3.5k
DevFest - Serverless 101 with Google Cloud Functions
tunmise
0
140
KMP와 kotlinx.rpc로 서버와 클라이언트 동기화
kwakeuijin
0
290
KubeCon NA 2024の全DB関連セッションを紹介
nnaka2992
0
110
Stackless и stackful? Корутины и асинхронность в Go
lamodatech
0
1.3k
Jaspr Dart Web Framework 박제창 @Devfest 2024
itsmedreamwalker
0
140
HTML/CSS超絶浅い説明
yuki0329
0
180
rails newと同時に型を書く
aki19035vc
5
690
Fibonacci Function Gallery - Part 2
philipschwarz
PRO
0
210
EC2からECSへ 念願のコンテナ移行と巨大レガシーPHPアプリケーションの再構築
sumiyae
3
560
Featured
See All Featured
The Power of CSS Pseudo Elements
geoffreycrofte
74
5.4k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Java REST API Framework Comparison - PWX 2021
mraible
28
8.3k
Optimising Largest Contentful Paint
csswizardry
33
3k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Building Flexible Design Systems
yeseniaperezcruz
328
38k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Practical Orchestrator
shlominoach
186
10k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
950
GitHub's CSS Performance
jonrohan
1030
460k
How GitHub (no longer) Works
holman
312
140k
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