1.はじめに
こんにちは。かじです。
最近、読まずに棚にしまってあった、リーダブルコードをようやく読み終えました。プログラマが読みやすく保守性の高いプログラムを書くためのコツをまとめている内容で、決して難しいことが書かれている訳ではありませんでした。しかし、よくよく考えてみると、なぜリーダブルに書けないんだろうかと思えてきました。
どういう処理構造になっているのかよく分からず、誰も触れたがらないコードを見たことは誰でも少なからずあるでしょう。
数千行にも及ぶの中で、変数には何の値が入っているのか、if文では何を判定しているのか、フラグが多すぎて何を確認しているのかわからなかったり、バグの原因になっていたり、そもそも動作していることが奇跡に思えるソースコードだったり。etc.
今日は、そんなプログラマあるあるが何故起こるのか、何故みんなリーダブルに書けないのかを考えていきたいと思います。
2.リーダブルに書けない原因その1 – 人的問題
まず一つ目は、人的問題、つまりプログラムを書く人そのものの問題があると思います。一番分かりやすい原因です。経験が足りない、保守性を意識していない、技量が足らないなど、プログラマ自身の問題になると思います。
シンプルな問題である一方で、一朝一夕で解決できないというのが、この人的問題かと思います。人材育成という面では、年単位で時間がかかることは必須ですし、教育する側の人材を確保するという点で、ダブルで難易度が高い問題かと思います。
コード規約の遵守の徹底やソースレビュー文化を作りながら、プログラマを教育していくという視点が必要になるかと思います。
3.リーダブルに書けない原因その2 – スケジュール的問題
スケジュールに時間がないために、機能の実装さえできればいいとリファクタリングできていないということがあります。ソースを見直すことに時間を費やすことができない、リファクタリングすることによってテストに工数が増えることを恐れてできないみたいなことがあるとおもます。
理想論ではありますが、製造やテスト工数を見積る際は、リファクタリング込みで算出するというPMやSE側の努力が必要かと思います。
4.リーダブルに書けない原因その3 – 保守上の問題
そもそも、現状動いているシステムがリーダブルじゃないということは多々あるかと思います。冒頭でもあるように、何故動いているか分からないようなシステムの改修時には、最低限の改修だけして、スパゲッティコードをそのまま放っておいてしまうということがあります。
何で動いていたか分からないけど、構造を直すには莫大な時間がかかってしまう。バグを生む原因になってしまったら、改修した人間の責任になってしまう。コードを広く直すことによって、追加機能以外の部分についてもテストをする必要が生じる。など、既存システムのスパゲッティコードを直すことにはネガティブなイメージが付きものです。
既存システムにプログラムが複雑になってしまっている場合は、コメントや設計書で修正点や問題点を残しておき、機会があった時に修正すると言う意識を共有することが大事かと思います。ただ、これでは問題の先延ばしにしている感は否めませんが。
5.リーダブルに書けない原因その4 – 組織上の問題
ここまで、3つの原因を書いていましたが、根本的問題として、組織上の問題に行き着くと思います。リリースや納品前にソースレビューをしないことは流石にないかもしれませんが、そもそもコード規約がないとか、リファクタリングの意識が少ないということ、工数やスケジュールに重きを置きすぎている、既存システムのプログラムがスパゲッティになっていることの認識不足など。組織の体質の問題になります。保守性の高いプログラムを書いたところで、機能的には変わらないので、一見すると営業的に売上に関係がないように感じてしまいます。しかし、その保守性の低さを放置したプログラムは、バグを多発して、後々ボディブローのように効いてきて、莫大な工数を生み出してしまう可能性があります。
これ自体は組織全体で文化を培う、仕組み作りを行うなどで対策をしていくしかありません。具体的な対処法はありませんが。
6.まとめ
ローマは一日にしてならずといいますが、リーダブルコードも一日してならず。
自分一人だけではなく、チーム全体で同じ意識を共有してプログラミングに取り組むことができるよう仕組みづくりを上流から下流まで全員で考えていく必要があります。
時間がかかる作業ではありますが、仕組みができてしまえば効率よく高品質なものを納品することができるようになります。最初は小さい歩みですが、後々効果が出てくる取り組みになると思います。
今回はここまでになります。最後までお読みくださりありがとうございました。
コメント