開発手法に見るトルシエ型とジーコ型
某開発で見聞きした話。
某さん：このselect文だとテストに通りません（だから通るように書き換えたいのだという）
ふんふん、Oracle特有の関数だよね。へぇ、通らないですか？
select to_date(sysdate, 'yyyy/mm/dd hh24:mi:ss') from dual
某さん：開発環境ではMySQLを使って開発していますのでOracleではありません。
（かなり脱力した感じで）へぇ、で、通るようにSQL文を変えたい、と。
その後いろいろやり取りがあって、結局某さんは、現在時の取得方法を知らないことが判明。
MySQLだと、Now()関数とかを使いそうな場面だよね。
って、よく調べるとsysdateも使えるみたいだね。とか、いう話を経て、
しかし、だ。ここでテストが通ったとして、最終的にはOracleで動かすんだよね？そのプログラムは。Now()とか使うとダメだよね。
目先のテスト項目の消化に（環境を変えてまでして）一喜一憂するのか、
それとも、最終目標のために、今できないものは後々のテストで吸収させるとか。
今求められているのは、どっちなのか、少し考えればわかるよね？
とか、言う話に。
俺は前者をジーコ的手法と呼び、後者をトルシエ的手法と呼んでいる。
ロングスパンで、同時並行に開発担当が動いている場合、トルシエ的手法を採用せざるを得ないことが多いのだが、
トルシエ的手法をとると動いている場面がなかなか見えてこないので、
（オヤジ魅了キーワード第一位の）「見える化」とかに感化されたオヤジ層に
「成果を見せろ」
と、詰め寄られることになる。
なので、その場しのぎのジーコ的手法が有効な場合もある。
つまり、「見える化」対応のための「見せてやる化」に時間を取る、のを嫌って安易な選択肢を選んでしまう、とか。
今は世の中的にそういう手法が評価される流れにあるので、それでも問題ないのかもしれないけれど、
時間を掛けた見えづらい、深い部分の部分の作り込み、に必要な能力が衰えていっているような気がするような。
まぁこの場合は最終成果版と開発版とで違う環境で動かす、という発想の時点でアウトなんだが。
せめて、違うデータベース使うなら、ANSIに沿うとかね。
と思ったが、各データベースの現在時刻取得なんてバラバラだったな。
と、思い出して、やっぱり、違う環境はダメだ。
