- 公開日
メンテナンス性の高いコードを書く意義とは
コードは汚くていい。「アイツがいれば勝てる」と言わせろ。に対するあるはてな匿名ダイアリー記事を読んでいて考えたこと。
良いコードはエンドユーザにとってはどうでもいい
非エンジニアを騙して手抜きするのは簡単。余程のヘタレでない限り手抜きをしても絶対にばれない。コードにコメントがなくてもモジュール化されてなくてもコピペ満載でもマジックナンバーだらけでも動いてさえいればユーザーは気にしない。
そう、単純に速く作るのは難しくはない。なんにも考えずにただ思いつくままに上から下に書いていけばいい。そうして出来上がったコードは大抵はひどいものだ。要らないコードがコメントアウトされて残り、バージョン管理されたコミットログもまともに書かれず、ネストが深く、関数化もまともにされていない、そんなコードだ。
無論、「良いコード」「綺麗なコード」の多くはユーザにとっては無価値なものであり、どうでもいいものである。 ユーザにとっての最大の関心事はそのアプリケーションが面白いか面白くないか、正しく動くかどうか、バグがないかどうかであって、コードが良し悪しなんてアウトオブ眼中だ。
悪いコードは生産性を下げる？
じゃあ悪い手抜きコードでいいのか？ というとそんなことはないはず。
手抜きコードをメンテさせられるプログラマの生産性は落ちる
手抜きコードのメンテはプログラマにとって最悪の仕事。綺麗なコードで数十分でできる仕事が２週間かかることもしばしば。最悪の仕事をさせられ、「仕事が遅い」と評価され、モチベーションが下がって更に仕事が遅くなる。
このことは「悪い」コードをメンテナンスさせられた経験のある人にとっては当然なことだと思う。
悪いコードは３行で書けることをきっと10行で書くだろう。また、悪いコードは5メソッドに分けるべきところを1メソッドに書くだろう。ときに悪いコードは3ファイルに分けるところを1ファイルに集約するだろう。悪いコードはオブジェクト指向をうまく利用できていないだろう。
このようなコードのメンテナンスは大変骨の折れる作業で、メンテナンスコストは高くつく。このメンテナンスコストも含めてトータルでコスト計算すると結局、コストは手抜きコードのほうが高くつくのではないだろうか。数式にするとこのようになる。
手抜きコードを書くコスト ＋ そのコードのメンテナンスコスト ＞ 良いコード ＋ そのメンテナンスコスト
つまり、メンテナンスコストを含めたコードのトータルコストは良いコードの方が安く済むのではないかということだ。
ただ問題は前者がイニシャルコストが安いので、一見すると「トータルコストも安く済むのでは？」と思えてしまうところだ。悪いコードをメンテナンスしたことのない非プログラマにはなおさらそう思えてしまう。
メンテナンス性の高いコードを書くメリットは何か
メンテナンス性/メンテナビリティの高いコードを書くメリットは何だろうか。まず上記にあげたように「メンテナンス時のコストが下がりトータルコストが下がる」ことである。
例えばあるソーシャルゲームを考えてみよう。それが使い捨てのゲームアプリであればひどいコードでいいかもしれない。だが中長期的にそのアプリを運用していくのであれば、メンテナンス性の高いコードを書くべきだ。その結果、保守コストは下がりトータルコストは低く済む。
ソースコードの理解に時間を要したり、最悪の場合、なぜそういうコードになっているのか最後までわからず、「触ると危ないコード」> になってしまうようなら、例え機能的に要件を満たせていても、中長期のメンテナンスの観点から言えば、そのソースコードはコミットしない方がプロジェクトのためになります。
またコードに気を遣い、コードの品質を高めようと努めている企業には優秀なエンジニアが集まりやすいという副作用もあるだろう。品質の高いコードを書こうとする企業には品質の高いコードを書く優秀なエンジニアが集まるし、そうでなければコードに無頓着なエンジニアが集まるだろう。
コードを書くことが目的ではない
ただ、最後に記しておきたいのはコードを書くこと自体は目的ではないということだ。会社のビジネスを成功に導くためにコード/プログラムがあるのであり、そのことはエンジニアが忘れてはならないことだと思う。
綺麗に書くのなんて当たり前、そしてその先で実現できるモノづくりに全力を尽くす。
まつもと氏は、美しいコードというものがあるという。それはアートで、「プログラマはアーティストだ」と言い切る。（中略）アートだと言ってもプログラムは飾るのが目的ではない。「実用に供してなんぼ。日本では用の美というらしいですが、どのぐらい目的に合致しつつ美しいかが重要」