私のプログラムは芸術でなければならない。

動作もそうだが（動作に関してはいまいちな気もする）、
ソースの見た目や流れの美しさに関しては徹底的に吟味され
美しくなくてはならない。
動けばいいというのは許されないのだ。
それは他の人がメンテすることも十分考慮に入れた作り方だ。

そう、自分のプログラムに関してはこれを貫いている。
しかし、こと他人のプログラムに関してはそうも言ってられない。
他人のプログラムを変にさわるとバランスが崩れて動かなくなることがあるからだ。
だから美しくなくてもそのままメンテしなければならない。

今私が扱っているプログラムは元々外注で作られたもので、
しかも社内には私以外にＣ言語がわかるものがいないので
その内容に付いては全く触れられたことがないようだ。
そのためかなり強引な作り方がされており、
はっきり言って作った本人以外わからん、いや作った本人ですらわからんのでは
というほどである。

私のプログラムでは汎用で使えそうな関数は徹底的に本体から切り分けられ
ライブラリとして登録される。こうすればライブラリのみでテストもできるし、
バグがあってもそれだけのリンクし直しで済むし、バージョンアップも簡単である。
そして何より本体を短くできる。
それはメンテし安さ（バグの少なさ）につながる。

しかしまあ、このプログラムはそういった概念がないため＋複数の人間が、
自分のいる関数を作っているためによく似た関数がそこら中にあるのだ。
メモリーが足りないと言っていたが、これではそうなっても当たり前という気もする。

まあ、今回はいい。
しかし今後もっと大きな変更が必要なとき、私にはこのソースをメンテすることは
出来ない。それにさらなる機能追加をすれば必ずメモリー不足になるだろう。
せっかく私という優秀なプログラムアーティストがいるのに、
せっかくソースをもらったのに、これからもずっと外注に頼ることになる。
これではもったいない。

今私に１年の期間をくれれば同じものを作ることができるだろう。
（他の仕事をしながらなら２年。）
しかし会社と言うところはそんな悠長な時間はくれないだろう。

ということはせっかく社内でメンテできるようにと思っていた計画は
だめになるということだ。
これは決して私の技術力せいではないぞ。
技術的にはこれくらいのものは十分作れる（豪語）。
私は多くの場合自分が主体になって自分流の開発をしてきたために
こういう他人のソースのメンテというのが苦手なだけだ。
（たいていの人はそうだと思うけど。）

まあ、一端は破綻してみせるのもいいだろう。
そうすれば上の考えも変わるかも知れない。
そうなって、１から作り直すとなれば私の力が発揮されるであろう。

余りに汚いソースを見たために仕事中に健康ドリンク飲む羽目になってしまった。

ああ、美学に反するプログラムは美しくない。