コードを消すことを恐れない

ども、@kimihom です。

f:id:cevid_cpp:20200611154855j:plain

今回はプログラミングにおいて最も難しいタスクの一つである、「コードを消す」ことに関して意識していることを記す。

なぜコードを消せないか

コードを消してシンプルにしていくこと。これはプログラムをメンテナンスしやすくして、バグ修正や開発速度を高めるために非常に重要なタスクである。

それなのに、なぜコードを消せないか。しばらくサービス開発運営を続けていればわかることだが、多くのリスクを感じてしまうからである。

このコードを消すと、きっと他のどこかに影響が出てしまうんだろうな
勝手に消すとコードを書いた A さんに悪いな
コードの量こそ資産。それを消すなんて資産をなくすのと同等
ひとまず残しておいて、サービスがうまくいったらゼロからリプレースしよう

エンジニアの多い組織での課題

とりわけ、エンジニアの人数が多い組織だと、コードを消すのではなく、システムをゼロからリプレースするってので対応しているケースをよく見かける。インフラからフロントエンドまで、全てを作り替えようという形でエンジニアに新たなモチベーションを与えることができる。そして、最新技術を採用することで、採用にもプラスに働くといった形だ。

チームの人数が多く、リプレースするほどの時間を確保できるのであれば、やる価値がある場合もある。だがそもそも、しっかりとコードがメンテナンスされていれば、今動いているソースコードで新しい技術を採用するなんてことはいつでも可能である。リプレースは同じ作業の繰り返しが90%以上であることを意識すべきだ。単にプログラミング言語やライブラリが替わるだけで、かつて自社の誰かが実装してくれたことをまた実装し直すことに時間を捧げなくてはならない。

エンジニアの多い組織でも、そのエンジニア全員が優秀・ベテランであれば、消すって判断を恐れないチームになる。しかし、エンジニアの中でビギナークラスが一人でもいると、その人がコードを消すなんてことはまずできない。初心者の書いたコードは、間違いなくコードレビューを通すことになるだろうが、レビューする側もじっくりレビューするなんてことは時間の関係もあって難しい。そもそも、レビューをするエンジニアリーダークラスになると、そもそもコードを書かなくなって、その初心者エンジニアに開発を任せるといったチームも多くある。そうして、新規追加されていったコードがどんどんと増えていく。

自社で書いたコードだけでなく、ライブラリのコードも消していく

とりわけ新規プロジェクトの場合は、時間を節約するためにライブラリを大量に取り入れて実装するケースもよくある。最初は問題ないんだけど、しばらくして問題が多く発生してくる。

まず、ライブラリが少ないと、ライブラリのアップデートも簡単になる。ベースのプログラム言語やフレームワークのバージョンをアップデートするだけでシステムの速度は劇的に速くなっていくメリットがあるのに、ライブラリが多いとそのアップグレードが大変すぎて諦める選択をするケースがある。本当に必要なライブラリだけを残し続け、それ以外の自前実装でもできそうなシンプルなライブラリは、できる限り使わないようにしていくと、メンテナンスがより簡単になる。

ライブラリのアップデートには2タイプあって、一つは機能追加。そしてもう一つはパフォーマンス改善である。作られたばかりの新しいライブラリでは、ほとんどが一つ目の機能追加が中心でアップデートされていく。ライブラリを既に満足して使っていた側からすると、単にそのライブラリが複雑になるだけで、この機能追加でアップデートする価値はない。しかし、二つ目のパフォーマンス改善は、全てのライブラリ利用者にとって嬉しい改善だ。パフォーマンス改善を積極的にやっているライブラリかどうかは、そのライブラリを使うかどうかの判断材料になる。

自分が使うライブラリを数少なくして選択するようになると、その数少ないライブラリに愛着が湧くようになる。ライブラリを一緒にメンテナンスしていくことになるので、もし何か問題が発生すれば、ライブラリのソースコードまで読んで必要に応じて修正するような作業をしていくことになる。ここまでできるようになって、初めてエンジニアとして一人前になれるといっても過言ではない。さらにそのライブラリのコードを消すくらいまでになれれば、かなりの上級プログラマだと言えるだろう。