本文從個人經驗出發，談談設計對軟體工程目標實現的影響。

一、軟體工程概念

首先明確下“軟體工程的概念”。

我們看下百度百科中的定義軟體工程（軟體工程概述）_百度百科 (baidu.com)

看下原文（注意，原文也有一些問題，但總體沒有大毛病）：

軟體工程一直以來都缺乏一個統一的定義，很多學者、組織機構都分別給出了自己的定義：
BarryBoehm：運用現代科學技術知識來設計並構造計算機程式及為開發、執行和維護這些程式所必需的相關檔案資料。
IEEE：在軟體工程術語彙編中的定義：軟體工程是：1.將系統化的、嚴格約束的、可量化的方法應用於軟體的開發、執行和維護，即將工程化應用於軟體；2.在1中所述方法的研究
FritzBauer：
 
在NATO會議上給出的定義：建立並使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效執行的可靠軟體的一系列方法。
《計算機科學技術百科全書》：
軟體工程是應用電腦科學、數學、邏輯學及管理科學等原理，開發軟體的工程。
     軟體工程借鑑傳統工程的原則、方法，以提高質量、降低成本和改進演算法。
         其中：
電腦科學、數學用於構建模型與演算法
工程科學用於制定規範、設計範型(paradigm)、評估成本及確定權衡
管理科學用於計劃、資源、質量、成本等管理。

比較認可的一種定義認為：軟體工程是研究和應用如何以系統性的、規範化的、可定量的過程化方法去開發和維護軟體，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來。

內涵：
一、軟體工程過程是指為獲得軟體產品，在軟體工具的支援下由軟體工程師完成的一系列軟體工程活動，包括以下四個方面：
1、P（Plan）——軟體規格說明。規定軟體的功能及其執行時的限制。
2、D（DO）——軟體開發。開發出滿足規格說明的軟體。
3、C（Check）——軟體確認。確認開發的軟體能夠滿足使用者的需求。
4、A（Action）——軟體演進。軟體在執行過程中不斷改進以滿足客戶新的需求。
二、從軟體開發的觀點看，它就是使用適當的資源（包括人員，軟硬體資源，時間等），為開發軟體進行的一組開發活動，在活動結束時輸入（即使用者的需求）轉化為輸出（最終符合使用者需求的軟體產品）。
   三個階段：定義階段：可行性研究初步專案計劃、需求分析； 開發階段：概要設計、詳細設計、實現、測試；執行和維護階段：執行、維護、廢棄
   原則：1、抽象；2、資訊隱蔽；3、模組化；4、區域性化；5、確定性；6，一致性；7、完備性；8、可驗證性
 

既然有分歧，我只能選擇自己認可的部分，即<<計算機科學技術百科全書>>所描述的：

軟體工程是應用電腦科學、數學、邏輯學及管理科學等原理，開發軟體的工程。軟體工程借鑑傳統工程的原則、方法，以提高質量、降低成本和改進演算法。
其中：
電腦科學、數學用於構建模型與演算法
工程科學用於制定規範、設計範型(paradigm)、評估成本及確定權衡
管理科學用於計劃、資源、質量、成本等管理

二、關聯的軟體設計概念

從“軟體工程”的定義看，涉及的內容非常之多。

本文限於篇幅，沒有能力也沒有必要闡述那麼多，所以主要從技術管理者的角度，闡述如何利用計算機的設計技術參與達成軟體工程的目標：

• 高質量完成專案
• 減低開發和維護成本

設計相關的內容非常之多，無法一一羅列，所以只列出以下內容：

1. 軟體架構
2. 設計原則
3. 設計模式
4. 演算法

其中“演算法”專業性太強，需要耗費的篇幅也太多，所以本文略過。

1.軟體架構

軟體構架_百度百科 (baidu.com)

軟體架構（software architecture），是一系列相關的抽象模式，用於指導大型軟體系統各個方面的設計。軟體架構是一個系統的草圖。

軟體架構描述的物件是直接構成系統的抽象元件，各個元件之間的連線則明確和相對細緻地描述元件之間的通訊。

