在軟件開發過程中，大到業務模塊的划分，小到技術組件的開發，都屬於組件化的思考范疇內。很多時候我們到網上搜索「組件化」關鍵詞，都只會看到關於前端組件化的資料，而對於后台開發組件化的資料卻很少，那這是不是代表后台組件化沒有意義呢？
后台組件化肯定是有非常大的價值的，對於業務開發人員也有非常大的效率提升。所以本文我將通過自己做組件化的一些經驗，談談我對后端組件化的一些看法，以及如何進行組件化開發，希望對在一線開發的工程師們有所幫助。
希望通過組件化的方式，能幫助一線工程師們減少對於重復業務代碼的編寫，提高開發效率，將更多時間和精力放在創新開發上。
如何發現組件化需求？
組件化，顧名思義，其實是通過將重復的業務操作統一起來，對外提供統一的接口，調用方不需要操心內部實現。通過組件化的方式，能統一業務代碼規范，減少冗余代碼，提高開發效率。
在軟件開發的組件化里，要發現需求，你必須深入到具體的業務過程中去，了解整個業務流程。只有這樣，你才能知道哪些東西需要優化，哪些東西是重復的。
當我剛剛進入珍愛網的時候，公司開啟了精細化運營的需求，很多時候同一個需求對廣東地區開放，而對湖南地區不開放。而當需求呈現正向積極效果的時候，需要對更多省份開放。
而這時候如果需要修改開放的測試地區，則需要開發、測試重新參與一次開發，並且走一遍開發流程。不僅僅效率低下，對於開發人員和測試的正常工作也是一種打擾。
針對這種情況，我試探性地開發出了開關服務。只需要再第一次開發的時候預埋上開關，之后如果需要修改測試省份就可以直接在管理后台進行修改，實時生效。
通過這種方式，你會發現原本需要開發和測試參與，耗時將近一天的開發流程。現在只需要產品自己操作，並且只需要幾秒鍾就能完成，幾乎提高了100%的效率。
所以說發現組件化需求的關鍵，是參與到具體的業務開發中，發現重復的，可統一的業務。
如何開發組件？
當你發現一個可以進行優化的需求后，你下一步需要做的其實就是進行全方位的調研以及設計，從而保證你設計出來的組件能解決問題，並且能為廣大需求方所接受。
根據我的經驗，我一般將組件分為下面三種：服務、組件、后台管理系統。
服務。這種類型的組件提供一個通用的服務，提供給內部的其他系統調用，從而讓其他系統的開發更加快捷。例如之前提到過的開發服務就是這樣的。通過服務接口的方式提供出去，調用方能更加方便地使用，並且其中心化的特性也便於后期升級。
組件。這種類型的組件一般是與業務無關的組件，其通過引入 Jar 包的方式提供給其他系統使用。例如我做過的一個 SysCode 組件就是這樣的，只需要引入相應 Jar 包，實現特定接口注入數據，就可以調用工具類進行 SysCode 操作。
后台管理系統。這種類型的組件其實就是一個管理后台，你發現客服部門經常用到某個功能，於是你將這個功能做到管理后台里，下次發生同樣的問題時，他們就可以自己解決。這也是組件的其中一種。
對於這三種類型的組件，在設計的時候側重點都略有不同。
服務類型的組件，在設計的時候需要對暴露出去的接口定義非常謹慎，因為接口一旦確定，后期就不能再變化，否則會導致原有使用方調用出錯。
而組件類型的，在設計的時候需要考慮的是使用的時候是不是很方便，使用的路徑會不會很長。
文章首發於【博客園-陳樹義】，點擊跳轉到原文《如何通過組件化提高開發效率？》http://www.cnblogs.com/chanshuyi/p/how_to_develop_component.html
如何推廣組件？
當你把組件做出來后，作為組件的開發者，你肩負着推廣組件的作用。
首先，你肯定要讓別人知道你為什么做這個組件，做這個組件的背景是什么，用這個組件有什么價值，最后就是怎么用？
而要回答上面所說到的問題，你不可能每個人問你的時候你都從頭到尾說一遍，所以你需要針對你的組件寫一個文檔。我比較推薦的一種做法是寫成一個 GitBook，這種呈現方式簡單明了，方便閱讀。
當你做好 GitBook 文檔后，你以為就這樣結束了么？
Naive！
這只是一個開始，你需要不斷地在日常的開發中去向你的同事推銷你的東西，把自己想象成一個熱愛工作的銷售，把組件當成是你的孩子，見人就說這個東西好，讓更多人知道他。
之所以將組件化的推廣說得如此艱辛的原因，我相信許多做過組件的人都明白。一開始做的東西別人都不願意去嘗試，因為誰知道你這里面有什么坑呢，我還不如自己弄呢。所以一開始的推廣使用注定是很艱辛的，甚至是很苦逼。
所以不要以為做出組件，寫完文檔就結束了，這其實只是一個開始。
不斷迭代！
魯迅先生說過：好文章不是寫出來的，而是改出來的。
在這里我也要說：好組件不是寫出來的，而是改出來的。
私以為所有做組件的人，都應該抱有不斷迭代的精神去做組件。
因為很多時候你剛剛做出來的東西都是非常簡單的，雖然能解決問題，但是對於業務抽象的理解不夠深刻，而且會存在多多少少的問題。
這時候你需要在不斷推廣和反饋中去優化你的組件，讓你的組件做得更好。之后再不斷地收集反饋，再優化，再反饋。
就這樣，也許經過三四個輪回，你對組件的理解就趨於穩定了。
這個時候，你才可以說這個組件做完了！