軟體開發流程簡述

研發流程簡述：
在這裡插入圖片描述

研發流程詳解：

需求提出：
①這個環節主要是產品爸爸給我們提需求，每個需求都是他們從使用者，或者自己絞盡腦汁想出來的，但是產品爸爸還拿不準，不能直接敲定，所以就需要我們大家（產品，UI，前端，後端，使用者端和測試）一起討論一下，看看這個需求是否合理，或者這個需求是否有意義，能否達到預期，技術實現的成本，週期等等。
需求PRD提出(軟體業務分析)：
①這個階段，產品爸爸會根據第一版聊下來的結果，大致出一個Demo版本的PRD，會畫出初版的原型圖，並且配上文字說明，所有涉及到的業務，還有互動細節都會羅列出來。
②這個時候大家又會圍繞這一版本去開會討論，敲定細節，這個環節會久點，因為細節比較認真，邏輯也不能出錯，還有UI稿子也得敲定，這裡如果不敲定邏輯，UI提前去畫原型圖，後面假如邏輯推翻，一切重來就會浪費大量時間。這一環節大家都會把細節問清楚，不瞭解的點也會去了解，測試，開發，UI我們都會在會議上提出自己的觀點，自己的意見，然後等產品反饋，最後意見一致之後，產品當天就回改出敲定版本。UI就會按照產品爸爸的意思去作圖，接下來就是互動設計評審了。
互動設計評審：
①UI會畫出使用者端，前端，H5開發所需要的UI圖，基本上就是我們看到的產品的樣子了，不過還是要敲定細節，比如按鈕合理不，或者上面資料是否在這展示，或者這裡展示的資料是否合理。這個環節會比較快，只要UI按照之前敲定的邏輯開發，出入不會很大，一般都是小改。
概要設計(軟體設計)：
①這個是大廠程式設計師需求下來之後基本上都會做的一步，不過看需求大小，可能很多小需求直接就詳細設計了，也有啥設計都不用做的小改動，具體需求具體分析嘛。很多不瞭解的同學可能會問，需要設計什麼呢？為什麼要設計呢？技術是把雙刃劍，你用了技術之後你是不是需要列出他的優點缺點，出問題之後的解決方案，還有可能出現的問題，注意點等等。這麼是為了讓你能有把控力，比如你這個需求接入了新技術Es（Elasticsearch）你什麼都不管你就是要接入它，你把他開發好了上線了，但是有啥坑你知道麼？上線崩了怎麼辦？
②這個環節你需要考慮這個需求涉及到哪些服務了，需要新增哪些介面，修改哪些介面，表有現場的還是要新建表，欄位要新建麼？其實遠遠不止這些問題，這就是我們做設計的主要原因，也是大家工作裡面能成長的途徑之一，你以為大佬們的經驗是怎麼來的？
詳細設計(軟體設計)：
①我們研發的時候整個流程往往很複雜，如果你理解不對直接就寫程式碼，最後容易造成返工。花點時間做詳細設計很有必要，你思路完全清晰了，寫程式碼那就是分分鐘的事情。
②涉及的都是流程圖，時序圖等等。
測試用例評審：
①測試會根據你的概要設計，評估你的影響範圍，你的影響點，新增和改動的介面啥的，去編寫自己的測試用例。測試用例，主要是為了把改動點影響點都考慮到，測全一點，免得上線了影響別的現有業務，也是為了把你開發的功能可能出現的bug給排除了。
介面定義&開發&前後端聯調：
①啥都敲定了，那就開發唄，開發差不多了，就得前後端聯調了。這裡有個小細節還是想說一下，一般開發前我們都會提前定義資料型別，介面名稱，然後在公司的介面工具上給出連結和引數，方便前端爸爸mock資料。他總不能等我們後端開發完了，才去開發嘛，這樣效率打折扣，所以都是後端先定義好，然後前後端並行開發的。
②後端開發好，一般都是會發布到聯調環境，我們有哪些環境，聯調環境在我們所有的環境中處於哪個地位呢？
程式碼Review：
①codeReview環節，畫一下重點，這可能是整個研發流程中，讓你成長最快的一個環節，讓組員和Leader Review你的程式碼，往往他們能給你很多業務上和技術上的建議和意見。
提測&灰度釋出&產品第一次驗收：
①這一階段就是把程式碼都發到日常環境，然後等測試爸爸測試，這個環節開發同學如果沒BUG是比較輕鬆的，等著就好了，但是如果你BUG多，那我覺得你可能會生不如死，因為有的bug真的找很久很久的，呼叫鏈路又長，特別是跨服務又涉及訊息佇列，或者第三方的介面什麼的。
釋出計劃：
①這個確實是比較重要的環節，這個環節主要是開發同學和前端同學說好一個釋出時間，然後制定一個釋出計劃，為啥要釋出計劃呢?我們開發一個需求，可能涉及到N個服務，這些服務是有依賴關係的，那就需要打包，比如訂單系統，依賴人員系統。優惠券系統，也依賴人員系統，然後訂單系統還依賴優惠券系統。
生成環境上線：
①這就是神聖而莊嚴的上線環節。
紀錄檔觀察&產品第二次驗收：
①一般釋出第一批之後不會馬上釋出第二批，而是觀察錯誤紀錄檔，看看是否正常，有時候會發現還是會出現異常情況的，那就保留錯誤紀錄檔，然後回滾。知道解決了再發布，順利的話就沒啥錯誤。
②一次釋出可能涉及服務多的話，真的有可能釋出這麼久，但是沒辦法，線上出問題就是掉腦袋的事情。紀錄檔觀察一般公司都有錯誤紀錄檔蒐集系統，或者自己登入跳板機檢視就好了。沒問題，發完之後告訴產品大大就好了。
需求結束：
①至此基本上一個需求可能就結束了，其實還是很不容易的，短的需求幾天，長的需求幾個月，中間塗塗改改，BUG，技術難點都是你要面對的，不過沒啥大問題，我們技術人嘛皮實能頂。

