高效程序员工作法(八)

战略设计是高层设计，它帮我们将系统切分成不同的领域，并处理不同领域的关系。我在前面的内容中给你举过“订单”和“用户”的例子。从业务上区分，把不同的概念放到不同的地方，这是从根本上解决问题，否则，无论你的代码写得再好，混乱也是不可避免的。而这种以业务的角度思考问题的方式就是 DDD 战略设计带给我的。

战术设计，通常是指在一个领域内，在技术层面上如何组织好不同的领域对象。举个例子，国内的程序员喜欢用 myBatis 做数据访问，而非 JPA，常见的理由是 JPA 在有关联的情况下，性能太差。但真正的原因是没有设计好关联。

所以要做好微服务，第一步应该是识别限界上下文。

每个限界上下文都应该是独立的，每个上下文之间就不应该存在大量的耦合，困扰很多人的微服务之间大量相互调用，本身就是一个没有划分好边界而带来的伪命题，靠技术解决业务问题，事倍功半。

一句话总结：

学习领域驱动设计

六、新入职一家公司，怎么快速进入工作状态

多数程序员习惯的工作方式，往往是从细节入手，很难建立起一个完整的图景，常常是“只见树木不见森林”，而我的方式则是从大到小、由外而内，将要了解的内容层层分解，有了大图景之后，很容易知道自己做的事情到底在整体上处于什么样的位置。我把上面的内容总结了成一份供你参考。

一句话总结：

了解一个大项目，从大图景开始。

七、面对遗留系统，你应该这样做

我们把前面学到的各种知识运用到了“改造遗留系统”上。只要产品还在发展，系统改造就是不可避免的。

改造遗留系统，前提条件是要弄清楚现状，知道系统为什么要改造，是架构有问题，还是领域模型混乱，只有知道根因，才可能有的放矢地进行改造。

改造遗留系统，我给你几个建议：

构建测试防护网，保证新老模块功能一致；
分成小块，逐步替换；
构建好领域模型；
寻找行业中关于系统构建的最新理解。
八、我们应该如何保持竞争力？

我们的焦虑来自于对未来的不确定性，而这种不确定性是一个特定时代加上特定行业的产物。

从长期来看，只要生活中还有需要用自动化解决的问题，程序员这个群体还是很有前景的。但随着时间的推移，程序员这个职业的溢价也会越来越低，单纯凭借身处这个行业就获得好发展的可能性也越来越低，想让自己的职业生涯走得更顺畅，还需要找到更好的目标，不断努力。

当你有了“一专”，拓展“多能”，就会拥有更宽广的职业道路。比如，我拥有了深厚的技术功底，通晓怎么做软件：

如果还能够带着其他人一起做好，就成了技术领导者。
如果能够分享技术的理解，就有机会成为培训师。
如果能够在实战中帮助别人解决问题，就可以成为咨询师

问题：

1.持续交付是否可以再做扩展？

别把自己局限在程序员这个单一的角色中，应该了解软件开发的全生命周期。在前面的内容中，我讲了不少做产品的方法，比如，MVP、用户测试等等。如果只把自己定位在一个写代码的角色上，了解这些内容确实意义不大，但你想把自己放在一个更大的上下文中，这些内容就是必须要了解的。

如果你还什么都不会，那有一份编程的工作就好。
如果你已经能够写好普通的代码，就应该尝试去编写程序库。
如果实现一个具体功能都没问题了，那就去做设计，让程序有更好的组织。
如果你已经能完成一个普通的系统设计，那就应该去设计业务量更大的系统。

从目前的发展来看，IT 行业依然是一个非常有前景的行业，但想在这条路上走好，需要我们成为 “T ”型人才，也就是“一专多能”。一专多能的前提是“一专”，让自己成为某个方面的专家。这个专家要放在行业的标准去看，这才能降低因为一个公司的波动而造成的影响。

一句话总结：

在学习区工作和成长。

总结：

持续交付

将生产部署纳入了开发的考量。
持续交付的基础设施通常包含持续集成环境、测试环境、预生产环境和生产环境。
构建流水线保证到了下游的交付物一定是通过上游验证的。
随着 Docker 的诞生，交付由发布包变成了 Docker 镜像。

DevOps

将开发和运维结合到一起。
环境配置工具上的进步，让基础设施即代码成了行业共识。

验收测试

验收测试要站在业务的角度编写。
BDD 是一种编写验收测试的方式。
Given...When...Then... 的描述给了一个描述业务的统一方式。
写好验收测试，需要构建测试模型。

SOLID 原则

设计模式背后的道理。
单一职责原则（Single responsibility principle，SRP）。
开放封闭原则（Open–closed principle，OCP）。
Liskov 替换原则（Liskov substitution principle，LSP）。
接口隔离原则（Interface segregation principle，ISP）。
依赖倒置原则（Dependency inversion principle，DIP）。
用好单一职责原则，前提条件是看待问题颗粒度要小。

DDD

它将思考的起点拉到了业务上。
DDD 分为战略设计和战术设计。
微服务做好微服务的前提是划分好限界上下文。
微服务的第一步，不要划分微服务。

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

程序员的三大美德：

懒惰、急躁和傲慢（Laziness, Impatience and hubris）。
小心 NIH 综合症（Not Invented Here Syndrome）。
写好构建脚本，做好项目自动化。
参照 Java 知识体系，学习运维知识。
软件设计最基础的原则是“高内聚、低耦合”。
分层架构是一种设计上的分解。
不同业务量的系统本质上不是一个系统。
采用简单技术解决问题，直到问题变复杂。实战指南

本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)

架构师升级历程

驱动开发