こんなことを、おいらが言って説得力があるのかわからないけど、

「@」でエラー抑制すると PHP が遅くなるという噂について : a++ My RSS 管理人ブログ

　↓

大切なのは数秒のスピードアップ？それとも？

でもね、よく考えよう。100万回ループさせたら9秒の差が出ました、って、、、 100万回とか1000万回ループするfor文なんてものを書くのは実際の開発現場においてよくあることなんだろうか？

元のエラー処理の考え方が富豪的だなとは思ったけど、安定して動いているなら一度書いたコードとしては、わざわざ直すレベルではない。

ネタ帳さんの方の、はてブコメントに大量のアクセスがあったら？という意見があったけど、それなら一度書いてしまったなら、そうなった時に直せば良いだけの話。

逆に言えば、プログラムを書いてお金をもらう人は、「安定して動いてるけど、望ましくない記述」という状態もまた真になってしまう、というのを十分に意識して欲しいというのがこの話で思ったこと。

特にWeb系はプログラムを簡単に直せるとは言いますが、無意味に直させるマネージャなんていないし、直そうとする人もいない。

それよりも「安定的に稼働している」という積み重ねた実績の方が価値が高くなってしまっているので、後から直すことは、それが例え正義だとしてもリスクが伴う以上、効果の方が上回る場合を除いて修正してはいけない。

だからこそコードは常に一期一会でもある。

神経質に思う必要はないからこそ、一つ一つのコードを書く際にはそれなりに意識して欲しいというバランス感重要。

----------------------------------

あまりに悲惨な納期設定の時には言わないけど、「クオリティ　vs 納期遅れ」で品質にこだわる人に伝える時に使うメタファとしては、「バッターボックス」の考え方をよく使う。

野球選手は三振したらアウトである。
イチローが何がスゴイか？というと、その制約の中で結果を出していること。

プログラマーやデザイナーにとっての三振とは納期のことだ。

つまり、プロは納期までの制約の中で、如何に良い物を作るか？こそが求められるし、それをやっている人が一流選手と言えるということ。

３ストライクを認めずに４球、５球と粘ってたら、そりゃいつかホームランも出るかもしれないけど、それはルール違反。

「ソースコードは一期一会」の考え方もそれと同じ。

リリース後に、不必要にコードクオリティのリファクタリングをするってのは、基本的に考え方が間違っているわけだから、如何に自分のバッターボックスで高いクオリティの仕事ができるか？というのがプロのありようだよね、という話になる。

そして、自分がバッターボックスに立っている間だけは、とことんこだわっても誰も文句を言わないのだから、是非ともその間に、とことんこだわって欲しいと思うところであるし、自分のこだわりをカタチにするための瞬発力となる頭の筋肉は常にトレーニングしておかねばならないと思う。（が、そんなエラそうなことを言えるアレではないのだが。）

補足：
F's Garage：ソースコードが「一期一会」の意味