軟體概要設計與詳細設計與軟體分析的區別：

概要設計：
①就是設計軟體的結構，包括組成模組，模組的層次結構，模組的呼叫關係，每個模組的功能等等。同時，還要設計該專案的應用系統的總體資料結構和資料庫結構，即應用系統要儲存什麼資料，這些資料是什麼樣的結構，它們之間有什麼關係。
②概要設計階段通常得到軟體結構圖
詳細設計階段：
①就是為每個模組完成的功能進行具體的描述，要把功能描述轉變為精確的、結構化的過程描述。
②詳細設計階段常用的描述方式有：流程圖、N-S圖、PAD圖、虛擬碼等
總結：
①概要設計只說明系統有多少個模組，各模組之間的介面和個模組本身的功能
②詳細設計說明某個具體模組如何實現，粒度應該比程式略高一些
需求分析–產生：
①軟體功能規格說明書,需要確定使用者對軟體的需求,要作到明確、無歧義。不涉及具體實現方法。使用者能看得明白，開發人員也可據此進行下面的工作（概要設計）。

開發流程詳解

系統解釋：

首先，系統是什麼？根據《系統架構》一書的定義，系統是由一組實體和這些實體之間的關係所構成的集合，其功能要大於這些實體各自的功能之和。
對於我們的場景，系統可能是 App、Web 應用、服務、批次程式等，也可能是包括所有這些的一個大系統。

產品原型，UI設計：

UI切圖：
①是指在設計稿裡整理出技術開發所需要的素材或圖片。合格的、嚴謹的切圖可以大大減少技術人員開發的返工率，減少技術人員的開發工期，提升開發流暢度，從而減少專案人力成本，最終開發出有利於互動，擁有良好視覺感的產品。
②切圖示注作為連線 UI 設計到技術開發兩者的工作模組，是不可或缺的。設計師需要熟悉工具、理解設計尺寸與切圖倍數的關係，才能在切圖時進行判斷：目前的設計稿尺寸與切圖單位是否正確匹配。
UI：
①User Interface 使用者介面。主要關注產品視覺呈現的效果。就是介面元素是什麼，形狀、顏色、尺寸，放在哪裡。
原型：
原型圖簡單的來說，就是一款產品成型之前的一個簡單的框架，就是將頁面的排版佈局展現出來，每個功能鍵的互動，使產品的初步構思有一個視覺化的展示。
總結：
①一般來說產品經理畫好原型圖.然後原型評審（UI參加）。
②UI出設計稿，UI切圖(方便開發)。然後UI評審。
③最後進入開發。

開發流程詳解：

