看完还敢说自己懂代码吗

比眉伴天荒 2021-12-21 04:21 298阅读 0赞

毕玄

一个优秀的工程师和一个普通的工程师的区别，不是满天飞的架构图，他的功底体现在所写的每一行代码上。

多隆

工程师对于代码，一定要精益求精，不论从性能，还是简洁优雅，都要具备精益求精的工匠精神，认真打磨自己的作品。

孤影

对程序员来说，关键是骨子里意识到规范也是生产力，个性化尽量表现在代码可维护性和算法效率的提升上。

工程师一边吐槽别人的代码，一边写着被吐槽的代码，频繁的系统重构和心惊胆战的维护似乎成了工作的主旋律。

无边无际真论的时间成本与最后的收益是成反比的。

一方库：本工程内部子项目模块依赖的库（jar包）

二方库：公司内部发布到中央仓库，可供公司内部其他应用依赖的库（jar包）

三方库：公司之外的开源库（jar包）

if不加大括号还有局部变量作用域的问题。

一致性很重要、可读性很重要，团队沟通效率很重要。有一个理论角帕金森琐碎定律：

一个组织中的成员往往会把过多的精力花费在一些琐碎的争论上。

个性化应尽量体现在系统架构和算法效率的提升上，而不是在合作规范上进行纠缠不休的讨论、争论，最后没有结论。

自动化IDE检测插件：

