代码之丑
郑晔
开源项目 Moco 作者
19833 人已学习
新⼈⾸单¥59
登录后,你可以任选2讲全文学习
课程目录
已完结/共 24 讲
代码之丑
15
15
1.0x
00:00/00:00
登录|注册

15 | 新需求破坏了代码,怎么办?

你好,我是郑晔。
我前面课程讲的所有坏味道都是告诉你如何在已有的代码中发现问题。不过你要明白,即便我们能够极尽所能把代码写整洁,规避各种坏味道,但我们小心翼翼维护的代码,还是可能因为新的需求到来,不经意间就会破坏。
一个有生命力的代码不会保持静止,新的需求总会到来,所以,写代码时需要时时刻刻保持嗅觉。
这一讲加餐,我来给你讲讲两个发生在真实项目中的故事。

一次驳回的实现

我们的系统里有这样一个功能,内容作品提交之后要由相应的编辑进行审核。既然有审核,自然就有审核通过和不通过的情况,这是系统中早早开发完成的功能。
有一天,新的需求来了:驳回审核通过的章节,让作品的作者重新修改。造成作品需要驳回的原因有很多,比如,审核标准的调整,这就会导致原先通过审核的作品又变得不合格了。
在实现这个需求之前,我们先来看看代码库里已经有怎样的基础。
首先,系统里已经有了审核通过和审核不通过的接口。
PUT /chapter/{chapterId}/review
DELETE /chapter/{chapterId}/review
在这个设计里,将章节(chapter)的审核(review)当作了一个资源。在创建章节的时候,章节的审核状态就创建好了。审核通过,就相当于对这次审核进行了修改,而审核不通过,就相当于删除了这个资源。
对应着这两个接口,就有两个对应的服务接口:
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

