全行業需要而非軟體工程

首先，需要糾正一點是，不是僅僅軟體工程需要先有設計，然後才能程式設計。所有的行業都需要先進行設計，才能夠去真正落地實施（當然，各行各業的用詞可能會有些差別，像拍電影通常稱之為：籌劃）。

“商業計劃書”就很好的體現了“先設計，在實施”的思路。商業計劃書中包含很多內容（如：市場痛點、競爭分析、運營支援、公司概況、財務預測、融資計劃、財務報表等等一些內容），這些內容核心就是在介紹兩方面：

一、我們有什麼資源、資料體現有哪些；

二、我們要完成的事情有什麼前景、如何實現這個事情。

第二點通常佔比70%，且是還沒有實現的東西，需要預先的規劃出來，把所有需要的準備工作用比較簡潔的方式描述出來。從某種角度來說，它也是一種藍圖。未來所有工作都是圍繞這個藍圖，不斷的延伸、展開的。

沒設計能不能幹？

那麼問題來了，既然有了設計之後，後面可以把它作為中心來進行展開。如果沒有設計，可以直接程式設計麼？

答案是可以的。正如：早餐是先吃麵包後喝牛奶，還是先喝牛奶後吃麵包的問題一樣，本身沒有特別硬性的規定。軟體專案同樣如此，在二十年前，中國網際網路產業方心未艾之際，有很多大牛級人物都是一邊編寫程式程式碼，一邊理順思路，慢慢設計並實現出劃時代意義的軟體產品的（例如：某民防毒軟體），當初他們無論是出於個人愛好也好，還是有遠大的夢想想要改變人們生活方式也好，最初他們也是對於產品的定位沒有一個清晰、準確的認知。

但是，沒有設計先編碼的方法，隨著客戶業務的複雜化和耦合化不斷增長，已經越來越凸顯出對軟體專案致命的影響。越是到軟體專案的後期，這個影響會越來越深遠，覆蓋的範圍也相應變大。

所以，後來大家做了很多優化，比如：建立完善的軟體設計思想和步驟，設立專門的業務分析&程式設計崗位，將程式模組化，將系統架構微服務化，都是在優化軟體專案從開始立項到最終交付過程中避免後期造成致命影響的措施。

這些優化其實也都是已“先設計再程式設計”為基礎的。

所以，軟體專案中先設計後程式設計是避免後期出現致命問題的一種優秀實踐。但也要根據業務的實際情況，避免濫用造成資源的浪費。

不只是軟體工程強調先設計後程式設計，其實任何的工程都是設計在程式設計前面，因為沒有設計就去程式設計那就是盲目行動，程式設計只是整個工程裡的一部分，而設計就是整個工程的靈魂，就像蓋房子時的框架，其次還有預算，材料，後面才是施工。

我以前做過幾年自動化方面的工程，不管是裝置改造還是幫人家做一個純軟體方面的專案，基本上在下訂單之後，第一步就是設計，因為在選材，造價之後就是下訂單，籤合同。然後就開始做這個工程了，第一步就是工程設計，目的就是在完成任務的前提下，形成一個完整的計劃：怎樣降低成本，提高產品的效能，怎樣把工程最優化，做到價效比最點，安全性最高。

所以設計是非常重要的，就像打仗時的作戰計劃，設計就是打仗時的作戰計劃，程式設計就像下一步的具體戰鬥任務。如果沒有作戰計劃，就直接衝向敵人亂打一陣，那必然打敗仗，甚至可以說是胡鬧。同樣沒有設計的程式設計就是沒有計劃的胡衝亂撞，沒有任何的效率。

比如，做用plc控制變頻器，用觸控式螢幕做上位機，這個比較小的軟體工程，我們肯定不能先去程式設計，因為你還沒做設計呢，你怎麼程式設計？用那種方式去程式設計？用什麼語言去程式設計？肯定沒法下手，我們必須先去設計。

一，我們需要先設計用那種控制方法，因為控制變頻器有：端子控制的方法，優點是程式設計簡單，但成本要高一點些，因為變頻器的給定需要外加d/a模組，或者其他給定源；通訊控制方式，優點成本低，但程式設計相對複雜，對技術方面要求稍微高一些，所以這個要提前設計好。

二，選材和防備，同樣的效能，肯定選價格最低的，但同時也要保證質量；同時我們要保證萬無一失，必須設計第二套方案作為備用。假設第一方案出現了意外，那第二套方案就可以應急，彌補第一方案的漏洞，這樣才能萬無一失。

三，我們可以程式設計了，展示我們的才華吧，在設計的框架下面，就像給了我們一個游泳池，你盡情表演吧！

所以說，不管什麼樣的軟體工程，雖然程式設計很重要，但必須設計在先，程式設計在後。

