「コードの品質を維持したまま開発スピードを上げる」を読んで


コードの品質を上げてスピードアップ

元記事はこちら
このジレンマは常につきまとっていて、プログラマの永遠の課題みたいなイメージ。でもこれっておかしな話で、なぜコードの品質を保つ必要があるのかと言えば、開発スピードをあげるためなんですよね。(他にもバグの発生を抑えるというのもありますが)
となると、開発スピードがどのくらいあがるのかっていうのがもう少しちゃんとわかるといいのかなーなんて思ったりしました。
スピードがあがるっていうよりかは、突貫のまま実装をしていったときに開発スピードが落ちてしまうよっていう考えにしないといかんのです。

Quaraさんがやっていることを参考する

現在はRuby On Railsで開発して、Githubでコードレビューしてます。

コミット後のコードレビュー

これはなかなか難しそう・・・

実際に実行をして、とりあえずものとしてできたのを確認した後でコードレビューっていう話だと思うのだけど、コードレビューをした後はまたテストをすることになる気がしちゃうので2度手間のイメージがあるし、コードレビューをして、「あれ、これ結構直さないとだめじゃん」みたいな場合に悲惨になりそうです。

私たちがコミット後にレビューを行えるのは、1人1人の開発者を信頼しているからです。私たちは優秀な人材しか採用しませんし、採用後は彼らのコードの品質に関する教育やツールに力を入れています。

ここから見る限りも結構レベルの高いコードを書いているイメージなのである程度最初に質の高いコードが書けていれば問題ないのかな、といった気がします。

ただし

そして、私たちは変更の種類ごとに、異なったコードレビュー基準を実行しています。エラーや失敗によってコストがかかり、致命的な問題が起こる可能性がある時には、普段行っているコミット後のレビューの代わりに、コミット前のレビューを行うことにしています。

時と場合にで分けてはいるようです。

 

コードレビューのルーティング

ここに関しては今そんなにエンジニアがいないので、みんなで見る、みたいなっているので取り入れなくてもいいかなーって思ってます。

僕の中ではコードレビューはコードの品質を高める意味もあるけど、コードの共有という意味も含まれているので、だれか詳しい人っていうよりかは、みんなで見るほうがいいかなと思います。

でもレビューワーをファイルにメタ情報として追加して、指定するやり方は面白いなと思いました。

テスト

ここはあまりできていない・・・

Railsを使っているのでRspecでテストしてますが、なんかこう意味のあるテストができている実感があまりない。

仕様変更があった時に、テストコードを直さずにテストを動かしたら、「テストが動かないじゃん」みたいになってテストを動かすためにテストコードを修正する、みたいな感じになってしまってます。

まあ、これはテストコードから最初に直せっていう話ではあると思うのですが・・・

コード品質のガイドライン

これはもう少しちゃんとやろうと思いました。

他でガイドラインあるので、それをそのまま頂いて、メンバーに浸透させていきたいと思います。
こういうのってどうやって、浸透させればいいのかな?コードレビューのことあるごとに、ここがガイドラインここに違反しているよ、的なのを織り込んでいければいいのだろうか。

メンバーがみんなちゃんと頭にはいって意味のあるものになると思うので、作ったあとの運用をちゃんとしたい。

古いコードのクリーンアップ

これはすごくいい。是非やりたい。

実際どんな感じかわからないけど、イベント的に定期的にやっているっていうのがいいなと思いました。

Lint

この辺はコードレビューで補っていた部分ではあるのですが、自動化できるならした方がいいですよね。Quartみたいに自前のLintを作るのは厳しそうなのですがruby-lintなるものがあるので、これは使ってみようかと思います。

まとめ

どれも参考になるものばかりだったのですが、この手のものが出来ない理由はやはり「やった結果どうなるのかがわかりづらい」っていうところにあると思うので、ここをエンジニア以外の人に説明できるように、うまく言語化・数値化できるようになりたいです。

コメントは受け付けていません。