はじめに
これまで数社渡り歩いて来た自分の経験を基に、新人エンジニアとしてIT業界に入った方に向けて、システム開発時に特に注意してほしいポイントをまとめました。
プログラムを組む際には、これらの点に注意を払ってもらると少しはトラブルが回避できるかも。
データの不整合
この子のカテゴリ、どの親のカテゴリにも属していないんだけど・・・
上記のような場合は全然軽いほう。
本当にまずいのはユーザー絡みのお金（ポイント）周り
・ユーザーが商品を購入したけど、ポイントが減算されていない。
・ユーザーにポイントを加算したけど、別のユーザーに付与されている。
・実際の金額より多く（少なく）減算されている。
等々、ユーザー（会社）に実害が出るパターン。
こうなった場合サイトを一旦停止して被害が拡大するのを止め、データの復旧を行うことになるのだが
ログ等がなく復旧不可となると・・・・考えただけでも恐ろしい。
トランザクションを張る、ログを取り何かあっても復旧可能な状態にする、様々なパターンのテストを行う等お金絡みの箇所は注意深く開発してほしい。
セキュリティの脆弱性
・SQLインジェクションやXSS等セキュリティの脆弱性があるままリリースしてしまい
ユーザーデータが外部に漏らしてしまう。
・また商品購入やポイント加算APIを誰でも叩ける状態で設置してしまう。
このような状態だと悪意のある第3者による不正ができる状態になってしまい、
またやっかいなことに早期の発見がなかなか難しい。
最初はプログラムを動かすことに精いっぱいで、中々気が回らないかもしれないが、チーム内でのポリシーやルールがあるはずなので必ず相談＆レビューしてもらおう。
サービスを止めてしまう
どこかの1ページがバグで見れなくなってしまった。
上記はまだ影響が少ないが、サイト全体が止まるようなバグはまずい。
参照箇所が多い基本的な共通機能を開発、修正するときは特に細心の注意を払って開発、テストしよう。
また特定の日付になると動作する機能をリリースし、その日がきたらバグでサービスがとまってしまったパターン。
深夜の0時開始とかだと対応者が限られていたり、対応にも時間がかかると思われるため最悪。
これもテストをしっかり行っていれば防げるはずだが、可能であれば依頼者に昼の12:00開始でも問題ないかあらかじめ打診しておき、リスクを軽減しておくのも手。
エラーに気づかない
・エラーが発生してもエラーを握りつぶしてどこにもエラーが吐かれない。
・エラーが発生してもサーバーのログに残るだけでなかなか気づけない。
最悪どこかのページが表示されないぐらいならまだいいが、商品購入など決済等のお金周り、外部に提供しているサービス等のエラーはすぐに察知する必要がある。
これもチーム内でのポリシーやルールがあると思うが、なにかあったらメール、slack等にエラーを発報してすぐに気づける体制を構築しておく。
サイトを重くしてしまう
よくあるのが、最初は問題なく動作していたが徐々に動作が重くなりついにはサービスが停止してしまうとうパターン。
大体がデータベースのデータ件数を考慮しないでシステムを組んでしまい、データが増えることによりデータベースに負荷がかかったことに起因している。
データが徐々に増えているような機能を組むときは、データベースのインデックスをしっかり設定した上で、必ず想定される最大のテストデータを用意してテストを行おう。
バッチが正常に終了しているか
ある程度の規模のシステムならバッチが必ずあると思うが
何件のデータを処理して、何件成功したか等ログに残すようにしよう。
自社のシステム起因でなくても、外部からのデータの取り込み等、外部システムの不具合で
データが送信されていないことがあり、正常に終了しているが実際には何も処理されていないこともあり得る。
またバッチの性質上、大量のデータを処理することがあり、メモリエラーで落ちることがある。
前述のとおりバッチもエラーに気づかないことがないようにしよう。
ログは極力残す
例えば
・ユーザーにポイントを加算するとき、単純にポイントを+1するのではなく
〇〇を利用したとこにより〇〇ポイントを付与した。
・外部サービスを叩いたとき結果だけ受け取るのではなく、リクエスト時のパラメーター、先方からのレスポンスをログに残す。
等後から何か起こったとき、その時の状態がわかり、原因が究明できるように極力ログは残すようにしたい。
DBのパフォーマンスに影響があるため片っ端から残せばいいわけではないが、お金絡みのログは最低でも残しておきたい。
DB設計はかならずレビューしてもらう
リリースした後にテーブル構造を変更することは、大抵工数がかかる＆サイトを一時的にとめないと変更できないことが多い。
後から変更したくなっても前述のとおり容易に変更することが難しいため、必ずチーム内でレビューを受けよう。
データの物理削除
チームのポリシーによるが、基本的にデータベースの物理削除はバックアップ処理以外では頻繁に行われないはず。
一般的には論理削除が主流だと思われるので、自分のコードに物理削除があるときは一度チーム内で相談しよう。
チームのルール、ポリシーに従う
基本的なことだけど一応。具体的なドキュメントやルールがなくてもコードを見て察することも大事。
あからさまにおかしいと思っても何かしら理由があるかもしれないので、自分ひとりで突っ走ることはせず必ずチーム内で相談、提案しよう。
最後に
何かあったときに重大インシデントに繋がりそうな箇所をあげてみました。
※これ以外にもまだたくさんありますが。
またインシデントが起こったときに早期に発見し、リカバリーできるように設計しておくのも大事。