关于组织架构、工作流程、岗位职责、上下游输入输出，我最初的经验并不在实际带团队中，而是在编写大规模代码中。
编写大规模代码需要保持代码的可维护性，多人合作，长期迭代，所以要对代码分层、分模块、需要做封装，公有私有，需要做抽象，做面向对象设计，设计对象名、属性、方法，然后需要画UML图设计对象和对象之间的合作关系，接口。
面向对象设计细分为OOA、OOD和OOP，其中只有OOP是和编写代码有关，OOA和OOD纯粹只是做“抽象设计”，事实上可以应用于编程之外，比如说设计组织架构和工作流程，思维模式是一样的。面向对象设计不像现实生活中那样，需要考虑人情事故与晋升机遇，在代码的世界里你就是绝对的神，你说要有光就可以有光，你就是董事长你就是CEO，你可以设计个岗，设计个部门，设计好向谁汇报，定义好这个部门的OKR，然后就让你设计的对象融入到整体进程里去发光发热了。这里最妙的地方就在于你的权力绝对大，不受限制，而设计的结果也绝对客观，不受执行力的影响，代码的运行是否健壮完全取决于你是否把正确的人放在了正确的位置上，而“正确的人”即为OOA，“正确的位置”即为OOD，而你是一人之力创造了这整个代码世界的创始人，好坏都是你能力的直接体现，锅都没得甩。
如果设计得不好，推倒重写代码也是有的，比较常见的错误是抽象错误和抽象不足。但重写的代价太大，好的架构师是不会出现这种情况的。好的架构师会保持大局观，通盘考虑全局的UML图，同时又能沉进去进行对象的公有接口设计，保持高内聚低耦合，可扩展，职责清晰易读易用，保证健壮性可兜底。
与“重写”对应的是“重构”，重写是代价巨大的，推倒重来，是应该尽量避免的，而重构是正常的，是根据外界需求变化而进行的适应性调整。如果架构设计得好，重构是低成本的，快速的，从容的。好的架构师不追求在前期就事无巨细一步到位设计清楚所有的细节，这容易导致过度设计，做很多无用功。他们追求的是“扩展性”，分层分块和设计工作流程时会高度重视，确保不要抽象错误和抽象不足。这是格局。维护住了扩展性，就可以随着项目的阶段进行重构了，比如不同阶段重点打造的对象不同，前期一些模块甚至只是占位符，接口不用真实去实现，而是硬编码个伪接口，确保全局能跑通。在中后期合适的时机，再逐步完善所有模块。
这种思维也更适合初创项目的精益创业，资源永远是不够的，很难高举高打一步到位。如何在不同阶段调兵遣将用尽可能少的资源既解决当前最优先问题，又保证全局跑通闭环和未来的扩展性，保持近期目标的清晰性和远期目标的模糊性，是管理者的必修课。而如何组织大规模代码有这方面的智慧，方法论和思维模式可以借鉴。
