動態表單工作量給後端
讓前端遠離互相傷害
乙個it公司的日常就是程式設計師、產品經理、ui等同事們的互相殘殺：
應用，不少前端就備受煎熬，除了修改需求的魔咒外，還有後端的重構和調整介面詛咒，即便需求沒改，後端介面或資料結構的調整前端也要巴巴的陪著改，甚至還要為此做大型重構。但是前端重構就真的只是前端重構，和後端一毛錢關係都沒有，工作量還是前端的，bug永遠是先提給前端，簡言之就是，修改需求前端要改，修改介面前端要改，改bug前端要先看（此處省略血淚史一萬行）難道前端就不能反殺一波，擺脫困境了嗎？當然可以，答案就是動態表單，自從有了它，可甩掉不少工作量。
前端開發最煩人的事之一就是寫一堆大同小異的表單，使用的控制項型別有很強的規律性，同型別控制項呼叫的後端介面型別也非常相似，每個表單用到的具體介面、控制項種類和控制項數量又不盡相同，就算封裝控制項復用也是杯水車薪，無法提公升工作效率。前端為了應對後端介面不斷調整修改，在框架層上封裝了一套介面呼叫機制，很大程度上降低了後端介面url調整給前端的影響，不論怎麼改只要介面名稱不變，前端統統可以一鍵搞定，而且還同步建立了資料管理機制，提公升前端效能。
這次，面對這些討厭而又常用的表單，前端的態度一樣是不能忍的。既然不能躲避，那就想辦法解決。因此開發了一套動態表單，從表單內容到資料提交統統由後端配置，前端只需要讀取解析表單配置渲染相應內容即可，使用者完成表單後提交資料傳送的請求也是由後端配置，前端做的只是按照要求傳送資料即可。這樣，前端在表單這一塊就再也不用被產品經理和後端影響，不論需求怎麼改，表單怎麼加，都不需要前端在做附加工作了，留下產品經理和後端研發互相傷害，前端幫著改改bug。
動態表單對很多前端開發人員來說並不陌生，前後端約定好表單配置資料模型，前端只需要實現動態表單解析功能即可。一套完整的產品怎麼可能只有簡簡單單的表單配置能，聯動表單、表單校驗等對前端來說依舊是個比較棘手的問題。以devops動態表單為例來說說表單聯動問題如何解決。
表單聯動主要有兩種形式，一是表單項的資料聯動，再來就是表項顯示聯動。
先來說說表單項資料聯動，舉個例子：表單中包含**庫和branch/tag/commitid兩個輸入項，顯然後者的顯示內容取決於使用者選擇了哪個**庫，此處就需要前端檢測使用者對**庫的選擇，然後將選定後的資料作為引數向後端傳送請求查詢branch/tag/commitid項的列表。
這樣的功能看著並不複雜，只需要監聽**庫的選擇實事件然後在事件處理中呼叫branch/tag/commitid項的查詢請求即可。但是，別忘了你現在在寫動態表單，一切都是配置好的模型，不能針對單獨的某欄位名寫if else做特殊處理（否則還叫什麼動態表單），**是固定的，不能寫任何個性化的**來處理事件，而且這只是乙個簡簡單單的兩項聯動，真正的專案開發中，多項聯動比比皆是。為了解決這一問題，前端在資料模型的設計上做了一定的思考，要求後端在配置動態表單的資料獲取url時將需要的引數以冒號加對應表單項的欄位名形式配置，示例：api/repo/commit?repoid=:repoid。此後，前端在解析整個表單的時候會給每乙個表單項傳遞完整的表單資料物件，當表單資料中的某項發生改變時，需要向後端傳送請求的一些表單項會監聽整個表單資料的變化，將與改變的表單項欄位名相匹配的url進行重寫，替換上對應的值，然後用發生改變的url向後端傳送請求獲取新的資料。配置示例如下：
[, ]
再來就是動態表單聯動顯示問題，如下圖顯示，當使用者選擇不同的介質策略時，顯示的表單項也是不同的：
針對這一功能，目前採用的解決方案是，在配置項上加上指定的eventname，當資料項發生改變時，針對不同的資料情況顯示或隱藏表單項，**如下：
artifactstrategychange: (attrvalue) => },
當然，這部分**還是免不了要在前端實現，這已經比乙個個的寫完整的表單工作量少了太多。
devops產品的cicd部分全部採用動態表單體系實現，在功能擴充套件上是極為迅速的，只要後端完成開發，基本整個功能擴充套件就接近了尾聲。經過的實踐，這套表單體系仍然有許多可優化之處，也在不斷的進行優化和調整，力求將它應用到更多產品中，盡可能的減少開發人員的工作量，提公升產品質量，縮短產品交付時間。
動態表單雖好但是也要充分考慮使用場景和開發代價，不要為了過分抽象**反而本末倒置，過度設計反而提高了研發成本。
工作量估算
我們的方法還是比較實用的 舉個具體的例子 我們做任何乙個工作,都先做sample,比如寫詳細設計,leader必須先寫,定sample,然後看leader做需要多少時間,然後按一定比例,比如pert方法就可以,然後按畫面去分,畫面數 預期每日完成數,測試也一樣,先做sample再算預期case數,再...
如何評估專案工作量
乙個工程需要的早期評估有三項 工作量 持續時間 預算。在這三項中，工作量必須首先評估。當了解工程所需的工作量，你就可以分配決定工程持續時間的資源，進而可以評估人力資源和非人力資源花費。用下面的過程來評估你的工程所需總工作量 1 決定評估所需的精確度。典型的情況是，評估的精確度越高，所需的細節就越多，...
什麼是工作量證明
工作量證明 proof of work 顧名思義，即指工作量的證明。pow機制的基本步驟如下 節點監聽全網資料記錄，通過基本合法性驗證的資料記錄將進行暫存 節點消耗自身算力嘗試不同的隨機數，進行指定雜湊計算，並不斷重複該過程直至找到合理的隨機數 找到合理的隨機數後，生成區塊資訊，首先輸入區塊頭資訊，...