軟件工程之思系列---初窺門徑

一、啥是軟件工程？

"軟件開發領域里對工程方法的系統應用"

"以工程的形式應用計算機科學和數學原理，從而經濟有效地解決軟件問題"

"將系統化的、規范的、可度量的方法用于軟件的開發、運行和維護的過程，即將工程化應用于軟件開發中"

" 為了經濟地獲得能夠在實際機器上高效運行的、可靠的軟件而建立和應用一系列堅實的軟件工程原則 "

"研究和應用如何以系統性的、規范化的、可定量的過程化方法去開發和維護軟件，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來的學科"

就上面這定義估計一般人理解不了

1、軟件工程起源：

上古時期怎么做軟件？----- 一頓猛敲代碼，能用就行，隨心所欲，快意恩仇

但是，這樣造出來的軟件，缺乏規劃，不好擴展，基本就是一次性的。

這種缺乏規劃的做法，導致軟件開發中出現大量的 進度延遲 、 預算超支。

——其實不光軟件，各種項目大多如此，俗話說“預算就是用來超的”。

計算機行業發展迅速，痛點越來越不能忍！人們稱之為“ 軟件危機 ”！

1968年，“北大西洋公約組織(NATO)科技委員會”決定一舉滅掉這個痛點！

他們提出了“ 軟件工程 ”的概念，試圖是用“工程化的方法” 解決 “軟件危機”。

從此，軟件開發歸為工程之列，成為工程項目領域最年輕的成員。

從此，程序員也叫“軟件工程師”（這可是猿到獅的升華）

至于軟件工程的目的，教科書上講的都很晦澀；

其實總結來說很簡單，就是—— “多快好省”地造軟件 。

還有一點注意：軟件工程關注的是 大型軟件， 所以很多“攻城獅”并沒有真正的看到或感受到軟件工程具體是個什么玩意。

2、軟件工程的本質特性

1. 大型項目——軟件工程的提出，主要是解決政府的大型軟件開發問題，沒考慮小型軟件；

2. 項目把控——軟件工程的中心課題是 控制 復雜性，使軟件項目不是空

3. 團隊合作——大型軟件項目，自然要很多人合作開發；

4. 需求變更——軟件經常變化，要適應不要抵制；

5. 開發效率——開發軟件的效率非常重要；

6. 用戶體驗——軟件必須有效地支持它的用戶；

7. 業務流程——在軟件工程領域中，創造軟件產品的軟件工程師們 往往缺乏產品相關業務領域的知識。

3、軟件工程7條基本原理

美國國家工程院院士 巴利·玻姆（Barry W. Boehm），1983年發表論文，總結了軟件工程的7條基本原理：

（1） 用分階段的生命周期計劃嚴格管理——各種工具往上頂、契合公司的可信活動

（2） 堅持進行階段評審——需求、設計、開發、測試、上線、運維、優化，周而復始

據統計，軟件的錯誤中，設計錯誤占63%，編碼錯誤占37%；越晚發現錯誤，代價越高。

（3） 實行嚴格的產品控制——需求不是你想改，想改就能就改

（4） 采用現代程序設計技術——先進的技術可以提高開發/維護效率，提高質量（技術選型）

（5） 結果能清楚地審查——各種監控工具給我上，不玩虛的，數據說話

（6） 開發小組的人員應該少而精——敏捷的精髓就是精兵強將

（7） 承認不斷改進軟件工程實踐的必要性——也就是“精益求精”、“工匠精神”什么的。

二、軟件工程師的價值是啥？

技術市場就像這喜怒不定的天氣，今天下個大數據的雨，明天刮個人工智能的風，面對琳瑯滿目技術浪潮的沖擊，程序員難免深感無力，深怕錯過了技術潮流從而失去了職場競爭力。 有時候我會思考難道在技術領域內不斷緊跟新潮，不斷提升技能就是我的價值所在?那么我是技術的主人還是技術的奴隸？

人之所以迷茫往往是找不到工作生活的重心，感受不到工作或生活的價值。那么什么是價值呢？說的大一點就是我改變了世界，說的小一點就是我的所作所為改善了某些問題。如果不清楚自己的行為、目標、價值三者的關系，那么又何來重心？又如何能分得清重要性與優先級呢？

程序員的迷茫不僅僅是面對技術繁雜的無力感，更重要的是因為長期埋沒于軟件世界的浩大的分工體系中，無法看清從業務到軟件架構的價值鏈條，無法清楚定位自己在分工體系的位置，處理不好自身與技術、業務的關系所致。

很多程序員打心底不喜歡業務，這一點我現在也沒改變(慚愧，努力中)，我更寧愿從事框架工具、技術組件研究的相關事情。

我有個朋友靈魂三問:"你研究那么多技術，有啥用？想做業界標準？給部門帶來了多少收益？"

