Rails 英文原文：Practical Rails Dev Tips to Improve the Code You Produce

大多数贴士和技巧，对于开发人员的重点是知识、经验或沟通技巧。虽说这些肯定是有用的因素，但是它们对于学习者能有效地执行还是太过抽象了。

成为一个更好的开发者没有捷径，但是这里一些实践和工具将肯定会有帮助。这里我将会分享一些东西来提升代码和产品，也提升开发者的水平。

这些是建议不是教条，请依据情况进行调整。

实现和加强编码风格指南

Ruby 是一门富有表现力的语言。有了这种表现力，就会有一百万种风格的代码来完成任务。统一这些风格有助于统一一个代码库，使其更容易地理解并更愉快地在其中工作。使用 rubocop 可以实现这一点。Rubocop 具有可让你调整和细化为你的喜好的预定义风格。不过现在讨论的不是你的编码风格，而是整个代码库风格的统一性。

但是你现在的项目代码风格十分杂乱？Rubocop 可以忽略已存在的违反风格指南的地方，让你随时修复。如果你愿意，它甚至会尝试修复违反风格指南的代码风格。

加强代码风格在个人和团队项目上是非常具有挑战性的。使用自动化工具强制执行这些风格，例如 guard-rubocop, CodeClimate, Hound 等，以防止提交错误风格的代码。为避免代码被污染，可以使用像 reek 这样的工具。

尽早收集性能指标

你可能已经在其他地方读过或者听过这句话：

“在大约 97％ 的时间里，我们应该无须关心效率问题：过早的优化是所有邪恶的根源。”—?Donald Knuth

这句话被引用了很多次，是个好的谋生建议。优化的时间通常是没什么警告的，所以当那一刻到来时，最好能很好地了解当下的情况。当性能成为问题时，已经有了的这些信息是非常有用的，而不是试图在迫在眉睫的时候才收集它。

使用 Librato 和 Skylight 等检出工具来收集产品的性能指标。另外，请参阅这个优秀的 gem rack-min-profiler，用于每个请求的性能指标。

避免耗费大的数据库查询

如果说过早的优化是不幸的根源，那么对性能差劲的代码的无知与其有着紧密的关系。当编写 Rails 代码时，通常会出现这样的情况：思考不足、未使用或使用代价昂贵的数据库查询。

Rails 的性能对于大多数 webapp 来说，通常是 “足够快的”。差的性能通常被归咎于 N+1 查询导致的数据库的数据多次往返。大多数性能监测工具都能识别这些问题，不过我们应该从一开始就避免它们。在开发中识别和消除这些问题可以使用优秀的 bullet gem。它会分析你的页面，当你加载的数据没有被使用或者有机会消除 N+1 查询时，它就会告诉你。

做有效的提交

我们都会在提交信息时犯以下错误：缺乏帮助的消息、或者有错误的代码、或者提交中有一个调试器调用。毕竟人都会犯错。

利用 git 的 pre-commit 钩子来分析改动并提交消息，以确保它们能够达到标准。从验证你的提交信息是有意义的开始，为了确保你的方案变动存在于你刚编写的迁移中，验证你的代码是遵循你编码风格指南的。检出可配置的工具，如 pre-commit (ruby)、pre-commit (framework)，或自己实现一个！

树立零停机迁移意识

不可避免地你将需要更改代码，改变数据库的结构。这些变更可能会导致你的应用在迁移时运行锁数据库的命令，从而导致宕机。

虽然你的应用没有在执行关键的任务，宕机也可以接受。但考虑到当需要在上次维护之后的第二天进行架构更改时，树立零停机意识，并养成习惯，这对你将会有所帮助。查看 这些优秀的指南，学习该怎么做。

编写全栈测试代码

你在写测试代码，对吧？单元测试非常适用于识别重大的改进，但验证所有的改动是否能正确地一起运行能让你更踏实。全栈测试会验证模型、控制器、视图和前端代码是否正好与用户期望的一致。Capybara 可让你针对真正的浏览器（如 Chrome 或 Firefox）或无界面（headless browsers）浏览器（如 PhantomJS）运行测试。

本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务