技术框架和团队

《人月神话》里有一个关于项目管理的经典的论断:「往一个延期的项目里加人,只会让项目进度更糟」。当然这句话是有背景和条件的,但是可以确定的是,多加一个人到项目里,开发速率不会提升到N+1。现在的各种软件开发方法论都在以打破这个宿命为目标,旨在让团队规模和开发效率能维持一个线性正比关系。

框架本来是一个技术概念,用于将一个复杂的问题进行分层抽象处理。在一个规模稍微大一点的开发团队里,技术上的分层,往往同时带来了工作上的分工:少数人专门做框架,其他人在框架的基础上写代码,让框架去解决设计上的模块化、解耦问题,使用框架的人集中精力实现业务逻辑。这种方法似乎完美解决了团队分工协作的问题,并且对于管理者来说,组织结构清楚,划分简单,很容易向项目里加人。但是实践证明,按技术分层分工会带来一些大家不希望看到的副作用。

任何的层次的划分肯定是基于当前的业务模式做出的决定,随着业务的不断变化,技术框架会越来越难用。一个典型的场景是,由于新的业务模式,业务开发向框架开发提出新需求,要求其在框架中实现一个新功能,而框架开发回应说:「这不是一个普遍需求,我不能在框架中实现,否则框架就没法维护了,你自己实现吧」。负责业务开发的人顶着时间压力,只能使用各种work around写quick and dirty的代码,代码开始smell bad…..直到某一天有人被熏得忍无可忍,喊道:「来改改这该死的框架吧!」, 当他挽起袖子准备大干一场的时候,等待他的是一坨一坨谁也看不懂的代码和依旧紧迫的项目排期,缓慢而又痛苦的大规模重构有如大姨妈一样在所难免。

业务逻辑的同事非常惨,老板认为,有人专门开发框架层,你们就专心实现业务逻辑,无限追求开发速度。于是他们长期扛着排期压力,对于框架之外的世界知之甚少,技术成长缓慢,长期维持这种状态势必工作效率低下。少数超人日夜加班之余,以惊人的毅力研读各种框架代码、技术书籍,苦练内功,终于当上了框架开发,心想实现我技术理想的时刻终于到了。于是在设计框架的时候,带着种种洁癖和技术情结无限追求实现的简洁、技术的通用,希望框架能在各种场景下都被用到,加之脱离业务逻辑,搞出了一些漂亮的废物。即使写出了好看又好用的新框架,面对数量浩大的遗留代码,如何打破惯性、平衡时间表进行迁移又成了巨大的问题。

我在有道对一个项目遗留代码持续重构的经历,使得我认为,大规模的重构无论对于技术还是对于业务都太过激进,是要避免的事情。代码通过零修碎补,小幅持续改进是安全又稳妥的做法,而前面那种平时不断欠债,到期一次偿还实在是既不优雅又不经济。曾经我从Ubuntu迁移到Archlinux正是看中后者的rolling update。要做到零修碎补,前提是尽量避免按技术层次的分工,一个人可以接触整个技术栈。每个人在新功能的开发过程中,都可以根据自己对业务的理解,对基础的工具或者框架做修正。当我接触到一个100人的开发团队后,我发现原来的想法too simple,项目规模上升一个规模后,问题演变成一个系统性问题,加上历史包袱问题变得更加复杂,以致于明明觉得很多地方不大对,就是找不到简单有效的解决方法,no silver bullet。

好在硅谷已经告诉我们,小团队一样可以做大生意。所以我选择暂时逃避这些复杂的问题,focus在做事上。虽然只在贴吧呆了两个月,但是这两个月却是非常宝贵的经历。感谢定坤给我这样的机会,并理解我的决定,无以为报。

最后还是记一下现在关于团队的一些观点:

  • 如果可能的话,控制团队规模。10人以下的时候,人的智力和效率还是接近线性叠加模型的
  • 尽量按业务垂直拆分团队,而不是按技术分层水平拆分,团队里的每个成员有共同的目标
  • 在一个团队里尽量避免开发的分层分工
  • 不同团队中相同方向的人需要保持交流
This entry was posted in 技术学习 and tagged , , . Bookmark the permalink.

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据