仔細想想很多時候業務在我們腦海中存留的只是邏輯和流程，我們丟失的是對業務場景的感受，對用戶痛點的體會，對業務發展的思考。這些都是與價值緊密相關的部分。我們很自然的用戰術的勤快掩蓋戰略的懶惰！那么這樣的后果就是我們把自己限死在流水線的工位上，閹割了自己能夠發現業務價值的能力，而過多關注新技術對職場競爭力的價值。這也就是我們面對繁雜技術，而產生技術學習焦慮癥的根本原因。

那么什么是業務呢？就是指某種有目的的工作或工作項目，業務的目的就是解決人類社會與吃喝住行息息相關的領域問題，包括物質的需求和精神的需求。使開展業務活動的主體和受眾都能得到利益。通俗的講業務就是用戶的痛點，是業務提供方（比如公司）的盈利點。而技術則是解決問題的工具和手段。

以我所在部門（制造部）為例，軟件活動的一切目的都會圍繞提高生產質量、提升生產效率、節約生產成本，協助部門實現偉大的戰略規劃。 技術如果脫離了業務，那么技術應用就無法很好的落地，技術的研究也將失去場景和方向，而業務脫離了技術，那么業務的開展就變得極其昂貴和低效 。

所以：

軟件工程師的價值是啥？------利用技術手段創造行業價值

啥是研發部門？-------研究點高大上的工具，供別人使用

啥是IT部門？------ 用研發部門的工具寫業務系統

三、如何做好一個項目/產品？

A、軟件項目管理的金三角：時間、成本、范圍

任總說過： 我們各級管理者和全體員工都不得以進度、功能、特性等為理由來降低可信的要求，確保可信的要求在過程中不變形。

這句話講的就是軟件項目里的金三角：時間（多久可以完成）、成本（花多少錢）、范圍（需要實現多少功能），這三個要素決定了最終交付的軟件的質量。

看到沒？是三要素決定了軟件質量，質量不是最初確定的，也不是神圣不可侵犯的，隨便一個糟糕的設計、一行壞味道的代碼都能讓軟件質量體無完膚，保證質量，談何容易？

想要軟件的成本低，又想要質量好，那就得等；想要便宜又想快速上線，那就得接受質量不好的現實；想要質量好又想要快速上線，那就得花錢；想要價錢便宜、質量好，又要快速上線，是沒有這種好事的。

借鑒一下著名的"金三角"理論：瀑布模型種范圍是固定的，時間和成本是可變；敏捷開發中成本和時間是固定的，范圍是可變的。

B、Supercell公司淺析及個人感悟

Supercell（超級細胞） 是一家 芬蘭 赫爾辛基 的電子游戲開發商。公司成立于2010年。知名的作品包括《 卡通農場 》、《 部落沖突 》、《 海島奇兵 》、《 部落沖突：皇室戰爭 》、《 荒野亂斗 》。

Supercell 只有 200 多名員工，一個游戲的研發人員只有 4-5 個，這跟國內公司大隊伍作戰很不一樣，都沒有一個部門的人多。介紹一下這200人的作戰模式

- 容忍失敗

團隊人員提出一個游戲 Idea，團隊成員就一起去實現它，但在開始之前會先設定一些指標，比如玩家留存、參與度，當游戲進入公測之后， 如果指標未達到，他們就會選擇放棄。supercell 允許各個小團隊不斷快速試錯，快速驗證，這個過程其實時間是非常寶貴的。

- 快速嘗試

曾經在兩年內，他們只發布了一款游戲「皇室戰爭」，但期間取消了 9 個項目，和若干很多優秀的創意原型。所以今天我們看到支撐 Supercell 百億美元估值僅僅幾款游戲，但其實其背后有數不清的被驗證失敗的項目作為墊腳石。

- 優秀的人（一群體態臃腫的大胖子組成的團隊，我看你咋敏捷，累死你）

采用倒三角的模式組織團隊，一個游戲公司下面分成了若干游戲小團隊，決定權不在公司管理者手中，而是在各個小團隊自己決定，因為小團隊才是真正知道產品的人，但產品目標沒達成就必須中止。這決定了團隊的每一個人是足夠 Super 的 Cell。

為了實現快速嘗試的目標，每個游戲的研發人員只有 4-5 個左右，他們是如何 Cover 原本繁雜的游戲開發流程，同時保持敏捷。其原因是他們開發一些基礎設施、內部開發工具和平臺，為其他小分隊提供工作的工具和框架。這樣研發人員只需像涂秘密花園一樣，按照自己的想法進行上色即可，大大提升開發效率和降低出錯可能性。這個過程其實 Supercell 是將游戲開發過程中需要用到的一些公共內容進行抽取，組 成一個個公共的 Component，當新起一個項目的時候，取所需的 Component，自定義部分還是交給各個項目 Idea 開發者。

看到 “公共內容的抽取” 會覺得與平臺概念類似，這兩者之間是否存在什么區別呢？ 平臺化更多的是技術層面的能力抽象 ，例如：統一用戶、統一權限、統一登錄，更多的是技術能力的復用 （jalor6、H.A.E、AUI？個人理解差距還是很大的） 。中臺范圍會更加大， 除了能力復用，還有數據的復用 ，重心是為業務服務，快速響應客戶需求。（ 后續再聊中臺、微服務、數據湖 ）

