(このブログを書いてたら、ちょうど昨日こんな投稿がバズってました) togetter.com
「綺麗なコードの書き方」「綺麗な設計の考え方」などについて、これまでプログラマの世界では多く語られてきていると思います。
リーダブルコードをはじめとして、書籍なども多数存在します。
ただ、これらの技術はプログラマの自己満のように捉えられることも多いです。
「綺麗なコードを書いてもユーザーには関係ない」という意見を言う人もいます。
個人的にはそんなことは全くないと思っているので、僕の考える「綺麗なコードを書く、設計をする」ことがプログラマだけでなく、プロジェクトやユーザーに与えるメリットをまとめてみました。
不具合が発生しづらくなる
まずシンプルにこれですね。
不具合は当然ながらユーザーにとって大きなストレスになるので、少なくなればなるほどそれだけでUXは上がります。
分かりやすい、適切なロジックになっていれば、バグは生まれにくいです。
パフォーマンス、セキュリティを適切に考えられている設計になっていれば、思わぬ攻撃にあったりアクセス増加があっても耐えられます。
各処理が疎結合になっていて、互いに影響しにくい設計になっていれば、改修時にデグレが起きづらいです。
逆に密結合になっていて各処理を変更した際の影響範囲が広い作りになっていると、改修した時に認識が漏れてテストされず、デグレに気付かず不具合につながるということもあります。
実装しやすくなることで機能追加とかもしやすい
スマホゲームやWebサービスで運用していると、その中で機能追加や改善などはどんどんやっていきます。
この対応を素早く、柔軟に対応できることは、ユーザーにとって喜ばしいことです。
綺麗な設計、実装になっていると、前述のように改修する時の不具合のリスクが減ります。
さらに言うと、影響範囲がどうなっているのかとか、改修前に色々と調査する時間も減るし、安心して改修できるようになります。
これにより運用中のプロダクトも、機能追加や改善などがやりやすくなります。
逆にいわゆるスパゲッティコードになっていたり、一箇所改修するとどこに影響が出るか分からないような作りになっていると、スムーズに対応することができなくなります。
最悪の場合、「ここはヤバくていじれない」と機能追加を諦めなければならない事態も発生します。
(レガシーコードのシステムを運用したことのある人なら一度は経験しているのでは)
品質が上がると時間が増える
ここまでも少し書いていますが、品質が上がると必要のない対応に使う工数が減り、時間が生まれます。
その時間を使うことで、より多くの開発をしたり、さらに品質を上げるために時間を使ったりと、ユーザーがより良い体験をするための時間を作ることができます。
不具合が減ることで、その分の障害対応などに割く工数が減り、時間が増えます。
スマホゲームやBtoCのWebサービスなどでは、なにか障害が起きると不具合の改修対応はもちろん、その補填対応、CSでのお問い合わせ対応など様々な工数が発生します。
こういった意味でも、品質を上げることは大きな価値があります。
もちろん綺麗なコードを書くだけでこれが完全に担保されるわけではありませんが、問題の一因としてはあると思います。
エンジニアの精神衛生が良くなり、より良いものを作れる方向に向かう
これは副次的な効果ですが大事なことで、綺麗なコードになっていることでそれをいじるエンジニアの精神衛生が良くなります。
それにモチベーションも上がりやすくなり、パフォーマンスの向上につながります。
生産性が上がればより多くのものを作れるというのもありますが、ポジティブなモチベーションの人が作ればより良いプロダクトになるというのもあります。
これは目に見えづらいものですが、すごく重要なことだと思います。
汚いコードや障害対応はストレスが高い
不具合発生時の障害対応というのは最もストレスのかかる作業だったりします。 あと、汚いコードはぶっちゃけ読むのもいじるのも辛いです。
まず中身を把握するのに時間がかかるし、読んでると頭が痛くなってきます。
改修する時にも、「ここ触るとどこまで影響があるんだ・・・」とか「あれ、この処理どうなってるんだ・・・」とか余計なことを考えなくてはならず、それもまたコストです。
そういった考えなくてはならない「余計なこと」が減ることで、精神衛生も良くなり、パフォーマンスも上がります。
モチベーションが上がると、いいものが作れる
汚いコードを触っていて精神衛生が良くない状態だと、自然とモチベーションも下がってきて、開発に対してネガティブな気持ちを生む要素となります。
綺麗なコード、美しく設計されたシステムを触っている時は、そのネガティブになりうる要素をへらすことができます。
そして開発に対してポジティブな状態になることで、より良いものが作れる可能性が上がります。
例えば開発しながらプロダクトに対して改善案や意見を出したり、プロジェクトに対してもポジティブな発言が増えやすくなるのではないかと思います。
逆にネガティブな状態ではそういったことへの意識は向きづらく、さらに後ろ向きな発言が増えてプロジェクトの雰囲気にも悪影響が出やすくなります。
マイナスを減らすことの価値は理解されにくい
ここまで書いてきたメリットは、
- 不具合が減る
- 余計なことを考える必要がなくなる
- 精神衛生が良くなる
など、マイナスを減らすことでプラスを生めるという性質のものが多いです。
ただ、こういった類のものはなかなか理解されにくいところがあります。
なぜなら、これらを考えるために、最初作る時にかける時間は多少増えるから。
ただ、そこで時間を短縮した分は、基本的に後で跳ね返ってくるものだと思っています。
なのでどうせ使う時間なら、先にやっておいた方がいいです。
作る時に使った時間は1回限りでも、その後にそれを触る度に、遭遇する問題は運用が続く限り何度も使う時間なので。
(と、分かっててもなかなかできないことが多いんですけどね・・・)
