如何在 Rails 项目中使用 Rubocop 统一程序风格？

团队开发一个Ruby on Rails项目时，写程序的风格很难统一，不管是从其他语言转行过来的老手，或是刚学习程序开发的新手，必定和其他团队成员有习惯不同的地方。适时使用像Rubocop这样的程序评量工具，会让团队的程序风格更趋于统一。

为何要统一程序风格？

Rails的设计风格是「传统比设定更重要」，因此长久下来，Ruby及Rails社群逐渐归纳出一套逻辑，希望在所有开发者都能养成默契，在加入开发各种项目时不会难以接轨。这套逻辑是由Bozhidar Batsov首先制定，称作“Ruby Style Guide“及”Rails Style Guide“。其中包含许多我们不陌生的写法，例如Ruby 1.9推出的新Hash写法，将{：foo =>“bar”}精简为{ foo：“bar”}，诸如此类的规定，不只让入门新手有很详细的参考，资深的开发者也可以依照这套逻辑来统一整体团队的风格。

不过，要花时间检查所有人的程序有没有符合这些规定，实在有点浪费时间，身为一个Ruby程序员，实在没理由不用现成的工具来完成这件事。这类协助检查程序风格并点出问题的工具称为「代码测评」，包括Rubocop、Rails best practices、Flog等，从不同角度来提供我们不同的数据。目前开源工具中最普遍使用的就是Rubocop。

Rubocop简介

Rubocop同样也是由Batsov这位神人开发者所写，只要一个指令，他就会告诉我们哪边的代码有问题。他完全依照Ruby Style Guide和Rails Style Guide内的风格来检查，因此只要把两篇文章读透了，每当产生错误，基本上也不致于到无法理解的地步。

最简单的使用方法就是在开始新Rails项目或其他Ruby项目时，依据说明在根目录下新增.rubocop.yml档案，并将所有需要及剃除的档案列出，接着就像是回家作业一样，每次写完一段程序就执行rubocop指令（或是搭配编辑器的整合功能），看是否有需要修改的地方。当然，他内置有数百个检查项目，刚开始使用一定非常不习惯，例如强迫每个method要保持在10行之内、每个class要保持在100行以内，这些对许多开发者来说都非常头痛。但只要耐着性子，每一次的修改都会越来越熟练，到最后你会发现那些标准的风格写法已经内化，写出来的代码都非常的有质量。

如何用于既有项目

当然，一般的团队在初创时期根本不可能将时间运用在如此奢侈的检测视工具上。大部分开始使用rubocop的项目都是已经有一定迭代的团队，发现团队间的代码风格难以统一，不得已才必须开始使用的工具，除了推行困难之外，要在短时间内解决所有问题难如登天，通常中型项目检查出来的问题都会超过1000个以上，不安排个两三个月，根本无法修复。

最好是在项目根目录的.rubocop.yml当中先将全部的检查项目关闭，确认无误后再逐一解开，藉由一个一个项目的修复，团队也比较容易培养默契。

这样一来，团队可以优先处理最容易有bug的问题，例如在项目当中写了binding.pry这样的中断功能，却没有在推送时拿掉，这样让其他团队成员接手开发时发现服务器会在莫名的地方暂停。

整合服务

Rubocop执行非常方便，而在团队管理上也有非常方便的整合工具。例如为了确保团队每个成员都有乖乖使用这个工具，就可以利用像Code Climate这样的持续整合（continuous integration）工具，让每位成员在将程序推送到Git服务器（例如GitHub）上时，可以设定自动检查是否有风格问题，只要不符合就会跳出警告，让所有漏洞无所遁形。基本上只要连续出现数个错误，大概就可以判断这个成员根本偷懒没执行这个工具了！

另一个很方便的服务是HoundCI，同样将程序推送到Git服务器时，会自动检查，更神的是会自动送出pull request，用以自动修正错误，这些整合服务都能在项目管理上加快速度，并且维持程式品质的良好。

小结

在项目中要统一风格并非易事，而自己身为开发者要能遵循这些原则也要花上一段时间。但随着项目的逐渐扩大以及团队成员的增加，使用这样的自动化工具来增加管理效率，才是像Matz所说”work hard to be lazy“的精神，只要先把原则建立起来，后续要管理就方便多了！共勉之！