阿里巴巴Java开发手册阅读

最近阿里发布了阿里巴巴Java开发手册(泰山版),花了点时间阅读下,这里MARK下个人感受

无规矩不成方圆

  • 有些人觉得没规矩不挺好?但假如项目中10个人,10个风格,10个规矩或者没规矩,代码又存在交集,这样的代码能维护吗?能不出问题吗?impossible!
  • 规矩,标准是为了提升协作性,降低门槛儿,代码差异化一定程度降低,每个人都这么做,熟悉了规矩,无论是自己coding还是看别的人code,自然就快,那么bug率自然也就降低了
  • 假如我是个独立开发,只有我一个人,我就不需要规矩了?我之前也这么认识,但逐步我改变了这个认识,就是个人也需要有自己的规矩,风格,因为这会让你效率越来越高,规矩的背后是标准化,统一化。
  • 这些规约的背后是前辈们,或者同行们从无数的坑,无数的雷中总结出来的,不一定恒对,但值得学习,值得参考,值得借鉴。

so,没规约,不见得单个问题解决不好,但不久的将来,一定出问题,害人害己。

规约实施工具-lint

  • 在实际的项目中,因为团队成员会有所波动,并且水平也是参差不齐,为了在代码上做到基本风格的控制,现在有了工具来从中辅助,比如java下的checkstyle,阿里的IDE插件,js下的eslint。
  • 当然lint只是一环,其它还要MR,CR,这几个环节的目的本质都是为了项目的统一,项目的质量。

一些规约的再学习

  1. FIXME表示需要立即修复的错误,而TODO表示的是之后需要做的事情,so,两者目的并不相同,可以互补。

    JetBrains旗下的IDEA,WebStorm对此都已支持

  2. 不允许任何魔法值

    1
    2
       const data = ['foo', 'bar', 'baz'];
    const dataLast = data[2]; //error
之所以禁止[魔法值](https://yq.aliyun.com/articles/517819),是为了提高程序的易读性,否则不读完代码块,很难知道这个数字的含义。
  1. 单个方法总行数不超过60行。代码逻辑分清红花和绿叶,个性和共性,绿叶逻辑单独出来成为额外方法,使主干代码更加清晰;共
    性逻辑抽取成为共性方法,便于复用和维护。

    个人觉得这个比喻非常贴切,面对复杂度,行数过多的代码,按照这种思维去提炼抽取,刻意练习,实际上并不存在无解的大代码块。

  2. 谨慎注释掉代码。在上方详细说明,而不是简单地注释掉。如果无用,则删除。 代码被注释掉有两种可能性:1)后续会恢复此段代码逻辑。2)永久不用。前者如果没有备注信息, 难以知晓注释动机。后者建议直接删掉即可,假如需要查阅历史代码,登录代码仓库即可。

    之前觉得所有注释代码一律删除,因为版本管理系统比如Git存储完整的历史,所以谈不上找不回来。但假如只是临时注释,而依赖历史去找确实成本并不低。所以少量的注释代码还是存在的,但是重点确实如上所说,需要有合理的解释。

  3. 大而全的常量类,杂乱无章,使用查找功能才能定位到修改的常量,不利于理解,也不利于维护。

    实际上不只常量,工具函数也类似,不能单纯按照技术划分,需要结合业务,功能拆分,这样降低他人查找的成本,提升效率。

更多规约需要实际项目中去感受和调整,总之合适即可

写在最后

  • 软件开发发展到今天,但凡是个产品,面临的就是变化,而应对变化,不变的是方法论,只是具体的值变动而已。规约的实施可以控制标准,有助于应对变化,提升效率,所以一定要做。