在實現階段，這些抽象元件被細化為實際的元件，比如具體某個類或者物件。在面向物件領域中，元件之間的連線通常用介面（電腦科學）來實現

2.設計原則

設計原則_百度百科 (baidu.com)

在進行軟體系統設計時所要遵循的一些經驗準則，應用該準則的目的通常是為了避免某些經常出現的設計缺陷。

目前，較為公認的設計原則包括：開放-封閉原則、依賴倒置原則、里氏替換原則、介面隔離原則等

3.設計模式

軟體設計模式_百度百科 (baidu.com)

軟體設計模式（Design pattern），又稱設計模式，是一套被反覆使用、多數人知曉的、經過分類編目的、程式碼設計經驗的總結。

使用設計模式是為了可重用程式碼、讓程式碼更容易被他人理解、保證程式碼可靠性、程式的重用性

三、設計如何影響工程管理目標的實現

作為軟體管理者（例如CTO,高階工程師）通常情況下在專案中主要做以下工作：

1. 設計
2. 管理
3. 必要的程式碼編寫

實際做專案的時候，因為客戶、專案特性、團隊特性等因素，無法或者也沒有必要做那麼細緻的設計，所以管理者更多工作是：

1. 定義軟體架構
2. 定義具體的技術框架
3. 定義開發規範
4. 對核心/複雜的部分進行設計指導，如有必要親自參與編寫
5. 其它一些管理工作

在管理的時候，主要工作：

1. 設計指導
2. 程式碼檢查（review）
3. 確認軟體目標

一個專案正常情況下，只要規範和設計做好，通常技術上就不會有太大問題，技術管理者的主要工作也算基本完成。

在一些更大型的專案/組織中，作為技術負責人，甚至都不參與編碼工作，因為設計工作和管理工作已經足夠繁重。

技術主管在履行技術管理主要職責的過程中，所需要利用的知識和比較多，但本文只討論三點：設計原則、軟體架構、設計模式。

下面我們來簡單討論掌握和合理以上三點的重要性。

1.設計原則

某種程度上，是一個作業指南，類似開發規範、編碼規範，但主要從技術的角度出發。它是一個指導性的文案，所有的設計必須遵守這些原則，再展開。

這些原則都較好理解，原則都是針對人的侷限性而定製的。

例如單一原則，它要求一個介面或者一個函式或者是一個類應該儘量簡單，因為如果複雜了那麼可能會出現如下問題：

1. 更多的程式碼量影響維護人的閱讀效率和理解
2. 當要修改的時候，相對容易發生錯誤，可能不小心修改了其它地方
3. 測試工作量更大。例如一個方法涉及到工資的計算、儲存、輸出，那麼就需要測試至少三個有關的功能。
4. 管理型工作增加。程式碼審查時間增加

2.軟體架構

它是一個系統草圖，起到指導性作用。我們常常提到方向、指導、領袖、明燈，這是因為指明一個方向和目標是非常重要的。

沒有正確定義工作/努力目標，那麼後續的工作就會出現許多問題。所謂南轅北轍反映的就是沒有正確指導的問題。

所以軟體架構起到一個“指路“的作用，指出了各個軟體功能/部件之間的構成方式--畢竟一般的軟體都有許多的功能。

這之後，我們才會考慮概要設計、詳細設計的問題。所以它非常重要。

不同的軟體架構，對人員、硬體、專案週期、軟體質量會又不同的影響。這個環節中，設計人員的工作就是結合實際選擇合適的軟體架構。

例如，一個大型工廠的裝置管理系統，用於登記、維修、巡檢、採購、報廢、和監控等等。

