你好，我是郑晔。

又到了我们划重点的时间了，因为篇幅关系，“综合运用”这个模块最为短小精悍。

在这个模块中，我们把前面学到的各种知识综合起来，运用在实际的工作场景中，让你知道这些内容并不是一个个孤立的实践，在实际工作中，唯有将它们结合起来，才能发挥最大功效。

重点复习

在这个模块中，我们学习到了一些新知识。

在这个模块中，我们还了解了一些重要的思路，让我们把工作做得更好。

实战指南

额外收获

在这个模块的最后，针对大家在学习过程中的一些问题，我也进行了回答，帮你梳理出一个思路，更好地理解学到的内容：

留言精选

关于入职一家新公司，怎么快速进入工作状态这个问题，西西弗与卡夫卡 同学分享了他的方法：

有朋友正在转型，从乙方商业化产品的交付经理转向新公司的产品经理。原本得心应手的思维方式和工作习惯，遇到了巨大挑战。以前只需依据已有产品的功能出解决方案，能做就能做，不能实现就是不能实现，到某个时间交付什么功能很明确，考核是以交付签字为准。现在需要面对各方需求，自己想明白用户真正的问题是什么，最终要交付的价值是什么，没有一个实体的谁人来签字，只有不断地迭代。

借鉴领域驱动设计，可以采用以下方法。简单描述的话，是一个点、一个圈再加一个箭头线，是不是有点像丘比特？

一个“点”，指的是用户核心价值。这是最关键的一条，基本上只能靠自己想明白。想，不是闭门造车式的苦思冥想，可以是已有的领域经验，可以从书本中学习，可以是大家的各种吐槽，可以是自己从旁边观察用户的实践，还可以是自己变身为用户的实践。

有些人会纠结“点”想的对不对，迟迟不敢动手。其实一开始想得对不对不是那么重要，关键是要有这“点”，然后快速到市场上验证，根据反馈再调整。

一个“圈”，指的是围绕核心价值划出的范围，即领域驱动设计中的限界上下文。产品经理面临的一个现实是，各种人都会给你提需求，只要他们觉得和你有关，还时不时来问什么时候可以实现。

需求轰炸之下很容易焦虑，不光自己焦虑，所有的利益相关者都会焦虑。依据核心价值，框出需求范围，在和各方交流过程中可以有一种确定性，减少焦虑，利于行动。

大家（不光是研发团队，也包括其他需求方）就能明白，哪些和当前核心价值密切相关，我们优先考虑；哪些与核心价值有关但它不在我们的范围内，属于其他团队，需要他们协助；哪些有关系，但目前没想清楚价值大不大，并且代价可能很高建议先搁置。范围不是一成不变，它随着时间会发生变动，所以我们不要追求固定，只要保证在某个时间段内，大家一致认同即可。

一个“箭头”，指的是实现路径，箭头指向核心目标（核心价值）。目标（核心价值）和范围描绘的是终极，而从现实到终极还有很多路要走，可能的路径还有很多条。我们需要琢磨怎么走更稳当，怎么走代价比较低，路上关键的里程碑是什么。路径对不对是其次，重要的是思考过程，可以把关键点需要交付的价值、需要支持的资源等等梳理清楚。

另外，西西弗与卡夫卡 同学还对于程序员如何保持竞争力的问题给出了非常不错的建议。

补充我的一些做法。工作中不要满足当前需求，要经常从自己上级主管甚至老板角度来审视自己的工作，思考业务的终极目标，持续琢磨扩展边界，挑战工作难度。

平时多看书多思考，除了钻研某个领域，还要多有涉猎，拓展领域，成为终身学习者。

适当运动维持健康，你有更多体力和更强抗压能力的时候，就可以超过不少人。

保持竞争力除了上述之外，要保持乐观，相信大多数事都有解决方法，在多数人都容易放弃的时候，你的坚持，就是竞争力。

对于新入职一家公司的场景，Y024 同学分享了他快速进入工作状态的方法：

1.我会在权限允许的范围内，时不时的到处翻翻 ftp、内部 wiki 等资源，星星点点构建全貌（业务、技术、团队）。

2.梳理系统数据流。去年很火的电视剧「大江大河」里，宋运辉初入职场的方式就很值得借鉴：先走通全部流程，有个全貌，利用图书馆、师傅等资源再自己动手各个击破并绘制流程图，最终实践检验认知，以技术说话融入团队。

