プログラマー回顧録(18)

~ エンデベッドシステム開発経験を回顧する ~

詳細設計完了。レビューで提示された2つ案。

詳細設計で言及することは以下4点。

①要求仕様に基づく当該機能の改修理由

②改修方針

③改修の内容

④改修の妥当性

①~④までを明確に文章化することで初めてソースコードを改修できる、コーディングフェーズに移行できるわけである。

そして、詳細設計からコーディングへとフェーズ移行するときもレビューは必須。

その参加者は、2人だった。

レビュアー、俺。レビューイ、担当者。

このとき、改修方針として提案されたのが2案。

案1)サーバーから取得した設定値群(1ブロックのデータ)を全てメモリに格納する。新しい設定値は後々参照できるよう構造体メンバに追加する。

案2)サーバーから取得した設定値群(1ブロックのデータ)を現在使われている分だけメモリに格納する。新しい設定値に関する構造体メンバの追加は行わない。

担当者の推しは、案1。

通知されたのだから取り込んでおけばよい。

妥当性としては、ソースコードを全て検索した結果、新たに格納したデータを参照する機能はないのでメモリに格納しても安全、とのこと。

絶対的な安全策でいえば案2なのだ。

だが、確かにデータを参照する機能がないのであれば案1でも問題ない。

担当者の推しもあり、案1を採用することでレビューを閉じたのであった。

振り返ってみるとここでバグが埋め込まれたわけである。

そう、振り返れば分かるのだ、何が間違っていたか。



これは個人的体験談を元にした回顧録です。企業名、人名などは架空の名称です。
毎週日曜日更新。
随時、加筆、修正を行います。

投稿日2022.06.12更新日0000.00.00

プログラマー回顧録