读书笔记: 可扩展的艺术

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

联合架构设计

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