後で困るプログラムの書き方

色々な案件を受けると、やっぱり「こういう書き方すると後で困る」というプログラムが出てくる。
というわけでそんな例を紹介。
随時更新、そのうちkindle化するかも。

バッチで先月という表現は使わない

現在時刻の~日前とか~ヶ月前とか、そういうプログラムをバッチで書く時は要注意。
例えば何かのエラーで失敗して、翌日再実行する、なんてことが起こると非常に困るのですよね。
というわけで、基本は先月じゃなくて指定日の~日前とか~ヶ月前にする。
指定日をバッチ引数で指定できるようにする。
引数がない場合は本日の日付、って感じにしたほうが良いです。

コントローラーに書かない

いわゆるMVCのFat Controller的な話。
個人的にはコントローラーに書くものは「再利用しない」を前提としたものにすべきと思ってて。
別のコントローラーに書かれている処理をこっちでも使いたい、なんてことが無いようにするべきと思うのですよ。
やっぱりレビューはそういうところを見たほうがいいですね。

common系共通関数を使わない

これは頻繁に起こるのですが、commonとかutilとかのディレクトリにある関数をいじりたいときの影響範囲が読めないとか。
本来はユニットテストでどうにかするべき点なのですが、だいたいユニットテストが適当なプロジェクトって多いですし。
オーバーロードができない言語も多いですし。
影響範囲が読めなくて困るようならいっそのこと共通関数なんてものを使わないのも手かもしれないですね。

modelとdbの対比

なぜか起こるのがmodelとdbがちぐはぐというパターン。
UserModelなのにDBはmemberとか、こういうのは探すのに苦労します。
実際ありがちなのはuserがもう一つ増えて、approved_userとかspecial_userとかできた結果ぐちゃぐちゃになるという例。
こういうのは早めにリファクタしましょ。
既存の影響とかは今考えるべき。後になればなるほど苦労するので。

つづく