本文宗旨
-
目標 ： 從一個程序猿的角度來解讀如何消化掉產品經理給的需求 即產品經理放一個大招 程序猿如何接大招
-
適讀人羣 ：
1⃣️ 剛入行的小白：對開發的流程還不太熟悉 接到一個需求 一頭亂碼 一頭霧水 不知道怎麼下手 或者 下手了 但做出來的效果不太好的
2⃣️ 對程序猿老手：解答針對自己技術生涯中開發流程方面沒有想通透的疑點；更好的梳理出有效的流程和印在腦子裏來指導自己或新手開發
流程梳理
-
1、看產品原型仔細看需求並把核心要點記錄下來加深瞭解和記憶
-
2、看是否有過類似的經驗 若有 看是否有借鑑和參考價值
-
3、對某一個對象進行設計字段（比對這產品原型上 不要遺漏了標註）
-
4、在比照着prd羅列一個對象的哪些屬性的時候 就會思考從技術上實現有沒有難點 如果有難點則標紅待處理
-
5、根據該對象的這些屬性上從現實角度思考下一個擁有這些屬性的對象能否合理的描述該對象 由此來檢驗屬性是否合理 （如果某些屬性不合理 很可能就是因爲對prd產品需求理解有誤導致）
-
6、把文字的屬性英文化即寫完整的sql語言（假如對需要還有些地方沒有理解透徹 通過寫sql 寫幾條數據梳理下 來達到解決掉沒有理解透徹的點的目的 這樣帶着問題來去做事情纔會有動力去做 ）
-
7、數據流轉（畫技術架構和時序圖）+ 全盤考慮（前後端數據如何交互） 這裏是關鍵點和難點和重點 （前面都是爲了這裏打基礎 但也不要怕麻煩 否則返工和修改bug的時間就會很長 就會得不償失
-
8、圖+產品需求結合反覆思考3遍是否合理
-
9、把功能點分點列條的梳理出來（畫圖和功能點羅列之間的先後關係？我是覺着先做架構設計等全局考慮 再做功能點比較好一些 但實際上可能會先做前後端交互的功能點羅列（其他的功能點羅列在架構設計等後面考慮））
-
10、做好排期
用一個實際工作中的例子來針對性的描述上面流程的每一步
實際工作中的例子描述
產品需求
簡介：開發公告模塊和banner模塊後臺管理系統
產品原型【主要部分】
發佈公告的產品原型如下
發佈公告的產品原型
發佈banner的產品原型如下
發佈banner的產品原型
套用上述流程 一步一步分析
看產品原型並記錄核心要點
-
發佈公告核心要點記錄
-
發佈banner核心要點記錄
-
banner列表頁面
後臺管理-banner列表頁面
是否有類似的經驗【若沒有 則可以參考下別人的經驗 或者 不參考】
關於公告和banner模塊我之前是有過開發經驗的
我現把之前的開發的效果截圖給大家看下 然後我們一起分析下其中有沒有借鑑經驗、是否可以拿來主義
發佈公告頁面
寫具體文章的頁面
banner列表
添加banner頁面
是否有借鑑價值：
1、頁面上幾乎沒有、原因是風格不一樣
2、1⃣️接口上應該也沒有 畢竟都是增刪該查 代碼都可以生成 沒有必要複用
2⃣️ 2個不同的系統 代碼風格都不太同 代碼差異也比較大 所以也沒有必要複用接口
3、數據庫字段方便 可以稍微參考下 因爲 公告、banner字段內容都差不多
4、公告這塊 因爲設計到 一個富文本信息 這裏可以用到我之前設計的 前後端交互的方式
具體說下這點
公告這塊 因爲設計到 一個富文本信息 這裏可以用到我之前設計的 前後端交互的方式
前端頁面
首頁欄目
公告列表頁面
公告詳情頁面
後端接口返回報文
欄目接口（動態配置）
查詢具體欄目下的所有的文章列表信息
查詢文章詳情（包含富文本正文）
綜上：
1、查詢所有欄目
2、根據欄目查詢文章列表
3、根據文章編號查詢文章詳情獲得富文本
交互方式設計
1、接口請求方（前端比如安卓端）
2、前端通過欄目編號查詢該欄目下的所有的文章列表 顯示到頁面上
3、用戶點擊某一個文章 訪問 特定的url 拼接文章編號
4、該特定url 代表一個網頁 該網頁會請求一個接口 （通過文章編號查詢文章詳情）
5、該頁面將獲取到的富文本信息渲染到頁面上顯示給用戶
總上分析
可以借鑑和複用的地方爲：
1、提供給前端頁面的接口
2、腳本儘量複用
這樣可以大大的縮減開發時間
對某一個對象進行設計字段（比對這產品原型上 不要遺漏了標註）
公告字段
有疑問的話 就去找產品確認
比如上圖中的 標紅部分
一個公告一個擡頭圖？還是一共公告可以有多個擡頭圖
直接決定公告-擡頭圖的字段內容和字段長度設計
如果是一個公告一個擡頭圖 則公告的擡頭圖字段就可以是一個圖片文件編號
如果是一個公告多個擡頭圖 則公告的擡頭圖字段就需要是多個圖片文件編號用逗號分割並且長度不一定
找產品確認，確定之後的結果
1、 一個公告只有一個擡頭圖
2、一個banner只對應一個banner圖片
banner字段
在比照着prd羅列一個對象的哪些屬性的時候 就會思考從技術上實現有沒有難點 如果有難點則標紅待處理
如上圖的2個標紅處
1、頁面上下移動？
這個是難點 之前沒有做過類似的插件 不過我查了下
https://www.cnblogs.com/taochen/articles/2344891.html
這篇文章應該可以解決這個問題
2、 定時觸發
我所能想到的是2個方案
1⃣️ 定時任務 查詢時間小於當前時間的 更改狀態
這種方式比較簡單 快速 同時技術含量比較低
2⃣️ 消息隊列 延遲發送或延遲消費
這種方式
1、增加自己對rockitmq延遲發送的理解、提高自己的消息隊列這塊的技術能力
2、封裝rocketmq中間件和使用的規範的技術流程 提升公司的技術實力
參考資料
https://blog.csdn.net/zhangcongyi420/article/details/90544486
最後決定優先用第2⃣️種方案 但把這個的優先級放到最低 時間充足的話 用這個方案
時間不充足的話 用第1⃣️種方案
根據該對象的這些屬性上從現實角度思考下一個擁有這些屬性的對象能否合理的描述該對象 由此來檢驗屬性是否合理
比如 在我閱讀產品原型的時候就會有一個疑問 在發佈公告上傳頭圖的時候 能夠選擇多張圖片 產品原型中並沒有明確說明（或者我對產品原型理解的不透徹） ，這點很關鍵，因爲會直接影響到對錶結構的設計 ，所以我找產品確認了之後，發現我的理解有誤，如果不進行確定，按照自己的理解開發，即增加了工作量也增大了bug率
後續說明
接下來的流程就不具體闡述了，因爲上述所說的都是基礎，只有基礎打好了，打穩了，你纔會更加的胸有成竹，下面才不至於出現方向性錯誤，細小的需求理解上的問題也很小會發生
本文使用 mdnice 排版