（他就每天只要天气晴朗，绕着设备上上下下、里里外外地跑。一个星期下来，全部流程走通；两个星期不到，原理搞通，仪表能读，普通故障能应付；第三星期开始，他可以开出维修单，但得给师父过目；第四星期起，谁有事请假他可以顶上，坐到仪表盘前抄表看动态做操作。师父说他学得很快。

第四星期起，没人可以让他顶替时候，他在仪表室后面支起绘图板。先画出工艺流程图，经现场核对无误，又让师父审核后，开始按部就班地根据液体走向，测绘所有设备的零件图、装配图、管段图等。

这工作最先做的时候异常艰难，首先是绘图不熟练，很多小毛病，尤其是遇到非标零件，还得到机修工段测绘，有时一天都绘不成一个小小非标件。如果车间技术档案室有图纸还好，可以对照着翻画，可档案室里的图纸残缺不全，前后混乱，想找资料，先得整理资料。

资料室中年女管理员乐得有个懂事的孩子来帮她整理，索性暗暗配把钥匙给宋运辉，要是她下班不在的时候，让宋运辉自己偷偷进来关上门寻找资料。

机修工段的人本来挺烦这个宋运辉，说他一来维修单子多得像雪片，支得他们团团转，有人还趁宋运辉上班时候冲进控制室指桑骂槐，被寻建祥骂了回去，差点还打起来。但后来集中一段维修高峰后，维修单子又少了下去，上面还表扬跑冒滴漏少很多，一工段和机修工段各加一次月奖，可见设备性能好转。

再以后遇到维修，他们不能确定要用什么零件，打个内线电话给控制室问宋运辉，一问就清楚。双方关系渐渐变得铁起来。基层有时候很简单，只要拿得出技术，别人就服。 ）

另外，Y024 同学还很认真地整理了专栏提到的部分图书：

郑老师拍案惊奇书单及简评，最近各大书店有活动，可以借机囤起来了。

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为《重构》所做的那样，出什么样的问题，应该采用怎样的手法进行处理。

对于如何面对遗留系统， 毅 同学提到：

1.了解原系统已实现的功能，没有文档就在心中划分好内部功能模块；
2.各模块的边界及关联，对于业务交叉点先思考通信机制；
3.看代码，通常是瓶颈优先，业务上是先复杂后简单；
4.选定切入点；
5.正式改造时先把原有功能抽象出来使用现有实现，改造的过程完成前不会受影响；
6.改造完成后切换到新实现进行测试；
7.稳定后替换旧实现；
8.重复4-7。

Wei 同学对于“T型人”的说法感触很深：

“T型人”这个太说到点了，到底是做“专”还是做“广”，哪条路线一直是我思考的方向；工作上跟大牛工作过，给我感觉几乎是全能的，我一直都想像他们那样，做一个多面手，但是如何做广，这一直是困扰我的一个问题。

我是dev出身，但是现实遇到的问题往往跟数据库，发布的平台相关；这样说下来，各种相关领域，数据库、k8s、网络协议、DNS ，都需要大量时间去积累；有时候什么都懂一点，反而让自己应该定位什么角色感到迷茫了，掌握的水平不足以让自己去应聘DBA、Ops，但是只是应聘dev似乎又有点“浪费”，跟那些熟悉最新语言/框架的对比起来没特殊竞争力。

今天学习“T型人”这个概念，让我好好思考了自己到底应该怎么定位。我首先是一个developer，这个是根；对语言特性的熟练掌握，各种best practices，例如课程中提到的TDD等应该熟练应用起来；然后在这上面拓展，学习架构知识，多思考对不同系统应该怎么设计，老师提到的DDD会认真学习应用；再有软件最终还是给用户使用，而不是单单提交代码。相关的数据库、k8s、监控运用根据实际遇到的问题再学习解决。

最重要的是，在学习区终身学习和工作！

对于如何持续保持竞争力的问题，enjoylearning 同学提到：

程序员如何保持竞争力很重要，在这个年轻人学习能力不断提升的IT行业，作为老程序员经验阅历眼光以及技术前沿判断力就显得越来越重要。

说起来这个职业是一个需要终身学习的职业，年龄不重要，能力才重要，是不是让自己永远呆在学习区更重要。

对于技术推广，desmond 同学的理解也很棒：

技术推广，不要先推广最难的部分，先推广能让对方感到最明显好处的部分。取得对方的信任，是友好沟通的基础。

感谢同学们的精彩留言。我们的专栏更新已经进入尾声阶段，后续我会为大家做一些对整个专栏进行全盘复习的内容，敬请期待。

感谢阅读，如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给你的朋友。

评论