讲讲我们的开发和管理理念

最近听到过多起软件行业“项目经理”的故事了，其实就是能堆砌几个技术框架用用；或者动辄就说自己写什么框架，然后谈论说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压缩来处理网络传输上的问题。


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



最后，推荐几本书，我相信思想的变化比学几样技术更能提升一个人的价值，而这些提升，大多来自于书籍。
A.J2EE design and development without EJB
B.《走出软件作坊》
C.杰克韦尔奇《赢》
感谢这些书籍的作者。

评论

23 楼 vincent_fan 2009-11-10  

lonlyleo 写道

这个我觉得没有明显的大小公司之分。如果大公司或者大部门和这个有很大区别的话，那应该是没有细分到项目小组。
业务一直是重要的，就像我们会有专门的PM来负责业务沟通一样，或者也会有一个专门的业务团队和用户沟通，比如ERP顾问。
我想楼主说得就是开发管理吧，如果从业务角度看，是完全不会这么写的。但技术人员毕竟是一个特别的群体，在任何地方，只要有开发，就可以从业务中剥离出来讨论。
每个人看文章都有不同的角度，ls既然说了就不必加最后一句解释了，反而见外:)

像Springside这样fullstack（这个词中文哪个比较对应？）的框架是非常好的，我们也从中收益不浅。自从从Strutc1转到SpringMVC之后，再也没有回到过Struts2，不是不想用，而且觉得没必要了，呵呵。大家平时技术交流多讨论一下就行，或者在某个小型项目中自己玩玩。

讨论一下感觉还是好多了，一些做过的事情，慢慢就会有些头绪和连贯的思路。

大公司的管理还确实不是这样的，至少我经历的不是这样的，有太多的风格，俗点就是鸟大了什么林子都有。当然可能这样的大公司是很不规范的吧，如收购很多小公司整合在一起的。

光从技术开发的角度，文章阐述确实很清楚，描述了一种较理想的状态；技术选型上其实有时候恐怕不完全由我们来决定，客户的科技部门是必须考虑的。

主要是怕啊，担心说一句话，别人就要质问你为啥这么说，遭到一群人的BS

22 楼 lonlyleo 2009-11-10  

vincent_fan 写道

  文章某些写内容写得确实是不错，不过技术性太强。换言之，一直在考虑技术上的东西，以及围绕技术的迁移和变化来描述；从中也可以看出，项目也比较小，并且是业务不是很深。
  这样的方式我只能理解成某个小部门，或者某个小公司，如果大公司会是另外的一种情况。
  如果对于业务很复杂的行业，如银行业等，业务人员也是需要特别考虑的一个因素。
 
  只是一些讨论，不对之处，也就是个讨论，没必要进行质问啥的，比如质问我什么叫业务负责啥的。

 

这个我觉得没有明显的大小公司之分。如果大公司或者大部门和这个有很大区别的话，那应该是没有细分到项目小组。
业务一直是重要的，就像我们会有专门的PM来负责业务沟通一样，或者也会有一个专门的业务团队和用户沟通，比如ERP顾问。
我想楼主说得就是开发管理吧，如果从业务角度看，是完全不会这么写的。但技术人员毕竟是一个特别的群体，在任何地方，只要有开发，就可以从业务中剥离出来讨论。
每个人看文章都有不同的角度，ls既然说了就不必加最后一句解释了，反而见外:)

像Springside这样fullstack（这个词中文哪个比较对应？）的框架是非常好的，我们也从中收益不浅。自从从Strutc1转到SpringMVC之后，再也没有回到过Struts2，不是不想用，而且觉得没必要了，呵呵。大家平时技术交流多讨论一下就行，或者在某个小型项目中自己玩玩。

讨论一下感觉还是好多了，一些做过的事情，慢慢就会有些头绪和连贯的思路。

21 楼 vincent_fan 2009-11-09  

  文章某些写内容写得确实是不错，不过技术性太强。换言之，一直在考虑技术上的东西，以及围绕技术的迁移和变化来描述；从中也可以看出，项目也比较小，并且是业务不是很深。
  这样的方式我只能理解成某个小部门，或者某个小公司，如果大公司会是另外的一种情况。
  如果对于业务很复杂的行业，如银行业等，业务人员也是需要特别考虑的一个因素。
 
  只是一些讨论，不对之处，也就是个讨论，没必要进行质问啥的，比如质问我什么叫业务负责啥的。

 

20 楼 benqeagle 2009-11-09  

确实写的很好，多点这种文章更能提高了

19 楼 DoubleEO 2009-11-09  

我也一直是用springside，前段也用了sitemesh，写了个通用而简单的分页，不过一直没用struts2，因为觉得spring已经完全够了，看了LZ的文章，深有感触

18 楼 lonlyleo 2009-11-09  

flashing 写道

是啊，我觉得最后一句说的就是问题的关键了，scrum更多的是考虑未来两周或者三周（一个sprint）我们做什么，而不是未来半年我们做什么。一点点的成功会累积成项目成的成功，关键作为leader得搞清楚每个sprint到底要干嘛。

嗯，我想以后推行XP的时候，可以和您请教一下经验。
其实每一个短周期的目标还是非常清晰地，只是我们没有一个统一的思路，有些人想得多（比如我），有些人想得少（比如某些RD大牛）。

17 楼 Frankie199 2009-11-09  

企业第一永远是利润，说的不错！所以奉劝愤青们换位思考

16 楼 flashing 2009-11-09  

lonlyleo 写道

flashing 写道

