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
150
Bugless Code
Yunosuke Yamada
October 16, 2022
Tweet
Share
More Decks by Yunosuke Yamada
See All by Yunosuke Yamada
AIエージェントのオブザーバビリティについて
yunosukey
1
690
OpenTelemetry + LLM = OpenLLMetry!?
yunosukey
2
600
クラウド開発環境Cloud Workstationsの紹介
yunosukey
0
290
フロントエンドオブザーバビリティ on Google Cloud
yunosukey
1
260
ChatGPTのアルゴリズム
yunosukey
0
380
React and XSS
yunosukey
0
310
DB Tree Algorithms
yunosukey
0
100
Tests in Go
yunosukey
1
120
圏論とコンピュータサイエンス / Category Theory and Theoretical Computer Science
yunosukey
0
290
Other Decks in Programming
See All in Programming
CDK引数設計道場100本ノック
badmintoncryer
2
580
Reactの歴史を振り返る
tutinoko
1
140
商品比較サービス「マイベスト」における パーソナライズレコメンドの第一歩
ucchiii43
0
210
Android 16KBページサイズ対応をはじめからていねいに
mine2424
0
730
レトロゲームから学ぶ通信技術の歴史
kimkim0106
0
140
NEWT Backend Evolution
xpromx
1
160
はじめてのWeb API体験 ー 飲食店検索アプリを作ろうー
akinko_0915
0
170
AI Ramen Fight
yusukebe
0
120
Understanding Kotlin Multiplatform
l2hyunwoo
0
230
AI時代の『改訂新版 良いコード/悪いコードで学ぶ設計入門』 / ai-good-code-bad-code
minodriven
24
10k
可変性を制する設計: 構造と振る舞いから考える概念モデリングとその実装
a_suenami
7
1k
Streamlitで実現できるようになったこと、実現してくれたこと
ayumu_yamaguchi
2
230
Featured
See All Featured
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.8k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
4 Signs Your Business is Dying
shpigford
184
22k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.7k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
The Pragmatic Product Professional
lauravandoore
35
6.8k
Scaling GitHub
holman
461
140k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
Site-Speed That Sticks
csswizardry
10
720
Producing Creativity
orderedlist
PRO
346
40k
How to Ace a Technical Interview
jacobian
278
23k
How GitHub (no longer) Works
holman
314
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