軟體工程的定義

學生時代老師教過我們 程式=演算法+資料結構， 但是程式就是一個軟體了麼？其實並不是，一個程式要想成為一個軟體是需要經過很多的過程的，包括需求分析、設計、測試、釋出等等的步驟，這些都屬於軟體工程的範疇，因此一個推論就是 軟體= 程式+軟體工程 ， 一個擴充套件的推論是 軟體企業=軟體+商業模式。

那軟體工程具體是什麼呢？軟體工程是把系統的、有序的、可量化的方法應用到軟體的開發、運營和維護上的過程，這是一個比較正式的定義，用我們自己的理解來說就是開發軟體過程中包含的所有活動之和就是軟體工程。書上講述軟體工程包含了軟體需求分析、軟體設計、軟體構建、軟體測試和軟體維護，這個範圍是比較狹義的，廣義的軟體工程還應該包含原始碼管理、構建、使用者體驗、使用者介面等等方面。

軟體的開發活動

從狹義上來將軟體工程是從需求分析開始，到最後的軟體維護終止，中間包含軟體設計、構建、測試、釋出。如果我們整體以一條線的模型來串起來，這就是我們熟悉的瀑布開發模型；如果我們每一小部分用一條線串起來，完成一小部分之後再接另一小部分，這就是迭代開發模型；在迭代開發模型的基礎上，加上敏捷的專案管理方法（XP，Scrum等），我們就得到了敏捷開發（可以看到敏捷開發和迭代開發並不是一個層級的東西，放在這裡可能不太合適）。

這些是我們平常比較熟悉的，不再多說。

軟體質量

軟體質量是我們比較關心的。軟體質量高，軟體的使用者就會比較舒心，產品不會頻繁的出問題，相反軟體質量低，使用者就會來投訴了。那如果實現高質量的軟體呢？

要實現高質量的軟體，我們就要看能在哪些方面來決定軟體的質量。前面定義中寫了一個等式 軟體=程式+軟體工程， 因此我們這裡的關於質量的推論就是 軟體質量=程式的質量 + 軟體工程的質量，說明僅僅是程式寫得好是不夠的，軟體開發所涉及的活動都會影響到軟體的質量（跟效能很類似，上下游的元件、服務都會影響到效能）。

程式的質量可以通過短期的衝刺或特殊辦法來提高，但是軟體工程的質量就不是靠取巧就能辦到的了，按書上所說，軟體工程的質量包含以下方面：

• 軟體開發過程的可見行（Visibility）
• 軟體開發過程的風險控制（Risk Management）
• 軟體內部模組，專案中間階段的交付質量，專案管理工具的因素
• 軟體開發成本的控制（Cost Control）
• 內部質量指標的完成情況（Internal Benchmarks）
  • 單元測試，每日構建，自動化，文件質量等

與測試的關係

軟體測試只負責軟體在開發完成之後所做的測試工作，從上面來看，軟體測試和軟體的質量保障區別還是很大的。在此我們明確一下軟體測試和軟體質量保障的概念：

軟體測試：運用一定的流程和工具，驗證軟體能實現預先設計的功能和特性，工作的流程和結果通常可量化。

軟體質量保障：軟體團隊為了讓軟體達到事先定義的質量標準而進行的所有活動，包含軟體測試。

很多時候線上出現了問題，開發可能會說"是測試沒測出來", 這其實是不對的，軟體測試只是軟體工程中的一環，軟體的質量是所有參與軟體活動的人共同來負責的，當出現了問題，我們需要審視我們的整個軟體工程流程，找出到底是哪出了問題，以後如何來預防這個問題。

團隊與個人

團隊有團隊的開發流程，個人也有個人的開發流程。當個人處在團隊中的時候，個人既要按照自己的流程來完成軟體的開發，也要考慮團隊的情況。

通過學習軟體工程，我們知道軟體質量並不是誰的事，而是所有人的事，要完成一個高質量軟體，個人不僅要完成好自己負責的部分，還要考慮整個團隊的工程，我們就擁有了領導力。

這讓我想起了亞馬遜領導力準則，不過這些領導力準則不僅讓你從團隊的角度出發，更要求你從企業的角度出發，這就是我們從小兵成長到leader的發展路徑。

最後

《構建之法-現代軟體工程》這本書對一個已經工作幾年之後的人是最有幫助的，雖然它很多都講的很淺，但是它給出了你一個索引，你可以順著它的線去尋找更高層的領域，而且很多方面為個人打開了一扇門，讓你從更高處來看待自己的工作，你也就知道了如