前言
如题，内行看门道，代码基本可以反映一位开发者的编码能力、逻辑思维、业务能力甚至更多。做代码review不是为了某次分享而专门去做的事情，他应该是一种习惯：习惯性的开发规范、习惯性的总结问题、潜移默化的自我成长。
什么是代码review
通常同学做代码review只是纯纯的技术，但这并不是一个正确的打开方式，业务是落地技术、验证理论的地方，所以没有业务代码只是干瘪的理论，而正确的技术方案，可以推动业务的良性的发展，所以技术和业务是相辅相成的，缺一不可。代码review可以达到一下几个目的：
- 发现业务缺陷并抛出缺陷，不限于逻辑、功能、安全等
- 提供更合理的编码逻辑，处理代码缺陷，提升代码质量，发现项目问题并抛出
- 若是能够为各个环节提供更加建设的意见就再好不过了
所以，做任何一个项目的起点一定是业务，了解了业务才能更好的规划技术
业务、技术
业务决定技术方案所以先了解实际业务在做技术规划，大致情况如下
- 根据业务上将各个模块划分、拆解后，代码层面统样做相同的处理
- 按照ui层、逻辑层、配置层、样式等规范进行开发，之前分享过多次，不再做介绍
- 公共组件、公共配置、公共逻辑抽离，合作开发好的抽离会更好的帮助队友
- 注释对于开发是很有必要的，仁者见仁
- 合理的语法、严谨的逻辑，话说同事接手模块都有bug(被测试重新提过来或者发现的)
在大规范前提下进行更细致的拆分，按此节奏走维护度、扩展性不会出现大的问题，但是很多业务和逻辑细节依然会出问题，接下来我们以代码为准实际分析一下
实际开发
看代码环节，同时把以下问题反馈给各位同学，涉及到公司业务的就不在此发了，只把几个通用的问题发一下
命名
父级已区分命名空间的，子模块命名可以足够简单，可以表明含义即可，
不确定的业务组件
- 按模块抽离的好处就是当有同学需要你的组件时拿来即用，但这里需注意抽离的组件要抽离彻底，包括样式
- 一旦业务组件成了公用组件，就要考虑扩展性和通用性，不要出现业务代码
- 尽量去封装、抽离提升封装能力，可以封装的东西坚决不写两遍
语法容错处理
无关后端数据异常，只要页面展现报错，前端一定没有正确处理
结语
如何在业务开发中成长是一件很重要的事情（无论是业务方向还是技术方向），理论终究是理论，没有业务实践理论站不住脚，没有跟上时代的技术业务扩展也会受技术方案的限制。如果因为一件事麻烦而不做，就缺少了一个极佳的实践机会
