第6章 认清现实瑕疵，改善数据建模

背景：你在通往大师的道路上继续前行。你可以指出公司遗留系统的弱点，并设计合适的组件进行替换，既使商业效果得到优化，又使工作流程更加友好。

6.1 分清概念建模和物理建模

在数据源混乱的系统中，一般最好保留一定的灵活性，不要在模型的物理层强加太多结构。

6.2 明确设计模型，追踪数据变化

事件溯源模式（更多参考）将独立事件建模为不变的数据。这些数据代表不变的事实。通过遍历事件序列并计算结果，可以看到系统当前的状态。

康威定律：设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。如果你的系统设计或者架构不支持，那么你就无法成功建立一个有效的组织；作为系统架构师，一定要深入领会康威定律，设计系统架构之前，先看清组织结构，也要看组织文化（民主合作式，集权式，丛林法则式，人才密度），再根据情况调整系统架构或者组织架构。（更多架构和康威定律的论述参看这里）

本章小结

• 保留数据的原始格式，不要试图立即将其转换为与概念一一对应的结构。你当然可以把原始数据处理成任何格式，但从复杂模型中提取与原始数据相同的信息，会带来不必要的麻烦。

• 在开发数据模型时，仔细考虑数据将被如何表示、查询和修改。在实践中，很少有项目只需要针对数据进行创建、读取、更新和删除等简单操作，因此一定要量体裁衣。

• 要把预览、备注、批准、审查和撤销事务性数据变更等操作设计得简单易行。要做到这一点，需要另外写代码，而不是依赖于预建的库。另外，在数据模型中采用事件溯源模式可以简化工作。（书中的实例是员工打卡系统）

• 数据管理工作流的设计要尊重和支持软件使用者的组织文化。若在设计时不考虑康威定律，系统很可能会被成千上万种使用方法压得不堪重负，最终崩溃。

第7章 逐渐改善流程，合理安排时间

背景：你对整个软件行业都已经足够熟悉。无论组织的哪个层级出现问题，你都能发现并修复。你的核心竞争力仍然是软件开发，但足够丰富的经验使你能很好地与各个层级的人员进行交流。

7.3 注意权衡工作的经济效益

帕累托法则：很多情况下，20%的投入就会有80%的产出。

7.4 限制积压工作，力求减少浪费

突破工作过程中的一个瓶颈，很自然地会让人看到另一个瓶颈。这是进步的标志。

未上线的代码不是资产，而是存货。而且，这些存货还容易腐坏，并具有持有成本。

若想跟上进度，要么放慢发布节奏，并且减少开发工作，要么加速反馈环。我认为将三者结合可以达到最佳效果。

7.5 力求整体大于部分之和

“玫瑰、花蕾和荆棘”的形式总结：“玫瑰”代表发生的好事，“花蕾”代表大有希望的事，而“荆棘”代表遇到的痛点。

海盗指标（更多参考）：（AARRR metrics, AARRR分别代表Acquisition、Activation、Retention、Revenue和Referral，即获取、激活、留存、收入和推荐），这些指标对任何公司都至关重要。

要足够了解周围每个人都在做什么，以便了解自己的工作是否符合大局。比如，每周让一位开发人员抽出一天时间解决客户支持团队认为值得处理的“小问题”。每周轮换，让所有开发人员都有机会处理客户的问题，从中获得经验。

本章小结

• 在处理系统级故障时，要根据需要停用或降级一些特性，使软件尽快回到可用状态。一旦压力得以缓解，便可以开始认真修复发生故障的部分。
• 寻找过度耗费时间的部分，用合理的安排加以限制，这样就可以省下时间进行其他工作。做决策不能只靠直觉，要使用“毛估”计算法，将经济因素也考虑进去。
• 谨记未上线的代码不是资产，而是存货。存货容易腐坏，并且具有持有成本。要帮助项目中的每个工作人员理解这一点。做法是让他们集中精力在给定的时间段内交付有价值的工作，而不是让团队中的每个人都为了忙碌而忙碌。
• 与分工不同的人合作时，试着用对方能理解的方式进行交流。从旁观者的角度看待问题，并思考：“这件事与正在和我交谈的人有关吗？这件事对整个项目有何影响？”

本章的案例问题及解决方式值得反复研读。

第8章 认清行业未来，再议软件开发

在不久的将来，“程序员是用技术解决人类社会常见问题的人”这一观点可能成为行业标准。

程序设计中最有趣的一直是解决问题、沟通等“以人为本”的方面；代码只是我能找到的解决问题最有力的工具而已。

站在足够高的层次与计算机交流，只需要关注如何解决问题，而不是纠结于代码编写中的细枝末节。

如果你想保持头脑清醒、不忘记问题背景，就需要一遍又一遍地问：“等等，我想解决什么问题来着？”