看新闻很累？看技术新闻更累？试试下载 InfoQ 手机客户端，每天上下班路上听新闻，有趣还有料！
在 “敏捷印度会议” 的数字化转型日, Fred George 谈到，当处理他所谓的 “模糊问题” 时，我们需要改变解决编程问题的方式。他提出的论点是, 在处理 Cynefin 框架的 “复杂” 领域时, 响应速度比任何其他因素都重要, 而且我们使用的软件开发模型不支持所需要的快速迭代, 这种快速迭代需要软件可以按分钟和小时的周期部署到实时环境中。他说, 理想情况下，开发 “团队” 由一个开发人员和一名客户组成，他们直接协作一起在非常短的周期内部署软件。
George 开始了他的演讲，名为物联网和微服务，他解释说，传统和敏捷实践非常适合“简单”和“复杂”的问题领域，在这些领域中，问题得到充分理解，如何解决这个问题是已知的。当问题领域需要了解，但潜在需求已经充分理解或可被充分理解时，敏捷开发实践和团队会很有效。
然后, 他探讨了不适合简单和复杂领域的问题类型，它们在复杂模型中的 “复杂” 和 “混沌” 域中, 在这里需求很不明确, 如何解决这个问题需要快速学习、反馈和适应。他举例说明了在金融机构贷款、日间交易、谷歌关键字广告和识别欺诈交易等领域涉及的模糊决策。
在这些模糊区域中, 解决问题的最佳方法是具备开发技能的人与客户坐在一起, 编写代码、部署它, 并在非常短的周期内向客户展示结果 ; 这样, 清晰的实际问题和解决方法就会从快速循环中浮现出来。
然后, 他利用他建立的一套微服务来控制家里的大量物联网系统, 以此作为示例介绍了微服务体系结构是如何支持这种工作方式的，他使用了"异步通信的所需的模式”，通过事件 / 消息总线协调职责，从而使许多小型服务能够独立开发 (在他的 GitHub 存储库中可以找到这些代码)。
他介绍了他在设计系统时使用的架构原理:
- 不确定性 => 刚好够用的设计
- 面向行为的服务 = > 尽可能小的服务与定义良好的行为
- 发布结论 = > 如果服务做一些有趣的事情, 就将其发布到总线上
- 通过冥等性 (如果需要重复相同的操作) 和所有元素的冗余来提供可靠性
乔治通过一些例子和场景, 以一些微服务的增量交付来吸引观众。他总结描述了该系统的一些发现：
- 大量信息出现在总线上
- 服务之间无 RESTful 接口
- 对多重实例 / 版本没有约束
- 不需要单元测试，因为微服务实在是太小了，所以不需要测试就可以理解它们的行为
- 快速失败的系统而不是验收测试
然后, 他讨论了这种针对模糊问题的开发方法与敏捷开发的不同之处。
- 极限编程的价值观中，“交流、简单、反馈、鼓励和尊重”是关键
- 由于团队非常小 (程序员和客户)，而且紧密协作——甚至结对都是可选项，所以不需要任何敏捷实践
- 开发人员和客户以外的所有敏捷角色都是不需要的
- 客户的角色不是定义需求，而是教开发人员领域，在理解问题和解决方案上面进行协作
他很清楚，这种方法对于每个开发项目来说不是必需的 (或适当的)，但是对于那些在模糊领域中的人来说，这是解决问题的最好方法。
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论