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

最近听到过多起软件行业“项目经理”的故事了，其实就是能堆砌几个技术框架用用；或者动辄就说自己写什么框架，然后谈论说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.杰克韦尔奇《赢》
感谢这些书籍的作者。

评论

43 楼 zjha4148 2010-03-22  

正在思考个人发展转型之道，关注架构师这个职位。。
《走出软件作坊》这书不错，还没看完，现在已经很有启发。更重要是思想的转变。但是架构师前提：一定要亲身写过代码实现，要不然对“思想转变”这个词汇感受不深。
感谢楼主，收获良多。《赢》我也想看看

42 楼 xixix2004 2010-03-02  

orcl_zhang 写道

引用

一个稳定而高效的团队，团结，有责任心，正直而勤奋，彼此信任但不依赖，各种优秀品质必须存在于每个人身上。

只能朝这个方向努力，这个是一个理想化的团队。不知道国内这样的团队有几个？

人无完人，是人就会有缺点，管理的艺术也正是把这些参差不齐的各种优缺点优化配置，合差化积。

41 楼 orcl_zhang 2010-02-27  

很受楼主的启发。但是很多地方也有点偏颇，而且感觉如果一个公司的企业文化和管理理念和技术扯上关系的，我觉得还没有上升到企业文化和管理理念。

引用

一个稳定而高效的团队，团结，有责任心，正直而勤奋，彼此信任但不依赖，各种优秀品质必须存在于每个人身上。

只能朝这个方向努力，这个是一个理想化的团队。不知道国内这样的团队有几个？

引用

所以对中层人员的提拔是必须绝对谨慎的，这会影响整个公司的价值观和未来方向。

这点很赞同。

40 楼 xixix2004 2010-02-27  

lkj107 写道

struts2跟spring现在重合的太厉害了，两个都用，实在是...
hibernate在大项目中用也是存在风险的
XP在国内基本是行不通的，XP一直认为是牛人组成的团队之间的开发方式，放到普通的程序员团队中，死的要多惨有多惨

赞同。

人员水平达不到那个层次，不要谈XP、不要谈敏捷。都是纸上谈兵。

39 楼 lkj107 2010-02-26  

struts2跟spring现在重合的太厉害了，两个都用，实在是...
hibernate在大项目中用也是存在风险的
XP在国内基本是行不通的，XP一直认为是牛人组成的团队之间的开发方式，放到普通的程序员团队中，死的要多惨有多惨

38 楼 lkj107 2010-02-26  

技术肯定是各个公司间一套适合自己公司的平台+组件
这样各个项目的开发，起步高，会省去很多技术攻关的时间和精力
组件不是说拿来开源的就用，而是有人能够控制的了这些开源的产品
不是说你看到双截棍很酷，就拿来用的，第一次拿起就去PK，估计先被双截棍打倒的是自己

37 楼 sun_in_china 2009-12-16  

感觉没有上升到管理的高度。

也许LZ讲的只是技术管理的一个方面的心得吧。

36 楼 mouge 2009-12-15  

mock1234 写道

lonlyleo 写道

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

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

终于看完了楼主的文章，我也没有看出什么。不过，凡是文章中可以具体化的东西，都有这位跟贴者的影子。也就是说，过上几年，那种对技术不求甚解仅仅纠缠于自己喜欢的服务端开发范畴的个别技术的态度，就让一个 pm 只能开发赝品而不是真正好的产品了。

唉，后生将来可能到“死”都不知道到底缺少什么！你所认为不值得花时间的那些让客户端非常酷眩的东西，可能是别的公司得以真正做出好产品的要点和需求发动机。而你所认为非常重要的一点点服务端开发经验（尽管也根本没有涉及大型网络系统架构知识），可能很多工作过一段的程序员都已经总结出来的，只是别人没有写成文章。

我跟你打赌，将来你会发现此文是一个满脑子技术思维（刚刚因为一两个项目而有些成就感）而对产品开发还没有清醒的人写的。

