にんげんだもの。バグは出すし、エラーも読まない。にんげんだもの。
人間なんてそんなものだ。あれは10年前だったかな、「バグを直しました!」とニコニコ顔で提出してきたヤツが、新たにバグを2つ埋め込んできた。あいつの顔が、いまもまぶたの裏に焼き付いている。人間だからな。しゃーない。わかる。
でもまあ、そんなヤツは大勢のひとから信頼を失い、結果、続けられなくなっちゃうのよね…。おーこわ…。
そうならないためにも、作るもののクオリティを上げるためにもバグ・エラーとの向き合い方を抑えておこう。
バグを少なく作るには
- とくかく小さく作る
- 仕様書のようなものを書いて、機能を整理する
- 完成状態に近い状態でしか見つけられないバグや抜け漏れを見つける
1. とくかく小さく作る
プログラムは積み上げるもの。小さく作って小さく検証。小さく作った部品を組み合わせて完成形を目指す。
- ひとつの機能だけ動く開発用のページやシーンを作り、そこで部品を作成・検証していく
- その後、作った部品群を組み上げていく
- 普段から変な値(外れ値)を入れても壊れないようにコードを書いておく
- 例えば0から1の値がきてほしいところで、-1などの値が入っても壊れないようにしておく
- 配列を使うときは配列の長さよりでかい数字でアクセスしないように、みたいな基本的なif文を挟んでおく
- 人生で10回くらいはテストコードを書く習慣を持ってもよい。壊れるポイントを予測しやすくなる
2.仕様書のようなものを書いて、機能を整理する
仕様書もワイヤーフレームもAPI定義もないまま、作り始めることがなんてザラだ。しかし、なんらかの地図があったほうが、より迷うことなく目的に近づける。 カジュアルな形式でよいので整理するとよい。整理することで抜け漏れを見つけたり、誤った解釈で実装することも減るだろう。
手書きでいいのでそれっぽい図を書く
ちなみにフロー図?とかの書き方なんて知らない。それっぽく書いて自分で整理でき、その図で他人に説明できればいい。
- 機能をリストアップする
- どういう状況でどういう操作をすると、どういう結果が得られるか、をスプレッドシート等に羅列していく
- 画面のワイヤーフレームを書いて、操作や機能を洗い出す
- 機能を洗い出して、APIの叩き方も確認するとよい
- 画面遷移も確認すると矛盾があったりAPI抜けがあったりすることを確認しやすくなる
機能が多くなってくると見落としが発生しがちなので、書いて整理し、抜け漏れをある程度潰しておこう。
3.完成状態に近い状態でしか見つけられないバグや抜け漏れを見つける
完成状態に近づくと、たくさんの機能がからみあっていく。たくさんの機能がからみあうと、想定しないことが起こる。そう、バグるのだ。
また機能やAPI、画面構成の抜け漏れもどんどん見つかっていく。複雑なアプリケーションだと開発初期段階ですべての状態を把握することは難しい。画面が出揃った終盤に管理画面が充実し様々な状況から状態が変更されることで、バグや抜け漏れが発覚することが多い。
なるはやで完成状態に近づけることもバグを減らすひとつの解だ。
エラーメッセージを見るとアレルギーが出るヤツが9割。正しく読めば直る!
プログラムを始めたてのころや、あっぷあっぷしながら実装してるときは、まともにエラーメッセージを読んでないことだろう。エラーメッセージを読まないヤツは、解決できるまでに膨大な時間がかかる。
エラーのメッセージには、エラーへのヒントが書いてある。よく読めばだいたい解決するし、エラーメッセージでググれば回答が見つかることもよくある。バグを出しがちなひとはエラーや警告の文章を無視しがちなのは間違いない(自戒を込めて…)。
落ち着いてエラーメッセージを読むと、以下のような割合になる気がする
- エラーメッセージのみで何が原因かがわかる場合が50% (メッセージにリクエストパラメータがおかしい等が書いてある)
- エラーメッセージをググるとわかる場合が30%
- それでもわからない場合が20%
- →そんときは同僚にすぐ相談!
- APIがぶっ壊れてるか、自分のAPIの叩き方が悪いか、属人的なバグが見つかる
ちゃんと向きあえば、8割は10分ほどで解決するだろう。
正しくエラーハンドリングをする
APIのエラーハンドリングとリトライの実装はかなりの難易度だが、パターンを覚えると攻略可能でもある。
エラーを握りつぶさないようにするだけでも、正解に近い。正しくエラーメッセージをUIに表示するだけで、誰の目にもエラーが見えるようになる。
エラーダイアログの実装例:
- エラーを検知したら、エラーメッセージやstatus codeを元にUIでエラーダイアログを表示する
- ダイアログではリトライを促したり、別のページに遷移させるなどをする
バグをすぐ見つけるには
すぐ壊れそうな箇所の眼力をつけるのが最速。つまり、コードがダサいかかっこいいかを見分けることが大事。こればっかりはダサさを上から目線で見れるように鍛錬しよう
ダサいコードかどうかは迷いなくコードを書くの参考図書を読むとよい。
ダサいコードの一例: