できました。と言う前に

僕がエンジニアとして仕事をする上で、よく見落としがちなミスなどをなくしていくためのメモ。
これを読みながら癖付けをして、心がけていけるようにすればきっともう少し苦労することも減るだろう・・・

実装は終わっていますか？

その実装は、本当に完了していますか？

エンジニアが実装をしていく上で、仕様書をそのまま読みながら素直に書くことって実は意外と少ないかと。必ず何ステップか挟みます。
仕様書をそのまま見ないで、箇条書きにしてから実装を進めています。

なぜ箇条書きにするの？

僕は仕様書を読みながら、その実装内容をよく箇条書きにしています。大本の仕様を考えて提示する側は文章で書いたほうが一般的だったり。あとは文系出身者の長文に慣れた人だったりします。でも我々エンジニアをしていると長文って読むのが退屈ですよね。このように長い文章書いていても途中で飽きてきてしまいます。
実装の現場では、箇条書きにした機能を一個ずつ、Todoやタスクリストに突っ込んで実装していきます。

なので、書いてある機能は、実装終わってますよね？

さて、本当に実装は終わっていますか？
これを読んでいる僕に問う。本当に実装は終わっていますか？仕様書に書いてある機能は漏れていませんか？

以下を確認しよう

タスクを片付けてるのって、細かいデイリークエストとか緊急クエストこなしてるみたいで楽しいですよね。

そのタスク、本当に終わっている？
タスクリストの説明を上から眺めてみよう。

• もしタスクリストに複数のやることが書いてあったらタスクを分割しよう
• やりかけで止まっていたら、備考に進捗を書いておこう

簡単なタスクしかやってないとか？

• 主要機能で面倒くさいものって優先順位高いんですよ。
• テストや別の実装に影響出る部分は先に片付けよう。

仕様の説明に対して、細かく分解したタスクリストに漏れは無い？

• 仕様書の文章を見ながら実装を確認してみよう。漏れてるかも？
• タスクリストが漏れてたら戻りがとても多くなるので重要。

エラー処理、書いてますか？

機能を実装するのがエンジニアの役目。仕様書には正常系しか書いていません。実装をしてコードの理解が進むに連れて各所でエラーが出てくると思います。これはハンドリングしていますか？ちゃんとエラーハンドリングも実装するのはエンジニアの仕事ですよ。正常系ができたからといって、それが全てではないですよ？見てますか？そこの僕。お前のことだぞ、一ヶ月前の俺よ。

プログラムは正常系だけ書いて「エラーが出ました。これはAPIが返してるので僕の担当ではありません。」これはだめ。何故か？だって画面を見ている人は「おかしいと思ったら、画面の設計者に文句を言う。」

さて。最低限のエラーハンドリングを考えてみましょう。

• 処理対象のデータがnull, undefinedなど
  • 検索結果の配列が0件はまだマシ。レスポンスがnullだったり、オブジェクトのキーがない等はよくあること
  • filter, mapといった処理を実装するときはnullを考慮する
• APIエラー
  • 必ずAPIはレスポンスを返すと思うな？HTTPステータスコードがあるということはエラーになるということだ
  • 値の検出はasync/await使っているならnull検出など。then, catch, finallyでもいい、適切に処理しよう
• その他、ライブラリのエラー
  • 使っているライブラリによるが、ネットワーク系のサービスなどSDK等はエラーを返す。
  • 大体の場合はexceptionを返すのでTry-catchで適切に処理しよう。
• 入力される値は適切なものとは限らない
  • フォームがあるとき、人は興味本位でそのフォームにありえない値を入れてリクエストする。
  • 業務系ならそれは異常パターンとして対処可能だろう。コンシューマー向けはそうはいかない。

テスト、してますか？

テストコード書くなんてそんな難しいこと俺にはできませんし？
かといって1つの実装ごとにテスト書いてられないってのも事実。APIとかバッチ系ならテストコード書くことはあるのですが・・・。