從產品作出原型，到研發程式設計實現，中間有巨大的鴻溝。越複雜的業務需求，這條鴻溝就越大。一般而言，我們至少還要有兩個步驟：業務分析與架構設計。
業務分析，主要處理的是業務領域的建模。解決的問題是業務上如何實現。然後是技術與架構方面的設計，主要針對的是技術實現，解決的問題是技術上如何實現。這兩個方面是會互相影響的，設計的時候往往需要來來回回的考慮這兩個方面。甚至系統開發時也時常會需要調整模型或者架構，當然相應的也需要更新檔案。
業務分析：
①分析方法：業務分析是針對業務領域的建模，產出就是分析模型。分析模型描述系統的邏輯設計與結構，一般會包括需求用例、實體模型以及業務場景的互動流程、狀態轉換等。分析模型讓非技術人員能夠理解系統是如何構造的，讓技術人員能夠以此為基礎搭建系統。
②理清業務需求：
<1>理清業務需求是所有分析與設計的前提：
1、確定系統的利益相關者（Stakeholder）及他們的關注點。
2、確定系統的業務需求，即「誰」使用該系統「做什麼」。
3、確定系統的功能範圍，即該系統「包含什麼」，不包含「什麼」。
<2>具體到系統的使用者，還需要細分到角色，即使有些角色實際可能是同一個人。比如對於門診，可能有護士、顧問或系統管理員等等，可以進行不同的操作。需求範圍簡單話用一個列表即可，複雜的系統可以考慮使用用例圖。
③建立實體模型：
<1>實體模型是確定系統包含的實體以及它們之間的關聯的過程：
1、理清業務概念，統一業務詞彙。
2、抽象業務實體，包括事件、人/角色、地點和事物等。
3、識別實體關係：繼承、聚合、關聯等。
<2>實體模型也叫 ER（Entity-Relation）模型。可以考慮使用四色法建模，一般可以使用類圖或元件圖表示。需要注意的是一定要理清業務的概念，統一命名和定義業務相關詞彙，這是進一步溝通的基礎。
④分析業務場景：
<1>場景分析用於確定具體業務場景中，各個參與者的互動過程，從而進一步完善分析模型：
1、分析具體業務場景，確定業務規則，梳理業務流程。
2、如果涉及複雜的狀態轉換，需要確定狀態轉換邏輯。
3、補充和完善實體模型的內容描述。
<2>對於一個業務場景，參與者可能包括人、內部模組、外部服務等，這一步需要理清楚整個業務過程和規則。需要注意的是，對於一些次要路徑或者異常路徑，也一定要考慮到。對於業務過程和規則，可以使用普通的流程圖、泳道圖，也可以考慮UML的活動圖，狀態轉換過程則可以通過UML的狀態圖展示。
架構與技術設計：
①架構方法：架構設計不一定要深入到具體的實現細節，但是應該儘量全面的考慮系統的各個方面。關鍵是要對專案風險有比較大的把握，這樣才能避免開發過程出現不可控的問題。具體設計需要多詳細，是需要設計者自己去把握度的。
②確定整體架構：首先需要在整體上考慮系統的位置和職責：
<1>確定系統在整個上下文中的位置，與其他系統的關聯。
<2>確定系統自身以及各個外部系統的職責。
③設計功能模組：其次需要確定系統內部的功能模組及其職責：
<1>確定系統的模組劃分。
<2>確定每個模組的職責以及模組間的關聯。
④明確架構關注點：然後需要確定系統架構的理念：
<1>理清架構設計需要考慮的關注點。
<2>確定系統的架構設計上的取捨。
⑤設計資料庫模型：如果分析時有了完善了實體模型，設計資料庫模型就不是什麼難事了。開發完成後，資料庫模型應該以資料庫為準，架構檔案就不需要保留這一部分了。
⑥設計介面：然後就需要確定 API 細節了。一般我們的服務的 API 是 JSON 格式 HTTP 形式的請求和回撥。API 可能是介面定義，也可能會有其他介面形式，例如訊息佇列等。設計階段，API 檔案可以通過 Markdown 檔案、RAP 等記錄，開發完成後可以獨立維護，或者使用 Swagger 和程式碼一起維護。
⑦場景實現：一般情況下，有了業務場景分析，有了資料庫模型和 API，系統的實現一般是比較簡單了。但可能還會有一些細節需要進一步考慮實現細節，以避免風險。可以考慮更細節的活動圖、時序圖甚至虛擬碼。
⑧其他考慮：對於我們的後臺系統來說，基本的技術框架都已確定，可以解決很多基礎的非業務需求。不過設計系統時，也還是需要考慮以下等方面。
連結：如何進行系統分析與設計

軟體開發流程涉及的圖

簡述：

