什么的代码才算好代码

毕业三年,说实话到现在 还是很浮躁 今天学学这个 明天学学那个,虽然一方面和自己的自控能力有关,但其实跟多的是有点着急吧 被这些个焦虑的软文给带的。

什么样的代码算是好代码?

我曾想过会有这么一本书 教我怎么写好 一个项目 从技术选型 到模块设计 到包命名 到类命名 到方法字段命名,找了找没发现  后来看到一本 叫做 代码质量管理的书(大致这个书名)看了看里面的内容 还是和我期望的有所偏颇。因为我现在 自己写一个项目 后端就我一个,慢慢的代码行数上来了 逻辑也变得复杂起来 觉得 有必要这么弄一下了,不然后面肯定头大。

我目前是这么处理的:

1. 消除 循环引用 

   如果你把所有的注解从@service换到@repository 代码就会告诉我  这个问题。 循环引用,是最不能出现的,这个应该是最低的需求,像这种业务代码,dao service bizservice controller 都已经设计的好好的了 ,有循环引用的代码 一定不是好代码,虽然spring帮我们解决了这个问题 但是就我们而言 不应该出现这个问题

2.  响应实体 和请求实体分开 每个接口对应于一个实体 不共用。

这种名字一般都有规范 其实这种 规范只是作为 一种参考 你可以自己定义 用swagger写点注解 最重要的是 请求实体和 响应实体与接口是一对一的关系

3. 接口名 方法名 字段名的一致性

一个http的路径名字 controller方法的名字 各种service方法的名字 最好使用同一个 不同的接口调用 名字最好不同 另外这个 名字最好可以体现 你要执行的逻辑 到了后面的service 分成小步骤 方法名可以做对应的调整

字段名 对于数据库同一个字段 不管在那个实体里面 名字最好一样 最好是与entity的名字一样 当然这就要求你 建表的时候 字段名也要尽量唯一了

4. 逻辑分层

   1.  controller 不做逻辑处理 最多做个 参数校验

   2. bizService 使用接口暴露 方法入口 虽然只有一个实现类 但是还是借用接口 不要直接 用一个class省事 这里进行主要的业务 逻辑处理。

  3. service  将biz中部分公用的逻辑抽离出来 放到这里实现 同样的也是使用接口

  4.  dao 只做数据处理 和一些 简单的逻辑  没有业务逻辑

有些时候这4层还不够 这就需要自己 加了 视情况而定 一般而言 4层已经足够了  我这边目前 只用 到3层 少部分用到4层

同时这里 还有个要求 就是可见 控制:

    conrtoller 只能 使用biz的接口  别的都不能用

    biz只能使用 service 或者dao的接口 不能使用 biz的接口

    service 只能使用dao层接口 不能使用service层或者biz层的接口

   dao层 尽量保持独立 

 如果按照上面这个规范 业务代码 是一定不会发生循环引用的 每一层只能调用相邻的 下一层的接口方法 不会形成闭环

当然 还有一些aop 什么的要 考虑下  以及日志记录什么的。

我目前就朝这三个方向整 大家如果有其他看法 欢迎一起交流

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页