じゃあ実装したコード、ちゃんとテストされていますか？
どんなにロジックもコードもキレイでも動かないコードに価値はない。ちゃんと動くコードを書いてこそのエンジニアですよね。ちゃんと書きなさい、俺。

というわけで、テストしよう。ちゃんとテストしよう。

テストの手を抜かない

エンジニアの皆さん。特に俺。コード書く以外の時間って退屈ですよね。僕はとても退屈です。できればコードだけ書いていたい。
でもテストしっかりやっておかないと、テストチームから戻ってきて結局やり直して自分で確認して・・・と三倍ぐらい時間かかっちゃうんですよね。工数の無駄。残業もしたくないでしょ？

テストでやることを厳選

絶対にやらなければいけないのは以下に。フォームとかの各項目単位でのテストは実装時にある程度見ると思うので僕が見落としがちなポイントをこちらに。
一つ一つを片付けて、バグ0件目指しましょう。テストチームを焦らせていきましょ。
基本的な部分の実装バグ出さないのを理想に頑張りましょう

事項で、絶対にこれだけはやっておこうっていうものを厳選

フロントエンド・画面系の確認

コンシューマー、エンドユーザーがまず見る場所。この部分一番クレームになりやすいので入念に確認しましょう。

基本機能

簡単なところ。ロジックが基本的ゆえに軽視しがちだけど単純なミスを埋め込みやすいところでもあり。

• テストデータは最低でも10件は作りましょう。
  • ソート、へんなバグがあるかも
  • フィルターかけると複合条件で余計なものも選択されるかも
  • まとめて編集できる項目、いくつか編集してAPI叩こう。だって、一つずつ編集はやらないよね。
• テストデータ、全件削除してみました？
  • 大丈夫でしたか？データ0件で不具合おきてない？
  • データがないことをユーザーに通知できていますか？
• データ全件削除されてから新規登録できる？
  • うまいことDBのリレーションが動いてないとか、大丈夫ですか？
  • リクエストのオブジェクト、数値の型はちゃんとNumberになっている？
• その使いまわしたコード、本当に動いてる？
  • 検索・登録・削除・・・一通りのAPIちゃんと叩いて確認しましょう。
  • リクエスト時のパラメータ確認した？
  • APIのエンドポイントあってる？
• なんでも入力可能な箇所は英字数字、記号、漢字、ひらがな、カタカナ、絵文字入れましょう。
  • 大体の環境って2022年現在、UTF-8ですよね。でも使用するフォントや環境によってはバグるかも？
• 一回目の動作ってだいたいOKなんだよね
  • 二回目の新規登録とか三回目の登録確認していますか？画面はちゃんとクリアされていますか？
  • 初回のクリア忘れはあるあるですよね。
  • 登録以外にキャンセル押した後とか、もう一回モーダル開けますか？編集モードになりますか？
• ボタン連打、大丈夫？
  • 押した回数だけ登録されるとかあるあるですよね。マウス壊すなよ・・・？

データなし

• そこ、表を表示するところですよね。
  • データ0件の場合は「データ未登録」などユーザーにはデータががないことを通知してあげましょう。
  • 0件でWarning, Error出てないよね？
• filterとかfindつかったデータ、0件のときって対応していますか？
  • null, undefinedのときの対応してるかチェック

エラー処理

• API叩いてデータ取得失敗しました。ユーザーにエラーを通知できていますか？
  • エラー画面を表示しましょう。
  • ダイアログやメッセージを表示しましょう。
• 登録・更新処理のAPI叩きました。エラーです。
  • 登録時のダイアログや画面はそのままですよね。再入力するのめんどくさいですよ
  • バリデーションエラーですか？リクエスト送る前に対処しましょう。
• エラー発生時のリロードは考慮していますか？
  • 再読み込みボタンの実装
  • ホームへ戻るボタンの実装
  • 治らない場合がありますよね？管理者のTwitter ID貼っておきましょう。

レイアウト崩れ・ブラウザや環境

• 極端に短い文・極端に長い文
  • 表示系ではレイアウト崩れ等が見えてくるかも。