連結：設計模式概述與UML類圖與知識概括
uml中活動圖與流程圖的區別：
①(流程圖著重描述處理過程，它的主要控制結構是順序、分支和迴圈，各個處理過程之間有嚴格的順序和時間關係。而活動圖描述的是物件活動的順序關係所遵循的規則，它著重表現的是系統的行為，而非系統的處理過程。
②活動圖能夠表示並行活動的情形，而流程圖不行。
③活動圖是物件導向的，而流程圖是程式導向的。

詳解：

軟體工程（軟體工程中的各種圖一般用於以下三個階段）：
需求分析階段：
①用例圖（思維導圖）：用例圖是指由參與者（Actor）、用例（Use Case），邊界以及它們之間的關係構成的用於描述系統功能的檢視。是系統的藍圖。

②流程圖：以特定的圖形符號加上說明，表示演演算法的圖，稱為流程圖
概要設計階段：
①類圖(ER圖):類圖(Class diagram)是顯示了模型的靜態結構，特別是模型中存在的類、類的內部結構以及它們與其他類的關係等。
詳細設計階段：
①時序圖：（Sequence Diagram），又名序列圖、循序圖，是一種UML互動圖。它通過描述物件之間傳送訊息的時間順序顯示多個物件之間的動態共同作業。
②狀態圖:狀態圖(Statechart Diagram)是描述一個實體基於事件反應的動態行為，顯示了該實體如何根據當前所處的狀態對不同的事件做出反應。
③活動圖：活動圖（activity diagram，動態圖）是闡明瞭業務用例實現的工作流程。

軟體開發總結

簡述：

連結：物件導向分析、設計、實現
真正的物件：
①我所理解的真正的物件就是現實生活中客觀存在或不存在的真正的物件。這個物件有一個明顯的特徵就是它具有非常多的狀態特徵和行為特徵。比如一個人是一個物件，他在一生中會經歷無數個互動場景，在這個過程中，每個人的行為特徵會不斷增多，大部分行為是通過後天學習得到的，只有少數行為是先天就具有的；另一方面，對於狀態特徵也是在時不時的變化，比如你的身高、體重，等等。最後，人因為會參與到不同的互動場景，會導致和他關聯的各種關聯資訊也會不斷增多，比如你去上大學，老師給你一張借書卡，此時你就擁有了一張借書卡，可以理解為你多了一個關聯資訊；哪一天你去參加英語四級考試，考了70分，然後你擁有了一本四級考試證書，上面寫這成績為70分，此時你也同樣多了一個關聯資訊，就是一本英語四級考試證書；
②這裡我想表達的主要觀點是：現實生活中的物件：
1）兼具各種場景下的所有狀態和行為特徵；
2）固有狀態會時不時的變化，通過參與互動場景還會增加一些關聯資訊；
3）行為會不斷增多，一般是通過學習得到；因此，我們從中可以知道，現實生活中的物件肯定不是我們設計軟體時候的物件，因為它是如此的複雜，包含了或關聯了非常多的狀態特徵和行為特徵；
物件導向分析階段時的物件：
①既然是分析階段，那我們就不要過多的考慮任何設計階段的思想。我覺得在分析階段，我們在分析物件時主要考慮兩個方面：
1）物件的狀態特徵變化規律；
2）物件的行為特徵變化規律；
②分析階段，我們往往從某個場景出發，分析該場景中有哪些「物件」，此時的「物件」之所以加雙引號是因為它不是真正的物件，而是真正的物件的某個方面，我們在某個場景下只關心物件的某個方面；我覺得分析階段的物件和現實生活中的物件應該是一致的，或者至少是邏輯上是一致的。也就是說，在物件導向的分析階段，我們應該將現實生活中我們所理解的物件的一切特徵在腦子裡描述清楚。比如同一個人，它在不同的場景下（一個場景代表了一個考慮問題的邊界）會參與不同的互動活動。這句話體現的含義是：
1）同一個物件會參與不同的場景，行駛各種互動行為；
2）同一個物件我們會根據我們不同的認識角度，對同一個物件的關注角度的不同，將其理解為不同的型別或角色；比如一個人，在家裡可能是父親，在公司可能是職員，在比賽場上可能是運動員。但無論我們給這個人授予什麼樣的稱謂，這個人始終是同一個物件。所以，在物件導向的分析階段，物件給我們的感覺是它在不停的變換其型別或角色；上面在談到什麼是真正的現實生活中的物件時提到，物件在參與到互動活動後會多出一些關聯資訊，這些資訊是屬於誰的呢？答案是：這些資訊屬於扮演了某個角色的物件的；之所以強調扮演了某個角色，是因為想讓大家明確物件一定是在扮演某個角色參與到某個場景互動活動後才具有那些關聯資訊的。
③總結：我覺得在物件導向的分析階段，我們分析的要點是：
1）站在現實生活中真正的物件的角度去理解物件的狀態特徵和行為特徵的變化規律；
2）理解真正的物件和物件的某一個方面（即我們所關心的「物件」），
3）理解同一個物件會扮演不同角色參與到不同互動場景；
4）理解物件的關聯資訊如何產生，關聯資訊是屬於誰的；
物件導向設計階段時的物件：
①首先說一下，目前的程式語言實現物件時，是以哪些方式讓建立物件的。
1）C#等基於型別的靜態語言，型別規定了物件可以具有的狀態特徵和行為特徵，物件的一切狀態和行為都是由其所屬的型別確定的；這又一個很明顯的好處時，我們在任何時候都知道物件的型別或介面，從而就能明確知道其資料結構，也就知道物件的狀態，從而可以方便的持久化物件的狀態或者重建物件；但這種為物件帶來狀態和行為特徵的設計思路同時也有一個缺點就是物件的型別或其表現出來的介面無法更改。這點是違背「真正的物件」或者「分析階段的物件」的特徵的；
2）javascript等弱型別的動態語言，這種語言認為物件無型別，物件的狀態和行為不需要從型別為模板獲取，狀態和行為可以隨時附加到某個物件上。這種思路其實很好，因為很符合上面提到的真正的物件的狀態特徵與行為特徵的變化規律。但是這種語言也有一些致命的缺點：
1）由於沒有型別，導致無法在使用時明確知道其具有哪些狀態和行為，這會增加程式設計出錯的可能性，只有在執行階段在會檢測到存取了不存在的狀態或行為；
2）同樣是弱型別的原因，物件無法被持久化，因為不知道要持久化哪些狀態，同樣，更不用說重建物件了；所以，基於這兩個缺點，我覺得動態語言不適合在伺服器端大量使用去做工程實現業務邏輯，而在一些不需要持久化物件狀態的使用者端環境，只在記憶體中處理邏輯的情況下使用這種語言比較適合；
②當我們在設計軟體時，如果是用C#等靜態語言、基於類和介面的語言去設計物件時，該如何設計呢？在設計階段，我覺得目標就是把分析階段得到的物件用盡量平滑的方式轉換為設計；需要把握的要點是：
1）從一個基本的類建立出物件；
2）用盡量平滑的設計思路去支援一個物件表現出不同型別或角色的特點；舉個例子吧：
3）xuehua這個物件首先是一個人，所以從Person這個基本型別中獲取基本的狀態特徵和行為特徵（如吃飯）；然後當xuehua去教書時，他會扮演教師的角色，扮演之後他就是一個教師了，然後他就具有了教師這個角色所賦予的行為（教書）了。上面的程式碼看上去和真正的物件在現實生活中的變化規律類似，非常平滑；這樣做有幾個好處：1）強型別；2）物件互動模型與現實生活中的互動模型完全一致，所以程式碼非常容易懂，可讀性強；3）物件不會隨著參與互動場景的增多而變得臃腫和複雜，因為由於引入了角色的概念，我們將互動模型實現為物件扮演某個角色參與互動活動的方式來設計，做到了物件動態被賦予身份，從而具有與該身份相關的狀態特徵和行為特徵；4）物件參與互動場景後所關聯的一些關聯資訊不會直接存放在物件上，而是放在了「扮演了某個角色的物件」上，在上面的例子中就是teacher物件；

var xuehua  =   new  Person();
xuehua.Eat();  // 吃飯
var teacher  =  xuehua.ActAs < ITeacher > (); // 扮演教師角色
teacher.Teach();  // 教書

物件導向實現階段時的物件：
①那麼如何實現這樣的設計呢？
var teacher = xuehua.ActAs();
②其實很簡單，可以類用裝飾模式來實現，我們都知道，設計模式中的裝飾模式可以動態給一個物件增加狀態或行為。所以在實現階段，我們可以設計一個Teacher類，大概設計如下：
<1>teacher就是實現階段的物件，而Teacher類則是實現階段的物件的型別；可以看到Teacher類關聯了一個Person物件，同時實現了ITeacher角色介面。所以ActAs，
var teacher = xuehua.ActAs();
<2>這個函數做的事情就是在內部建立一個Teacher類的範例，該範例對當前的Person物件有一個參照，然後返回。也許你會說，返回回來的teacher物件已經不是原來的xuehua物件了，而是一個新的物件，並且封裝了xuehua這個物件；沒錯，所以說這是實現上的問題。我們在關注業務時，關心的不是當前物件的真正型別，而是關心物件的狀態特徵、行為特徵，或者技術化一點來講就是關心物件的互動模型，關心的是物件扮演什麼角色在進行互動。

public   class  Teacher : ITeacher
{
     private  Person actor;

     public  Teacher(Person actor)
    {
         this .actor  =  actor;
    }

     public   void  Teach()
    {
         // do the teach operation.
    }
}