読者です 読者をやめる 読者になる 読者になる

せらぴんブログ

サークル「せらぴん」のうのはな透です。やっぱり眼鏡っ娘が好き!!

備忘録(2012年度PJ)

去年の炎上PJでの備忘録

1. 一括処理は個別処理を再利用できるように設計しろ

今回開発したのが一括取込処理。個別の登録処理は画面上から行うのですが、画面処理がフレームワークに則っている関係かほぼ再利用不可。しょうがないので個別処理と同じことを一から再コーディングする羽目になりました。さらに設計書も杜撰なため処理漏れが多数発生。コイツの改修に半月以上掛かりました。同じことをするのに別々に実装しなければならないなんて、どれだけナンセンスなんだ、と。一括処理を実装するのなら、個別処理の設計時に再利用性を考えながらやらなければダメです。

ただし一括処理は個別処理の束でもありません。別のPJですが、「一括処理に時間が掛かりすぎるので、間のチェック処理を全部省いてくれ」なんて改修もありました。*1

一括処理は結局大なり小なり個別処理で行っているチェック処理を犠牲にしなければならないので、どこを犠牲にするかは事前に詰めておかなければならないでしょう。

2. データ構造が悪ければ何をやってもダメ

一括取込処理ということで取り込むためのデータが与えられるわけですが、そのデータというのが文字列配列。これを配列のまま整合性チェック、DB登録するという実装をしました。データを参照する度に「えーと、この値は配列のN番目に入ってて、整数に変換して……」とかやってるんです。もうねアボカド、バナナと。

データがあるならクラスにしちゃえばいいんです。文字列配列引数に取るコンストラクタ作って、整合性チェックとか細かい処理もvalidateメソッド作ればいいんです。二種類データあるなら継承使ったりFactory使ったりすればいいんです。それを神クラスひとつに全部詰め込んでしまうとわ……。

知識としては知っていても、実際に現場で活かせるとは限らないということがわかりました。

*1:この件はSQLをチューニングすればチェック処理を犠牲にせず速度向上させられたかもしれませんが、納期の関係でチェック処理を省きました。