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
フロントエンドオブザーバビリティ on Google Cloud
yunosukey
0
160
ChatGPTのアルゴリズム
yunosukey
0
360
React and XSS
yunosukey
0
280
DB Tree Algorithms
yunosukey
0
93
Tests in Go
yunosukey
1
110
圏論とコンピュータサイエンス / Category Theory and Theoretical Computer Science
yunosukey
0
260
Other Decks in Programming
See All in Programming
AI時代のプログラミング教育 / programming education in ai era
kishida
22
20k
OUPC2024 Day 1 解説
kowerkoint
0
390
技術好きなエンジニアが "リーダーへの進化" によって得たものと失ったもの
pospome
5
1.3k
Develop Faster With FrankenPHP
dunglas
2
2.3k
S3静的ホスティング+Next.js静的エクスポート で格安webアプリ構築
iharuoru
0
190
RCPと宣言型ポリシーについてのお話し
kokitamura
2
140
MCP世界への招待: AIエンジニアが創る次世代エージェント連携の世界
gunta
2
530
GDG Super.init(version=6) - From Where to Wear : 모바일 개발자가 워치에서 발견한 인사이트
haeti2
0
560
研究開発と実装OSSと プロダクトの好循環 / A virtuous cycle of research and development implementation OSS and products
linyows
1
190
Firebase Dynamic Linksの代替手段を自作する / Create your own Firebase Dynamic Links alternative
kubode
0
170
goにおける コネクションプールの仕組み を軽く掘って見た
aronokuyama
0
120
読もう! Android build ドキュメント
andpad
1
240
Featured
See All Featured
KATA
mclloyd
29
14k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Faster Mobile Websites
deanohume
306
31k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
25k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
GraphQLとの向き合い方2022年版
quramy
45
14k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
40
2k
Bash Introduction
62gerente
611
210k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
How to train your dragon (web standard)
notwaldorf
91
5.9k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.7k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
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