zhang_qxian的专栏

如何创建用户故事地图用户任务是构建故事地图的基本模块 使用目标层级的概念，可以帮助汇总小任务或分解大任务。隐喻：石头，砸成小石头后仍是石头 故事地图通过从左到右的叙事流来组织。补充细节 探索替代故事。细节、替代、变化和异常都成故事地图的主体。保持流动。 提取故事地图的主干。高层故事。活动组成故事地图的主干。 使用切分来识别和特定结果相关的所有任务和细节。此时活动卡片不要移动。概念总结：任务是描述人们做什么事情的动词短语 任务有不同的目标层级 故事地图中的任务被布置在从左到右的叙事主线

对产品故事进行首次讨论，应聚焦于如何具象化产品的机会。需求其实很可能是一个假想，那么唯一可行的做法是验证想法是否具备可行性。验证的方法很多，比如和客户、用户深入交谈，观察他们目前做事的行动，不断和他们反馈，用手绘线框图（Axure）和高保真模型实现解决方案的具象化，并以此和客户/用户进行沟通。通过原型和用户测试来验证产品方案是否真的有用，有价值，并能够质疑用户所说的内容，然后在开发过程中学习（Scrum），迭代乃至最终发布。必须要始终记得，交付给客户/用户的是可用产品。基于验证的学习循环：开发-（最小可

计划，为了更少的开发故事地图帮助大型组织建立共识。贯穿各个团队的产品发布地图，可以帮助团队以可视化的方式展示依赖关系。大型用户故事地图解析：1、故事地图的主干在顶部；2、地图要涵盖整个发布计划；地图要涵盖贯穿多个用户和系统的叙事主线。提前发现可能造成损失的潜在风险是好事而不是坏事需求范围并没有蔓延，而是我们对需求的理解更深刻了。要做的事情太多，如何排定优先级？聚焦于系统外的预期成果来决定系统内需要什么功能！！聚焦于成果，即产品发布后用户能使用和感知的东西，切分发布计划应该以成果为导向【针

两个最重要的认识：使用用户故事的目的不是为了写出更好的用户故事 产品开发的目的不是开发出产品。使用用户故事的目的是最终达成共识，而达成共识最高效的方式就是面对面，借助于可视化手段来讨论，并用卡片、照片或者视频等做好备忘，以便于后续能够回忆起当时讨论的场景。不要试图去写完美的文档，不同的人对同一段文字的理解可能有天壤之别。如果从更高的层面上来讲，你的工作是改变世界（或多或少），因此软件本身并不是重点。重点在于outcome，即软件本身给用户带来了什么样好的改变。对于软件来说，想要开发的功能，总比.

演进式架构的未来基于AI的适应度函数。这个方向后续指的关注。如何能够把AI和研发过程联系起来？是崇尚简单粗暴管理，还是崇尚智能自动管理？目前有无可用开源工具或者平台支撑？ 生成式测试。需要继续什么了解。目前的基本理解，生成式测试不同于单元测试（也有类似的地方）。单元测试是指定明确的输入输出+断言来判断程序的正确性，生成式测试是程序自动生成输入+断言来判断程序的正确性。为何要构建演进式架构呢？有什么充足的理由吗？显然，首先要评估是否值得付出额外的时间和精力来构建可演进的架构。其次，可以看看有哪些衡量因

