別人的“輪子”雖然好用，但卻不能過分的依賴。畢竟別人的永遠是別人的，身為偉大的猿類，我們得有自己的“輪子”。
當然，自己造輪子也得分時間和場合，如果項目中著急用，你還非要自己從0開始造一個，那就有點不合適了。個人建議是：項目過程中，以借用別人的“輪子”為主，但是用別人的輪子的時候，一定要為更換“輪子”預留出空間。等不太忙的時候，就可以自己造一個了，然后用自己的“輪子”去替換別人的“輪子”。
好了，以上純屬扯淡的個人意見，下面開始進入正題：
個人感覺，造“輪子”就像開發項目一樣，不能上來就直接動手就寫代碼，這樣的話，很容易漏下“需求”，造“輪子”就要像做項目一樣，按照項目流程一步一步地進行，這樣才能保證“輪子”是好用的，引入項目之后，是能夠保證項目正常運行滴。
淡扯得有點多了，下面進入正題，簡單闡述下對于造“輪子”這件事的個人觀點。
1、需求調研
上面提到了，造“輪子”，可以當作是一個簡單的項目來進行，既然是做項目，首先就要調研需求了，不過，貌似，大概，可能，這個需求的關鍵用戶就是你自己，好吧，是自己更好，起碼溝通沒有障礙了，那我們就找個角落自己和自己好好的交流交流，把需求定下來。需要注意的是，好記性不如爛筆頭，就算關鍵用戶是自己，也要把需求整理下來。
需求整理的話，推薦用Markdown來寫，至于為啥，我覺得來個樣式比較有說服力:
看到木有，有木有感覺還不錯，所有的需求直接羅列出來，已經實現了的需求還可以打個對勾，展現效果是不是很不錯。而寫法也賊簡單：
- [x] 功能需求1
- [ ] 功能需求2
- [x] 功能需求3
2、系統設計
需求有了，下一步就要做系統設計了，產品經理要開始做原型圖了。不過，問題來了，產品經理呢？這個，貌似還是你自己。
既然還是自己 ，那自己就愉（苦）快（逼）的去開搞吧。
在畫原型圖之前，我覺得我們有必要整個流程圖出來。畫流程圖的工具，我依然還是推薦Markdown。至于理由的話，請往下看：
效果不錯吧，寫法上，也不難：
graph TD
A(開始)-->B{是否正確}
B-->|true| C[正確的流程]
B-->|false| D[不正確的流程]
C-->E(結束)
D-->E
3、實現功能
這個沒什么好說的，就是按照流程圖，按照需求列表，去實現所有的功能就好了。這里唯一需要注意的一點就是：現在先別想著要做成通用的“輪子”，目前的任務，就是把需求列表的功能去實現就好了。不要想著一步到位，就算你對自己的水平很有信心，也不建議一步到位，按部就班才是比較穩妥的方式，畢竟，“輪子”造好了，還要給別人用的，還是穩一點比較好，不然不僅坑了自己，還要坑那些信任你，使用你“輪子”的人。
4、抽取代碼，封裝通用的“輪子”
功能實現了，最后才是去抽取代碼，把自己造的嶄新的“輪子”制造成大家都能通用的“輪子”
5、測試
這個就不用多說了，測試這種東西，我是簡單粗暴的直接放到自己得項目中，當然，不是正式版本，只是放到測試版中，進行測試，當然，有條件的，還可以找測試的小姐姐幫忙去測一測。
好了，“輪子”制造過程就介紹到這里了。我也開始去制造自己的“輪子”了，以后我的“輪子”都會按照這個流程慢慢發出來的，不過能發出來幾個，可就真不敢保證了，以后要準備轉小程序和Java后臺了，能干多久的Android，真的不好說了，哎。。。。。。。。。
最后，推薦一下比較好用的Markdown編輯器以及上邊提到的Markdown語法
工具推薦2個：有道云筆記 和 Typora【有道云筆記是支持上邊介紹的流程圖語法的，Typora僅支持部分流程圖語法】
