目次
キレイなソースとは
システムエンジニアとしては、たまにゼロから作り直したいと思うことがある。
ソースの解読性が低く、保守やバージョンアップが大変な状態を、他者から引き継いだとき。
でも、このソースのぐちゃぐちゃさを、お客さんに理解してもらうのは、とても大変。SEがちょっと苦労するくらいなら、余計なコストや時間、リスクをかけて欲しくないからだ。「ソースがぐちゃぐちゃで大変なんです。」と言っても、聞く耳を持ってくれないことの方が多い。
ソースを直すように仕向ける
こういうときは、ふてくされて諦めずに、お客さんの立場になって、「それは直した方がいいね。」と思うような提案をするのがポイント。たとえば、品質の確保が充分出来ないために、障害の発生確率が高まってることを報告する。
お客さんにとって障害が発生しやすい、と言われたら、何かアクションを取らざるを得ない。ソースの複雑度を計測し一般的な指標から現状分析して、全部とは言わなくても、ヒドイ部分の作り直しを提案するなどが効果的。
1つ注意としては、ぐちゃぐちゃ設計が前任者の責任になるので、前任者が同じ会社の場合は、なぜそうなってしまっているかの理由を用意しておく必要がある。 前任が違う会社ならば、引き継いだタイミングで、必ず現状の分析評価をすること。引き継いで、手をいれ始めたら、責任が曖昧になってしまうので事前に行うこと。
こういう地道な努力はとても重要で、システム開発の方向性が、お客さんにとっても、開発者たちにとっても、良いものに変わっていくと思われる。