私はセルネッツでQA（Quality Assurance）エンジニアとして、品質保証のためのテストを実施しております。
QAの業務内容は会社によって違いますが、製品が仕様に沿って動作するかを確認したり、
不具合によるシステム障害を回避するためにどんなテストをすべきかを考えたり、開発エンジニアでは気付きにくい不具合を検出して品質を保つための試行錯誤をしています。
そのような業務の中で今回は、ソースコードをレビューしていて見つけた可読性の低いコードを掲載およびそれらをセルネッツ的にどのように改善すべきかの指針を示したいと思います。
可読性が低いコードって良くないとなんとなくわかっているけれど…
「動けばとりあえずいいんじゃないの？」と思っている方って意外と多いのではないでしょうか。
よく周りから「可読性が高いコードを！」と耳にすることがあると思います。
もし他人が書いたソースコードに対して修正や追記する場合、チラっとコードを見ただけで「見やすい！」「きっとこんなことがしたいんだろうなー」と分かるとミスも少なく修正や追記をしやすくなります。
これはメンテナンス性が高いということに繋がります。
逆に可読性が低いコードの場合メンテナンス性が低いということになります。これは誰もそのソースコードに対してメンテナンスができなくなってしまうということです。
では、そもそも「可読性」とはどういうことなのでしょうか？
「可読性」とは読みやすさのことです。コードが頭に入ってくる時のスムーズさとも言えるのではないかと思います。
コードをぱっと見ただけで、「読みやすい」、「きっとこういうことがしたいんだ！」と理解できる書き方がされているかどうかということです。
開発者は初めから「可読性が低いコードを書こう！」と思ってコードを書いているでしょうか？
きっとそんなことはないはずです。ではどうして可読性が低いが生まれてしまうのでしょうか？ いくつか原因はあると思いますが以下が原因の上位になるものではないでしょうか。
可読性をあげることは大切とよく言われますが、それはいったいなぜなのでしょうか。
大きな理由は以下の点です。
| 理由 | 詳細 |
| メンテナンスのしやすさ | ソースコードは一度書いたら終わりではありません。 改修や機能追加など様々な理由で追記や書き換えが当たり前のように発生します。 また、自分だけが見るものではなく多くの人が見ます。 可読性の低いコードの場合、自分が書いたコードであっても時間が経つと何をしているか理解できないことが発生します。 であれば、当たり前ですが他人はもっと理解できません。もしその開発者がいなくなってしまっていたら… 可読性が低いコードはメンテナンスできないことに繋がります。 |
| コードの間違いに気付きやすくなる | コードの間違いに気付きやすくなるのです。 可読性が低いコードは読みにくいため書いてある処理を理解するのが難しくなります。 そのため間違えに気付きにくくなります。そうするとバグの温床になってしまいます。 さらに怖いのはバグを見つけられないまま開発したシステムが世の中に出回ってしまう可能性があります。 |
ではここで実際に可読性が低いコードの例をお見せします。※一部抜粋しております
ソート処理の一部です。
罫線を描く動作をマクロ記録したものです。
1つの処理をするだけで長い長いコードが書かれており、見やすいとはコードとは言えません。
セルネッツは、VBA開発の前にExcelを使用しているということを前提としています。プログラムですべて解決しようとせずにExcelの機能もうまく活用します。
自分で一から考えてシステムを動かすことは素晴らしいですが可読性を意識し、どうしたら見やすいコードでやりたいことができるのかを考えましょう。
上記コードの例のそれぞれ改善案をご紹介します。
ソートをしたい場合VBAならこれだけで済みます。
VBAのライブラリを使えば可読性も高く、バグが潜むリスクがかなり減ります。
罫線を描きたい場合は別シートに「書式シート」を用意し、コピーする一行だけで済みます。
このようにすることで罫線を変更したい場合でもソースコードを書き換えることなく対応可能です。
可読性が高いコードと聞くとハードルが高く感じてしまう方も多いと思います。しかし、第三者に見せることを前提に開発するようにしたらどうでしょうか。
まずは「どうしたら見やすいコードでやりたいことができるか」を意識しながら開発を行っていくと可読性の高いコードになっていくと思います。それがメンテナンス性の向上に繋がっていくのです。
メンテナンス性が向上することにより開発の工数を減らすことができます。よって、低コストで品質の良いシステム開発ができるのです。