不能集中精力先做好一两个项目吗，或者说如果利润足够支持这么多开发人员，是不是该招人了啊。我觉得还是稍微排队一下好，尽量最少安排两个人。不了解具体情况，建议仅供参考，有时候所谓的最佳实践更多是心理上的调整，比如你安排两个人做同一件事情之后。

我们是内部团队，估计这也是问题的关键吧，呵呵。内部项目想要加入什么理念？有时候我也不太相信会有什么“理念”可以被允许拿来使用。“生产力”就是快速出成果，一个又一个的小开发。

一年当中，也有机会集中精力做好几个项目，难的是持续性，每个人差不多半年就会切换一个项目。

可能实践的突破口就在于心理上的调整，我总是期望大家都能找到自己专攻的方向，然后向您所说，团队有一致的工作意志，一起前进；但每推行一阵就会感觉到疲惫。

但有时候换一种角度考虑，比如考虑我们下一步可以做哪些实际的开发工作，不去考虑那些长远的、所谓的规划的时候，会感觉好一点。

是啊，我觉得最后一句说的就是问题的关键了，scrum更多的是考虑未来两周或者三周（一个sprint）我们做什么，而不是未来半年我们做什么。一点点的成功会累积成项目成的成功，关键作为leader得搞清楚每个sprint到底要干嘛。

15 楼 lonlyleo 2009-11-09  

flashing 写道

不能集中精力先做好一两个项目吗，或者说如果利润足够支持这么多开发人员，是不是该招人了啊。我觉得还是稍微排队一下好，尽量最少安排两个人。不了解具体情况，建议仅供参考，有时候所谓的最佳实践更多是心理上的调整，比如你安排两个人做同一件事情之后。

我们是内部团队，估计这也是问题的关键吧，呵呵。内部项目想要加入什么理念？有时候我也不太相信会有什么“理念”可以被允许拿来使用。“生产力”就是快速出成果，一个又一个的小开发。

一年当中，也有机会集中精力做好几个项目，难的是持续性，每个人差不多半年就会切换一个项目。

可能实践的突破口就在于心理上的调整，我总是期望大家都能找到自己专攻的方向，然后向您所说，团队有一致的工作意志，一起前进；但每推行一阵就会感觉到疲惫。

但有时候换一种角度考虑，比如考虑我们下一步可以做哪些实际的开发工作，不去考虑那些长远的、所谓的规划的时候，会感觉好一点。

14 楼 flashing 2009-11-09  

lonlyleo 写道

写得非常好。
我的困惑是，您所写的，是一个团队为了一个目标在奋斗
而我的团队，每个人几乎都有单独的项目，7、8个人，7、8个项目，只有在做大项目的时候才会凑在一起
我经常感觉到很疲惫，这样的团队，是消防队！除了第一点“生产力”是必须要保证的以外，我们没有感到多少支援我们去做“可维护性”、“精英团队”的事情，我常常默许那些在我看来可以提高可维护性、可扩展性以及有利于团队共同成长的事情，我也在努力去了解但不深入研究一些新的东西，也在推广CI和极限；但也更多地感觉到，我已经无法掌控，部分成员明显有很强烈的功利心态，置所谓的可维护性和可扩展性于不顾，全力满足老板的“生产力”需求。

我心中常有一种凄凉的感觉，也许这样是不对的吧。。。

不能集中精力先做好一两个项目吗，或者说如果利润足够支持这么多开发人员，是不是该招人了啊。我觉得还是稍微排队一下好，尽量最少安排两个人。不了解具体情况，建议仅供参考，有时候所谓的最佳实践更多是心理上的调整，比如你安排两个人做同一件事情之后。

13 楼 yecllsl 2009-11-09  

LZ写的还是比较符合实际的，比较理性。

12 楼 lonlyleo 2009-11-09  

写得非常好。
我的困惑是，您所写的，是一个团队为了一个目标在奋斗
而我的团队，每个人几乎都有单独的项目，7、8个人，7、8个项目，只有在做大项目的时候才会凑在一起
我经常感觉到很疲惫，这样的团队，是消防队！除了第一点“生产力”是必须要保证的以外，我们没有感到多少支援我们去做“可维护性”、“精英团队”的事情，我常常默许那些在我看来可以提高可维护性、可扩展性以及有利于团队共同成长的事情，我也在努力去了解但不深入研究一些新的东西，也在推广CI和极限；但也更多地感觉到，我已经无法掌控，部分成员明显有很强烈的功利心态，置所谓的可维护性和可扩展性于不顾，全力满足老板的“生产力”需求。

我心中常有一种凄凉的感觉，也许这样是不对的吧。。。

11 楼 Aaronic 2009-11-09  

真正的经验之谈，可惜不能参与你们的团队

10 楼 tsxm 2009-11-09  

确实不错，收获不少

9 楼 tsxm 2009-11-09  

确实不错，收获不少

8 楼 Ethan29 2009-11-09  

观点非常好！我也非常认同楼主，对于优秀的团队和产品就是以代码质量为前提的！一切注重Process而忽视代码的管理者注定会带领团队走向没落！

7 楼 simba.wjxy 2009-11-08  

一个成功的模式要能够快速的复制，一个新人来到公司能够很快的融入开发，一个人的离开也不会影响到开发，这样厉害。

6 楼 angin 2009-11-08  

rails更适合贵公司

5 楼 rocwon 2009-11-07  

JE上还能找到OZ6关于第2本书的评价。。。

4 楼 whaosoft 2009-11-07  

flashing 写道

A.J2EE design and development without EJB
B.《走出软件作坊》

你推荐的头一本书 就现在的趋势快推翻了
不过第2本好多人都应该好好看看 ..