良いコードを書くために意識していること

ども、@kimihom です。

今日はこちらの本を一気読みしたので、それの感想と自分の思うところを書く。

まず、著者の縣さん。リモートで1回/リアルで1回お会いしたことがあるのだけども、個人的にものすごく尊敬している方だ。というのも、日本で自己資本x自社サービスで軌道に乗せた第一人者的な立ち位置にいるエンジニアだと思っているからである。私も自己資本自社サービスでやってる会社の CTO なので似ている部分がある。彼はメールで連絡したら、名もない一人のエンジニアの私が作ったサービスをすぐに登録して使ってみてくれて、フィードバックをくれた方だ! あの時の感動は今でも忘れられない。この体験を通して、私も自社サービスがうまくいってきたら、その後に出てくる色々な Web サービス開発者を投資以外で支援できるような人になっていきたいと思ったほどである。

そして本書を読んでみたら何と自社で Web フレームワークも作っていたという過去を知った。まさに日本の Basecamp だなぁと改めて感じた。おそらく国産 Ruby on Rails 的な立ち位置を目指してそのフレームワークの開発は始められたのだろう。実際、当初は Seasar はかなり盛り上がっていたからな。この開発は結局止まってしまったみたいだけど、オープンソースの Web フレームワークに関して今度お話を聞いてみたいなという純粋な感想を抱いた。

良いコードを書く

さて、だいぶ個人的な体験の前置きが長くなってしまたので本題に移ろう。本書を読んでみて思ったのは、「そうだよね」っていう同意が90%以上。本を通じて言語化されていたように思える。私も前職ではコードレビューをひたすらやっていた経験もあったりして、そこら辺の基本は身についていたのだろう。独学で磨き上げのスキルで育った方には、一回読んでみると一般的な企業がどんな視点でコードレビューしているのかとかがわかって、より良いコードが書けるようになるかと思う。

さて、以下は私が思ういいコードを書けるようになるための方法について書こう。

「誰かが書いたひどいコードを読む」ってのはまず一つ目にいい方法だと思う。そのひどいコードってのは、改善の宝庫だ。どの分をどうまとめて、効率よく書けるのかを一緒にコードを書いた人と議論することができる。そうしてレビューする人とされる人それぞれが成長できるのである。コードレビューのいいところってそこだよね。

そういうのは基本的にフレームワークに乗っかったコードなので、基本的にはちょっとしたメソッド分けとか、やったとしてもクラスに分けたり程度だろう。そこから先のいいコードを書くためにはどうしたらいいか。

私はバッチフレームワークを書いてみるのをお勧めしたい。 Web フレームワークはもう世の中に出回ったのを使えばいいし、基本的な認証とかも全部ライブラリで揃っているから、車輪の再発明ってのはあまり楽しくないと思う人も多いことだろう。しかし、バッチフレームワークは割と自前でゼロから書く場合が多く、これはデザインパターンとかを駆使して構造化された正しいコードを書くのにいい練習になる。そもそもデザインパターンってのも、いいコードを書こうとして考えた結果のパターんをまとめたものに過ぎないので、それなりに訓練の詰んだエンジニアが共通認識として言語化された程度のものである。だからまずはしっかりとコードを書くってのが大事だ。

私の場合は、あらゆる外部サービスと連携して顧客データをインポートしたりメッセージを外部サービスに送ったりするようなツールを作っている。それぞれの外部サービスをストラテジーとして定義し、差分以外の部分をフレームワーク化して共通にしていくのである。結局フレームワークってカッコよく言っても、ちょっとずつ共通化して使いやすくしていく改善に過ぎないので、恐れずに始めて行けばいいんじゃないかな。

ちなみに、ちょっとプログラミングできるようになると黒魔術たっぷりなメタプログラミングなコードを書くことになる。そして後で使ってみるとめちゃめちゃわかりづらくメンテしづらいものができたことに気づくだろう。このような後悔もやればわかるから、後悔するほどにメタプログラミングにどっぷりやってみるのをお勧めする。

オープンソースのコードを読むってのはよく言われる訓練の方法だが、ゼロから読んでいくってのは集中力が続かないので、バグが起きたら徹底してコードを読んで原因を探るような習慣をつける程度でいいと思う。もしうまく見つけられたら Github でプルリクエストを送ればコントリビュータにもなれるし一石二鳥だ。

いいコードを書けば、サービスに愛情が湧く

良いコードを書くってのは大事だ。良いコードでできたサービスは、大切にメンテナンスしたくなる。より良いコードにするために既存機能を壊さずにリファクタリングを積極的に行ったり、そのためにいいテストコードを書いたりする。もっとこうしたら良くなる、ってのをどんどん手をつけて、余計なものが削ぎ落とされた、それはそれは美しいコードってのが出来上がる。これはもはやプログラマの美徳のようなものだ。

逆にたくさんの人が手がつけて汚くなってしまったサービスのコードはメンテナンスしたくなくなる。そうすると、できるだけ傷をつけずに用件を満たせるような方法を探るようになる。そんでたまにバグの沼にはまってしまった時は「アチャー、ついてないな」と思いながら時間を潰すことになる。そんなサービスのメンテナンスはつまらない。

ここまで書けば、どっちがいいかなんてのは明確だね。必ずいいコードを書こう。そして妥協は絶対にしないこと。未来の自分の宿題を作らないこと。そういうプロフェッショナルとしてのプログラミングを行えば、今後の自分はよりハッピーになる。

そのためには、中途半端なプログラマを雇ってはいけない。彼らは何も考えずにコードを汚していく。コードレビューって言っても、その汚いコードに対して全部書き直せ！なんて言えない場合もあり、基本的にできない人が書いたコードが積もってどんどんとサービスのコードを汚していく。本物のプログラマは、サービスのコアのコードであっても、ダメなコードなら勇気を持って削除して描き直せる人である。そういった人が起こしたバグを責めてはいけない。むしろそれで良くなっているのだから、テストコードなどをしっかりと書いてサポートすべきなのだ。

「機能変わらないのに時間かけてプログラミングするって意味あるの？具体的に言うと今後の開発でどれくらい工数が削減されるの？」とか言うビジネス野郎の意見なんて無視してしまえ。彼らはプログラミングのプの字も知らない奴らだ。サービスのメンテナンス性や柔軟性を高められるリファクタリングがどんだけ大事かはプログラマにしか具体的な効果を実感できないのだ。

そのような強い思いがより良いコードを生むための源になるだろう。サービスやソースコードに強い意志を持っている人が結局はいいエンジニアになっているのである。