阿里巴巴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. 不允许任何魔法值

   const data = ['foo', 'bar', 'baz'];
   onst dataLast = data[2]; //error
   

   之所以禁止魔法值，是为了提高程序的易读性，否则不读完代码块，很难知道这个数字的含义。

3. 单个方法总行数不超过60行。代码逻辑分清红花和绿叶，个性和共性，绿叶逻辑单独出来成为额外方法，使主干代码更加清晰;共 性逻辑抽取成为共性方法，便于复用和维护。

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

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

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

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

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

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

写在最后

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