よくある話ではありますが。不必要に複雑なソースを書くプログラマという人達がいます。単純にシンプルに書けば済むことを、特殊なトリックを駆使して書いてしまうわけです。このタイプのプログラマは、おおむね、迷惑な存在と言えます。後から他のプログラマがメンテしようとしたとき、面倒なことになるからです。
かつては、PCの性能が不十分であるために、トリックを使って性能を稼ぐ必要が生じたこともありました。それは、必要悪として是認されていたものです。しかし、有り余るほどのCPUパワーを得て、PCの性能が飛躍的に上がった今、そのようなことをする必然性はなく、トリックなどを使うことは悪であると断言して良いわけです。
つまり、トリックを駆使して不必要に複雑なソースを書くプログラマは、本人は自分が賢いと思っているのかも知れませんが、実際には賢いと言うよりは愚かである、と言うことができます。
ソースは、分かりやすく、シンプルであるのが一番です。
……。
という話を、けっこう信じてしまっていて、ある程度それを実践していたりしたのですが……。
これは正しい態度ではなかった、と思うようになりました。いえ、正確に言えば、思い知らされたと言った方が正しいでしょう。
とはいえ、不必要にソースを複雑に書くことが正しいと思っているわけではありません。それは無意味なことです。そうではなく、トリックを駆使することは不要であるという主張が、実は成立しないのだと思い知らされたわけです。
その切っ掛けは、りすと亭のメッセージスレッド管理の構造を設計していたときにありました。メモリを食いすぎず、迅速に実現する方法をいろいろ検討した結果、かなり複雑に絡み合うデータ構造が必要であることが分かりました。ソースの構造を理解しないプログラマがちょっと書き換えると、すぐに動作が狂うようなトリッキーなソースになることは避けられません。
それが確信に変わったのはMagSite1の開発のときです。延々と続く試行錯誤の末、メモリを食いすぎず、必要な性能を得るためには、トリッキーなソースにならざるを得ませんでした。
もう結果は明らかです。
最低限、どうしても実現したい機能を実現するために、複雑で分かりにくいソースを必要とするケースはいくらでも発生するのが現実です。綺麗で分かりやすくシンプルなソースだけで全てをこなすことは不可能、ということです。
これは、別の言い方をするなら、現在のPCの処理能力は、まだまだ十分と言うにはほど遠いということです。有り余るCPUパワーがある、などという言い方は間違いです。CPUパワーは極めて乏しい資源に過ぎず、ちょっと量の多いデータを与えると、すぐに限界に達してしまいます。(厳密に言えば、CPUだけの問題ではなく、メモリの限界もあれば、バスの限界もあるし、ディスクの限界もあります。これはシステムのトータルの問題です)
もちろん、何もかもトリックを肯定すると言うわけではありません。明らかに、コンパイラの最適化能力によって無意味化されたトリックがあります。たとえば、2倍するときにシフトを使うとか、よく使う変数をレジスタ変数に割り当てる、といったテクニックは、コンパイラが上手くやってくれる範疇であって、試みてももうメリットはありません。そういう低レベルのトリックは無意味だと思います。
しかし、計算量を減らしたり、ディスクへのアクセスを減らすようなトリックは、未だに有益です。たとえば、MagSite1ではアクセスカウントのファイル書き込みを遅延させていますが、これはレスポンスを向上させると同時にディスクへのアクセスが過度に集中しないようにする意図を持って設計された一種のトリックです。カウントアップとディスクへの書き込みの処理がソース上で離れた位置にあり、読みにくいソースですが、これは必要とされて作られたものです。
そのようなことから思ったのは、大人の顔をして綺麗事を唱えるよりも、必要とあらば何でもやってのける「熱血プログラミング主義」も必要である、と言うことです。
さあ、熱く行こうぜ!
とはいえ、何の準備もせずにただ熱くなって複雑で分かりにくいソースを書いても自滅するだけです。実際に、私が熱血可能であるという背景には、テストファーストによる効率アップと信頼性の維持があります。おそらく、これ抜きで複雑なソースを書いたならば、相当の遠回りを要求されたことでしょう。
それから、不必要に複雑なソースを書くことは、やはり避けるべきでしょう。それを遂行するパワーがあるなら、必要に迫られて複雑なソースを書くときのために取っておく方が良いと思います。
最後に補足しますが、この文章の中身を信じるも信じないも、あなたの判断です。信じて実践して問題が生じても、何の責任も取れません。念のため。また、私自身が、明日にも他の主義を唱えている可能性もあることを付け加えておきます。
