当前位置:网站首页 > 编程语言 > 正文

程序员代码指南(程序员的代码)



🙋🏻‍♀️ 编者按:本文作者是支付宝后端开发工程师言戒,提供了关于简洁代码的一些参考思路,欢迎查阅~

在大部分业务领域的开发来说,主体代码基本分为【业务向】【数据向】,两者都是重业务逻辑的业务代码。这类代码通常复杂度来自业务,且变化比较频繁,如果没有良好的习惯和编码设计,很容易臃肿不堪,被人形容成“面条”。

如何写得易读,易懂、易于修改,即简洁代码。

本文提供一些简单的参考思路。

极端的说,简洁的代码可以满足“我的代码一行都不能删”,例如教材版的HelloWorld。

然而现代工业化软件设计中,业务复杂,分工协作,变更/维护频繁且长期,势必要有结构分层,依赖/耦合关系抽象和再次组织。

那么在这样的客观环境下,简洁结构追求的是什么呢?

答:分层

1.满足业务需求

2.尽可能使逻辑简单,表述易于理解

3.尽可能最小化模块,易于变更维护

4.尽可能简化配置项,减少操作成本

5.尽可能没有相似/重复代码

6.尽可能用程序逻辑去替代人脑逻辑

简洁代码的价值显而易见:【易读,易测,易修,易改】

应该时刻以简洁代码为目标,但也需要根据现实情况和操作成本以及能力,量力而为。

Q1:简洁代码 Vs 简单代码

A1:简洁代码是指逻辑、结构、表述条理清晰简洁,并不等同于代码简单,相反奖复杂代码写的简洁存在挑战,要有良好的设计。

简洁代码良好的结构和模块化拆分,正是为了更好的修改和扩展准备的,越合理的单元化,增量的功能涉及的影响面也越小,就越容易修改;即便不修改,也便于调试和测试;出了 bug 也很容易排查和改正。

Q2:简洁代码 Vs 低代码

A2:简洁代码并不一定是代码行数最少。

只论行数,所有逻辑写在一个方法内,总行数最少;但这样并不简洁,反而是臃肿。

简洁代码会因为合理的分层,实际在代码行数上有轻度增量,典型的增量部分如:出入参模型、转化、模块内聚的校验等。

Q3:简洁代码 Vs 设计模式

A3:如果合理的使用设计模式,本质上并不会与简洁代码冲突。

设计模式的目的也是为了让代码可维护,可扩展。

但对设计模式的使用要充分理解,不能因为似是而非的理解胡乱选型,反而增加了复杂度;

有一些设计模式本身有一定复杂性,这部分仁者见仁,看 coder 自身的水平。

总结来说,合理的设计模式,正是一种简洁代码。

每个团队都有各自的分层,以我所在团队当前系统常见分层来举例。

RPC/TR/Handler->service->manager->dao 

对应的模型分别是 Info、Model、Config/VO、DO

代码分层的目的是为了将抽象分等级,是一种抽象方式的约定,模型对象的命名给出了约定的标准;

标准分层是一种基本思路,归根到底是抽象结构的定义,实操层面允许一定灵活性,适当的进行代码结构调整,以减少层次,减少模型,减少 convertor 等。

但是有一些原则:

1、DO 对象不可替代,不可复用其他层次对象,必须单独一个模型。DO 对象一般不能直接出现在业务层,绝对不能出现在最上层。

2、 4 层模型不是固定死的

如果两层模型结构非常接近,可以酌情合并或者跨级引用,减少一次模型定义和模型转化。

模型合并优先级:从上至下。(原因:a.上层模型通常更必要,比如rpc模型前端必然需要;b. 发生模型少量参差,通常上层模型可以兼容下层模型,即通常上层模型要更具象,字段要更多,下层模型更抽象,字段更少)

3、4 层结构不是固定死的

Service 和 Manager 都是业务层抽象,Manager 粒度更细,Service 更复合。

对于某些简单业务,可以合并成一层(个人偏好&建议,合并到 Manager,这样如果后续有业务扩展增量写 Service 是纯新增逻辑,而不用动 Manager;反之,就得从 Service 里 extract,影响面变大)

4、Repository 层的时机。

简单的单表操作,普通 DAO 层基本足够,但是在有些场景,操作数据/资源,有较为复杂的逻辑,比如批量读写,多路 sql 等,这时候可以用 Repository 来 2 次封装。但是要避免出现 Repository 里只做 DAO 的调用转发(因为这样除了增加代码量外没有任何意义)。

案例

点评:

1.业务抽象直接等同成了rpc接口抽象,而所有逻辑都在业务层里面实现,导致rpc层单薄(核心代码只有一行方法调用),而业务层臃肿(原始方法接近200行)

2.接口层做的逻辑太多,没有任何逻辑拆分,只是单纯的运算罗列堆积,导致臃肿

3.原本应该在上层做的通用逻辑下放到了业务层:比如活动降级校验、配置校验。进一步增加了业务层的臃肿

建议:

1.rpc抽象:首页接口,业务层抽象多个子业务:【面额处理】、【券周期处理】、【发券处理】

2.子业务模块在首页接口里组装衔接

