中级工程师之路之优雅代码之道

 

第一点, 三个小原则:

1. 代码行数长度不应该超过50行,否则不易复用与维护.

2.在controller里面最好不要有私有函数(私有方法)

3....

第二点,数据和代码分离:

数据实际上就可以认为我们在函数里面所处理的参数,在我们mvc里面基本可以认定为controller. ..代码实际上就是对数据的处理..  一般我们是要将这两点分离开来.在函数(入参,出参),的参数配置在配置环境里面,,一般不进行显式构造.

第三点:mvc拯救世界.

这里实际上是对model , view, controller进行了剖析.刚刚也说model实际上就是数据,,而view则是对数据在前端页面的展现形式, controller是对model的处理,对实例属性进行具体的操作.,我们一般在写代码时,可以先写出对数据处理的方式,,,(utile,service)  然后由controller负责扮演中心控制台角色对各个方法的使用对数据进行处理.

第四点:分层.

这里讲的是controller.service,dao三层之间完全分离, service层主要是与业务逻辑等和业务有关联的逻辑代码,dao层是对数据库的数据处理,这里dao层可以是(mybatis,jdbctemplate等),service对dao层实现过程中可以忽视究竟是什么数据库

,controller对service,utile其调用的时候完全不用管里面是什么,我们只需知道调用时这个方法能实现什么功能即可.,, 

dao层后面还可以有一个缓存层,,同理.

第五点:先简单在聚合:

将页面内各借口完全分离,否则在一个页面内几百行代码一个接口改动,其他接口可能都要改动. 

如果页面上有两个接口或模块关联非常紧密,,我们可以将他们两个复合起来,视其为一个接口(体会意思即可,说法不严谨).

当有多台web 实现负载均衡对 多个service调用时,,,service之间尽量不要互相调用, 而使用web服务器对他们分开调用.

我们分离之后并不知道有多少service,,如果出现多个service之间互相调用的情况容易造成代码逻辑混乱,当代码出现问题时,我们也不好对问题定位..

若service之间必须调用,可以写一个接口对这两个service进行调用, 最好不要超过三层.

第六点:三种层级的抽象:

这三种层级分为 private,utile,和service.

private是私有方法,,自己类使用的方法.

utile则是工具,,可以写成所有项目都可以使用的那种工具类,

service是在当前项目中所拥有的实现.      

service和utile的可同过有无业务逻辑来区分.

在写代码过程中,对代码进行无数次的重构可以通过这三点来进行定位, 对层级的构思,复用程度.

第七点: 项目延期:

在做方案设计时, PM提出功能之后,我们这时就要对功能的实现进行思考,在方案评审这三天,要将对功能的想法落实为具体文档,(难点或无法实现的提出来单独讨论),在这三天要解决所有实现问题.

写过代码之后我们可抽出部分时间对代码进行重构.提高以后做项目的效率.  

重构完成进行性能测试.一定要确保 接口稳定性,

如果在项目进行过程中出现意外问题,要及时沟通,确定问题出在哪里,估算延期时间