theme: channing-cyan highlight: atelier-lakeside-light

學會自我提問

業務開發是技術能力的試金石，如果日常開發總會有各種狀況，需要開發者提起重視。

今天着重嘮一嘮我總結的業務功能開發中提高效率的小技巧。

在開始重點內容之前，我先列幾個捫心自問的問題：

多任務併發，如何有條不紊的進行工作？
某次需求難，難的是UI、交互還是數據存儲？
來來回回的這幾個頁面功能變更，我的開發效率提升了嗎？
接連三個需求之後，我的哪種開發能力變強了？開發效率？思維敏捷性？解決問題速度？新技術的掌握和應用？
為什麼別人的功能開發總是想的那麼全面？

一般公司都有項目覆盤，尤其大型項目上線之後，針對開發過程中遇到的問題，進行復盤，能夠總結開發經驗。自我提問，可以當成一次自我覆盤。一段時間做一次，可以查漏補缺。

曾子曰：“吾日三省吾身：為人謀而不忠乎？與朋友交而不信乎？傳不習乎？”

技術人的三省吾身：“我問題解決了嗎？我技術進步了嗎？我開發速度變快了嗎？”

設計文檔

“磨刀不誤砍柴工。”講的就是開發前設計文檔的撰寫。

我的設計文檔主要包括開發排期、需求梳理、重點功能設計。撰寫設計文檔的主要目的是，評估開發週期和合理設計開發功能。我所在的技術部門，每次都要進行設計評審，只有設計文檔中的功能設計得到認可之後，才能進入開發階段，否則需要重新進行功能設計。所以我每次都會認真設計我要開發的功能。

開發排期

我一般做開發排期時，到頁面維度，根據具體頁面的難易程度計劃開發時間，以小時為單位。

而聯調排期，也是到頁面維度，根據當前頁面的接口的數量和接口的入參以及返回的結構難易進行評估，以小時為單位。

我是在保險科技公司，主要負責理賠業務的開發。下面是我某次開發時的排期：

| 修改（新增）頁面 | 開發時間/h | 聯調時間/h | | -------- | ------ | ------ | | 理賠列表頁 | 6 | 3 | | 理賠詳情頁 | 2 | 2 |

上面表格中的排期，是經過以下三個階段之後，最終確定的排期。

簡單頁面開發如何排期

對於相對簡單的頁面功能，我一般先梳理修改項是什麼，比如文案修改、新增展示內容、哪些可以用公共組件，哪些可以做成公共組件。簡單頁面基本在需求梳理結束之後，心裏就有一個開發預期了，時間上也能比較有比較準確的評估。

比如像詳情頁，因為我們有現成的組件。只需要根據頁面內容組成展示數組通過props傳給詳情組件即可。所以我開發評估了2h，聯調時考慮到返回的數據較多、結構較為複雜，所以我也評估了2h。

詳情頁組件的開發，我之前寫了一篇文章 【工作小記】後台系統代碼簡潔之路-詳情頁設計 。

複雜頁面開發如何排期

複雜頁面，我一般都先進行拆解。複雜的邏輯經過拆解之後，會分出很多細項，細項中還是區分簡單和複雜，但是這個時候難點不在是憑空感覺的，而是很明確知道的難點在哪，時間評估自然也會準確很多。

比如像後台列表頁類的頁面，因為我們的項目已經有搜索項組件和列表組件，所以列表頁一般1h就能搞定。

而列表上的操作項往往是較複雜的表單功能。比如新增報事，需要填寫的內容較多，所以我評估了4h。

而其他的取消、刪除、日誌等都有現成的組件，所以1h就能完成。這樣一個頁面，開發時間的6h就出來了。

而聯調方面，取消、刪除、日誌組件已經將接口請求也考慮進去，所以聯調排期只需要考慮添加操作即可。添加操作考慮到數據結構的複雜和編輯的回顯，所以我評估了3h。

反問方式確定最終排期

我在做完全部的排期之後，並不會着急發出來，我會最後審查一下所有的開發時間。

這個時候我會在心裏反問自己幾個為什麼。

這個頁面為什麼排期時間長，是哪個功能比較複雜、複雜點在哪？然後向下找一下複雜功能，看一下設計方案，最終確定它的複製程度以及實現難點在哪。然後再次評估時間的準確性。
這個頁面為什麼排期這麼短，頁面的交互、UI、操作是不是都很簡單，可以很快完成開發。再次確認功能複雜性確實不高的時候，就能確定最終的開發時間了。
我的整個排期計劃是否合理，有沒有壓縮或者誇大排期。誇大排期會影響個人技術的成長，而壓縮排期會有延期的風險。兩個都不推薦，合理性考慮是開發排期最終的自我檢驗。

詳細的功能設計