3.跟子业务本身无关的辅助逻辑、或者通用逻辑(比如活动校验、全上下文要用的配置校验)在rpc层编写

案例(代码略)

1.Service内所有代码仅简单调用Manager层;

2.Repository内所有代码仅简单调用DAO层;

建议:

如果只是简单转发,按需合并或简化层次,如合并掉Manager/Repository

点评:

案例中传参多达12个,同时包含map,list复杂结构 传参过多的时候问自己两个问题:

1、这些参数都是必要的吗?有简化可能吗

2、这些参数所运算的逻辑,都必须在这个方法内吗?

建议:

1.【内聚】传参都是必要的, 传参的处理逻辑也是必需在本方法内完成的。

2.【内聚】传参最小化。只用到useId就不要传UserInfo,只用某一个value,就不要传入整个集合。

3.【内聚】自给自足。能用本方法内通过工具类获得的(如Util.get(userId)),就不要在上文获取后当做入参传递

4.【重构】合理抽象依赖关系,简化方法内部逻辑,少做点事。

代码案例

以上两个方法执行逻辑一致。

区别在于方法2把result当做入参,返回值改成void。

这是出入参误用的典型特征,虽然语义能够执行,但是后续加上维护变更后,容易导致:

1.书写代码栈深变长,代码变的冗长。

2.result的修改发生在方法中,读码容易忽略,修bug或者需求调整时,容易遗漏。

建议:

【入参】是程序计算因子,一般只读,不做变更。

【出参】是程序计算结果,一般只在赋值时候做变更。

1.合理抽象,明确输入输出

2.严格定义出入参(入参只读,出参只在赋值的时候写)

3.如果特殊场景,必须要传参修改,方法内部要标明,例如:fillConfig,processModel等

点评:

原始需求“活动的最后一天,发奖状态特殊处理,前端展示【已开奖】,否则展示【明日再来】”。

代码案例中,直观的从prd翻译,自然的就耦合活动时间相关的判断了,导致if条件复杂冗长。

但挖掘需求条件,隐含了条件:

【活动最后一天】=【发奖最后一天】=【6.18当天】 根据需求只管理解是活动最后一天,但根本关联因素条是发奖时间。

因此耦合关系应该只依赖发奖时间配置,而不是活动时间配置。

判断条件即可简化成“是否发奖结束”,而这个值可以从配置参数中获取。

建议:

深度需求分析,找到真正的关联关系,而不是业务语义直接翻译,以此定义出逻辑、变量的耦合关系。

点评

1、判断条件内含多层嵌套,分支链路复杂

2、同一个判断条件,在多条分支中重复判断,本案中taobaoRedPacketDowngrade条件,有3处判断,加大了阅读和维护难度,后续业务调整很容易修改遗漏 

建议

1.分支的走向路径要一致,一个分支尽量把逻辑做完,避免重复开启分支导致的复杂度增加

2.简化逻辑,定义出子逻辑,提取成子方法

3.用程序逻辑思考,把逻辑理顺,而不是简单粗暴的对业务语义直接翻译

【功能正确】【结构简单】【条理清晰】

【易读,易测,易修,易改】

合理抽象,合理分层

高内聚,松耦合

用程序逻辑去思考,而非需求翻译

适当的编写技巧

单个方法太长时(建议不超过40行)

参数太多时(建议不超过4个)

单元测试非常难编写时(写一个单测,需要造非常多的前置数据)

配置变复杂时(改一个逻辑,需要改多个配置联动,或者要求配置里有逻辑限定)

“这段代码好像刚刚写过”的感受时(DRY原则)

后记

java中抽象、封装、继承、多态,哪一个是最关键的?

刚入行时我觉得是多态。因为多态的特性复杂,以此能够衍生出很多编程技巧。

工作经验越是往后积累,越能明白抽象的重要。

小到代码的参数抽象,方法抽象;中到业务的模型抽象,逻辑抽象;大到架构抽象,模式抽象。

抽象是最考验抓本质的本事,只有把抽象思路理清楚,才能在地基之上建高楼。

如何能把业务抽象的更简单,是写成简洁代码的根。

《代码大全》

《重构》

《代码整洁之道》

《编程珠玑》

《effective java》

《java8实战》

到此这篇程序员代码指南(程序员的代码)的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章,希望大家都能在编程的领域有一番成就!

版权声明


相关文章:

  • 单播地址有哪些(单播地址包括哪些)2025-01-26 08:54:08
  • jflash命令行烧录S32K144(jflash命令行烧录S32K144)2025-01-26 08:54:08
  • win10虚拟机xp怎么联网(xp系统虚拟机怎么联网)2025-01-26 08:54:08
  • win32是什么意思(win32是什么文件夹)2025-01-26 08:54:08
  • 文件比较工具(文件比较工具 查重)2025-01-26 08:54:08
  • ip地址计算工具(ip地址计算工具app)2025-01-26 08:54:08
  • ip反查域名 ip138(ip反查域名查询网)2025-01-26 08:54:08
  • 显示本机安装(安装在本机是什么意思)2025-01-26 08:54:08
  • pem文件(pem文件用什么打开)2025-01-26 08:54:08
  • ipv6回环地址(ip地址为回环地址)2025-01-26 08:54:08
  • 全屏图片