赞成你所说的,LZ团队的对生产力追求是很要命的想法.而且基本上是一种近期生产力的观点,远离客户为中心的产品观.为什么喜欢用简单的技术来解决一切问题,其实也是一种安于现状的做法.而且只会使技术趋于平庸.就是纯粹从技术方面来说,只是从简化代码量来衡量团队的技术标准,是很粗浅的技术思维,我们软件技术最终目的为了解决概念复杂性问题,能够清晰完整地表达应用问题比起一行说不清所以然的代码来说,是更值得去努力.LZ的简化代码论调其实也反证他对开源的态度,也许更接近微软的态度,"快速生成器"可能更好的选择.如果这样,我认为还不如涉足"元编程"

35 楼 photon 2009-12-07  

如果楼主能谈谈这些体会所针对的业务背景或者是项目背景，大家讨论的时候也许能更有针对性一些。

34 楼 flashing 2009-11-27  

其实很多时候我推荐一本书，并不是说这本书全部都说的对；只要能解决你一部分问题和迷惑，那就是有意义的了。
这是我初中时候化学老师讲的读书理念，我一直觉得老太太说的很有道理，呵呵。

雁行 写道

文章不错，很有启发意义。
不过推荐的第二本书，看倒是看了，至今仍没有解决“地主家也没有余粮”的问题，
书中似乎也没有给出解决之道啊。

33 楼 天上蝎 2009-11-25  

学习了。。真的很不错

32 楼 雁行 2009-11-24  

文章不错，很有启发意义。
不过推荐的第二本书，看倒是看了，至今仍没有解决“地主家也没有余粮”的问题，
书中似乎也没有给出解决之道啊。

31 楼 ztka 2009-11-22  

楼主举例怎么还在淘宝，google上面？？？毕竟这两家公司基于互联网的，产品方向不同，很多时候，IT是企业的衍生辅助而服务的。所以更多公司用的都不是开源产品。

可以看看世界500强里面，财务软件统一的基本都是SAP，ORACLE，管理软件SAP,ORACLE等等，企业内部架构，沟通微软，MSOFFICE等，或者IBM Notes，建立在开源上面的这些企业应用太少啦。说道IBM，他们主要营收方面可不是开源。

30 楼 lonlyleo 2009-11-22  

我还是继续对楼主的观点表示认同。

有几位同学强调UE，我想说，我现在是我们Team里面UE做得最好的程序员，但我还不是程序写得最好的UE。我的案头多少还有几本有关用户体验的书。--我的困惑是，我应该如何主动从具体编码中脱离出来，而不是被动地？

把ETL和hibernate摆在一起很有创意

Firebug不好吗？没有列出HttpWatch和IDT就是不考虑IE了吗？web的调试和测试难道就只为解决兼容性？

29 楼 ddden 2009-11-18  

我比较关注你所说的两个方面。
1、技术选型。根据你的描述，这方面你很保守，主要就是基于ssh。以我的经验，必然在ssh的基础上进行了封装，形成了一个符合自身业务特点的核心，大部分人都会给这个核心起个名字，叫做xxx框架。ok，ssh的那点事儿，是个有2-3年j2ee开发经验的人都很清楚。你还强调了不用ext（你是不是想说不用ext之类的ajax框架？）、flex，不用微软的技术等等，我想知道的是， 在UE需求如此强烈的今天，你是如何给客户保证UE的？很想知道你做的是什么业务，面对的是什么客户，更想看看你们的产品，能给个链接吗？
“虽然很少提及但是我们熟悉 Linux以及各种分布式解决方案……”，根据你的描述，你们的分布式解决方案到底是啥啊。部署在Linux，那你们用的数据库用什么？需要考虑多数据库兼容吗？如果需要，你们是怎么做的？
另外，对于真正的海量数据，我所接触过一个银行（全球top10之一）项目中，使用powercenter来做ETL，hibernate？谁知道行不行了。