文章通过一个实际项目案例,探讨了面对新需求时如何避免破坏已有代码的方法。作者强调了对新增接口和实体的谨慎性,提出了避免随意修改实体的重要性。在具体案例中,作者通过引入新的模型来关联调度信息,避免了对核心实体的改动,从而减小了代码改动量。文章还强调了对于接口和实体变动的谨慎对待,以及对单一职责原则的重视。总结时刻,作者强调了谨慎地对待接口和实体的变动。整体而言,文章通过实例向读者展示了在面对新需求时,如何通过谨慎的设计和思考,避免对已有代码造成破坏。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《代码之丑》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(12)

  • 最新
  • 精选
  • qinsi
    应该不是所有的需求都可以像文中描述的一样,最终避免改动接口的。一样要改动接口的话,增加新接口的同时保留和有计划地废弃旧接口,应该也是合理的接口升级实践。基础设施做得好(开发效率高,接口监控到位),搬砖熟练的话,可能新需求还没分析完,新接口已经实现好了...

    作者回复: 当然不是所有的需求都不改动接口,这里的重点是要谨慎地分析该不该加新接口。程序员一定不能把脑力劳动做成体力劳动。

    2021-02-02
    8
  • Jxin
    1.案例一,面对同个问题,未看郑大佬的解法时我的思路是相反的。 2.入口要写成2个方法,决策依据是单一职责(如果可以明确走不同分支,就不该通过状态判断来让一个函数实现复用)。至于实现部分是否走相同函数,那是关于复用和隔离的权衡,与时间和场景有关,并不绝对。 3.我的理解,郑老师是把审批不通过和驳回都归为"拒绝"的方法,所以也符合单一职责。从业务的角度来评定单一职责。而我是从代码实现的角度来评定。

    作者回复: 这里的重点是,接口不要轻易增加,一定要多问几个为什么。

    2021-02-04
    2
    4
  • return
    老师好,请教一个问题, 如果因为需求变动 确认过眼神 某个实体确实不需要了, 该不该把他删了。 不删的话 代码有误导性, 删的话, 所有用到过这个实体的地方都得改。 老师有啥好办法吗😄

    作者回复: 如果是确实不需要了,建议删掉。你纠结的点其实就是代码写得不好的地方,正好借着机会调整一下。删代码还是比较容易的,调用关系很容易发现,简单的方法靠IDE快捷键就好。

    2021-02-02
    4
  • 修冶
    老师你好,请教下一个应用不同模块都有查询功能,入参和出参都类似,请问这种情况是对外暴露一个接口,入参里加个业务类型做区分,还是暴露2个接口,感谢

    作者回复: 类似还是相同?相同的话,可以考虑用一个接口,类似的话,以后的变化,有可能会让差异增大,我更倾向于多个接口。

    2021-03-23
    2
    3
  • 老师,我想问一个和这节课内容无关,但是我很迷茫的事情,就是->如何提高“解决问题的思路”,事情是这样的: 前两天我们有个项目,需要导出客户账单的pdf,每个月每个账号要导出来多个账单pdf(比如这个月10个pdf,上个月20个pdf),然后这些pdf要以导出时候的时间戳做命名(例如今天导出时间戳是12384958293 ,明天同样导出本月的话单 时间戳就是 12384923049)并可以根据时间戳作为pdf账单内容的顺序(时间戳最小的是第一个账单,时间戳最大的是最后一页账单),客户导出的时候根据pdf的顺序一个一个的将pdf下载下来。这样产生的问题就是,明明只需要每个月只生成一份的pdf,变成了每次导出都要重新生成。 然后我们负责开发这块的同事(我们技术最厉害的,解决问题的思路很“宽”) 就和产品经理说这个事, 产品经理说:这是要求的,必须要以时间戳做名称, 开发的同事:但是这样很浪费系统资源,每次都要重新生成重新导出。 。。。。。。(争吵十分钟) 当时 他们在讨论的时候,我也在考虑这个问题,如果是我,我要怎么办才能既保证产品经理要求的时间戳方式,又能不浪费系统资源(即,每个月的pdf无论客户导出多少次,系统内都只生成一份当月的pdf),但是我没跳出来“根据pdf的顺序一个一个的将pdf下载下来”这个圈,一直以这个为依据去思考如何解决这个问题。 这时候,我那个负责开发这块内容的同事就说,那这样吧,我把这些pdf封装到一个zip里边,然后把zip按照时间戳来命名,可以吧,这样既可以打到你说的 每次下载都要根据时间戳命名的要求,又能满足每个月只需要生成一份pdf,不浪费系统资源的要求。 当时我就眼前一亮 是啊,我咋就没有想到用“zip压缩封装”的方式呢,这样不仅时间戳的要求满足了(pdf在zip里边排序的方式也可以用其他方式表示),还将本来需要下载多次的pdf,变成了下载一次,优化了下载的体验,一举多得啊。 说了上边的事情,我主要想表达的就是,怎么样才能提高自己解决问题的思路呢,zip我知道,将多个pdf封装到一个zip里我也见过,可以说这些东西我全懂,但是我就是没能将他们联系到一起,去解救这个问题。其实,也许还有更好的办法去解决这个东西。但是,通过这个事情我就发现了->我解决问题的思路真的很“狭隘”,水平很低。 因此,老师有没有什么推荐的书籍之类的,能提高遇到问题的时候,解决这些问题的思路呢,我觉得解决问题的思路这件事太重要了,可能比学技术更重要。学技术只要下功夫基本就差不多,但是提高自己解决问题的能力这件事自己完全不知道该怎么做,才能提高自己这方面的能力,还希望老师能指点一下
    2021-02-02
    9
    16
  • 子铭
    我在思考另外一个事情,就是关于改动接口和系统稳定性之间的关系问题。我个人理解,不增加新接口,在原有基础上修改,这样的做法会不会破坏原接口的稳定性,如果原接口是一个影响面较广,使用场景较多(类似支付消费这样的接口),那如果有一个系的需求过来,那在原有接口基础上修改和增加一个新的接口进行一个选择,我个人认为还是增加一个新的接口更有利于系统的稳定性,在原有基础上对老接口的修改,势必会破坏接口的稳定性,甚至出现可能预料以外的接口,就借用郑老师在文中的那句话。 “接口,是系统暴露出的能力,一旦一个接口提供出去,你就不知道什么人会以什么样的方式使用这个接口。”,尤其是一些比较敏感的接口,总是在老接口的基础上作修改,就有一种“超级接口”的坏味道的感觉,不知道我的理解 是不是表述清楚,是不是片面,欢迎指正。
    2022-03-19
    2
    1
  • Lee
    想请教一下,比如对于同一个实体,可能存在多个组合条件,不同场景下查询,此时在controller层时提供多个API,然后转为内部领域对象进行一个查询逻辑?
    2022-11-23归属地:广东
  • ifelse
    谨慎地对待接口和实体的变动--记下来
    2022-06-02
  • 三生
    老师,碰到一个这样的需求,一个开关值,还有一个是动态值,我想在不修改实体的情况下,共用在一个字段内,但是其他人说,这样这个字段业务就不够明确(单一)别人可能看不懂,所以他添加了一个字段,我觉得是否应该讲开关和动态放在一起,这样既明确又不用新增字段
    2022-05-18
  • Even
    1. 为什么对外提供的接口越少越好。因为提供的接口越好,管理成本会上升、以后难收敛。 2.
    2022-03-20
收起评论
显示
设置
留言
12
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部