39 | 面对遗留系统，你应该这样做

郑老师拍案惊奇书单及简评，最近各大书店有活动，可以借机囤起来了： 1.重构 作者: Martin Fowler https://book.douban.com/subject/1229923/ 严格说来，我并没有完整的读完这本书，不过，正如作者自己所说，这样的书原本就不指望能够读完，因为有一大部分其实是参考手册。正是我读过的部分让我知道了重构，让我知道这么做可以把代码写得更好。 2.敏捷软件开发 作者: Robert C·Martin https://book.douban.com/subject/1140457/ 这是一本名字赶潮流，内容很丰富的书，这本书让我开始理解软件设计，从此不再刻意追求设计模式。 3.测试驱动开发 作者: Kent Beck https://book.douban.com/subject/1230036/ 读的是英文版，因为当时中文版还没有出版，所以，我不敢说，我通过这本书很好的理解了测试驱动开发，但它却为我打开了一扇门，让我知道了一种更好的工作方式。 4.修改代码的艺术 作者: Michael Feathers https://book.douban.com/subject/2248759/ 这是一本讲解如何编写测试的书。至于这本书的具体内容，我的评价是实用。如果说不足，那么，这本书缺乏一个列表，就像Martin Fowler为《重构》所做的那样，出什么样的问题，应该采用怎样的手法进行处理。

改造遗留系统或者防止代码快速腐化的一点体会就是从领域模型入手。我们有两套遗留系统：合同系统以及CRM系统。刚开始时两者比较独立，随着业务发展，两者有了比较密切的关联。方案评审时发现，大家理解业务需求没问题，但是没有分清楚领域模型，只是把需求简单归了下类，哪个是合同系统，哪个是CRM，流程搅和到了一起。我认为其中的关键是，想清楚或者定义清楚每个系统的核心价值或职责是什么，而不是看和哪个有关就丢进去

现在确实有很多最佳实践，而且资料也很好找，修改遗留代码，也要根据实际业务改变而做相应修改，分成小块，逐步替代，测试更紧，保证修改有效，才不至于越改越烂。当然，最好的代码也有时效性，在变化之中寻求不变才是至关重要的

问个问题，一般web服务依赖数据库，这部分如何做好单元测试？如果去掉数据库，很难测试相应的sql语句

拜 REST 所赐，行业对于 HTTP 的理解已经大踏步地向前迈进，CDN 才有了巨大的进步空间。 请问如何理解呢？

老师，怎么获得电商行业领悟模型的领域建模实战资料？有书或则文章之类的吗？我这边就是电商供应链业务。公司发现比较快，进而几乎是以上问题的重灾区。第一步加监控，补核心或经常有问题业务块的日志，并对一些会导致脏数据的异常点加告警。第二步，补部分测试代码，重构了啥，就补啥。第三步，小步重构代码，子父类属性迁移，带事务的方法聚合，异步的方法聚合，业务代码顶层调用函数提炼。第四步，书写业务白皮书，降低其他人参与进来的成本，提高调整效率。

老师，“有些行业已经形成了自己在领域模型上的最佳实践”，有相关资料分享一下么，谢谢老师！

老师，我想问一个关于单元测试的问题，假设我要测试的函数是一个关于tcp的网络发送函数，这个函数里面又调用了系统的send函数。但是这个函数要测试成功就需要创建socket建立tcp连接。这样为了测试这个函数我就要实现一个tcp的服务端，这样牵扯的东西也比较多，测试用例就比较复杂。所以我想问一下，老师在写类似这样功能的单元测试是怎么实现的。看了老师文章后发现单元测试很重要，也在自己项目中实践，但是这个问题一直困扰着我。谢谢

正在着手重构一个系统。重构前信心满满，把老系统的一些显而易见的问题一一罗列下来，并想好了对应方案。即where are we，where are we going。 但执行过程中并非一帆风顺，重构过程中也不断发现新的问题和代码坏味道，导致重构之前的重构。 总结，过于追求完美，导致前进较慢。应该执行优先，在保证重构出比之前好的系统并解决关键问题的前提自下，速度优先

今天的课程对于开发一个新系统同样很适用。 思考为什么做和做什么，最后才是思考怎么做才能够确保尽可能腐化的更慢一些？ 注意多积累 领域模型和行业最佳实践。 对于全新的找不到最佳实践的新赛道，争取跨领域迁移，做成自己领域内的最佳实践。