2、开发模式。“还采取了Scrum的开发模式，并结合XP，推崇TDD”，这个可就相当的NB了。在“还”之前，应该还是RUP吧。“使用firebug来进行各种web相关内容的调试和测试”，你们的产品不考虑IE的吗？如果考虑IE，那firebug在IE下的那个破玩意儿，你的开发团队用的很爽吗？你们的产品到底是给谁做的啊，是中国人吗？如果是中国人，IE是必须考虑的，这是国情，我躲不过去，你应该也是一样的。
你提到了很多很多的东西，给我的感觉是，这爷们儿，厉害，估计除了生小孩，别的啥都会。

以上是我看了楼主你的帖子后想说的话，谢谢。

28 楼 flashing 2009-11-13  

mock1234 写道

flashing 写道

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



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

 

我没有往下看，所以对后边的不做评论。仅看到这一段就发现这个逻辑很典型、又扯淡。

“开源”是一家公司么？如果不是，干么拿整个开源世界跟一家公司去比？

如果你要去比较开源，那么你应该把所有使用开源产品的公司包括进来，作为一个不需要偷换概念的完整实体，然后再跟微软或者某家公司去比较。

难道大多数使用开源的公司都像你说的那样幸运么？幸运者你敢说有百分之十么？

典型的看了一个片面的东西就妄下论断啊，你心态太浮躁了。你都没看完为什么出这么个结论。我只是想表达开源足够让你把事情做好，但是产品是否成功，架构的选择很重要，这只是一些案例而已。并非ms没有成功案例也不是说用开源都成功，这个逻辑思维如果不是因为心态浮躁，很容易让人误解为不是文科生改行来的，太感性了。
另外借live的例子批批你下面的看法，live应该说界面还可以，易用性不算太差，但是响应效率和故障率显然不是太好，这是一个典型的互联网产品没做到位的案例；产品最核心的东西偏离了，界面说明不了任何问题。

27 楼 flashing 2009-11-13  

mock1234 写道

lonlyleo 写道

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

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

终于看完了楼主的文章，我也没有看出什么。不过，凡是文章中可以具体化的东西，都有这位跟贴者的影子。也就是说，过上几年，那种对技术不求甚解仅仅纠缠于自己喜欢的服务端开发范畴的个别技术的态度，就让一个 pm 只能开发赝品而不是真正好的产品了。

唉，后生将来可能到“死”都不知道到底缺少什么！你所认为不值得花时间的那些让客户端非常酷眩的东西，可能是别的公司得以真正做出好产品的要点和需求发动机。而你所认为非常重要的一点点服务端开发经验（尽管也根本没有涉及大型网络系统架构知识），可能很多工作过一段的程序员都已经总结出来的，只是别人没有写成文章。

我跟你打赌，将来你会发现此文是一个满脑子技术思维（刚刚因为一两个项目而有些成就感）而对产品开发还没有清醒的人写的。

呵呵，不用打赌，我从事这个行业10年了，曾经在国内最大的做产品的公司作为核心程序员供职多年，产品绝对不是客户端很炫就ok了，这才是新手做一两个项目时候的思维……头几天在一个ext的群里看到一个兄弟说用了一顿ext最后客户认为不好看，晕死……需求的本质是什么，绝对不是一个很炫的框架ext或者flex；甚至于这玩意都不会让产品产生更多的竞争力。
另外上面那个兄弟我也能理解，如果一个team没有一个强有力的推动者来告诉你怎么做才是对的，是很可怕的，最后就是本来好好的东西反倒起到了相反的作用，这样的案例不少见。归根结底还是人，你见识过真正的牛人就不会这么说话了，呵呵。

26 楼 duyouhua1214 2009-11-11  

flashing 写道

最近听到过多起软件行业“项目经理”的故事了，其实就是能堆砌几个技术框架用用；或者动辄就说自己写什么框架，然后谈论说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.杰克韦尔奇《赢》
感谢这些书籍的作者。

25 楼 hudefeifei1 2009-11-11  

Ethan29 写道

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

项目公司和互联网公司同属技术型公司，前者更偏技术，后者更偏运营

24 楼 harry 2009-11-11  

貌似很好很强大，但经验告诉，实际并非完美