事先亮明身份，我是一個工作了五年的程式設計師。那麼回過頭來，我覺得我應該有資格分析一下這個問題。

為什麼要設計先行？

第一，如果沒有設計，程式設計師沒有任何事情是可做的。如果有人跟你說，還能搭個框架。我只能說，他們公司十有八九是外包或者是一套架構走天下的那種。實際上，按照正確的流程，程式設計師或者架構師需要根據需求進行框架規劃。在需求出來之前，什麼工作都沒法開展。

為什麼提到需求呢，需求又跟設計有什麼關係？需求是設計的基礎，設計是需求的表面特徵。一個完整的專案流程，在客戶提出需求之前，UI需要根據客戶需求確認專案UI，產品經理需要整理需求，分析客戶的隱藏需求（這一點很重要，因為大多數客戶都沒法準確描述自己想要什麼），據此出具需求分析或者需求說明書。架構師根據需求說明書，設計（注意）系統架構。然後專案負責人根據需求說明以及架構師設計的架構，規劃專案模組劃分，然後交由下面的程式設計師開發。程式設計師接到領導下發的任務說明，需要以此編寫自己負責模組的實現邏輯（也就是設計開發步驟），最後才是開發。

第二，先有設計能有效的防止你後續跟產品經理以及客戶二（不定多少）次修改需求引發的撕逼甚至鬥毆。

正如前面說的，大部分客戶不知道自己想要啥，甚至產品經理都不知道自己想要啥。所以一個完備的設計圖或者正規的文件都是跟他們撕逼過程中最重要的證據。

第三，先有設計再實現，更利於實現的提速。因為設計本身就是在思考這個功能該如何完成的過程。這對於程式設計師來說很重要。

第四，可以顯得自己很專業，方便跟甲方爸爸多要錢。

當然，在我看來最大的作用是為了以後撕逼的時候，有他們瞎鬧的證據。

所以，設計對於程式設計師來說很重要。

首先先說明一點，不僅僅是軟體工程強調必須現有設計，對於很多的工程都是一樣的。既然這裡說的是軟體工程，那麼我們就從軟體開發的層面來做分析。

我們在開發軟體的時候第一件要做的事情就是做需求的分析，也就是我們面向的使用者（可以是公司，可以是自己，可以是任何一個有需求使用者或者群體）想要一款什麼樣的軟體，或者說我們的軟體會給使用者帶來什麼樣的價值，為使用者解決了什麼樣的問題。

我們在瞭解了具體的需求之後就需要去分析和研究我們怎麼樣做才能滿足使用者的需求，這就是一個設計的過程。設計分析的過程很複雜，主要包括幾個點：

技術的選型，我們用什麼樣的技術來滿足軟體開發的需要，需要考慮到團隊開發人員的技術水平以及擅長的領域。模組的劃分，我們根據軟體不同的功能種類，將軟體劃分為不同的功能模組，這樣可使使軟體的結構更加清晰，更能讓人理解，方便開發期間的人員安排也同時滿足的後期的軟體維護需要。演算法和資料結構的設計，在完成了模組劃分之後，需要深入到每個功能模組的內部，分析通過什麼樣的演算法或者資料結構來解決對應的功能模組問題。效能的考慮，在滿足了基本的功能後，可能會出現比如軟體執行速度慢，使用的人多了感覺卡頓等等問題，這時候就需要想辦法提升軟體的效能。提升軟體的效能又是有很多領域的知識。擴充套件性，一般軟體都是需要迭代的，每個版本都會有相應的新功能上線，一款設計良好的軟體可以很容易的增加新的功能，反之糟糕的軟體想往裡面增加功能可能就會十分的痛苦甚至根本沒有辦法增加功能。穩定性，也稱為魯棒性，在一般的認知裡，我們認為一款軟體要想穩定的執行是通過嚴格的測試才可以，當然必要的嚴格的測試十分重要。但是在軟體設計層面上也是要做很多的工作，尤其對於平臺型的應用，穩定性的設計十分重要，比如咱們常用的Windows系統，我們應用程式意外崩潰了，但是對Windows沒有任何影響。安全性，安全性的範圍就比較廣泛了，比如我們在設計的時候要考慮到一些問題：保證使用者的資料不會丟失，保證使用者的資料不被惡意的訪問，保證系統不被惡意攻擊，在系統遭受攻擊時如何保證系統資料的安全等等

上面列舉了一些我們在開發軟體之前要考慮的問題，如果這些問題沒有想好，沒有做任何的設計，可想而知，我們最終會遇到什麼的困難，在很大程度上會影響軟體整體的交付，要麼是考慮的不周全導致進度無法估計，要麼交付的軟體不符合要求，要麼在後期整個軟體都沒有辦法有效的維護。

