Spring中的aware接口详情
193
2022-06-15
大多数贴士和技巧,对于开发人员的重点是知识、经验或沟通技巧。虽说这些肯定是有用的因素,但是它们对于学习者能有效地执行还是太过抽象了。
成为一个更好的开发者没有捷径,但是这里一些实践和工具将肯定会有帮助。这里我将会分享一些东西来提升代码和产品,也提升开发者的水平。
这些是建议不是教条,请依据情况进行调整。
实现和加强编码风格指南
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)运行测试。
来自:http://developer.51cto.com/art/201704/538287.htm
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
发表评论
暂时没有评论,来抢沙发吧~