`

讲讲我们的开发和管理理念-引用

阅读更多

引用说明:原文来自于 http://www.iteye.com/topic/508928,为了方便本人阅读,文本格式略有调整。


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

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics