Fred George:转变解决模糊问题的方式

  • Shane Hastie
  • 冬雨

2018 年 3 月 18 日

话题:语言 & 开发架构文化 & 方法

看新闻很累?看技术新闻更累?试试下载 InfoQ 手机客户端,每天上下班路上听新闻,有趣还有料!

在 "敏捷印度会议" 的数字化转型日, Fred George 谈到,当处理他所谓的 "模糊问题" 时,我们需要改变解决编程问题的方式。他提出的论点是, 在处理 Cynefin 框架的 "复杂" 领域时, 响应速度比任何其他因素都重要, 而且我们使用的软件开发模型不支持所需要的快速迭代, 这种快速迭代需要软件可以按分钟和小时的周期部署到实时环境中。他说, 理想情况下,开发 "团队" 由一个开发人员和一名客户组成,他们直接协作一起在非常短的周期内部署软件。

George 开始了他的演讲,名为物联网和微服务,他解释说,传统和敏捷实践非常适合“简单”和“复杂”的问题领域,在这些领域中,问题得到充分理解,如何解决这个问题是已知的。当问题领域需要了解,但潜在需求已经充分理解或可被充分理解时,敏捷开发实践和团队会很有效。

然后, 他探讨了不适合简单和复杂领域的问题类型,它们在复杂模型中的 "复杂" 和 "混沌" 域中, 在这里需求很不明确, 如何解决这个问题需要快速学习、反馈和适应。他举例说明了在金融机构贷款、日间交易、谷歌关键字广告和识别欺诈交易等领域涉及的模糊决策。 

在这些模糊区域中, 解决问题的最佳方法是具备开发技能的人与客户坐在一起, 编写代码、部署它, 并在非常短的周期内向客户展示结果 ; 这样, 清晰的实际问题和解决方法就会从快速循环中浮现出来。

然后, 他利用他建立的一套微服务来控制家里的大量物联网系统, 以此作为示例介绍了微服务体系结构是如何支持这种工作方式的,他使用了"异步通信的所需的模式”,通过事件 / 消息总线协调职责,从而使许多小型服务能够独立开发 (在他的 GitHub 存储库中可以找到这些代码)。

他介绍了他在设计系统时使用的架构原理:

  • 不确定性 => 刚好够用的设计
  • 面向行为的服务 = > 尽可能小的服务与定义良好的行为
  • 发布结论 = > 如果服务做一些有趣的事情, 就将其发布到总线上
  • 通过冥等性 (如果需要重复相同的操作) 和所有元素的冗余来提供可靠性

乔治通过一些例子和场景, 以一些微服务的增量交付来吸引观众。他总结描述了该系统的一些发现:

  • 大量信息出现在总线上
  • 服务之间无 RESTful 接口
  • 对多重实例 / 版本没有约束
  • 不需要单元测试,因为微服务实在是太小了,所以不需要测试就可以理解它们的行为
  • 快速失败的系统而不是验收测试

然后, 他讨论了这种针对模糊问题的开发方法与敏捷开发的不同之处。 

  • 极限编程的价值观中,“交流、简单、反馈、鼓励和尊重”是关键
  • 由于团队非常小 (程序员和客户),而且紧密协作——甚至结对都是可选项,所以不需要任何敏捷实践
  • 开发人员和客户以外的所有敏捷角色都是不需要的
  • 客户的角色不是定义需求,而是教开发人员领域,在理解问题和解决方案上面进行协作

他很清楚,这种方法对于每个开发项目来说不是必需的 (或适当的),但是对于那些在模糊领域中的人来说,这是解决问题的最好方法。

查看英文原文Fred George on Solving Fuzzy Problems

语言 & 开发架构文化 & 方法