• 文章ちゃんと長文いれてますか？
  • 日本国憲法前文
  • 憲法第九条
  • 吾輩は猫である
• デザイン確認しよう。
  • Mac/Safariではデザイン大丈夫ですよね。
  • WindowsとChromeみました？もちろんFireFoxもですよ
  • ブレークポイントのレスポンシブ確認した？画面サイズの想定漏れはない？

サーバーサイド・DB処理系

バックエンドは表に見えにくい。ぶっちゃけバックエンドでエラーが起きてもフロントが怒られる。調査した結果それがバックエンド側のエラーだとわかったとき、とても顰蹙を買うでしょうな・・・。
テストのやり方はいくつか。テストコードを書いてもいいし、各ファンクションを叩いてシナリオテストを自動化してもいい。APIは認証が絡むのでテストがとてもめんどくさいですが、やっておきましょう。

基本機能

• APIリクエストのバリデーション周り
  • 配列が0件。ちゃんと処理できてる？
  • required項目のパラメータがnullを検出している？DBがNot nullだとエラーになるよね
  • string項目にnullは大丈夫ですか？テーブルはNull禁止ですよ？
  • 想定外の文字・数字・記号。ちゃんとバリデーションチェックしてますか？
• レスポンスの中身
  • 異常データ返してない？
  • 不用意にnullを返さないこと。
  • 不用意にパラメータをなくさないこと。iOSだとプロパティが勝手に消えてアプリがクラッシュします。
• リクエストの組み合わせパターン
  • API叩くときって、いろんな条件でリクエストが来ますよね。一通りの組み合わせはチェックしていますか？
  • 仕様で、いくつかのパターンがあります。想定されるレスポンスがちゃんと生成されていますか？
• CORSとか認証系
  • 認証エラーになってない？それ本番環境ですよ。
  • 逆に認証してるつもりが全部通過してたりしない？

データなし

• 取得データが0件の場合。
  • 配列で0件と返ってくるならいいのに。nullが潜んでるとforEachとかmapでエラーになる。
  • 逆にnull想定のコード書いたのに0件の配列が来る場合もある。
  • 条件分岐がどっちを通っているかは極力、ログに出そう。
• nullとかUndefinedが帰ってきたときの対応はしていますか？
  • データなしはデータなしですよ。
  • Nullとかは想定していないからと500 Internal Server Errorは気軽に返さないようにしよう

エラー処理

• SDKのエラーは処理してる？
  • フレームワーク、ライブラリによっては正常に終わるとは限らないよね
  • try-catchで適切に処理しよう
  • レスポンスはエラー発生時のレスポンスも想定しておこう。0件や、null、ステータスコードなど
• DBとかキャッシュやストレージのレスポンスエラーって考慮していますか？
  • もちろんネットワークの無効にいればエラーも起きますよね
  • プロセスが落ちている場合もあるかも
• バッチ処理など、プロセスが落ちた場合
  • ちゃんとエラーが通知される仕組みは作っていますか？
  • 「そういえば動いてないな・・・」は危険。動いてないことに気づかない
• 落ちた場合のリトライって自分で実装する必要は無いけど・・・
  • Zabbix等で監視してアクション実行などやっている？
  • GitHub Actionsなど、極力サーバーレスに移行しよう。（スマホからも実行できる）

エンジニアの健康

もちろんエンジニアだって人間です。どんなにコード書くのが好きでも、どっかで限界は来てしまいますよね。無理のない範囲で仕事していく努力も必要です。

しっかり寝てますか、それとも人間やめますか？

• 睡眠負債・睡眠不足
  • 睡眠の習慣は見直したいところ第一位。寝不足は自身のバグの原因。
  • 考慮不足や注意力不足などを生みます。
  • なんか心身が疲れてるなとおもったら、一日7時間は寝よう
• でもやりたいことが多くて寝る時間が・・・
  • 大丈夫、あなたが寝るといえば、一緒にゲームしてる友達も寝ます。
  • YouTubeは今日見なくても死なない。
  • ニュースも今日見なくてもいい。
  • アニメもいま見なくてもいい。
  • 通勤中に片付けましょう。（電車通勤に限る）
