读书笔记: 可扩展的艺术

https://book.douban.com/people/fleure/annotation/20458253/

联合架构设计

<原文开始>JAD （联合架构设计）流程的最后一步是决定是否需要把功能提交给 ARB（架构评审委员会），进行最后的审查和批准。... 如果该功能满足下列任何一项，就应该提交给 ARB。 1) 与架构设计原则不符。 2) 就设计达不成共识。 3) 做过重大的权衡决策。 4) 高风险的功能。 </原文结束> ## 团队规模 <原文开始>我们假设经理应负的基本职责包括以下三点：确保给工程师分配了项目，无论是自己分配的，还是根据管理层指示分配的；确保执行了行政工作，如解决了薪资问题或者传达了人事信息等；以及接收项目的状态更新信息，以便报告给高级管理层。考虑到这种基础水平的管理职责，一个新近从工程师升到管理层的初级经理可能会发现，即使只管理 6 个人的团队，行政工作和项目管理的工作都会耗费她一整天的时间。... 比起那些做过一遍又一遍的工作来说，新工作通常需要花费更多时间，而且要求更加专注。在决定一个团队的最佳规模时，经验水平是一个要考虑的关键因素。</原文结束> <原文开始>一般来说，业务责任人和产品经理都想建立更多更大的面向客户的项目，这样他们才能不停地击败竞争对手，扩大收益来源，拓展客户基础。这时团队规模过小会带来两个主要问题。首先，根据所采用的产品开发生命周期方法不同，较大的项目需要更多的迭代或更长的开发时间。... 其次，如果增加了工程师数量，那么支持人员的数量也随之增加，包括经理的人数。</原文结束> <原文开始>工程师天生会对自己能够完成的工作保持过分乐观的态度，如果他们推脱过去能够完成的工作量，这会是一个明显的信号，说明他们自觉生产力下降了。</原文结束> <原文开始>比这个难得多的是在团队规模过大时，拆分团队。如果团队拆分不当，会造成可怕的后果，如代码的所有权不清楚、更难以沟通、重新适应新经理而工作压力增大。... 首先需要关注的是代码或工作，我们将在第三部分详细地讨论故障域这个概念，这些域通过隔离服务，从而限制了故障的影响范围，也许拆分团队是个把代码拆分到故障域的好机会。</原文结束> ## 为什么要考虑组织 <原文开始>组织设计和架构中的另一个要点是，一旦确定了组织或团队的边界，组织或团队的冲突就会随之而来。</原文结束>