《人月神话》里有一个关于项目管理的经典的论断：「往一个延期的项目里加人，只会让项目进度更糟」。当然这句话是有背景和条件的，但是可以确定的是，多加一个人到项目里，开发速率不会提升到N+1。现在的各种软件开发方法论都在以打破这个宿命为目标，旨在让团队规模和开发效率能维持一个线性正比关系。
框架本来是一个技术概念，用于将一个复杂的问题进行分层抽象处理。在一个规模稍微大一点的开发团队里，技术上的分层，往往同时带来了工作上的分工：少数人专门做框架，其他人在框架的基础上写代码，让框架去解决设计上的模块化、解耦问题，使用框架的人集中精力实现业务逻辑。这种方法似乎完美解决了团队分工协作的问题，并且对于管理者来说，组织结构清楚，划分简单，很容易向项目里加人。但是实践证明，按技术分层分工会带来一些大家不希望看到的副作用。
任何的层次的划分肯定是基于当前的业务模式做出的决定，随着业务的不断变化，技术框架会越来越难用。一个典型的场景是，由于新的业务模式，业务开发向框架开发提出新需求，要求其在框架中实现一个新功能，而框架开发回应说：「这不是一个普遍需求，我不能在框架中实现，否则框架就没法维护了，你自己实现吧」。负责业务开发的人顶着时间压力，只能使用各种work around写quick and dirty的代码，代码开始smell bad…..直到某一天有人被熏得忍无可忍，喊道：「来改改这该死的框架吧！」， 当他挽起袖子准备大干一场的时候，等待他的是一坨一坨谁也看不懂的代码和依旧紧迫的项目排期，缓慢而又痛苦的大规模重构有如大姨妈一样在所难免。
业务逻辑的同事非常惨，老板认为，有人专门开发框架层，你们就专心实现业务逻辑，无限追求开发速度。于是他们长期扛着排期压力，对于框架之外的世界知之甚少，技术成长缓慢，长期维持这种状态势必工作效率低下。少数超人日夜加班之余，以惊人的毅力研读各种框架代码、技术书籍，苦练内功，终于当上了框架开发，心想实现我技术理想的时刻终于到了。于是在设计框架的时候，带着种种洁癖和技术情结无限追求实现的简洁、技术的通用，希望框架能在各种场景下都被用到，加之脱离业务逻辑，搞出了一些漂亮的废物。即使写出了好看又好用的新框架，面对数量浩大的遗留代码，如何打破惯性、平衡时间表进行迁移又成了巨大的问题。
我在有道对一个项目遗留代码持续重构的经历，使得我认为，大规模的重构无论对于技术还是对于业务都太过激进，是要避免的事情。代码通过零修碎补，小幅持续改进是安全又稳妥的做法，而前面那种平时不断欠债，到期一次偿还实在是既不优雅又不经济。曾经我从Ubuntu迁移到Archlinux正是看中后者的rolling update。要做到零修碎补，前提是尽量避免按技术层次的分工，一个人可以接触整个技术栈。每个人在新功能的开发过程中，都可以根据自己对业务的理解，对基础的工具或者框架做修正。当我接触到一个100人的开发团队后，我发现原来的想法too simple，项目规模上升一个规模后，问题演变成一个系统性问题，加上历史包袱问题变得更加复杂，以致于明明觉得很多地方不大对，就是找不到简单有效的解决方法，no silver bullet。
好在硅谷已经告诉我们，小团队一样可以做大生意。所以我选择暂时逃避这些复杂的问题，focus在做事上。虽然只在贴吧呆了两个月，但是这两个月却是非常宝贵的经历。感谢定坤给我这样的机会，并理解我的决定，无以为报。
最后还是记一下现在关于团队的一些观点：
- 如果可能的话，控制团队规模。10人以下的时候，人的智力和效率还是接近线性叠加模型的
- 尽量按业务垂直拆分团队，而不是按技术分层水平拆分，团队里的每个成员有共同的目标
- 在一个团队里尽量避免开发的分层分工
- 不同团队中相同方向的人需要保持交流