一般情況下，我們會採用複合架構。總體上採用b/s(一般客戶會這麼要求），非監控部分採用簡單的分層即可，而監控的採用管道+事件/訊息+分層。

因為這個需求中，最大的問題就是硬體監控資料網路通訊的高併發和即時性，而不是人類活動的高併發和即時性。

要不要試試微服務？

現在動不動就提到的微服務架構，並不適合用到這個專案。因為微服務的主要解決的問題是：針對需求和負載變化頻繁的情況下，實現大量例項的快速部署，從而大大降低維護成本。

那麼我們這裡有沒有大量例項了？不需要，最多部署幾個例項或者主機即可，最多做一些負載均衡。

有沒有頻繁變更，頻繁重新部署，大量部署的情況？作為核心問題，採集沒有頻繁變化的必要，也沒有必要頻繁重新部署。

如果一定要強上，那麼會面臨以下問題：

1. 增加開發資源支出，因為現在cloud需要更好的硬體支援，這樣有可能需要重新採購更好的裝置，或者增加新的裝置
2. 增加設計難度和成本，從而導致設計週期更長
3. 增加除錯難度和成本，因為功能分佈在多個小服務中，日誌也多
4. 增加運維成本，因為部署的程式更多，出現問題概念也更大，所以無論時間和難度都提升了
5. 增加升級成本，進行升級的團隊必須數量掌握cloud開發，本來任何團隊都可以的

有人會說，需求沒有太多變化不是正好可以不要那麼多維護成本了嗎？

那應該是因為沒有考慮人員成本的問題。 例如如果我不做微服務框架，那麼可能會以不需要掌握這個框架的程式設計師為主，這樣是不是可以節約支出？

又有人說，我人員素質提高，效率就提升了，提升了效率就提高了單位產出。

問題是，無論怎麼樣還是要比採用非微服務的耗費更多的支出。還有從企業角度出發，為什麼不想著節約支出，這些節約的支出用於提升團隊的收益不是更好？

此外，就算這個專案多了不算很多的支出，但是從企業，組織的角度出發，難道所有的專案都需要cloud開發嗎？組織總是有做不完的大專案（能夠有很高回報的）嗎？

事實上，從整個行業角度看，絕大部分的專案都低併發（tps<10000)，關鍵資料少（值得重複利用，每年產生資料在幾千萬到一億內）。

大部分的專案都不是那麼賺錢，需要嚴格控制成本。

大部分公司也不是一直都有很賺錢的專案。

所以對於大部分小微公司/組織而言，控制成本就非常重要了。控制成本的最主要辦法是控制人員薪資、同時提升工程效率。

這種情況下，這些公司/組織就沒有必要所有的人員都是高素質（高成本）。自然對人員沒有那麼多的要求，就結合實際給他們安排相對簡單又可以做的工作，而他們的工作又能夠保證達成專案目標。

從客戶的角度出發，更加複雜的軟體架構，會導致他們的支出：更多的硬體資源支出、更多問題可能導致的成本、更長的工期等等。

所以選擇核實的架構是很重要的，它會影響技術上的實現、專案目標達成、成本。

3.設計模式

設計模式是一個描述物件關係的套路，這些套路要麼能夠實現技術目標，要麼是能夠提升編碼效率，降低維護成本，從而達成管理目標。設計模式是在具體設計和編碼階段所需要關注的。

例如單例模式主要是實現技術目標--強制一個例項，以保證對特定資源的控制。

例如轉換器模式（介面卡模式）可以節約開發時間，減少支出成本的管理目標。這是通過利用已有的功能的基礎上達成。當然您要是不在乎，重新開發一個也可以。

四、小結

軟體開發根本上和建大樓是一個道理，需要考慮專案目標（安全、適用等等）、能夠賺錢。

所以，瞭解有關設計概念/技術，併合理地應用到專案中，是很重要的。

作為者是技術主管或者設計人員，需要把節約開支，提升效率的想法貫徹到每個專案中，這是他們的本職工作。

作為技術主管必須有管理思想，必須嚴謹對待自己的工作。如果他們不這麼做，那麼就是失職，畢竟企業是盈利機構。

作為普通的程式設計師，也必須理解這些概念，如此才能更好地理解團隊目標，理解設計意圖，貫徹設計意圖。

至於非盈利專案和個人專案則是另外一回事，想怎麼折騰就怎麼折騰，例如用微服務實現企業的考勤需求，用b/s方式實現複雜的圖形設計。