自分はＷｅｂではありませんが・・・
http://maname.txt-nifty.com/blog/2006/12/beautiful.html
美しいコードに言及されてます。
それは、時と場合にもよるんです。
いや、別に反対するつもりは全くないのですよ。ＴＢ元の方の意見は痛い程わかります。
ただ、世の中には汚くならざるを得ないｏｒ汚くてもよいソースもあるって事も忘れてはいけないです。
（１）簡単なスクリプトでデータを生成したりする使い捨てプログラム。
そのまんまです。
自分は吐き出したx,y座標データを扱った事があります。
データをテキストに出力し、そのデータをvbaでコンバートしてC言語のデータファイルを作成しました。
#include
このインクルードファイルの中身はタダの2次元配列です。
使い捨てのプログラムなので、次に使う時はすっかり忘れてます。
ワザワザ思い出すより、もういっかい書いた方が早いです。
コメントを解析する作業や・ソースを綺麗にするメンテナンスとのバランスが悪いと思ったからです。
（２）保守費用で稼ぐために適当に動いているプログラム。
人としてどうかと思いますが、意図的にそんな事してる大手もあるんじゃないでしょうか？
（３）時間を稼ぐプログラム
保守しやすく分割をしソースをレイヤー化するのはメソッド、関数の呼び出しのオーバーヘッドのコストが掛かります。
こだわる人はマクロ関数を使ってる人もいました。多分その人しか理解できないでしょう。
（４）一度ロムに焼いてしまえば二度と保守が無いプログラム。
これは、少し不思議に思われるかもしれませんが、前の会社はそうでした。
お金はいいのですが、とにかく滅茶苦茶に仕様変更が入ります。
企画している人間でさえ仕様を理解していない為に考察漏れが非常に多く、対応する為にソースを直しまくりでした。
夕方の会議の後にはいきなり仕様変更です。それも２日後などです。
その日の内に見積もりを立てないと間に合いません。
メンテナンスをする時間なんかありません。
コメントは機能名をそのまま関数の頭に貼り付けるだけです。
処理のコメントはよっぽどトリッキーな事意外は付けません。全て頭の中です。
「あぁこの関数のネーミングやばかったな」と思っても直す時間はありません。
ある機能のいい名前考えても次の日にはその部分が無くなってる事なんてザラなのでやる気もおきません。
仕様変更に堪えうる為に最初の基盤部分の設計がどこまでスマートにするかが勝負です。
しかし、それとは逆にコピペをするべき所はしてました。そうしないと変更に堪えれないからです。
共通化を計ると言う事は、共通している部分に依存してしまう事になります。
さらに共通化を計る時間も必要になります。
そんな時間はありません。その為に途中で人材投入なんて事は絶対に不可能です。
通常の会社では４人でやる作業を自分達は２人でこなしてました。
ファームのC言語みたいな抽象化が弱い言語を別の人間の脳と同期化を計るにはかなり時間が掛かります。
なんで通常の１．５倍のリソースで１人の人間が担当した方がコストは安くなります。
擬似タスクみたいな時系列的なプログラムはソースを覚えてないと話になりません。
タスク処理の中で排他処理の不正な動作を突き止めたりする時は想像力との戦いです。
コメントを読んでソースを思い出すのは時間が許しません。
そういった理由でソースはグチャグチャ、破綻しないレベルでのぎりぎりのメンテナンス。
腕だけでは無く経験値による作業が非常に多かったです。
もう最後は体力勝負です。
凄まじいテストをくぐり抜けてリリースです。
当時は２０後半だったのですが、多分３０代だと体力が持ちません。２０代前半だとタフさが足りないと思います。
ちなにみ最後のプロジェクトは破綻しました。別チームが壊れてしまいました。
まぁ常にデスマーチみたいな感じでしたが、周りは驚く程年収は良かったですよ。
もう二度としないと思いますがね。普通の１．５倍働いて１．５倍の金を貰っても将来が見えませんでしたから。
体と心は何度も病む寸前までいきました。まさにマグロ漁船ですね。
まぁそんな感じの現場もあるって事を知っていただきたいです。
もちろん、最近の業務系プログラムになってからは綺麗なプログラムを書いてます。
明日も仕事です。単体テストも殆ど終わってますが、ソースのメンテナンスとコメントを付けに行ってきます。
