開發軟體的方式多種多樣。有瀑布型(wate***ll model)，有漸進型(incremental model)，有進化型(evolution model)，有樣機型(prototyping model)，有rup，有xp，有敏捷開發。不一而足。到底應該選用那種方法呢？
軟體開發歸根結底不外乎兩方面：技術和管理。技術方面包括分析、設計、程式設計、除錯等。管理包括人員管理、進度管理、風險管理、質量管理、文件管理、**管理等。而上述這些方法也都是圍繞這兩方面，不過是各有側重而已。
選擇何種方法很大程度上取決於專案的特點和開發團隊的狀況，而不必拘泥於某一種方法。如果對專案的需求很清楚並有類似的開發經驗，不妨採用瀑布型開發方式，因為最省時間。如果對需求不很清楚也沒有開發類似專案的經驗，可採用漸進型，或漸進型加樣機型。
我本人一直從事軟體工具的開發。每個新功能的開發基本上都是新的挑戰。所以，我們用漸進型開發方式較多。
在確定開發乙個新功能(feature)後，我們會花一些時間考慮總體設計，主要是分模組、分層，一般不會超過
一、兩個月。主要是弄清高層模組之間的關係，並確定重要的類。我們會畫一些模組圖、類圖和序列圖(sequence diagram)，使大家對系統有整體了解。大框架確定後，就開始寫**。我們不是每個模組每一層都分別寫好後再整合，而是採用功能驅動(feature-driven)的方式開發。我們列出能想到的子功能，排出其先後次序。最重要、最基本的功能先開發。
在開發每個子功能時，我們只寫這個子功能所必需的類、介面(inte***ce)和方法(method)。然後馬上把各模組、各層整合起來，盡快讓系統動起來。這樣開發組能及時對系統進行直觀的評價，這樣有助於盡快加深對系統的認識，也能讓質量控制組盡早介入，及時提供反饋資訊。
在開發過程中，各模組、各層的開發基本上是齊頭並進的。在我們看來，軟體就像是長起來的，而不是拼起來的、搭起來的。隨著功能的增多，系統會越來越複雜，而我們對系統的認識也越來越深。我們會隨時調整系統的設計。去掉重複的類、重複的函式，引入抽象，引入設計模式，使系統設計逐漸趨於合理。而軟體本身也就像乙個小樹苗一樣在精心呵護、修剪下成長為有用之材。
當然，這個過程並不簡單。需要每個開發成員能自覺地不斷改進設計和**。雖然**複查能阻止一些錯誤的發生，但如果開發人員不自覺，很難寫出優秀的**。
另外，每個模組都應有乙個明確的設計理念(design philosophy)，也就是設計目標。例如，有些模組可能強調可重用性，有些強調可擴充套件性，有些重視效能。在調整設計時要遵循設計理念。
我們也重視單元測試，但並不拘泥於測試驅動開發(test-driven development)，尤其在設計方案沒確定以前。在類之間的關係比較穩定後，我們開始大規模寫單元測試案例(unit test case)。在除錯時，盡量用單元測試案例復現所要排除的錯誤。這樣單元測試案例就會越積累越多，從而避免類似錯誤的重**生。
由於系統很早就能運轉（儘管功能還很簡單），質量控制組能及早介入，提供反饋。這是軟體開發成功的關鍵之一。發現問題要及時解決，尤其是關係到整體設計的問題。
不管組員的開發能力多強，開發組一定要有乙個明確的領頭人（或曰架構師）。架構師要在必要時作出決斷，而決斷往往在綜合考慮各種因素後所做的妥協。架構師即要胸懷目標又要腳踏實地。胸懷目標是有明確的設計理念，知道軟體最終要做成什麼樣。腳踏實地是根據實際情況找出一條通向目標的、風險最小的路，要知道什麼時候該做什麼，做到什麼程度。目標不明確，會走錯方向；不腳踏實地，會走上一條崎嶇曲折、充滿荊棘的路。
軟體開發是乙個複雜的過程。軟體業的一些先驅們一直在尋找與軟體業類似的行業，以借鑑一些經驗。有人認為與建築業類似，有人認為與手工業類似。把軟體看成是乙個有生命的實體，讓它逐漸長起來，或許也是乙個不錯的模擬。
北雁
２００６年９月
軟體是怎麼收費的
對於這個問題，首先搞開發的人肯定會說 廢話，軟體不收費，開發軟體的人喝西北風去？不收費是不科學的！但當我們作為使用者，在用著大量的破解軟體時，恐怕不會這麼想吧。對於沒有付費的能力和沒有付費的概念這兩種情況，後者比前者可怕得多。企業不收費不賺錢無法生存下去，再好的產品也無法迭代下去。以前都是收軟體許可...
好的軟體是怎麼寫出來的？
參加industriallogic的軟體培訓，有很多感觸。正像敏捷一樣，一位創始人也說敏捷其實並不神秘，乙個愛動腦筋的程式設計師做幾年軟體之後，自然會採用這些方法來改進工作效果 提高效率。確實也是這樣。軟體培訓內容也是這樣，雖然很多問題，之前也思考過，也改進過，但在真正的工作環境中，看到很多code...
好的軟體是怎麼寫出來的？
參加industriallogic的軟體培訓，有很多感觸。正像敏捷一樣，一位創始人也說敏捷其實並不神秘，乙個愛動腦筋的程式設計師做幾年軟體之後，自然會採用這些方法來改進工作效果 提高效率。確實也是這樣。軟體培訓內容也是這樣，雖然很多問題，之前也思考過，也改進過，但在真正的工作環境中，看到很多code...