凡是都有例外，如果你做個很小的功能，小工具性質的軟體，可能就不要考慮這麼多的東西了。

一個大的專案必須要先有設計，一定要先設計，而設計之前必須要做的事情就是需求分析。需求分析是瞭解使用者“做什麼”，需求分析包括瞭解功能和效能需求，只有瞭解了使用者的需求以後再設計才能保證在專案完工後返工的現象發生。

設計階段包括四個方面：資料設計，系統結構設計，過程設計，介面設計。 結構設計：定義軟體系統各主要部件之間的關係。 資料設計：將模型轉換成資料結構的定義。 介面設計：軟體內部，軟體和作業系統間以及軟體和人之間如何通訊。 過程設計：系統結構部件轉換成軟體的過程描述。

用一副簡單的圖來描述一下軟體設計。軟體設計分成兩個模組，模組劃分和結構化設計，設計之前先要了解設計的任務和設計的基礎，這樣在設計的時候才能有方向感。軟體設計的任務：概要設計和詳細設計。這是在軟體設計階段的兩個文件。概要設計的主要任務是把需求分析得到的資料流圖轉換為軟體結構和資料結構。

詳細設計的就要將每個模組的具體設計情況通過業務流圖，程式流程圖，PAD圖，NS圖來將展示出來。

進入了設計階段，這個專案就進行了三分之一了，設計，編碼，測試三個階段完成後就可以組裝成有效的軟體了。設計階段的文件預期讀者使用者，技術人員和管理員，這些文件就是將設計時候的想法用文字表達出來，供預期讀者參考。

前期設計得不好，對以後的程式設計來說，絕對是個噩夢。

好的設計，是有高擴充套件性、伸縮性的，可以應對千變萬化的需求，不至於需求改了，或增加需求，而造成程式碼大改。

這要求設計者有良好的軟體架構能力，設計思維要有高遠瞻性

軟體有很多開發模式，最經典的瀑布模型就是需求分析、概要設計、詳細設計、單元測試、組裝測試和確認測試，但這種方式費時費力，是不適合當前網際網路市場需求快速變化需要的，有各種極限程式設計模式，比如快速原型法，先弄出一個簡單的Demo給客看看，再不斷快速迭代重構軟體，還有測試驅動，我先寫測試指令碼，再寫能讓測試通過的程式，再重構迭代，有很多方法，我參與第一個專案，專案經理就畫了張效果圖，列出了一個包含幾千條資料元素的資料字典，就以此為依據分塊讓我們寫程式了，這也是種開發方法

軟體工程或者程式設計專案，需要先規劃設計後程式設計實施的主要原因還是每個人的程式設計思路特別是嚴密性不一樣，而且沒有明確清晰的控制要求的話，很容易考慮不周全，程式就會不完善。

其實專案如果很小，那麼即使考慮不周全，在除錯的時候也能發現問題，並及時修正。

而當比較大的專案，控制要求或者任務書，就需要集思廣益的不斷探討確認。這個過程相當於程式設計實施已經預演了一遍，而且多人考慮確認，就可以減少很多考慮不完善的問題。

而且，有確定的控制任務檔案，也有利於大家分割槽域的分工合作，你做A部分，我做B部分，他做C部分。

套用一個成語“凡事預則立，不預則廢”，因此任何稍微複雜一點的系統，都應該先有經過廣泛意見採集與確認的頂層檔案作為指導，後續的工作才能有序的開展，後邊檢查出錯點，也同樣有一條主線可循。

作為一個系統工程師，我堅決同意一定要先有設計架構再有軟硬體開發。但是，作為一個專案主管，我做的絕大部分軟硬體開發專案都不可能有也從沒有過穩定的需求和框架乃至預算工期。一切都是隨時在變動的，因此一切都必須是隨時可變動的。如果你的開發工作是以一份幾周前幾月前的框架檔案做基礎和指導，你百分之九十是在做無用功。你必須以幾周乃至幾個月一年以後才會出現的框架檔案做你的指路明燈。你可能會說，這東西現在不是根本不存在麼。沒錯，所以你開發的時候根本就不可能有這樣的玩意，那是專案結束之後反推整理出來的。。。。那你依據什麼開發的？經驗。經驗是唯一的依靠。你不可能做到百分百的正確，但是經驗可以讓你百分之六七十的工作是有效的。剩下的，你知道，有些專案還能挽救，另外總會有些專案是歸於失敗的。

一般軟體開發是客戶提出軟體需求，根據需求我們才能開始制定專案，因為需求會涉及很多模組，所以我們應該先把他們設計聯絡到一起才可以開始研究程式碼，如果設計階段沒有制定好的話，我們光寫程式碼軟體整體會鬆散無序，無法達到客戶的需求。