[https://github.com/alibaba/p3c][https_github.com_alibaba_p3c]

第1章 编程规约

传统意义上的代码规范，包括变量命名、代码风格、控制语句、代码注释等基本的编程习惯，以及从高并发场景中提炼出来的集合处理技巧与并发多线程的注意事项。

POJO类中布尔类型的变量都不要加is前缀，否则部分框架解析会引起序列化错误。

接口类中的方法和属性不要加任何修饰符号（public也不加），保持代码的简洁性，并加上有效的Javadoc注释。尽量不要在接口里定义变量，如果一定要定义变量，必须是与接口方法相关的，并且是整个应用的基础常量。

对于Service和DAO类，基于SOA的理念，暴露出来的服务一定是接口，内部的实现类用Impl后缀与接口区别。

领域模型命名的规约如下：

1、数据对象：xxxDO

2、 数据传输对象：xxxDTO

3、展示对象：xxxVO

不允许任何魔法值（即未经预先定义的常量）直接出现在代码中。

避免通过一个类的对象引用访问此类的静态变量或静态方法，造成无谓增加编译器解析成本，直接用类名来访问即可。

相同参数类型，相同业务含义，才可以使用Java的可变参数，避免使用Object。

Object的equals方法容易抛空指针异常，应使用常量或确定有值的对象来调用equals。

正例："test".equals(object)

反例：object.equals("test")

final可以声明类、成员变量、方法以及本地变量，下列情况使用final关键字：

1、不允许被继承的类，如：String类。

2、不允许修改引用的域对象，如：POJO类的域变量。

3、不允许被重写的方法，如：POJO类的setter方法。

4、不允许运行过程中重新赋值的局部变量。

5、避免上下文重复使用一个变量，使用final描述可以强制重新定义一个变量，方便更好地进行重构。

慎用Object的clone方法来拷贝对象

1、对象的clone方法默认是浅拷贝，若想实现深拷贝，需要重写clone方法来实现属性对象的拷贝。

类成员与方法访问控制从严：

1、如果不允许外部直接通过new来创建对象，那么构造方法必须限制为private。

2、工具类不允许有public或defalult构造方法。

3、类非static成员变量并且与子类共享，必须限制为protected。

4、类非static成员变量并且仅在本类使用，必须限制为private。

5、类static成员变量如果仅在本类使用，必须限制为private。

6、若是static成员变量，必须考虑是否为final。

7、类成员方法只供类内部调用，必须限制为private。

8、类成员方法只对继承类公开，限制为protected。

对任何类、方法、参数、变量，严控访问范围。过于宽泛的访问范围，不利于模块解耦。思考，如果是一个private的方法，想删除就删除；可如果是一个public的service方法，或者一个public的成员变量，删除时手心不得冒点汗吗？变量像自己的小孩，应尽量让它在自己的视线范围内。变量作用域太大，如果任其无限制地到处跑，你会担心的。

并发处理

获取单例对象需要保证线程安全，其中的方法也要保证线程安全。（资源驱动类、工具类、单例工厂类都需要注意）

线程资源必须通过线程池提供，不允许在应用中自行显式创建线程。（使用线程池的好处是减少在创建和销毁线程上所消耗的时间及系统资源，解决资源不足的问题。如果不使用线程池，有可能造成系统创建大量同类线程而导致消耗完内存或者“过度切换”的问题。）

线程池不允许使用Executors创建，而是通过ThreadPoolExecutor的方式创建，这样的处理方式能让编写代码的工程师更加明确线程池的运行规则，规避资源耗尽的风险。

Executors返回的线程池对象的弊端如下：

1、FixedThreadPool和SingleThreadPool：

允许的请求队列长度为Integer.MAX\_VALUE，可能会堆积大量的请求，从而导致OOM。

2、CachedThreadPool和ScheduledThreadPool：

允许的创建线程数量为Integer.MAX\_VALUE，可能会创建大量的线程，从而导致OOM。

第2章 异常日志

Java类库中定义的可以通过预检查方式规避的RuntimeException不应该通过catch的方式来处理。

catch时请分清稳定代码和非稳定代码。

应用中不可直接使用日志系统（Log4j、Logback）中的API，而应依赖使用日志框架SLF4J中的API。使用门面模式的日志框架，有利于维护和各个类的日志处理方式统一。

第3章 单元测试

好的单元测试必须遵守AIR原则。

1、A：Automatic自动化

2、I：Independent独立性

3、R：Repeatable可重复

工程规约中应用分层中提到的DAO层，Manager层、可重用度高的Service，都应该进行单元测试。

编写单元测试代码应该遵守BCDE原则，以保证被测试模块的交付质量。

1、B：Border，边界值测试，包括循环边界、特殊取值、特殊时间点、数据顺序等。

2、C：Correct，正确地输入，并得到预期的结果。

3、D：Design，与设计文档相结合，来编写单元测试。

4、E：Error，强制错误信息输入（如非法数据、异常流程、非业务允许输入等），并得到预期的结果。

第4章 安全规约

表单、AJAX提交必须执行CSRF安全过滤

第5章 MySQL数据库

vachar是可变长字符串，不预先分配存储空间，长度不要超过5000个字符。如果存储长度大于此值，则应定义字段类型为text，独立出来一张表，用主键来对应，避免影响其他字段的索引效率。

字段允许适当冗余，一提高查询性能，但必须考虑数据一致。冗余字段应遵循：

1、不是频繁修改的字段。

2、不是varchar超长字段，更不能是text字段。

当单表行数超过500万行或者单表容量超过2GB时，才推荐进行分库分表。

如果预计三年后的数据量无法达到这个级别，请不要在创建表时就分库分表。

禁止左模糊或者全模糊，如果需要请通过搜索引擎来解决。

禁止使用存储过程，存储过程难以调试和扩展，更没有移植性。

第6章 工程结构

1、开放接口层：可直接封装Service方法暴露成RPC接口；通过Web封装成HTTP接口，进行网关安全控制、流量控制等。

2、终端显示层：各个端的模板渲染并执行显示的层。当前主要是velocity渲染、JS渲染、JSP渲染、移动端展示等。

3、Web层：主要是对访问控制进行转发，对各类基本参数校验，或者对不复用的业务简单处理等。

4、Service层：相对具体的业务逻辑服务层。

5、Manager层：通用业务处理层，它有如下特征。

对第三方平台封装的层，预处理返回结果及转化异常信息。

对Service层通用能力的下沉，如缓存方案、中间件通用处理。

与DAO层交互，对多个DAO的组合复用。

6、DAO层：数据访问层，与底层MySQL、Oracle、HBase等进行数据交互。

7、外部接口或第三方平台：包括其他部门RPC开放接口，基础平台，其他公司的HTTP接口。

如果Service层出现异常时，必须将出错日志记录到磁盘，尽可能带上参数信息，相当于保护案发现场。

如果Manager层与Service同机部署，则日志方式与DAO层处理一致；如果是单独部署，则采用与Service一致的处理方式。

分层领域模型规约：

1、DO（Data Object）：与数据库表结构一一对应，通过DAO层向上传输数据源对象。

2、DTO（Data Transfer Object）：数据传输对象，Service或Manager向外传输的对象。

3、BO（Business Object）：业务对象。由Service层输出的封装业务逻辑的对象。

4、AO（Application Object）：应用对象。在Web层与Service层之间抽象的复用对象模型，极为贴近展示层，复用度不高。

5、VO（View Object）：显示层对象，通常是Web向模板渲染引擎层传输的对象。

6、Query：数据查询对象，各层接收上层的查询请求。注意超过2个参数的查询封装，禁止使用Map类来传输。

第7章 设计规约

用例图来表达结构化需求会更加清晰。

使用时序图来表达并且明确各调用环节的输入与输出。

设计的本质是识别和表达系统难点，并找到系统的变化点，并隔离变化点。

世间众多设计模式其实就是一种设计模式，即隔离变化点的模式。

系统架构设计的目的

1、确定系统边界。确定系统在技术层面上的做与不做。

2、确定系统内模块之间的关系。确定模块之间的依赖关系及模块的宏观输入与输出。

3、确定指导后续设计与演化的原则。使后续的子系统或模块设计在一个规定的框架内继续演化。

4、确定非功能性需求。非功能性需求是指安全性、可靠性、可维护性、可扩展性等。

避免发生如下误解：

1、敏捷开发 = 讲故事 + 编码 + 发布。

敏捷开发是快速交付迭代可用的系统，省略多余的设计方案，摈弃传统的审批流程，但在核心或关键模块上，必须进行必要的设计和文档的沉淀。

[https_github.com_alibaba_p3c]: https://github.com/alibaba/p3c

看完还敢说自己懂代码吗

发表评论取消回复

还没有评论，来说两句吧...

相关阅读

相关一文带你深入理解JVM，看完之后你还敢说你懂JVM吗？颠覆you认知

相关不懂JS的实用工具库Lodash，怎么敢说自己会JS ?

相关看完这篇文章，还说自己不会使用Zookeeper命令吗

相关你还在纠结如何判断范式吗？看完这篇就懂了

相关假期三天，我肝了万字的Java垃圾回收，看完你还敢说不会？

相关不懂精简指令集还敢说自己是程序员？

相关前端面试还不懂这些技巧？看完跳槽少说涨50%(下）

相关前端面试还不懂这些技巧？看完跳槽少说涨50%(上）

相关看完还敢说自己懂代码吗

相关反射都不会，还敢说自己会Java？