■ゴミプロ
「無駄」が表にでないプロジェクトの悲劇
時間、費用、作業・・・、無駄の対象はいくつかある。
その中で、「無駄」なソースコードの話。
最近、現場で目にした「無駄」のはなし。
そもそも、アジャイルでもウォーターフォールでも、開発手法で最後に頼れるリソース。何が正しい状態なのか？ これが原点。特に詳細設計書の取り扱いが問題だ。
見ると、間違いだらけ(‘◇’)ゞ。
これが正しいと思って行動すると痛い目にあう。
では、ソースコードとマスタを紐解く。
当然のように難解怪奇である。
ソースコードの見やすさやライブラリの構成（分類）、粒度・サイズなど、規程がないから、膨大で入り組んだパスタの海を泳ぐことになる。疲労困憊。溺れそう。
＊
メモリがバカ高かった頃のエンジニアは、コードを書く点で優秀だった。
思考を紙にまとめて、何回も見直し、イン・プロセス・アウトで最適化。
「適応」や手続きをチェックして、コードルールの意味を標準化する。
生産性も重要だったが、プロとして、エンジニアの書いたコードの標準・芸術性まで話題になったぐらいだ。
標準化と個性の高い芸術性は矛盾しているように映る。
が、芸術性を美しさとしたとき、そこには哲学が生まれる。
システム構築には美しさ・哲学が必要だ。
美しいコード群にはバグが少ない（と思う）。
なぜなら、秩序があるから。
入れ子だって、深くならない。適切なライブラリ粒度によって担保されるからだ。
ペーパーリストが謳歌していたその昔、コードは、あの１頁の行数を意識していた。
「知恵」というのは、そういう生い立ち・環境条件から生まれるのだろう。
＊
何処か、ゴミ問題と似ている。
ゴミプログラムだけは作りたくない、そんな、心境。
