提高Rails开发者编码效率的实用小贴士

   <p>大多数贴士和技巧，对于开发人员的重点是知识、经验或沟通技巧。虽说这些肯定是有用的因素，但是它们对于学习者能有效地执行还是太过抽象了。</p>    <p>成为一个更好的开发者没有捷径，但是这里一些实践和工具将肯定会有帮助。这里我将会分享一些东西来提升代码和产品，也提升开发者的水平。</p>    <p>这些是建议不是教条，请依据情况进行调整。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/41cc60e650eb0eddef07276610aa1da4.jpg"></p>    <p>实现和加强编码风格指南</p>    <p>Ruby 是一门富有表现力的语言。有了这种表现力，就会有一百万种风格的代码来完成任务。统一这些风格有助于统一一个代码库，使其更容易地理解并更愉快地在其中工作。使用 rubocop 可以实现这一点。Rubocop 具有可让你调整和细化为你的喜好的预定义风格。不过现在讨论的不是你的编码风格，而是整个代码库风格的统一性。</p>    <p>但是你现在的项目代码风格十分杂乱?Rubocop 可以忽略已存在的违反风格指南的地方，让你随时修复。如果你愿意，它甚至会尝试修复违反风格指南的代码风格。</p>    <p>加强代码风格在个人和团队项目上是非常具有挑战性的。使用自动化工具强制执行这些风格，例如 guard-rubocop, CodeClimate, Hound 等，以防止提交错误风格的代码。为避免代码被污染，可以使用像 reek 这样的工具。</p>    <p>尽早收集性能指标</p>    <p>你可能已经在其他地方读过或者听过这句话：</p>    <p>“在大约 97% 的时间里，我们应该无须关心效率问题：过早的优化是所有邪恶的根源。”— Donald Knuth</p>    <p>这句话被引用了很多次，是个好的谋生建议。优化的时间通常是没什么警告的，所以当那一刻到来时，最好能很好地了解当下的情况。当性能成为问题时，已经有了的这些信息是非常有用的，而不是试图在迫在眉睫的时候才收集它。</p>    <p>使用 Librato 和 Skylight 等检出工具来收集产品的性能指标。另外，请参阅这个优秀的 gem rack-min-profiler，用于每个请求的性能指标。</p>    <p>避免耗费大的数据库查询</p>    <p>如果说过早的优化是不幸的根源，那么对性能差劲的代码的无知与其有着紧密的关系。当编写 Rails 代码时，通常会出现这样的情况：思考不足、未使用或使用代价昂贵的数据库查询。</p>    <p>Rails 的性能对于大多数 webapp 来说，通常是 “足够快的”。差的性能通常被归咎于 N+1 查询导致的数据库的数据多次往返。大多数性能监测工具都能识别这些问题，不过我们应该从一开始就避免它们。在开发中识别和消除这些问题可以使用优秀的 bullet gem。它会分析你的页面，当你加载的数据没有被使用或者有机会消除 N+1 查询时，它就会告诉你。</p>    <p>做有效的提交</p>    <p>我们都会在提交信息时犯以下错误：缺乏帮助的消息、或者有错误的代码、或者提交中有一个调试器调用。毕竟人都会犯错。</p>    <p>利用 git 的 pre-commit 钩子来分析改动并提交消息，以确保它们能够达到标准。从验证你的提交信息是有意义的开始，为了确保你的方案变动存在于你刚编写的迁移中，验证你的代码是遵循你编码风格指南的。检出可配置的工具，如 pre-commit (ruby)、pre-commit (framework)，或自己实现一个!</p>    <p>树立零停机迁移意识</p>    <p>不可避免地你将需要更改代码，改变数据库的结构。这些变更可能会导致你的应用在迁移时运行锁数据库的命令，从而导致宕机。</p>    <p>虽然你的应用没有在执行关键的任务，宕机也可以接受。但考虑到当需要在上次维护之后的第二天进行架构更改时，树立零停机意识，并养成习惯，这对你将会有所帮助。查看 这些优秀的指南，学习该怎么做。</p>    <p>编写全栈测试代码</p>    <p>你在写测试代码，对吧?单元测试非常适用于识别重大的改进，但验证所有的改动是否能正确地一起运行能让你更踏实。全栈测试会验证模型、控制器、视图和前端代码是否正好与用户期望的一致。Capybara 可让你针对真正的浏览器(如 Chrome 或 Firefox)或无界面(headless browsers)浏览器(如 PhantomJS)运行测试。</p>    <p> </p>    <p>来自：http://developer.51cto.com/art/201704/538287.htm</p>    <p> </p>