NEWS

改修しているコードが空白とタブが混在しているため、SAN値がピンチなzukaです。このようなコードを目の当たりにし、コードの「品質」について真剣に考えてみたくなりました。

はじめに

みなさんは「とりあえず動けばいい！」というコードを量産したことはありませんか？

自分はたくさんあります。

言い訳をすると、「時間がないから」なのですが、このようなことは往々にしてあるものです。 しかし、「とりあえず動く」コードの先に、明るい未来が待っていないことは明白です。

 

• ・理解しがたいコードで、途中参画したメンバーに迷惑をかける
• ・数週間前に書いた謎のコードで、自分自身を恨みたくなる
• ・バグの改修をしたらデグレードし、お客様に迷惑をかける
• ・バグの改修の度に、デグレードの脅威に脅かされる

 

...挙げだすとキリがないのでここまでとしますが、とにかく「とりあえず動く」コードにメリットは(ほぼ)ありません。
※もしかしたらメリットがあるかもしれないので、断言はいたしません...。メリットあれば教えてください。

とりあえず動くコードを卒業

そんな、誰も何の恩恵を受けられないコードを書くことを卒業したい...。
卒業するにはどうしたらよいでしょう？

 

• ・コードを書く前に設計する
• ・テストコードを書く
• ・コード規約に沿ったコードを書く
• ・時間をとってきちんとレビューする

 

...などなど、どれも「時間があれば」断然やった方がよいことが挙げられます。
そう、「時間があれば」ね。

しかし、時間がないプロジェクトが多数を占めているのが現実です。
そんな時間がない中でも、コードの品質を高めるためにできることはあるはずです！

まず、簡単なことから始めてみる

時間がないと嘆いていても、品質の良いコードは生まれません。その嘆いている時間で、簡単なことから始めてみましょう。

時間のない中でもできる品質の良いコードへの第一歩、それはコード規約に沿ったコードを書くことです。

プロジェクト開始時に、コード規約を必ず決めておきます。
コード規約は言語ごとに世にたくさん出回っているので、お好みのものをチョイスします。
あとは、メンバーに周知徹底するだけ。

...が、周知徹底しても必ず規約外のコードが量産されてしまうものです。レビューする時間があれば規約外のコードを指摘することも可能ですが、レビューにはそれなりの時間がかかります。

では、そんな時はどうしたらよいでしょうか？

そうだ、Jenkinsに任せてしまおう！

時間がないのなら、他の人に任せてしまうのがてっとり早い。

そこで、Jenkins氏の登場です。かなりメジャーなお方なので、今更感もありますが...。
Jenkinsに規約外のコードを検知してもらい、かつ検知した場合は叱ってくれるようにお願いしてしまいます。

Jenkinsに働いていただくためには、Jenkinsをお迎え(インストール)し、仕事を依頼(設定)する必要があります。

実は、仕事を依頼(設定)するところがなかなかの難所です。しかし、一度覚えてしまえば流用して使い続けることが可能なので、この難所をなんとか乗り越えて、Jenkinsに存分に働いていただきましょう。

まとめ

「品質の良いコード」と一口に言っても、何をもって品質が良いとするのか、様々な意見があるかと思います。

今回の観点としては、「読みやすく理解しやすい」コードを目指していくことにします。「読みやすく理解しやすい」コードは、バグを抑制することにも繋がり、開発者にたくさんの恩恵をあたえてくれるはずです。

 

次回の連載第２回では、Dockerを活用してJenkinsをお迎えしたいと思います。