~ エンデベッドシステム開発経験を回顧する ~
詳細設計完了。レビューで提示された2つ案。
詳細設計で言及することは以下4点。
①要求仕様に基づく当該機能の改修理由
②改修方針
③改修の内容
④改修の妥当性
①~④までを明確に文章化することで初めてソースコードを改修できる、コーディングフェーズに移行できるわけである。
そして、詳細設計からコーディングへとフェーズ移行するときもレビューは必須。
その参加者は、2人だった。
レビュアー、俺。レビューイ、担当者。
このとき、改修方針として提案されたのが2案。
案1)サーバーから取得した設定値群(1ブロックのデータ)を全てメモリに格納する。新しい設定値は後々参照できるよう構造体メンバに追加する。
案2)サーバーから取得した設定値群(1ブロックのデータ)を現在使われている分だけメモリに格納する。新しい設定値に関する構造体メンバの追加は行わない。
担当者の推しは、案1。
通知されたのだから取り込んでおけばよい。
妥当性としては、ソースコードを全て検索した結果、新たに格納したデータを参照する機能はないのでメモリに格納しても安全、とのこと。
絶対的な安全策でいえば案2なのだ。
だが、確かにデータを参照する機能がないのであれば案1でも問題ない。
担当者の推しもあり、案1を採用することでレビューを閉じたのであった。
振り返ってみるとここでバグが埋め込まれたわけである。
そう、振り返れば分かるのだ、何が間違っていたか。
これは個人的体験談を元にした回顧録です。企業名、人名などは架空の名称です。
毎週日曜日更新。
随時、加筆、修正を行います。
投稿日 | 2022.06.12 | 更新日 | 0000.00.00 |