每個軟件企業都有自己的開發文化，各自有所不同。在這篇博文中，flashing介紹了自己對開發文化的理解，并分享了提升生產力的心得。

最近聽到過多起軟件行業“項目經理”的故事了，其實就是能堆砌幾個技術框架用用；或者動輒就說自己寫什么框架，然后談論說struts2等框架如何如何慢云云來忽悠菜鳥，于是寫出此文，談談想法。

#t#淘寶用開源，微軟用自己的東西，金山什么都用，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.杰克韋爾奇《贏》

感謝這些書籍的作者。

原文標題：講講我們的開發和管理理念 by flashing