軟體質量保證
 |
一位 Wikibookian 認為此頁面應該拆分為具有更窄子主題的較小頁面。 您可以透過將此大頁面拆分為較小的頁面來提供幫助。請務必遵循命名策略。將書籍分成較小的部分可以提供更多焦點，並允許每個部分做好一件事，這有利於所有人。 |
高質量的軟體應用程式讓使用者感到滿意。他們喜歡使用它，並且它不會妨礙他們。它能夠快速產生正確的結果，無需解決錯誤的變通方法，不會崩潰或佔用系統資源，並允許使用者繼續他們的生活。程式要麼對他們來說是不可見的，他們不會考慮使用它，要麼執行得非常好，以至於他們喜歡使用它，並可能向朋友推薦它。
另一方面，質量差的軟體應用程式會讓使用者感到惱火、煩躁和/或沮喪，甚至會導致他們損失大量時間、金錢或更糟糕的情況。它要麼太慢，以至於他們失去耐心等待它執行其功能。要麼它經常崩潰或佔用系統資源。要麼它可能看起來很醜陋，或者具有設計糟糕的使用者介面。要麼它有其他錯誤，例如導致資料丟失的錯誤。無論其缺陷是什麼，它都無法或部分無法成為使用者手中有用的工具。
作為軟體開發人員，我們的使命是確保我們開發的軟體是高質量的，以便它能夠正常執行其功能，而不會給使用者帶來痛苦或損失。
現在我們可以提出兩個問題
- 是什麼使軟體具有高質量？
- 如何確保我們的軟體確實具有高質量？
第一個問題的答案比較簡單：維基百科有一篇關於軟體質量的文章，以及Shlomi Fish撰寫了一篇題為“是什麼使軟體具有高質量？”的文章，列舉了許多良好軟體應用程式的方面。大多數終端使用者可以透過使用程式並證明他們對它的看法來判斷程式是否為高質量（當然，不同的人可能會發現使或不使軟體適合他們的不同方面）。
一旦我們解決了這個問題，我們現在就可以專注於第二個問題：我們如何確保我們的軟體是高質量的。這將是本書的主題。這個問題或它的各個方面一直是無數書籍、論文、文章、部落格文章和其他寫作的主題。在這本書中，我們將嘗試涵蓋所有方面，並給出對實現高質量程式的各種建議方法的各個方面的各種觀點。畢竟，詢問兩位軟體開發人員有關軟體工程某些方面的問題，您將得到三個不同的答案。
編寫良好程式的第一條規則是“不要立即編寫它”。相反，尋找一項可以完成您想要完成的所有或大部分工作的現有成果，並加以利用。軟體商店重新實現現有軟體的趨勢被戲稱為“此處未發明”綜合徵（或簡稱 NIH）。如果您能夠重用現有程式碼來完成您想要做的事情，那麼您將能夠更快地完成。
由於定價、許可、法律或其他方面的原因，現有成果可能並不總是適合使用。例如，許多開源專案重新實現了專有軟體：OpenSSH 是 SSH 協議的客戶端和伺服器的開源實現，該協議已經有一個專有實現；GNU Octave 是專有 Matlab 的純淨室實現；KDE 和 GNOME 桌面（以及後來的 XFCE）旨在為專有 CDE 桌面提供開源替代方案；等等。GnuTLS 的開發人員不得不開始對 OpenSSL 進行純淨室重新實現，因為 OpenSSL 具有一個有問題的（但仍然是開源的）許可證，與 GNU 專案青睞的 GPL 許可證不相容。而且這種情況還在繼續。
有時，給定的軟體包可能存在太多錯誤而無法挽救，可能與目標平臺（作業系統、程式語言、處理器架構、虛擬機器等）不匹配，因此重新實現可能更快。儘管如此，通常可以找到足夠接近的東西作為需要解決的任務的基礎，並且可以重用此程式碼。
Joel Spolsky 在他的“Joel on Software”網站上撰寫了一篇題為“為‘此處未發明’綜合徵辯護”的文章，他在文章的結尾說：“如果它是一個核心業務功能——無論如何都要自己做。”
一些查詢已編寫軟體的良好來源包括，但請注意，大量此類程式碼可能是在某些許可證下許可的，例如GNU 通用公共許可證，這些許可證與“收縮包裝”非開源軟體（即所謂的“專有軟體”）的一些使用不相容。
- 軟體目錄，例如Freshmeat或自由軟體基金會的自由軟體目錄
- 開源軟體開發中心（“Forge”），例如SourceForge。
- 通用網路搜尋引擎，例如Google 搜尋。
- 各種Linux 發行版和其他發行版或作業系統的軟體包儲存庫。
- 各種語言或平臺的軟體包集合，例如 Perl 程式語言的CPAN（“全面 Perl 檔案網路”）。
通常，使用良好的搜尋引擎（嘗試多個關鍵詞）和 Freshmeat 進行搜尋就足夠了。如果您仍然想確保，您可以嘗試詢問是否有人可以在流行的網際網路中繼聊天 (IRC)網路（如Freenode）的相關頻道或不同型別的網際網路論壇中為您指出此類程式。
功能規範是旨在解釋終端使用者將如何與程式互動以及程式將如何響應的設計文件。Joel Spolsky 在他的“Joel on Software”網站上有一篇關於編寫功能規範的四部分系列文章，他在其中介紹了編寫功能規範的原因和方法。此外，可以找到一些開源專案的以下開放內容功能規範
- 自由職業者公告板的功能規範（具有聖經主題）。
- 改進 CPAN 模組分類的功能規範（以 FOSS 世界名人為主題）。
- Windows 軟體包管理系統功能規範（以奧茲與米莉中的角色為特色）。
有些人認為，編寫和準備功能規範所需的時間最好花在編寫程式碼上（為了他們的辯護，應該注意的是，編寫它們比編寫其他設計文件（如全面的技術規範）要少得多）。在開源軟體的背景下，功能規範可能與《大教堂與集市》系列文章中的建議不一致，埃裡克·S·雷蒙德在該系列文章中聲稱，程式設計師應該在他們能夠以集市風格開始開發之前，獨自完成一個有限的工作版本。
程式碼設計是在最初階段進行的一項腦力活動，用於規劃程式碼未來發展的方向。設計的方法有很多：編寫技術規範（可能不完整），在編寫程式碼之前編寫文件，與團隊進行設計會議，思考，編寫筆記，準備圖表等等。大多數軟體開發人員在面對這個問題時，都會同意在編寫程式碼之前做好程式碼設計是一個好主意，因為修復設計糟糕的程式碼可能會花費更多的時間成本。
一些軟體工程學派（例如極限程式設計）指出，無論向實際程式設計師交付多少設計，他或她仍然需要自己進行最少的設計，例如決定如何構建子程式的內部結構，或者如何命名臨時變數。
極限程式設計方法傾向於不贊成“前期大設計”，即在實現時將應用程式設計到最細微的細節，聲稱這很可能被證明是錯誤的，很可能浪費大量時間，並且會讓底層程式設計師感覺自己受到了輕視。相反，它提倡每週進行一次設計會議，以確定程式碼未來的發展方向。
待辦事項：新增更多內容。
重構是指在不改變程式碼外部行為的情況下，提高程式碼內部質量（或優雅性）的過程。根據馬丁·福勒的《重構》一書（以及之前人們“清理”程式碼的經驗），重構可以透過對現有程式碼庫應用一些易於理解的轉換來完成，同時在每個點上都保持程式碼的完整性，需要很少的精力並且很少有破壞程式碼的風險。
除了重構之外，一些程式設計師有時會覺得需要重寫程式碼的某些部分，他們認為這些部分要麼完全不優雅，要麼無法滿足程式碼新功能所需的任務。這種重寫的一種極端形式是從頭開始專案，這被稱為完全重寫。
待辦事項：新增Joel的“你永遠不應該做的事情，第一部分”，以及“Rub a dub dub”，關於ack-users郵件列表中重寫的討論。