「良い」コードとは？

この記事は何？

この記事はエンジニアが徒然なるままに書きなぐったポエムです。

「リーダブルコード」と並んで評される名著「Clean Code　アジャイルソフトウェア達人の技」を読んでみたので、思考の整理のために「良い」コードとは何か？という問いに自分なりに向き合ってみました。あくまでも個人の一意見なので、参考程度に読んでみてください。
皆さんも「良い」コードとは何か？について考えてみるきっかけになれば幸いです。

「良い」コードとは？

皆さんは「良い」コードの定義とは何だと思いますか？そもそも「良い」コードを書く目的とは何なのでしょうか？少し考えてみましょう。

私は「良い」コードとは次のように考えます。

1. 可読性が高い（readableである）
2. メンテナンス性が高い（maintainableである）
3. デファクトスタンダードに沿っている

一つ一つ詳しく見ていきましょう。

1. 可読性が高い（readableである）

まず開発者の皆さんに認識してほしいのは「Code for humans, not machines.」ということです。
昨今の大規模なWeb開発の現場では、何百人が同じサービスを開発していることも少なくありません。時系列の古い新しいを含め、とても多くの開発者があなたのコードを読みます。

一つ例を挙げました。

let y = new Date().getFullYear();

あなたはこのコードから yの意味を悟ることができるでしょうか？JavaScriptや何らかの言語に長年親しみのある開発者にとっては「代入文の現在の年を取得する関数だから、 y は現在の年である」と推測できるでしょうが、新しく入ってきたインターン生はこの一文だけで y の意味を推察できず、その下の何行もある関数の中身をざっと眺めなければなりません。

では、次の場合はどうでしょう？

let currentYear = new Date().getFullYear();

代入演算子の右側は同じですが、命名した変数名が異なります。名前がcurrentYear であれば、読む相手がたとえ今日入ってきたインターン生でもこの currentYear というブラックボックスに何が入っているかを推測できます。

インターン生が y の意味が推察できるようになるまで、30秒かかったとしましょう。一方、インターン生は currentYear の意味が理解できるまで1秒かかりました。およそ30秒の差がありますが、インターン生が50人いたとしたら全体で25分の差につながります。

チーム開発の現場に所属した開発者はまず、一人のエンジニアがコードを書く時間よりも誰かに読まれている時間の方が圧倒的に長い事実を知りましょう。また、一人の書いた何気ないコードが他の人の時間を無慈悲にも奪ってしまういう自覚を持ちましょう。

誰しも幸せになりたいはずです。
ユーザーに幸せを与えるためにコードを書く気持ちは何よりも大切ですが、ボクたちが幸せになるために可読性の高いコードを書くことを覚えましょう。

2. メンテナンス性が高い（maintainableである）

さて、可読性の高いコードは書けたとしましょう。でも、それだけで十分でしょうか？あなたはそのコードに対して何かしらの変更を施し、コミットして、プルリクエストを送らなければなりません。

一つの場所を変更したら、自分は変更を加えていないはずの場所が壊れて思わぬ不具合が出たり、また変更する時の影響範囲が広すぎるがゆえにちょっとした変更が容易でなかったり、はたまたモジュールやコンポーネントが密結合になっているがゆえに同じような処理をする場合でも再利用できずに最初から書かざるを得なかったり、あなたには心当たりはありませんか？

結局のところ、読むのが用意なコードと変更するのが容易なコードとの間には違いが存在します。

メンテナンス性・保守性が低いコードは「内部で分岐が多い」「副作用が多い」「責務が複数ある」といった特徴があります。このようなコードはテストケースが多くなり、バグを生みやすくなります。React界隈でstateが嫌われているのはこういった理由からです。

また自分で実装する前にまず同じことが実現できるライブラリがないかを確認してみましょう。保守性の高いコードを書くより、自分たちで保守しないというのも一つの手です。

3. デファクトスタンダードに沿っている

これは最近、POLの技術顧問でレクター代表取締役の松岡さん（@matsutakegohan1）から聞いた考え方で、「なるほど確かに」と思ったのでご紹介です。以下、「タスク管理ツールは何を使えばいいか？どのように管理するか？」という質問への彼の回答を共有させていただきます。

私がツールなど、何かを選定するときに意識していることの一つは デファクトスタンダードであることです。

Gitのブランチの運用フロー、どうしてますか？ git-flowですか？ GitHub Flowですか？ どっちでもいいんですが、なぜ世の中の会社がその運用方法にしているかって、それがデファクトスタンダードだからです。

もし明日からPOLに他の会社からエンジニアがやってきて、以前もgit-flowでやってましたっていう人がいたらその人はその日のうちにバグを1個くらい直せるわけじゃないですか。逆にPOLの人たちがもし明日他の会社に行くことになったとしてすぐそこで活躍できるわけじゃないですか。

そこはもう僕らのコアコンピタンスでもなんでもない。逆にデファクトスタンダードに沿っていないこと、それ自体が開発組織のウィークポイントになる。だから、デファクトスタンダードを使ってください、という話です。

という話です。

言語やフレームワーク、ライブラリ選定から、命名規則などのコーディングルールに至るまでベストプラクティスやデファクトスタンダード、デザインパターンと呼ばれる概念が存在します。それは、先人たちによる血の滲むような実験と失敗から得られた結果です。巨人の肩に乗り、イノベーションの谷を越えるのです。

でもそれって、本当に「良い」コード？

コードの可読性が高いことは、ユーザーにとってもあなたの会社にいるエンジニア以外の同僚には何も関係ありません。彼らにとって「良い」コードとは、欲しい機能がいち早く手元で動かせるコードかもしれないし、レスポンスタイムが短いコードがより良いと評価するかもしれません。私は、あくまで「開発者にとって」何が善で何が悪かを伝えようとしています。

今までのコードが全て悪いと言っている訳ではありません。逆に今までを創り上げてきた全てのコードとデベロッパーに感謝しています。「過去のコードを笑うな、過去のコードから学べ」という言葉にある通り、彼らの意志を引き継ぎ、意味を与えるのは我々しかいません。よりスピーディにより多くのユーザーにサービスやプロダクトをデリバリするために、一緒に「良い」コードを創っていきましょう。

最後に

「レガシーコード改善ガイド」の著者であるマイケル・フェザーズ氏はクリーンコードとは何か？という問いについて次のように言及しています。

クリーンコードは常に誰かが気配りを持って書いているように見えます。

コードをより良くするのに、すぐにわかるような明白なものは存在しません。こうした事柄はすべて、コードの作者が考えるのです。改善について思いを馳せると、あなたは、あなた自身が座っている場所へといざなわれます。そこであなたは、誰かが残してくれたコードを前に感謝を捧げているのです。

クリーンコードとは、つまるところ気配りされたコードのことです。誰かが時間をかけて、コードを単純で、秩序を保った状態に維持しているのです。

この記事を読んでくれた内の一人でも多くのエンジニアが『「良い」コードとは何か？』という問いに向き合ってくれることを願って、筆を置くことにします。