开发团队的管理（转）

最近听到过多起软件行业“项目经理”的故事了，其实就是能堆砌几个技术框架用用；或者动辄就说自己写什么框架，然后谈论说struts2等框架如何如何慢云云来忽悠菜鸟，于是写出此文，谈谈想法。



淘宝用开源，微软用自己的东西，金山什么都用，Google、IBM和ORACLE以及JBOSS则全力支持OpenSource，诸多公司，我也不细评了，从最终产品运行效率看，微软最差，Windows Live系列的产品慢的不成样（最近几个月才略有改观），反倒是用开源的一个比一个快；看看google和淘宝。所以说，没有什么快慢，只是用的人如何。
管理也好，技术也好，都是渗透着一种文化，而这种文化以及文化背后的可操作性的东西，不亲身体验，是永远无法学会和想明白的。



说说我们公司的软件开发文化吧。



首先是最为本质的东西，作为软件企业，我们追求什么？答案很简单：第一是生产力，第二是可维护性（所谓的可维护性里面包括了可扩展性），第三是精英团队。
这里解释一下，为什么1，2，3是这样的顺序而不是其他。
首先我们是一家公司，正如杰克韦尔奇所说，任何一家公司和企业，第一目标是利润，永远不能偏离这个目标；而这也是一切其他文化的基础。一个简单的例子，20万的项目，20个人月和5个人月的成本差异显然是巨大的，而我们的目标则要努力压缩这个人月的数字以期最大化利润；而最大化的利润也意味着员工的薪水空间和企业的高速成长。而可维护性意味着在团队人员流动以及新人加入时，可以有无缝接替；或者客户需求变更或者架构提升时，可以几乎无痛的切换。第三点精英团队，并非是找一堆清华的高材生，而是一个成长型的，真诚团结并且务实的团队。我们要做的是让一群聪明年轻人成长为精英，让他们拥有切实的能力和自信，从而立足于一个行业并受到同行和客户的尊敬。可能有人会问，为什么不提用户？我想说的是：任何一家企业，都必须尊重用户，而也只有精英团队，才能真正的为客户提供高质量产品和服务，而不是每天生活在抱怨和混乱的项目开发中。



那么我们如何实现这些文化呢？


首先我们讲生产力的话题。作为我本人来说，我对各种新技术都喜欢研究一下，但是极少高度深入；作为“架构师”的角色，我喜欢把这种研究的氛围推广。不过研究归研究，如果要应用到项目中那还是有原则的，比如：A.不能简化代码量的，不用；B.难以上手的，不用；C.不稳定的，不用；D.自己造轮子的（缺乏可持续维护），不用。


基于这几个原则，目前热门技术中，我们不用EXT或者Flex，因为它违反了A和B；不用ibatis，因为违反了A；不用GWT，因为违反了B；基本不用微软的方案，因为很多MS的方案都违反C；而不自己造轮子，尽量基于标准的Spring/Struts2/Hibernate框架，则是处于人员更迭和维护的考虑，具体可参考J2EE design and development without EJB；我也后悔用Mina，因为缺乏持续性的维护，这方面显然不如netty和grizzly。


那么我们使用什么呢？为了简化代码量，我们使用了Springside的方案，提供了最简单实用的CRUD和Web分页以及复杂查询方案；并更进一步的使用了Sitemesh，从而最大成度的屏蔽了绝大多数开发人员和HTML/CSS打交道的机会；这样也不用在EXT和FLEX间折腾了；Struts2的Convention插件提供了足够简单（我认为不是最）的Web映射机制，可以大量减少配置；Spring则提供了声明性事物（基于Aspectj或者元数据声明），对象依赖的自动装配，以及未来可扩充（暴露服务）框架；而对Hibernate的深入理解，可以解决绝大多数情况下的存储问题；当然我们从来不搞绝对化，特殊情况特殊处理，该JDBC直接操作的时候我也绝不会滥用Hibernate。另外，对多线程编程、锁机制、网络以及底层IO的精通，这些都成为团队可以在项目中快速前进的优势。



当然如何来衡量呢？
比如Hibernate，如下几个问题：1，什么是ThreadLocal，Hibernate如何结合ThreadLocal？2，你能马上说出来inverse和cascade关系，cascade种类以及差异吗？3，Hibernate什么情况下，会产生inner join，什么情况下会产生outer join？可以强制吗？什么架构的情况下应该避免一对多和表连接？
如果你能快速的不查资料的回答上来这几个问题，那么我相信你绝对不会讨厌Hibernate，也绝对不会有常见的使用上的困惑。比如Hibernate结合Hibenrate search和solr，可以用最少量的代码为我们带来高效的企业级海量数据检索。


另外，为了提升生产力我们还采取了Scrum的开发模式，并结合XP，推崇TDD，从UnitTest到selenium都是团队工作必不可少的亲密伙伴（这么多年来实在厌烦了V字形的传统模式，以及一堆堆的文档），我们鼓励写清洗的代码，代码就是文档，注释就是需求。我们使用了CI工具，比如hudson或者bamboo；使用jira或者trac来让每个成员明确项目每个迭代中的目标，考虑到我们是年轻的团队，发布周期一般是2周而不是更长；使用maven（部分结合ant）来做项目生命周期管理，使用firebug来进行各种web相关内容的调试和测试，虽然很少提及但是我们熟悉Linux以及各种分布式解决方案……

诚然，工具和框架的堆砌并非可以达到目标，必须让这些实践和其中蕴含的价值观深入人心，才可能让这一切产生威力。我们从很早就开始推行的代码价值观，比如优先处理错误，变量命名规则，代码书写的规则和技巧，和最近我看到的thoughtworks文集中提到的几乎完全一样；这些“最佳实践”构成了团队务实的开发理念。
总结性的说，上面提到的一切，新技术，敏捷，过程改进，其实都是为了能够产生生产力的“最佳实践”。

当然，空谈永远难以解决问题，技术上的务实和有效评估并提出方案才是王道。比如文章开始提到的struts2性能问题，作为我们的解决方案，会是：首先评估项目规模，评估每秒的并发request数，用ab等工具来评估时间最长的几个action，使用jprofiler等工具来查找本地瓶颈并解决（比如sql缺乏优化，多表连接等带来的性能问题），使用ehcache并做gzip压缩来处理网络传输上的问题。


那么有了这些，团队就有战斗力了吗？答案并非“不”，而是“不确定”。一个稳定而高效的团队，团结，有责任心，正直而勤奋，彼此信任但不依赖，各种优秀品质必须存在于每个人身上。术业有专攻，但是品行不可能有差异，一个新人，要么同化，要么离开，没有第三种选择，这也是我们为什么更喜欢可塑性更强的年轻人的原因。这一切如何产生呢？我们的原则是在中国，我们相信企业文化来自于老板，来自于“带头大哥”，言传身教决定了这一切；所以对中层人员的提拔是必须绝对谨慎的，这会影响整个公司的价值观和未来方向。