C、個人解讀：

軟件工程三要素： 方法、工具和過程 ，這無可厚非。但是我認為項目的成功與否關鍵的核心點是 “人”， 無論你多NB的理念、方法沒有人去做或是做不好那就一點P用沒有。。。

涉及的人員包括：產品經理、BA、SE、開發人員、DBA、測試人員、運維人員、平臺技術支持人員、周邊協作團隊。

D、目前我參與的和見過的項目流程

1、立項

上會！（研究一下能不能上？咋上？誰上？啥時候上？怎么上？）

2、產品/項目規劃（暫時沒見過有這個規劃）

3、業務需求澄清階段

（1）講業務價值（有的講、有的不講、有的講不清楚）

（2）講解需求（要有需求文檔，詳細的！！！能指導做設計的那種）

（3）理解需求（這個有難度，可能存在就是理解不了的情況）

（4）修改需求后再次講解需求、理解需求（可能還是 存在就是理解不了的情況 ）

4、環境準備階段

（1）上會！（ 叫啥忘記了，看看把你這個項目塞到哪？是別人的子還是自己的父 ）

（2）申請APPID（名正言順了）、申請子模塊（大樹底下好乘涼了）

（3）申請服務器（得求助運維）

（4）綁定部署單元（得求助大佬）

（5）各種環境配置（得求助好多大佬）

5、項目搭建階段（終于到SE的環節了）

（1）jalor6還是H.A.E（基本都是jalor6）

（2）Gauss還是Oracle（基本都是Guass）

（3）maven多模塊項目結構規劃

（4）GIT庫創建

（5）多租戶

（6）網關

（7）各種第三方組件引入（lombok、swaggerUI、mybatis。。。。）

（8）公共模塊編寫（統一restful返回值、統一異常處理、工具類、消息隊列、redis緩存、上傳下載、導入導出、定時任務、UEM、監控策略、數據源配置、事務配置）

6、開發階段

（1）概要設計

（2）詳細設計（表設計、服務設計）

（3）開發人員開始CRUD

（4）核心人員解決技術難題和復雜邏輯

（5）自測

（6）轉測

（7）申請變更號

（8）上線、有BUG、回退、挨批、找BUG、修BUG、再上線！

（9）運維，現在都在推行DevOps，自己的-就自己吃吧

7、求助階段（這個能力太重要了！！！）

（1）求助團隊內部同事

（2）求助部門平臺組同事

（3）求助流程IT平臺組同事

（4）求助關系不錯的同事（目測這個是最管用的途徑）

這一頓操作下來，整個開發鏈條上涉及的人員較多，如果某些環節出現了問題（人出現了問題），說實話，項目失敗的概率很大，成功的概率不敢妄自揣測、估計。

上一幅極具代表性的圖片：

按照從左到右，從上到下的順序依次來說說每幅畫的意思：

1. 客戶：我家有三個小孩，我須要一個能三個人用的秋千。它是由一繩子吊在我園子里的樹上。客戶在描述需求時傾向于提供過多的信息。

2. 產品經理：秋千這東西太簡單了，秋千就是一塊板子，兩邊用繩子吊起來，掛在樹上的兩個枝子上。

3. 工程師按照產品經理的要求設計產品。兩個樹枝上掛上秋千哪還能蕩漾起來嗎？除非是把樹從中截斷再支起來，這樣就滿足要求了。

4. 程序員：開始寫程序。兩條繩，一塊板，一棵大樹，接在樹的中段；太簡單了，工序完成。

5. 測試人員：收到開發部門的產品進行測試。一根在末端系了個圈的繩子。

6. 銷售人員：終于產品完成，銷售人員開始向客戶推銷：通過人體工學，工程力學多方面研究，本著為顧客服務出發，我們的秋千產品讓您如同坐著沙發一樣舒適。

7. 當需要用到文檔的時候，總是找不到。這么小的工程沒有文檔很正常，只要需求說明書與合同就可以了。

8. 實施人員交付的產品的時候，只要把繩子系在樹上就可以了。

9. 客戶：花了這么多錢，真的能和過山車相媲美了。

10. 客服解決問題的方法簡單粗暴。

11. 市場營銷做的廣告那是相當的高大上。

12. 瞧！客戶真正想要的只是一個簡單的輪胎秋千。

計算機科學是跨學科特別明顯的，包括但不限于高級代數、概率論、離散數學、數據庫、數據結構、大學物理、匯編語言、編譯原理、計算機網絡、操作系統，計算機組成原理、數字電路、模擬電路、工程學、博弈論、信息論、密碼學。。。。在這個領域時刻要保持小學生一般的求知欲與謙卑姿態，當你知道的越多，你不知道的會更多

切記不要手里拿著錘子，就把所有問題看做釘子！

5G游戲 軟件開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。