読者です 読者をやめる 読者になる 読者になる

argius note

プログラミング関連

プログラムは「動けば良い」か

「動けば良い」以外の要素は、

  • パフォーマンスが良い
  • 動きに無駄が無い(メモリ使用量が少ないなどリソースが節約されている)

のように、機能に直接関係するものと、

  • メンテナンスし易い
  • 構造が整理されている
  • 可読性が高い

のように、動いているプログラムに直接関わらないものがある。
パフォーマンスやリソースの節約は、良いに越したことは無いが、これらを高い水準に保つのは高い技術力が必要であるため、一定水準を超えれば性能を満たしている、とみなして良いと思う。
構造やメンテナンス容易性についてはどうだろうか。この製品が、ROM媒体*1として使用され、後から修正する余地が無い場合や、ソースが二度と利用されることがない存在ならば、無視しても構わない。では、この製品がリリース以降も保守されるものだった場合、どうなるか。
メンテナンス容易性は、保守される製品については言うまでも無く確保したい。メンテナンス料が一定の場合、実際のメンテナンスに要するコストは低いほうが当然良いわけで、メンテナンス性の高さが、利益に比例することになる。新規でこの類の製品を製造する場合に、メンテナンス性を考慮しないで製造することは、その対価にもよる*2が、非常に質の悪い仕事と言えよう。
構造が整理されていること、高可読性については、メンテナンスの容易さにつながる。新規製造とは別のチームに開発が委ねられることになっても、メンテナンスコストをある程度の水準で維持できる*3だろう。
メンテナンスが不要の場合でも、可読性や整理された構造はあったほうが良い。なぜなら、完成前のコードは、メンテナンスが進行形だからだ。すべてのコードが頭に入っていれば良いけど、普通は*4そんなことは困難だ。あとで自分が見返しても分かりやすいように書くべきだ。また、整理された構造は、バグも埋め込まれにくい。デバッグも容易だ。
メンテナンスが容易で、構造が整理されていて、可読性の高いコードを書くにはどうしたら良いか。それは、標準を知ること。標準に近い書き方であれば、標準を知っている他人が見ても読みやすい。多くの先人たちが、本やWebでこれらの情報を公開している。標準は唯一とは限らないので、それ以上は各人の判断となる。

*1:ゲームのカートリッジとか。

*2:適正な数値が算出されることは稀だ。

*3:当然、引継ぎに要するコストは勘定されている前提で。

*4:普通じゃない人は確かに存在しますが。