在 9 月 17 日由 @ThoughtWorks 中国主办、 @InfoQ 负责策划组织和实施的 QClub: 对话《卓有成效的程序员》作者、ThoughtWorks 软件架构师 Neal Ford 上， Neal 做了题为“浮现式设计”的演讲，本文将对他的分享做下简单的回顾。
演讲主题：浮现式设计
Neal Ford 说作为一个极客，他更喜欢技术的实践，他引用了前美国国防部长的一段饶舌的言论引申出：
软件中预先做大量设计的风险在于你不能提前知道什么是你不知道的，过早决定的设计只是些没有事实的猜测。
然后他通过一个金字塔来形容软件的架构，即你可以轻易移动顶层的组件，而移动底层的组件却要付出昂贵的代价，因此，他强调应设计简单的架构。而浮现式设计允许你等到最后的反应时刻再做设计决定。
然后 Neal 从四个方面来介绍浮现式设计：
- 浮现式设计促进因素
- 和阻碍浮现式设计战斗
- 找到管用模式
- 利用找到的模式
对于浮现式的定义，Neal 解释道这是一种自然而然的产生或者超过预期突然的出现架构设计方式。
Neal 认为通过不断的思考能够自然而然的生成抽象和模式，他称之为傻瓜式模式，主要分为两种类型：
技术模式：安全、验证、事务数据
领域模式：业务逻辑、共享功能
然后他提到了“最后反应时刻”，即越迟做决定能够拥有最大的修改权限，当问题堆积的越久就能够积累越多的知识，当然这个等待时间不是等待到最后一分钟。最后反应时刻是浮现式设计的主要思想。
Neal 认为浮现式设计中测试驱动开发必不可少，它能够在以下方面帮助我们：
- 超越测试本身增加对设计的理解
- 测试中诞生好的设计
- 更好的抽象
- 更少的事故复杂性
- 内部的原子化理解
然后，他通过重构解决“完全数”的代码来具体举例说明测试驱动开发使用前后代码设计的改变。
接下来 Neal 介绍了使用圈复杂度与外部耦合来对代码复杂度进行估计，进而发现代码中需要改进的地方，使用模式来优化这些代码。
最后 Neal 表示浮现式设计的引进需要单元测试、重构、持续集成等，这些操作起来都很困难，可以通过主动或者被动的预测来推进整个过程。
Q&A（问答环节）
为了促进参会者与 Neal Ford 的近距离交流，深入探讨在演讲过程中的疑问，本次活动设置了 Q/A（问答）环节，Neal 对大家的问题进行了简要的回复。
我们对现场的一些问答进行了总结：
Q：底层架构的改写将会动摇整体架构，但在浮现式设计中涉及底层重构的时候怎么办？
A：架构本身也存在演进，通过测试与持续集成来保证架构的稳定改变。
Q：架构的好坏对浮现式设计的引入具有很大的影响，那在架构设计方面是否具有好的一些实践帮助我们更好的使用浮现式设计？
A：这方面存在很多的实践经验，比如 Martin 说到的架构要尽可能简单，现场一时无法一一总结。
Q：历史架构是应该重写还是应该重构？
A：通常来说重构会花费更多的努力，可以通过度量机制找到有问题的那部分，架构上的问题需要重写，设计上的问题需要重构。
Q：我们现在做的是大数据的相关开发工作，主要使用 c 来进行开发，那么，我们想如果迁移到 Java，是否能够提升开发速度？
A：我认为不同的语言都能很好的解决问题，而大数据现在面临的最大问题是网络延迟，你应该把重点放到这个上面。
最后，Neal 还现场赠送了 5 本他的新作《presentaion Patterns》，有关本次对话的更多信息，你可以通过关注 @ThoughtWorks 中国、 @InfoQ 了解更多。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论