如何通過元件化提高開發效率？

後台元件化肯定是有非常大的價值的，對於業務開發人員也有非常大的效率提公升。所以本文我將通過自己做元件化的一些經驗，談談我對後端元件化的一些看法，以及如何進行元件化開發，希望對在一線開發的工程師們有所幫助。

希望通過元件化的方式，能幫助一線工程師們減少對於重複業務**的編寫，提高開發效率，將更多時間和精力放在創新開發上。

元件化，顧名思義，其實是通過將重複的業務操作統一起來，對外提供統一的介面，呼叫方不需要操心內部實現。通過元件化的方式，能統一業務**規範，減少冗餘**，提高開發效率。

在軟體開發的元件化裡，要發現需求，你必須深入到具體的業務過程中去，了解整個業務流程。只有這樣，你才能知道哪些東西需要優化，哪些東西是重複的。

當我剛剛進入珍愛網的時候，公司開啟了精細化運營的需求，很多時候同乙個需求對廣東地區開放，而對湖南地區不開放。而當需求呈現正向積極效果的時候，需要對更多省份開放。

而這時候如果需要修改開放的測試地區，則需要開發、測試重新參與一次開發，並且走一遍開發流程。不僅僅效率低下，對於開發人員和測試的正常工作也是一種打擾。

針對這種情況，我試探性地開發出了開關服務。只需要再第一次開發的時候預埋上開關，之後如果需要修改測試省份就可以直接在管理後台進行修改，實時生效。

通過這種方式，你會發現原本需要開發和測試參與，耗時將近一天的開發流程。現在只需要產品自己操作，並且只需要幾秒鐘就能完成，幾乎提高了100%的效率。

所以說發現元件化需求的關鍵，是參與到具體的業務開發中，發現重複的，可統一的業務。

當你發現乙個可以進行優化的需求後，你下一步需要做的其實就是進行全方位的調研以及設計，從而保證你設計出來的元件能解決問題，並且能為廣大需求方所接受。

根據我的經驗，我一般將元件分為下面三種：服務、元件、後台管理系統。

服務。這種型別的元件提供乙個通用的服務，提供給內部的其他系統呼叫，從而讓其他系統的開發更加快捷。例如之前提到過的開發服務就是這樣的。通過服務介面的方式提供出去，呼叫方能更加方便地使用，並且其中心化的特性也便於後期公升級。

元件。這種型別的元件一般是與業務無關的元件，其通過引入 jar 包的方式提供給其他系統使用。例如我做過的乙個 syscode 元件就是這樣的，只需要引入相應 jar 包，實現特定介面注入資料，就可以呼叫工具類進行 syscode 操作。

後台管理系統。這種型別的元件其實就是乙個管理後台，你發現客服部門經常用到某個功能，於是你將這個功能做到管理後台裡，下次發生同樣的問題時，他們就可以自己解決。這也是元件的其中一種。

對於這三種型別的元件，在設計的時候側重點都略有不同。

服務型別的元件，在設計的時候需要對暴露出去的介面定義非常謹慎，因為介面一旦確定，後期就不能再變化，否則會導致原有使用方呼叫出錯。

而元件型別的，在設計的時候需要考慮的是使用的時候是不是很方便，使用的路徑會不會很長。

當你把元件做出來後，作為元件的開發者，你肩負著推廣元件的作用。

首先，你肯定要讓別人知道你為什麼做這個元件，做這個元件的背景是什麼，用這個元件有什麼價值，最後就是怎麼用？

當你做好 gitbook 文件後，你以為就這樣結束了麼？

*****！

這只是乙個開始，你需要不斷地在日常的開發中去向你的同事推銷你的東西，把自己想象成乙個熱愛工作的銷售，把元件當成是你的孩子，見人就說這個東西好，讓更多人知道他。

之所以將元件化的推廣說得如此艱辛的原因，我相信許多做過元件的人都明白。一開始做的東西別人都不願意去嘗試，因為誰知道你這裡面有什麼坑呢，我還不如自己弄呢。所以一開始的推廣使用注定是很艱辛的，甚至是很苦逼。

所以不要以為做出元件，寫完文件就結束了，這其實只是乙個開始。

在這裡我也要說：好元件不是寫出來的，而是改出來的。

私以為所有做元件的人，都應該抱有不斷迭代的精神去做元件。

因為很多時候你剛剛做出來的東西都是非常簡單的，雖然能解決問題，但是對於業務抽象的理解不夠深刻，而且會存在多多少少的問題。

這時候你需要在不斷推廣和反饋中去優化你的元件，讓你的元件做得更好。之後再不斷地收集反饋，再優化，再反饋。

就這樣，也許經過三四個輪迴，你對元件的理解就趨於穩定了。

這個時候，你才可以說這個元件做完了！