但显然不是每个事情都要在架构设计阶段搞定，否则等于是被弄蒙了，这时候架构师的一个关键职责就是要能区分出哪些东西预先需要搞定，而哪些东西则要在迭代过程中解决。
一般来讲重置成本越大，牵涉的人越多的事情越应该由架构师预先搞定，否则就容易做无用功，对开发工作产生致命伤害。具体来讲这类事情由三个核心部分组成 (做什么 + 怎么做）：
选定Tech Stack
概要设计，确立分工的基础
协同方式
再其次则是相对比较传统一点的部分，不管从哪里开始迭代，总是要切分前端后端的职责，设计彼此交互的接口，要区分出来哪些是纯工具型的模块（比如日志），哪些是基础设施型的（比如用户管理与权限），哪些是可以彻底进行迭代的（比如具体的某个功能）。这些东西之间是有一种内在的时序关联的，不是简单一句：我们迭代吧，我们测试驱动开发吧，就可以的，那会导致很大的混乱，所以这里也是架构师要扮演角色的地方。传统上管这个叫概要设计，虽然这词现在不怎么用了，但这词其实还不错的。当然架构师不一定要一个人搞定所有这些事情，而是要肩负起协调大家搞定这些事情的职责。这个地方依赖于产品的类型对业务知识的要求程度不同：一般来讲越是面向个人的产品，在业务知识上要求越低；越是面向企业的产品业务知识的要求越高。简单讲做天气应用的时候可能直接做就行了，但做财务应用时了解财务的某些知识就挺必须的
在开发产品时，这三样事情不搞定，迭代都不好迭代。抽象点来看是这样：假设说在现有人员的基础上，预先搞定某问题需要耗费的成本为X，而迭代后，事到临头再处理，其耗费的成本为Y，那么无疑的Y>X的问题都应该是尽可能预先处理的问题，而不能以迭代为借口堂而皇之的进行忽视。而上述三方面问题，基本上是Y>X这类。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
