手を抜くことの美学、前向きなことの功罪

世の中、手を抜くと怒られるのがまぁ常だとは思うけど
なかには手を抜いた方が結果がよくなる場合がある

たとえば、安定稼働しているシステムを別の環境に移し替えるような場合
あるプログラマは

「この際だから、ついでにリファクタリングもして効率よくしちゃおう!」
とか余計なことを考えちゃう
まぁ前向きな考えではあると思うが
仕事には『決められた時間内に』というプログラマが大嫌いな大前提がついていたりする

それなら
動かないところだけ抜き出し、改修作業は極力パタン化しサルでもできるよう考える余地を残さない
改修はひたすら電子的な雪掻き作業に徹する
リファクタリングなってとんでもない、修正箇所は最小限で余計なことは一切しない
といった、真っ当ではあるが、かなり手抜きの方法もある


■前向きなプログラマ君のメリット

・新しい取り組みにチャレンジできた満足感
・もしかしたらちょっと効率よくなったかもしれない(まぁこれも自己満足)

□前向きなプログラマ君のデメリット

・時間がかかる
・新たなバグを投入(投入されるバグの数はスキルに反比例)
・システムテストを細かくやらないとダメ

■手抜き君のメリット

・考えるのは最初だけ、後は作業なので仕事が早く終わる
・改修した部分テストで済む場合が多い

□手抜き君のデメリット

・退屈な作業
・早く終わって定時で帰ると白い目でみられる


まぁあれです
十分優秀なプログラマの場合どっちでやってもOKだと思うのですが、そうでないプログラマの場合は激しく後者のアプローチをおすすめします
それに、大半のユーザーはどちらの方法にするかには全く興味がなく、元の安定稼働したシステムがローコストでそのまま正しく動くことだけ望んでいます
つまり、前向き君のメリット≠ユーザーの要望 なのね
というか、むしろユーザーの要望は手抜き君に近いんじゃないかと

えっ 俺ですか?
もちろん後者ですとも! 手抜き最高ぉ!!

でもって
そんな前向きなプログラマ君が残したシステムをずっとデバッグし続けてる俺って…
何かの罰ゲームでしょうかねぇ…

追記:
プログラムに興味あるなら これをちょっと読んでみるといいかも
俺もコードを書くときは「いかにシンプルに早く書くか」を念頭においている
システムのデザインも同じでいかにシンプルに設計するか(それと統一性)
なんせ時間が一番高いコストなのよ
複雑なコードは書くのも面倒くさいし、読むのはもっと面倒(とくに人が書いたコードは)
面倒なこと=時間がかかる
時間がかかる=コストがかかる
だからね