??? 一 生活燦爛,望君多珍重
??? 寫下這篇牢騷小文之前,先簡略描述一番在下目前的生存狀態:上班時間:基本沒事情做,在看各種自己感興趣的技術,理論,寫一些實踐的代碼,每天下午4點,必到樓下溜達15分鐘,順便喝杯咖啡;晚上,讀書,寫程序;周末,游玩,唱K,足球.
??? 很開心的日子,對不?
??? 美好和悲慘通常不分家.作為我們公司的軟件程序員,我體會更深.更多的時候我在出差,那時候我不可能還在這個匆忙的城市度過自己的悠閑時光.我會深入祖國大后方,老老實實的蹲在某個小城市政府部門某棟小樓的某個辦公室(有時候是機房),每天像銷售/商務人員一樣向官員了解他們需要的軟件功能,然后快速開發部署以供他們使用,然后等待他們的詰責再要求,然后蹲回機房老老實實再改程序再部署再接受審判......循環周而復始.沒有周末,沒有閑暇,沒有陽光,沒有足球.
??? 在一個備受對方刁難的項目實施過程中,我在某地過了四個月這樣的日子.連續120天啊!???
??? 所以,在沒有出差的日子(不出差也意味著我在公司會無所事事),我要盡情的享受生活!
???
??? 二
??? 這兩年大家對spring的贊美之聲一直不絕于耳,囿于工作性質和時間,我不能太深入的實踐這個框架,去年只是買那本<j2ee development without ejb>來翻翻.Johnson 的論點確實深得我心,很多時候,用戶其實不需要分布式,不需要更改數據庫,不需要太過笨重的事務管理...(這些對用戶來說都是透明的),他們關心的只是軟件如何滿足他們的需要,讓他們能盡快的展開工作.為此,我們設計的系統就要開發周期短,易維護,靈活易增加功能,還要足夠健壯......
??? 什么?高靈活性,高可靠性,高健壯性?不是我們一直追求的目標么?你也許會這么反駁我.
??? 問題是我們所鼓吹的跟我們所實際做的完全兩樣.在下早年曾對sun的pet store模型很感興趣,把相關文獻源碼基本看了幾遍.并以開發人員的身份實際參與了一個應用該模型進行開發的大型項目.該項目80-100人的規模,總歷時5年.我在項目快要接近成功的時候離開了這個公司,回首這段開發經歷,不勝其苦.應用這類模型進行開發,根本不可能做到所謂的高靈活性,易于維護性,易于提高生產力.每測試一個ejb就要等待15-20分鐘啟動ejb容器的滋味,你嘗過嗎?
??? 這段時間寫了一些spring的代碼,很為spring的簡略而驚奇.但spring就是銀彈嗎?在我正要在公司內部寫一系列小文鼓吹spring之前,我這么問自己.我悲哀的回憶起,我的悲慘經歷完全和技術無關.對,spring采用ioc,程序易于測試;spring包裝了rmi,很方便的完成ejb的功能;spring提供了各著名持久框架的膠水,讓ibatis,hibernate,jdo都能輕易集成到其中...
??? 但是,我們原來的框架也不算太差啊?雖然由于前期規劃不好,代碼風格混亂不堪,水平參差不齊,但從架構組成,開發周期和運行性能而言,足以滿足用戶的實際需求了(系統的實際運行也證明了這點).那么,問題究竟在哪里?
???
??? 三
??? 我問自己.問題在于技術嗎?也許是,銷售和市場人員是這么抱怨的.但如果按照經典的軟件工程過程來分析,是誰在獲取需求?誰在編寫需求說明書?回答:可能是銷售人員和項目經理進行調研進而編寫需求.誰在編寫概要設計說明書?回答:沒有,時間很緊,來不及寫.誰在編寫詳細設計說明書?回答:沒有...誰在寫測試報告?回答:來不及寫...誰負責部署,反饋信息?回答:具體到每個程序員......
??? 別笑我.你也許認為,像我目前公司的這種情況,是很極端的例子,不可能公司不寫任何文檔,不進行任何測試的.好的,我告訴你,我們也有文檔.我從公司服務器雜亂無章的文檔中翻出了最初的需求文檔,它的內容證明了它是不折不扣的垃圾.我也翻出了某一兩個功能模塊的文檔(這還是我堅持要他們寫的),內容和實際程序設計不止差了十萬八千里.我找不到測試報告,也許這個系統真的沒有測試.就這么拿出去部署應用了.程序員又怎能不辛苦?
??? 一句老生常談的話概括:管理問題.這是小公司屢見不鮮的毛病.
???
??? 四
??? 如果說這個例子過于極端,那么看看管理良好的公司所開發的項目?前文所述應用pet store進行開發的公司,是某大公司在本地的子公司(簡稱S).S的項目開發流程非常規范.專門的需求分析員,專門的系統設計師,專門的開發人員,專門的測試小組,測試人員,測試流程.....可以說一切資源人員配置都按照大軟件工程的標準進行配置.結果呢?在開發那個80 * 5 * 12 人月的項目中,眾人一樣累得死去活來,晚上加班到12點是常有的事.
??? <人月神話>強調了一個問題:開發人員之間的交流成本非常昂貴.<人件>旗幟鮮明的論證(或憧憬):在軟件開發中,人是最重要的.然而這兩本書我認為理論性過強了,似乎也不符合我國的現實.我更喜歡這本小書:<軟件工藝> 它說:做軟件如打鐵,就是手藝.將系統交給好的程序員,他自然能做出好的軟件.好的程序員,應該需求分析,架構設計,編碼各方面都有很深的造詣.... 這本小書真讓我愛不釋手.
??? 我想,即使有銀彈,槍法不同的人使用,恐怕效果也不一樣.最好的小說,通常都反映了人本性最深邃的一面.同樣,要設計最好的程序,必須要由最好的程序員來進行.這里程序員的范疇很廣,在我的概念里,是把需求分析師,架構師,開發人員,測試人員都包含進去的.
??? 一個好的程序員應該善于與人溝通交流,邏輯思維能力要強.有一定的文史哲基礎,能將枯燥的事物用形象的比喻介紹給用戶.有一定的文筆,能簡潔流暢的編寫需求分析書.
??? 一個好的程序員應該精通系統架構.在了解需求之后能迅速將抽象的需求實際轉換為相對具體的東西(如程序原型,uml用例圖,甚至一些能說明情況的草圖),以充當需求和程序架構的橋梁.用戶根據這些成果表達/修改他們的需求,設計師根據這些成果進行框架的設計.
??? 一個好的程序員應該精通各種框架技術,熟悉相應數據庫(指應用開發而言),這樣他才能有選擇,有比較的確定用戶的功能如何做,如何做得好.
??? 一個好的程序員應該有一定的編碼水平.起碼不能寫出太離譜的代碼.
??? 一個好的程序員還要懂得如何去測試,如何發現系統漏洞,甚至如何去攻擊之.
??? ......
???
??? 我的水平也就到這里了,其他的我寫不出.雖然不能孤立的撇開管理談技術,但我覺得,假如一群好的程序員能夠做到了自己的最好,最后卻在公司窩囊的領導下搞砸了一個項目,那他們也足以問心無愧.
???
??? 五
??? 以下一系列小文是我在公司的無聊之作.剛開始我為了實際應用spring做了個小小的源碼缺陷跟蹤系統(Bug Tracking System),后來我發現這個程序雖然寫出來了,但我根本無從評估它是否易用,是否易維護,是否符合別人的使用準則.我不得不啟動界面讓別人實際的看程序,最后獲得"哦,這東西不適合我使用"的評價.老實說花了這么多時間獲得這樣的評價真讓人沮喪.于是我想寫幾篇需求和設計文檔,以使我和別人易于溝通,易于交流,而不用每次都要實際的啟動程序.
??? 原來,在經歷整年的出差/開發/部署生涯中,我極端懷疑文檔的意義.我想不可能在環境很緊迫的時候能做到一邊更改代碼一邊更改文檔.但我現在意識到,這是自己的認識偏差所導致,假如不把文檔作為程序開發的約束,而作為需求溝通,設計思想交流的橋梁,恐怕它的意義會大大提高.
??? 我很喜歡<理想國>,于是把下列小文盡量寫成對話的形式.并且借用了司馬相如作品的主人公,力求寫得生動有趣.
??? 我想和你交流的想法如下:
???
??? 1)需求分析師如何和用戶聊天以提煉需求.真實模擬國內調研時間短,需求難以明確的特點,并盡量少的在獲取需求過程中使用計算機術語.
??? 2)系統設計師如何和需求分析師分析需求,編寫需求說明書.
??? 3)系統設計師如何根據需求說明書撰寫概要設計,確立程序開發所采用的框架.
??? 4)實際開發的過程
??? 5)測試(也許會省略,^_^)
??? 6)其他......
???
??? 希望大家不吝賜教,我正在急需反省的時期,呵呵.謝了!
???