詳細的功能設計有助於更加合理的預估排期。我一般會以單個頁面為開發緯度，每個頁面的UI、交互、表單操作等難易程度不一，甚至同一個頁面不同的操作難易程度也不一樣。所以功能梳理會協助更好的評估排期。

所有的功能都需要列出實現方案嗎？

並不是所有的功能都需要列出具體的實現方案。有些文案修改、新增展示內容、或者新增的操作已經有現成組件等，只需要列出需求的內容和實現描述即可。有些相似的功能，比如添加/編輯彈窗，只需撰寫添加的實現方案即可。

重點功能怎麼設計？

複雜的交互包括幾種，操作流程過長、嵌套層級過多，聯動項過多，不同場景的功能不一樣等。

流程圖

流程圖是開發很好的幫手。比如登錄流程，複雜的登錄流程，流程較長，會根據用户的狀態的不同做不同的處理，這個時候憑空想象，總會出現遺漏。不如動手畫一下流程圖，可以幫助避免遺漏。

複雜功能拆解

複雜的功能，也有簡單的部分。比如嵌套層級過多的功能，每一層的功能可能並不複雜。所以對於這類需求，我會先進行功能剝離處理，再耦合在一起。比如我曾經有共需求是查詢不同年的不同月份下的不同狀態的理賠數據，並且可以進行點擊跳轉到不同頁面。我根據年、月、狀態，進行了三層數據處理，在將處理後的數據整合在一起。這樣不同維度的功能處理不受干擾。

熟悉業務

對業務的熟悉程度也能間接的提升開發速度和開發質量。

在開發中，通過對業務認知的加深，掌握舉一反三的能力，可以再功能設計上增加功能的複用性和可擴展性。

詳情頁組件，也將原本複雜的案件詳情頁面簡化了，只需將頁面內容按照原型中給定的內容重組成數組，通過props傳給詳情頁組件即可。且支持特殊展示內容和操作功能，也大大縮短了詳情頁的開發時間。
不同業務之間的相似操作，比如列表的批量刪除操作，這個操作我在其他業務開發時遇到過，後面理賠業務也需要開發這個功能，因為已經有現成的功能，所以我直接拿過來用了。這個操作，我之前也總結過一篇文章 【功能實現】多個批量操作的鏈式實現 。
在做重構時，熟悉之前的業務，可以簡化某些判斷邏輯。比如圖片的有效期，會根據產品性質的不同區分是否需要，之前在頁面展示和提交時都做了判斷。重構時，我將判斷提前到了獲取頁面數據的位置，展示和提交時不需要做二次處理。

老頁面修改的功能隔離

在修改老頁面的時候，如果新增功能和老的頁面功能能夠區分開，即能減少因不熟悉代碼導致的漏提測功能問題，也能夠減輕測試的壓力。

比如新增的圖片有效期的功能。

數據回顯

```js componentDidUpdate() { // 獲取圖片信息 this.getImgInfo(); }

/* * 獲取圖片信息 / getImgInfo = () => { // let resData = res; // 接口數據 let imgInfo = resData.imgInfo || {}; this.formRef.current.setFieldsValue({ ...imgInfo, }); this.setState({ imgInfo, }) }; ```

頁面展示

```js /* * 圖片有效期展示內容 / imgContent = () => { return ( <> 短期長期
); };

......

{this.imgContent()} ...... ```

數據提交

js /** * 表單提交操作 */ submit = value => { let { imgInfo } = this.state; let params = { ...value }; // 有圖片時 if (imgInfo.hasImgType === 1) { params.imgEndFlag = value.imgEndFlag; } };

自問自答

前面自我提問的幾個問題，歸根結底是對自己開發效率、開發質量、開發能力的盤問和深思。

並行可行

工作中難免會遇到並行任務，我們熟知四象限法則能很好的幫助我們合理安排工作。但是實際開發中的並行需求，可能完成時間都差不多，所以不能簡單的按照緊急程度進行排期。

我領導教我的方法是，將一天的時間進行拆分，根據任務量進行時間劃分，比如簡單的任務，可以劃分2小時去做開發，內容較重的任務花6小時進行開發。

做好任務分工，我在工作中挺遊刃有餘的。一般2-3個任務同時進行對我來説壓力不是太大，再多就有壓力了。

全面可全

再説一下這個考慮全面的問題。

一般複雜情況漏掉某些場景的情況，可以通過畫流程圖和設計圖避免。

另外就是對自己要做的功能所處的業務充分熟悉，有些特定場景也的業務功能，可以通過閲讀代碼註釋、結合上下文、結合前後頁面進行更詳細的瞭解。

提升是必然

你十分清楚自己要做的事情的時候，無形中就節省了一些走彎路的時間。而設計文檔就可以幫助你清楚要做哪些事。

前端開發提效小技巧之業務功能篇