【轉(zhuǎn)】講講我們的開發(fā)和管理理念

willyomg

最近聽到過多起軟件行業(yè)“項目經(jīng)理”的故事了，其實就是能堆砌幾個技術(shù)框架用用；或者動輒就說自己寫什么框架，然后談?wù)撜fstruts2等框架如何如何慢云云來忽悠菜鳥，于是寫出此文，談?wù)勏敕ā?



淘寶用開源，微軟用自己的東西，金山什么都用，Google、IBM和ORACLE以及JBOSS則全力支持OpenSource，諸多公司，我也不細評了，從最終產(chǎn)品運行效率看，微軟最差，Windows Live系列的產(chǎn)品慢的不成樣（最近幾個月才略有改觀），反倒是用開源的一個比一個快；看看google和淘寶。所以說，沒有什么快慢，只是用的人如何。
管理也好，技術(shù)也好，都是滲透著一種文化，而這種文化以及文化背后的可操作性的東西，不親身體驗，是永遠無法學(xué)會和想明白的。



說說我們公司的軟件開發(fā)文化吧。



首先是最為本質(zhì)的東西，作為軟件企業(yè)，我們追求什么？答案很簡單：第一是生產(chǎn)力，第二是可維護性（所謂的可維護性里面包括了可擴展性），第三是精英團隊。
這里解釋一下，為什么1，2，3是這樣的順序而不是其他。
首先我們是一家公司，正如杰克韋爾奇所說，任何一家公司和企業(yè)，第一目標是利潤，永遠不能偏離這個目標；而這也是一切其他文化的基礎(chǔ)。一個簡單的例子，20萬的項目，20個人月和5個人月的成本差異顯然是巨大的，而我們的目標則要努力壓縮這個人月的數(shù)字以期最大化利潤；而最大化的利潤也意味著員工的薪水空間和企業(yè)的高速成長。而可維護性意味著在團隊人員流動以及新人加入時，可以有無縫接替；或者客戶需求變更或者架構(gòu)提升時，可以幾乎無痛的切換。第三點精英團隊，并非是找一堆清華的高材生，而是一個成長型的，真誠團結(jié)并且務(wù)實的團隊。我們要做的是讓一群聰明年輕人成長為精英，讓他們擁有切實的能力和自信，從而立足于一個行業(yè)并受到同行和客戶的尊敬�？赡苡腥藭�問，為什么不提用戶？我想說的是：任何一家企業(yè)，都必須尊重用戶，而也只有精英團隊，才能真正的為客戶提供高質(zhì)量產(chǎn)品和服務(wù)，而不是每天生活在抱怨和混亂的項目開發(fā)中。



那么我們?nèi)绾螌崿F(xiàn)這些文化呢？


首先我們講生產(chǎn)力的話題。作為我本人來說，我對各種新技術(shù)都喜歡研究一下，但是極少高度深入；作為“架構(gòu)師”的角色，我喜歡把這種研究的氛圍推廣。不過研究歸研究，如果要應(yīng)用到項目中那還是有原則的，比如：A.不能簡化代碼量的，不用；B.難以上手的，不用；C.不穩(wěn)定的，不用；D.自己造輪子的（缺乏可持續(xù)維護），不用。


基于這幾個原則，目前熱門技術(shù)中，我們不用EXT或者Flex，因為它違反了A和B；不用ibatis，因為違反了A；不用GWT，因為違反了B；基本不用微軟的方案，因為很多MS的方案都違反C；而不自己造輪子，盡量基于標準的Spring/Struts2/Hibernate框架，則是處于人員更迭和維護的考慮，具體可參考J2EE design and development without EJB；我也后悔用Mina，因為缺乏持續(xù)性的維護，這方面顯然不如netty和grizzly。


那么我們使用什么呢？為了簡化代碼量，我們使用了Springside的方案，提供了最簡單實用的CRUD和Web分頁以及復(fù)雜查詢方案；并更進一步的使用了Sitemesh，從而最大成度的屏蔽了絕大多數(shù)開發(fā)人員和HTML/CSS打交道的機會；這樣也不用在EXT和FLEX間折騰了；Struts2的Convention插件提供了足夠簡單（我認為不是最）的Web映射機制，可以大量減少配置；Spring則提供了聲明性事物（基于Aspectj或者元數(shù)據(jù)聲明），對象依賴的自動裝配，以及未來可擴充（暴露服務(wù)）框架；而對Hibernate的深入理解，可以解決絕大多數(shù)情況下的存儲問題；當然我們從來不搞絕對化，特殊情況特殊處理，該JDBC直接操作的時候我也絕不會濫用Hibernate。另外，對多線程編程、鎖機制、網(wǎng)絡(luò)以及底層IO的精通，這些都成為團隊可以在項目中快速前進的優(yōu)勢。