• 寝ることは最大のデバッグ。
  • 寝るようになってわかる。びっくりするぐらいコードのバグが減る。
  • ひらめきも改善して難しいコードも割と片付くようになる。
  • 睡眠で自分自身をデバッグしましょう
  • 昼寝も有効。眠いときは15分タイマーセットしてさっさと寝よう。

運動、してますか？

• コード書くのに熱中して同じ姿勢でずっと作業してませんか？
  • 血流の低下等の原因。エコノミー症候群等にもなる。
  • 背中の凝り、肩のこりは集中力低下を生む
• 1日30分は散歩しよう
  • 歩くのは全身運動
  • 骨盤が揺れて、型でバランスを取るので関節が全体的に緩む。
• 筋肉をほぐしてないから不調が出る。
  • 肩こりや背中の筋肉が張る。
  • 坐骨神経痛や後頭神経痛の原因は後ろ側の筋肉をほぐしていないこと
• ラジオ体操はとても有効。
  • 固まってて日常生活でほぐれない背中の筋肉がほぐされるのでおすすめ
  • 2m四方あればできるし、音楽だけあれば手順は皆覚えているので容易
• 筋トレも有効
  • 普段使わない筋肉に負荷を与えていきましょう。
  • 筋肉を育てて基礎代謝をアップさせカロリー消費を促進しよう

食べ物大丈夫？

• 腸内環境を改善する
  • 野菜や根菜、キャベツを食べろ
  • キャベツで胃酸過多を抑えらえる
• 豚肉・トマトで夏バテ対策
  • エアコンの環境下にずっといることも夏バテの原因に
  • 水分のとりすぎは無いが、塩分も食べ物も適度に
• 冷たいものとりすぎは控えよう
  • 内蔵が冷えると活動が低下する。
  • 腸内環境は割と全身の健康に影響する

ちゃんと話そう。

• 考えているだけでは、コードは動きません。
  • 書いても考えてもコードって動かないのです。ちゃんと動かしたいときは、声に出そう。
  • 独り言でも良いので言葉に出すのは有効。
  • 実装悩んだら相談しよう。アドバイスもらうこともあるけど思考の一番の整理はアウトプットによるもの
• チャットでの相談とかでも良いんだけど、思ったよりは伝わらないのでボイスで。
  • でも非同期のメリットもあるので、書き残しておこう。
  • まずはチャットで聞いてみる。わからなければ勝手にボイスになるから。
• 雑談、大事。
  • 余計な話ししてる間に解決することもあるし、思いつくこともある。
  • Twitterとか眺めてしまう時間が長いなら周りの人と話してみよう。昨日の晩飯でも良い。

ストレス発散

• 思ったよりも外出は楽しい
  • 暑いけど出かけるのって大事。買い物行ったり、散歩に出たり。
  • 体すべて、頭も手も足も使って生きてることを実感しよう
• 運動大事。
  • 力を入れると発散になる。筋トレとか。
  • バッティングセンターおすすめ。安いし、おもったよりも疲れる。
• 家事をやる。
  • トイレ掃除とか風呂掃除、溜まった洗濯物
  • 食器洗うのも大事。たまにガスコンロ周りとかもしっかり掃除してあげよう。
  • 溜まったタスクが片付く感覚に似ている。すごく楽しい。やると止まらなくなる。

参考：プログラマの心の健康

考察

自分が過去に指摘されてきたことをベースにまとめてみました。もうちょっと少ないかなと思ったのですが、思ったよりもありますね・・・。
エンジニア人生を送って長いものの、こういったところがずっと消えずに苦労している最中でもあります。基本的なことができないとやっぱり信頼とかにつながらないので、上の人に「できました！」と報告する前にもう一度見直していこうと。

しばらくはこの記事を自分で見ながらエンジニアとしての市場価値を高めるため、マイナスポイントの底上げに努めていければなーと思っています。
こんなポイントや、あんなポイント追加してほしい等ありましたらコメント等ください。