本作品採用
知識共享署名-非商業性使用-相同方式共享 2.5 中國大陸許可協議
進行許可。
【本文成文於2023年6月，曾作為公司內部資料使用。日前重拾舊文，感慨頗多。時至今日，文中的部分內容已經過時（如頻繁測試的概念已經被測試驅動開發所取代），但作為軟體開發工作流程的通俗版仍有一定的價值，希望對涉足軟體開發領域的新人能有所幫助。】
在軟體系統的開發過程中，不管是系統的全部生命週期，還是乙個模組的開發過程。貫穿其中的軟體問題往往有逐步擴大的趨勢。
系統開發過程中的bug
需求分析時的bug
設計時的bug
編碼時的bug
發布時的bug
編碼過程中的bug
編碼初期發現的bug
編碼過程中發現的bug
編碼後期發現的bug
與此同時，令我們感到困惑的是，隨著bug的逐漸變大，尋找和消滅這些bug的難度也隨之變大。也就是說，越到後期，其危險性也越大。尤其是在編碼過程中發現的bug，如果在編碼後期發現錯誤，那將是我們程式設計師的災難！想一想在30分鐘內完成的**我們將用一天的時間尋找其中的bug。這對我們的身心將是多麼大的考驗！那麼如何在編碼過程中避免這種bug逐漸變大的趨勢呢？
攀岩是一項充滿刺激的運動，為了不使你在攀岩過程中有個三長兩短，安全裝備是必要的。那麼攀岩活動中我們需要使用哪些工具，注意哪些問題呢？
最高峰：
最高峰就是攀岩的目標，這幾乎是第一要素，我們不可能在岩壁上胡亂爬吧！
大地：
我們生命的保障，也是冒險活動的起始點。
攀登點：
攀岩過程的每一步我們都在尋找下乙個攀登點。攀登點是穩定的，所謂一步乙個腳印。攀登點間隔不易過小，否則則有停滯不前的趨勢；攀登點間隔不易過大，否則將有很大的風險。
鐵釺和安全繩：
我們每攀登幾步，就應該在岩壁上打上乙個鐵釺，並將安全繩固定在上邊。如果我們在攀爬過程中失足，還好有剛剛固定的鐵釺保護，我們可以從最後乙個鐵釺處重新向上攀爬。如果我們在攀岩過程中忘記使用鐵釺，一旦失足，那…
在攀岩過程中，每爬一步，離目標就越近一步，但我們的危險就越大。這跟軟體開發是不是很象呢？在攀岩活動中，有很多任務具和措施保護我們遠離危險，軟體開發是否有相似的工具和措施呢？
常規的開發流程
下圖是我們常見的軟體開發流程，讓我們看看它與攀岩活動是否有相似的地方？
式樣書與最高峰
作為軟體開發的第一要素，式樣書的重要性怎樣形容都不過分。它是我們軟體開發的最高峰，我們的所有活動都以式樣書為準。大型系統的式樣書主要以用例說明為主；模組開發的式樣書主要以函式說明為主。
原型與大地
任何軟體系統都有乙個原型，這就是我們軟體開發的大地。它是基礎，是我們行動的指南。在大型系統中原型意味著架構，它是綜合測試的基礎；在模組開發中原型意味著測試環境，它是單元測試的基礎。
頻繁測試與攀登點
軟體開發是乙個充滿創造性的工作，每一步都充滿了不穩定的因素。和攀登點的概念相似，我們在開發過程中的攀登點必須準確、間隔必須適中。準確性可由測試完成，而間隔適中意味著頻繁。頻繁測試可以達到降低風險的目的，也是避免bug變大的首要手段。要想實施頻繁測試，單元測試將起主導作用。
版本管理與鐵釺
在攀岩運動中，鐵釺起著至關重要的作用。它首先是乙個攀登點，其次它比攀登點更穩定。在軟體開發過程中，版本管理與鐵釺起著異曲同工的作用。在軟體開發過程中，只要軟體功能達到一定的穩定性之後，就應將其匯入到版本庫中。也就是說在版本庫中存放的版本都是相對穩定的版本。這裡所謂的「穩定」有兩個含意：經過單元測試沒有bug；實現了某個功能。
類似攀岩的開發流程
回過頭來，我們再看一下上面提到的軟體開發流程圖，這一次讓我們變換一下觀察的角度。如下圖，這樣看是否覺得軟體開發更像攀岩呢？
要想玩轉我們的攀岩活動。下面的一系列技能是我們首先要掌握的：
設計人員要會寫式樣書，開發人員要會看式樣書。式樣書的格式在專案組內必須統一，至於內容的質量嗎，就要靠sqa了。
理論聯絡實際是重要的。
這是我們的鐵釺！是各位開發人員必須掌握的工具。
想做攀岩高手嗎？拿起單元測試的**吧！另外，原則就象法律一樣，是很有權威的。我們的攀岩活動也有幾個原則，必須遵守：
統一軟體開發過程（rup）提出的軟體開發模式是：用例驅動、以架構為中心、迭代和增量的。是否和我們的攀岩活動（式樣書驅動、原型為中心、頻繁測試與版本管理）相似呢？我們可以將「攀岩模式」作為rup的通俗版加以理解。
開源軟體運動觸發中國軟體開發模式變革
當你在網際網路上 衝浪 時，或許不會意識到，你所瀏覽的 可能是linux作業系統 是apache伺服器 是mysql資料庫 是php語言 你同樣可以自由地獲取這些軟體的源 並在遵循一定許可規則的情況下可以自由 多數情況下還可以免費 使用而不會被人指控盜版 侵權。如果沒有這些開放源 軟體 open s...
軟體開發總結 需求與開發
需求不是越多越好，也不是越詳細越好。使用者價值是不允許討論 妥協 的，具體實現方案是允許討論 妥協 的。實現和預想之間可能存在差距 例如時間，複雜度，難度，可能性 所以開發人員應該也是需求參與者，負責向需求提出者反饋這些問題，以利於需求提出者做出進一步決策。一是完備性 需求需要明確為什麼樣的使用者提...
房子裝修與軟體開發
忽然發現裝修和軟體開發之間竟然那麼的相識，於是乎我就想把軟體開發的流程貫徹到裝修過程中，希望三個月後由於裝修流程的改進，我的裝修效果能較好的滿足客戶 我 的需求。裝修的平面方案花了三天的時間，首先讓設計師了解房子的基本情況以及我們的基本要求，然後共同協商，製作出平面方案，也就是相當於軟體開發的概要設...