軟體工程迷思
“什麼是軟體工程？”，這是一家CMM5級，敏捷4年，號稱全國最大的軟體公司的一位開發人員的問題。而從我接觸的眾多專案來看，重業務輕工程在這個公司並非個別現象。大公司尚且如此，眾多小公司就可想而知。沒有軟體工程的指導，他們是怎麼交付一個又一個的軟體版本的呢？
軟體工程是研究和應用如何以系統性的、規範化的、可定量的過程化方法去開發和維護軟體，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來。軟體工程的目標是：在給定成本、進度的前提下，開發出具有可修改性、有效性、可靠性、可理解性、可維護性、可重用性、可適應性、可移植性、可追蹤性和可互操作性並且滿足使用者需求的軟體產品。
其實光看這個定義也沒多大用處，我們對照看一下PMP中定義的鐵三角“成本、進度、範圍”和“軟體過程定義”引申出的質量鐵三角“人、過程、工具”。一個是從管理的視角，一個是從過程的視角來看待軟體開發，似乎沒有對錯之分。但在不同的企業文化中，會產生截然不同的措施和活動來，向左走or向右走？
以市場導向的公司更注重進度、成本，通常採取更多的管控措施確保目標達成，較少關注人。而在工程師文化導向的企業中，更關注人的因素，過程和工具都是人的輔助。孰優孰劣其實並沒有定論，前者更關注收穫利益，後者的員工更容易感覺到成長和幸福。
我們開啟軟體開發過程來看該公司的工程活動，參考【維基百科】，ACM 與 IEEE Computer Society 聯合修定的 SWEBOK
- 軟體需求（Software requirements）：需求分析是一個逐層分析細化的結果。使用需求分解分配表跟蹤，大致需要經過三層分解，將原始需求分解到模組級，並分配到對應的模組組開發。在理想化的情況下，模組之間介面都已經明確，大家可以各不干擾埋頭苦幹，幹完整合就完事了。可惜的是，現實往往很骨感。
- 1、每個版本都是這樣的增量需求、分解，導致無人對軟體整體有把握；
- 2、需求分解包含了設計過程，導致分析師花了很大的精力考慮實現，對需求是否符合客戶期望卻關注較少；
- 3、分析師長期脫離程式碼，其設計的介面往往並不符合需要，返工量巨大；
- 4、部分專案沒有產品經理或分析師對需求負責，導致自相矛盾的需求層出不窮。
- 近年來已經意識到這個問題，需求開始按特性進行分解，但和現有組織結構的矛盾依然突出。
- 要處理好需求的矛盾，必須關注的是：分析和設計的關係、全量和增量的關係，其中尤為關鍵的是必須有產品經理掌握產品整體的發展，權衡需求，保證實現的真正是需要的需求。
- 軟體設計（Software design）：通常設計要經過HLD/LLD，也就是從概要設計到詳細設計的細化過程，看起來很完美。但從上也能看出，SE往往在正確的事和把事情做正確之間犯糊塗，設計結果可想而知。而且需求都是補丁式的分解和開發，並未能審視新需求對架構的影響，採取更好的方案，這樣的軟體必然走向架構的腐化。其實有時候也不是設計師不知道有更好的方案，但要協調多個組的配合往往超出設計師的精力能及，出現妥協的方案就成為了更好的選擇。詳細設計就更搞笑，往往寫完程式碼了，在QA的要求下補補文件，就出來了，QA檢查後就束之高閣。當然不這麼做，開發人員也會被要寫到偽碼級的word文件逼瘋。
- 近年來在敏捷的影響下，文件的工作量已經少了很多。但又走向另一個極端，就是裸奔。軟體往往不經設計直接開始編碼。
- 要做好設計是很難的，目前看來並沒有銀彈。著力點還是在人上：1、正確的導向，不能為了滿足流程或其他，而是要回歸到產品本身生命週期和質量需求上；2、人員能力，設計和開發不能分離，否則設計不能落到程式碼中，始終是個屁。
- 軟體建構（Software construction）：在BT來審計前，大部分人認為構建不就是把軟體編出來能釋出出去嗎。領導不重視，也沒有開發人員願意幹這個。但只有專案經理在軟體開發完，各模組開始整合時才能感受到這種痛苦。不同的構建工具、構建環境、相同開源軟體的不同版本，要把這些元件整合在一起能跑起來，那是個要脫一層皮的事情。知道BT要求原始碼交付、一鍵式構建，這才發現情況已經到了多嚴重的地步。
- 構建的改進多是管理上的措施，如果能一開始重視，這是個順理成章的事。感謝BT！
- 軟體測試（Software test）：以前有人說，最好的測試改進措施就是裁撤測試部。這話雖然極端，但反映出測試人員是多麼重要卻無奈。由於測試部的存在，開發人員的測試技能退化為零。經常正常功能都有問題的版本也發給測試人員。而居然有測試部俺提單數考核測試人員的績效，可以想象這是一出什麼樣的鬧劇。我們不缺測試了流程，UT/IT/ST，不缺測試工具，也不缺方法，我們的測試缺什麼呢？
- 軟體維護與更新（Software maintenance）：公平來說，維護做得相對還可以。這個“可以”並不是指軟體的質量維護得有多高，而是在規範的生命週期管理流程下，改動做到了可追溯。
- 軟體構型管理（Software Configuration Management, SCM）：在公司叫配置管理，我們有著專門的配置管理部，但是
- 軟體工程管理（Software Engineering Management）
- 軟體開發流程（Software Development Process）
- 軟體工程工具與方法（Computer-Aided Software Engineering, CASE）
- 軟體品質（Software Quality）
“敏捷開發”（Agile Development）被認為是軟體工程的一個重要的發展。它強調軟體開發應當是能夠對未來可能出現的變化和不確定性作出全面反應的。
敏捷開發被認為是一種“輕量級”的方法。在輕量級方法中最負盛名的應該是“極限程式設計”（Extreme Programming，簡稱為XP）。而與輕量級方法相對應的是“重量級方法”的存在。重量級方法強調以開發過程為中心，而不是以人為中心。重量級方法的例子比如CMM/PSP/TSP。
（Aspect Oriented Programming，簡稱AOP）被認為是近年來軟體工程的另外一個重要發展。這裡的方面指的是完成一個功能的物件和函式的集合。在這一方面相關的內容有泛型程式設計（Generic Programming）和模板。