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
140
Bugless Code
Yunosuke Yamada
October 16, 2022
Tweet
Share
More Decks by Yunosuke Yamada
See All by Yunosuke Yamada
AIエージェントのオブザーバビリティについて
yunosukey
1
570
OpenTelemetry + LLM = OpenLLMetry!?
yunosukey
2
400
クラウド開発環境Cloud Workstationsの紹介
yunosukey
0
250
フロントエンドオブザーバビリティ on Google Cloud
yunosukey
1
230
ChatGPTのアルゴリズム
yunosukey
0
370
React and XSS
yunosukey
0
300
DB Tree Algorithms
yunosukey
0
99
Tests in Go
yunosukey
1
110
圏論とコンピュータサイエンス / Category Theory and Theoretical Computer Science
yunosukey
0
280
Other Decks in Programming
See All in Programming
從零到一:搭建你的第一個 Observability 平台
blueswen
0
210
rbs-traceを使ってWEARで型生成を試してみた After RubyKaigi 2025〜ZOZO、ファインディ、ピクシブ〜 / tried rbs-trace on WEAR
oyamakei
0
1k
Rethinking Data Access: The New httpResource in Angular
manfredsteyer
PRO
0
220
iOSアプリ開発もLLMで自動運転する
hiragram
6
2.1k
Proxmoxをまとめて管理できるコンソール作ってみました
karugamo
1
410
Practical Domain-Driven Design - Workshop at NDC 2025
mufrid
0
130
技術的負債と戦略的に戦わざるを得ない場合のオブザーバビリティ活用術 / Leveraging Observability When Strategically Dealing with Technical Debt
yoshiyoshifujii
0
160
衛星の軌道をWeb地図上に表示する
sankichi92
0
250
Use Perl as Better Shell Script
karupanerura
0
650
TSConfigからTypeScriptの世界を覗く
planck16
2
1.3k
CQRS/ESのクラスとシステムフロー ~ RailsでフルスクラッチでCQRSESを組んで みたことから得た学び~
suzukimar
0
190
技術懸念に立ち向かい 法改正を穏便に乗り切った話
pop_cashew
0
750
Featured
See All Featured
Facilitating Awesome Meetings
lara
54
6.4k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
1
78
Being A Developer After 40
akosma
91
590k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.2k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.8k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.6k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
19
1.2k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.6k
Raft: Consensus for Rubyists
vanstee
137
7k
The World Runs on Bad Software
bkeepers
PRO
68
11k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
47
2.8k
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