當然如何來衡量呢？
比如Hibernate，如下幾個問題：1，什么是ThreadLocal，Hibernate如何結(jié)合ThreadLocal？2，你能馬上說出來inverse和cascade關(guān)系，cascade種類以及差異嗎？3，Hibernate什么情況下，會產(chǎn)生inner join，什么情況下會產(chǎn)生outer join？可以強制嗎？什么架構(gòu)的情況下應(yīng)該避免一對多和表連接？
如果你能快速的不查資料的回答上來這幾個問題，那么我相信你絕對不會討厭Hibernate，也絕對不會有常見的使用上的困惑。比如Hibernate結(jié)合Hibenrate search和solr，可以用最少量的代碼為我們帶來高效的企業(yè)級海量數(shù)據(jù)檢索。


另外，為了提升生產(chǎn)力我們還采取了Scrum的開發(fā)模式，并結(jié)合XP，推崇TDD，從UnitTest到selenium都是團隊工作必不可少的親密伙伴（這么多年來實在厭煩了V字形的傳統(tǒng)模式，以及一堆堆的文檔），我們鼓勵寫清洗的代碼，代碼就是文檔，注釋就是需求。我們使用了CI工具，比如hudson或者bamboo；使用jira或者trac來讓每個成員明確項目每個迭代中的目標，考慮到我們是年輕的團隊，發(fā)布周期一般是2周而不是更長；使用maven（部分結(jié)合ant）來做項目生命周期管理，使用firebug來進行各種web相關(guān)內(nèi)容的調(diào)試和測試，雖然很少提及但是我們熟悉Linux以及各種分布式解決方案……

誠然，工具和框架的堆砌并非可以達到目標，必須讓這些實踐和其中蘊含的價值觀深入人心，才可能讓這一切產(chǎn)生威力。我們從很早就開始推行的代碼價值觀，比如優(yōu)先處理錯誤，變量命名規(guī)則，代碼書寫的規(guī)則和技巧，和最近我看到的thoughtworks文集中提到的幾乎完全一樣；這些“最佳實踐”構(gòu)成了團隊務(wù)實的開發(fā)理念。
總結(jié)性的說，上面提到的一切，新技術(shù)，敏捷，過程改進，其實都是為了能夠產(chǎn)生生產(chǎn)力的“最佳實踐”。

當然，空談永遠難以解決問題，技術(shù)上的務(wù)實和有效評估并提出方案才是王道。比如文章開始提到的struts2性能問題，作為我們的解決方案，會是：首先評估項目規(guī)模，評估每秒的并發(fā)request數(shù)，用ab等工具來評估時間最長的幾個action，使用jprofiler等工具來查找本地瓶頸并解決（比如sql缺乏優(yōu)化，多表連接等帶來的性能問題），使用ehcache并做gzip壓縮來處理網(wǎng)絡(luò)傳輸上的問題。


那么有了這些，團隊就有戰(zhàn)斗力了嗎？答案并非“不”，而是“不確定”。一個穩(wěn)定而高效的團隊，團結(jié)，有責(zé)任心，正直而勤奮，彼此信任但不依賴，各種優(yōu)秀品質(zhì)必須存在于每個人身上。術(shù)業(yè)有專攻，但是品行不可能有差異，一個新人，要么同化，要么離開，沒有第三種選擇，這也是我們?yōu)槭裁锤�喜歡可塑性更強的年輕人的原因。這一切如何產(chǎn)生呢？我們的原則是在中國，我們相信企業(yè)文化來自于老板，來自于“帶頭大哥”，言傳身教決定了這一切；所以對中層人員的提拔是必須絕對謹慎的，這會影響整個公司的價值觀和未來方向。



最后，推薦幾本書，我相信思想的變化比學(xué)幾樣技術(shù)更能提升一個人的價值，而這些提升，大多來自于書籍。
A.J2EE design and development without EJB
B.《走出軟件作坊》
C.杰克韋爾奇《贏》
感謝這些書籍的作者。