Viibar Freaks

株式会社Viibarのブログです。Viibarを色々な角度からご紹介していきます!

コードリポジトリは適切に剪定していきましょうという話

f:id:Viibar:20160902143013j:plain

こんにちは、Viibarエンジニアのshrkwです。好きなgemはdeviseです!

前回はリードをやってくれているgaoohがViibarでの開発で大切にしていることを書いてくれました。そのなかで言及のあった、 機能の削除やコードの整理について掘り下げたいと思います。

ちなみに僕は入社して9ヶ月くらいですが、消してる量の半分しかコードを追加していません。マイナスの生産量ですね。

f:id:Viibar:20160902141626p:plain

 

なぜ削除するのか

機能とコードの2つの側面からみてみます。これらは本来的には同一であるべきですが、機能を落とすことが先に行われ、コードの削除は後追いになるケースも多いと思います。

なぜ機能を削除するのか

こちらの判断は比較的シンプルで、ビジネスに価値を提供できていない場合、その機能は削除するべきです。

- 変化したビジネスに追いついていない

- ユーザーを混乱させている

- ユーザーに使われていない

- その機能から得る対価が管理するコストに見合っていない

これらの場合、その機能は削除するべきでしょう。

なぜコードを削除するのか

なぜコードを削除するべきなのか、ある意味自明な問いかけですが、いくつかの要素に分解してみます。

バグのリスク

使われていない機能はそれだけメンテされにくく、バグが発見された場合でも積極的な改善は見込めないでしょう。バグが存在すること自体がすなわち悪いわけではありませんが、潜在的なリスクとなっていることは間違いありません。

言語、フレームワークのバージョンアップを阻害するリスク

例えば言語やフレームワークのバージョンアップをする場合や、全体に影響するライブラリを入れ替えたりする場合にはシステム全体をチェックしなければなりません。型の弱い言語では特に顕著ですが、型が強くてもチェックはしますよね。

そんなときに使われていないコードまで管理するとしたらうんざりしてしまいます。

教育のコスト

新しいエンジニアが増えたときにこのコードは使っていないということをいちいち伝えなければならないし、また、教えられた側はそれを記憶しなければなりません。こんな行為は意味がなく、ビジネスの価値を提供せずに、ただ単に教えられた側の脳のリソースを消費するだけです。

ドキュメントを残せば良いとも思うかもしれませんが、そんな悲しいドキュメントを残すくらいならば、いっそ削除していってしまいましょう。

間違った教育のリスク

例えば新しいライブラリを入れたりしてコードの書き方が変わったときに、使われていないコードは更新対象から漏れやすいです。新しいエンジニアが参考になるコードを探している時に、そんな古いコードを参考にしてしまったら、良くないコードから良くない方法を学んでしまう可能性があります。

レビューで指摘するコストがかかるのもよくはないのですが、もしレビューを通過してしまったら良くないコードがさらに量産されてしまう恐れがあります。

どう削除するか

機能を削除することが決まったら、必要であればユーザーへの通知を行い、その後、導線の削除を行います。

導線を削除するのは、単純にリンクを削る、差し替えるなどを行いますが、メールなどでリンクを載せている場合は、削除する機能へのリンクはリダイレクトに差し替える必要があります。新しいページ、もしくはトップページへのリンクとなるでしょう。

アクセスがなくなっていることをログなどから確認できたら、実際の削除のプロセスへ移ります。

コードの削除

ViibarはRailsでサービスを開発しており、以下の様な順序での削除を推奨しています。

基本的に、ほかのコードへの影響が少ないところから削除していって徐々に影響範囲の大きいところを消していき、データ自体の削除を最後にしています。また、データについてもバックアップの残し方を整理しており、なるべく考えなければいけないことを減らすようにしています。

1. script, job, job spec

2. view template, partial, layout, css, js, feature spec, mail template, mailer method, mailer spec

3. controller, controller spec, config, config/routes.rb, (routes.js)

4. model, model spec, decorator, factory

5. table, column

だいたい、1,2を同時に行い、残りの3,4,5を順を追って実施していくという流れにすることが多いです。

また、Viibarでは開発フローについてのドキュメントを用意しており、そのなかで削除のプルリクエストを作る際の雛形を以下のように用意しています。この雛形からそのPRが対象とするところ以外を消して、あとはチェックリストにチェックをしていけば作業の漏れを減らすことができます。

### 事前

```
$ git ls-files | grep -i foobar
$ git grep -i foobar
```

### チェックリスト

- [ ] script
- [ ] job, job spec
- [ ] partial
- [ ] layout
- ref. layoutの被利用状況を整理したスプレッドシートへのリンク
- [ ] css, js
- [ ] view template
- [ ] feature spec
- [ ] mail template, mailer method, mailer spec
- [ ] controller, controller spec
- [ ] config, config/routes.rb, (routes.js)
- [ ] model, model spec, decorator
- [ ] factory
- [ ] relation
- [ ] table, column

### 事後

```
$ git ls-files | grep -i foobar
$ git grep -i foobar
```

まとめ

ほとんどのサービスは生き残ることがないのだからメンテナンスよりとにかく速く作ることが大事!というのも真実です。ですが、Viibarのサービスは幸運にも生き残り続けており、今後も伸ばし続けていくつもりです。

そんな状況では、意識的にコードを整理整頓していかないとあっという間に管理不能になってしまいます。すでに散らかっているからといって、掃除をしないでいい理由にはならないのです。ぼくたちは、考えるべき余計なことを減らして、やりたいこと、やるべきこと、価値を提供できることに集中できる環境にする努力を続けています。これは、Viibarには比較的経験豊富なエンジニアが多いことが影響しているのかもしれません。

Viibarではこのような、サービスのライフタイムを考えた開発に共感できるエンジニアを絶賛募集中です!