第8章实践演进式架构一、组织全功能团队。敏捷软件开发中的最佳实践之一。这里主要需要关注运维角色。 围绕业务能力来组织团队。 产品高于项目。产品生命周期长于项目。增加团队成员责任感的最佳方式，就是负责到底。 应对外部变化。一个有效的方法是，采用消费者驱动契约的模式。这个模式和SOLID中的依赖倒置很类似。就是Client来定义契约，Service来实现这个契约。相当于构建一张安全网，对这些契约进行适应度测试。但必须清醒的认识到，这需要团队具备一定的成熟度才可以。 团队成员之间的连接数。N(N-

演进式架构的陷阱和反模式反模式：供应商为王。即以供应商提供的架构为核心来组织自身业务，被供应商掌控全局。类似于20200517的HW事件，美国通过掐断半导体晶圆片的供给（非禁止，要许可）。也就是说，如果你的商业帝国强烈依赖于第三方供应商（尤其是不可替代），那么可能大厦一夜即倾。 陷阱：抽象泄露。所以重要的抽象，在某种程度上都会泄露。随着技术栈的不断变化，如何保证业务在技术不断发展时还能保持一定的稳定性？当然，重建几乎是不可避免的，但如果能在重建时付出的代价较小，显然对组织的研发效率是具备正面效应的。

第五章演进式数据数据库脚本管理策略：目前项目采用的策略是合适的，即保留每个产品版本的基础全量脚本，同时添加从上一版本到目前最新版本的升级脚本。最新的全量版本包含了最新的升级脚本。这样的好处是，如果是升级场景，在不迁移数据情况下，仅通过升级脚本即可完成升级。在新系统部署时，则运行全量脚本。在存在大量数据库操作的时候，微服务的限界上下文如何确定？因为数据库是整个系统的强力耦合点，因此单纯构建一个数据库微服务，第一直觉是不合适的。个人觉得，应该是先从业务领域入手，服务要围绕业务来构建。当需要操作数据库时，

架构中的耦合。首先需要看到，耦合是复杂系统必然的属性之一，就像生物的细胞一样，必须相互交换信息才能体现出正常的功能。但不合理的耦合却是要极力避免的。我们常说高内聚低耦合。内聚是通过业务语义的关联来组织的，那么内聚带来的，往往是模块化（物理形式往往是DLL或者服务）。文中提到了具有高度功能内聚并可独立部署的组件可使用架构量子来隐喻。这里需要注意的是，如果想能够真正独立部署，往往离不开数据库，框架或者其他第三方组件，而在架构设计时，显然这种是最需要延迟决策的部分。因此，架构量子更多是从结构性元素的完整性来考虑，

适应度函数，本质上就是一组评估函数，用以评估架构在不同维度上的表现，并从全局角度进行平衡，从而实现增量和引导式演进。简言之，其实就是能够构建出一套架构监控机制。适应度函数，并不一定全部采用自动化手段，甚至某些维度不可能采用自动化手段。评估函数的确定，和问题域密切相关。需要识别出关键维度和相关维度。架构特性---适应度函数----探索式架构设计工程效率提升（CI）----这里联想到百度的工程效率部。微服务架构，让我联想到Erlang的进程，所有进程都是独立的，相互不耦合，仅仅通过消息进行通讯。

接口隔离原则（Interface Segregation Priciple，ISP），简单说来就一句话，即不能强迫客户依赖于和他无关的接口。从本质上来讲，ISP就是隔离变化的波及范围。如果变化波及到了本身并不使用这些变化者功能的地方，这本身就是非常可怕的。对于修改和新增功能无法预测，对于大型项目来说是一场灾难。 在《敏捷软件开发：原则、模式与实践》中提到，“胖类会导致它们的客户...

一谈哲学，好像和编程没什么关系。而且这种虚无缥缈的高大上抽象思维领域，怎么和写代码这种更接近于逻辑和数学的操作关联起来？其实不尽然。我们说，任何的编程语言和设计思想，都是作者对于现实世界的理解在软件领域的投射。首先举一个大家编程中最常见的概念：面向对象。面向对象最初起源于对于人体细胞的隐喻（https://blog.youkuaiyun.com/zhang_qxian/article/details/...

昨日一朋友携家带口到上海来度假，晚上一起聚餐。席间聊天，本来家长里短，突然画风一变。朋友说，以前搞软件开发多年，做事情的思路对现在工作帮助很大。比如会想怎么把一份手工做的事情，通过写点代码，把它变成自动化。举例说，他们要维护成千上万台机器，配置各不相同，要安装各种操作系统。因机器配置不同，就需要人工填写一些模板，然后把模板导入到待装的机器上，再启动安装。以前都是手工完成，做一个模板，动辄要几天时间...

混合OO和函数式设计

原文链接：http://developer.51cto.com/art/200912/171578.htm

Alan Kay谈OO

大师们关于面向对象的若干看法

没有什么能代替对问题本身的透彻认识，除非中了头彩。没有什么解决方案能放之四海皆准，在某一场合的最佳方案，可能在别处偏偏是最差的。好方法通常具有一定的普遍适用性，熟悉以往的成功案例，可以温故而知新。解决之道不光是掌握方法，还得掌握时机，这样就能随机应变，让方法来适应问题，而不是削足适履。就算懂得再多方法和时机，实战不会根据现有知识来出题，很多领域前人也未曾探索，还是谦虚第一。

不要甘于平庸，要做超越平均水平的人

代码成本昨天在#SCNA(北美2010软件技术大会)的一个专题小组讨论会上，@chadfowler提出了这个问题：“有多少项目是因为程序的原因而失败？”我想，他的潜台词是，造成项目失败的主要原因是业务问题，而非技术问题。今天早上我把这个问题发布在了微博上。很快就有了回复，几乎所有人都认为导致项目失败的原因中，业务问题是罪魁祸首。完全没错，项目会因为成本，需求，进度计划，管理等问题而

Screaming Architecture架构的尖叫    uncle bob    30 Sep 2011    ArchitectureImagine that you are looking at the blueprints of a building. This document, prepared by an architect, tells you

前几天看到一则触目惊心的朋友圈，大概意思是，某地产商董事长下达红头文件，要求设计院接到营销户型配置及设计要求后，当天内通宵出图，而且还算了一笔账，一万块，可以让一个设计师干十天，也可以让五个设计师白加黑，通宵干一晚。当然，这事情真假与否自有良心对作俑者进行拷问，当某一天出了事情之后自有法律进行严查，但这种触目惊心涉及居民生命的事情，实在让人瞠目结舌。由此想到软件开发。相信不少人有过这种悲催的经历，...

Bjarne Däcker. Concurrent functional programming for  telecommunications: A case study of technology introduction. November 2000. Licentiate Thesis. 在Joe Armstrong的 《面对软件错误构建可靠的分布式系统》（Making rel