Bugless Code

Transcript

1. バグを生みにくい実装 2022/09/16 山田悠之介
2. 目次 1. バグを未然に防ぐ 2. 読みやすいコードを書く 2
3. 1. バグを未然に防ぐ 3
4. バグには種類がある バグはその発生原因によって分類ができます。 『組込みソフトウェア開発における品質向上の勧め バグ管理手法編』 は IPA による組込みソフトウェアについての文献ですが、 Web アプリケーションにも共通する部分が多いです。 この文献には「バグの区分」があります。 今回は実装について触れます。 4
5. バグの区分（実装区分の一部） ロジックの誤り 条件の誤り、演算の誤り、など インターフェースの誤り non null な引数に null を渡す、呼び出す関数を間違える、など タイミングの誤り 処理を書く場所が違う エラーチェックの誤り エラーチェックをしない、後処理が適切でない 機能の欠如 仕様と実装が異なる 5
6. バグの区分（実装区分の一部） 防ぎやすいものと防ぎづらいものがあります 機能の欠如 実装者が既存仕様や既存実装、新規仕様を正確に理解する タイミングの誤り 理解した処理の流れを正確にコードに落とし込む これらを防ぐのは属人的で、比較的難しいです。 インターフェースの誤り 例えば関数の型を厳密に付けることで、 自分やその関数を利用する他の実装者もバグを防げます。 6
7. 型について any は論外です ライブラリの型が any を含む場合そのまま使わない string は改善の余地があります 日付 → Date URL → URL 種類が有限 → Literal types 種類は有限ではないが規則がある → Template literal types number も同様です 7
8. 「エラーチェックの誤り」 JavaScript の例外は非検査例外なので例外処理を忘れがちです。 例外を投げるのはやめましょう。 以下のようにすることでエラーチェックを強制できます。 type Data = | { value: Value; error: undefined; } | { value: undefined; error: Error; }; 8
9. 「ロジックの誤り」 簡単に防げるものもあります。 == , != ではなく === , !== を使う isNaN() ではなく Number.isNaN() を使う if 文の {} を省略しない デフォルトパラメータを使う x ?? y のような処理を何回も書くのは良くない 返り値の型を書く コンポーネントは JSX スタイルで使う 9
10. 正規表現を避ける 正規表現は強力ですが問題も多いです。 正しいか分かりづらい パフォーマンスが悪くなることがある 別の方法がある場合は避けたほうが良いです。 数値形式の場合 isNaN() を使えないか 日付形式の場合は Date 、 URL 形式は URL のコンストラクタでパースする startsWith , includes , endsWith などで代用できないか 10
11. Falsy に注意する 特に "" に注意が必要です。 新フォーム定義では Falsy な値によるバグがいくつか出ました。 if(str) ではなく if(str !== undefined) や if(str !== "") ではないか考え直しましょう。 number の場合も NaN はダメだが 0 は OK か、など考えましょう。 11
12. 2. 読みやすいコードを書く 12
13. どんなに気をつけてもバグは生まれる 1 人でどんなに気をつけてもバグる時はバグります。 もし、あなたのコードがバグっていたとしても読みやすいコード、 読みやすい PR ならレビューで発覚する可能性があります。 もし、発覚せずにマージされたとしても読みやすければ将来調査、 修正がしやすいです。 もし、バグっていなかったとしても、今後何回も読まれます。 読みやすければ将来の自分や他の開発者の生産性を上げます。 （逆にそうでない場合、他人の生産性を下げることになります） 13
14. 読みやすいコードを書く 読みやすい名前を付ける 例えば id は分かりづらい コメントを書く オプショナル引数はどういう時に必要なのか 処理の場合、なぜそうしたのか、 逆になぜ別の方法にしなかったのか書く 関数を分ける 一度に 1 つのことをする pure な関数はテストしやすい 14
15. 読みやすいコードを書く 読みやすいテストを書く テストは振る舞いの説明です コミットを分ける 一度に 1 つのことをする これらの多くは『リーダブルコード』にも書かれています。 15
16. 無駄な処理をしない 不必要な処理をしていると、それを読んだ人は 「もっと簡単な方法があるのになぜそうしないのだろう」 と考えてしまいます。 必要十分な処理を書きましょう。 三項演算子を減らす 返り値を使わない場合 map ではなく forEach useState , useEffect を減らす state と effect は React のライフサイクルで特別なもの 16
17. ネストしない ネストしたコードは読みづらいです。 early return する 必要なら関数に切り出す 三項演算子を使わない if 文のネストのほうがマシです コールバックを使わない then ではなく async , await を使いましょう 17
18. 正解はない 読みやすいコードを書くためのポイントは限りがないです。 どのようなコードが読みやすいか、 どうしたら自分のコードが分かりやすくなるか 考える続ける必要があります。 例えば PR を出す前にもっと良いやり方がないか何回も （1 回ではない）考えましょう。 18
19. 参考 『組込みソフトウェア開発における品質向上の勧め バグ管理手法編』 https://www.ipa.go.jp/sec/publish/tn12-005.html 『リーダブルコード』 『Airbnb JavaScript Style Guide』 https://github.com/airbnb/javascript 19