别人的“轮子”虽然好用，但却不能过分的依赖。毕竟别人的永远是别人的，身为伟大的猿类，我们得有自己的“轮子”。
当然，自己造轮子也得分时间和场合，如果项目中着急用，你还非要自己从0开始造一个，那就有点不合适了。个人建议是：项目过程中，以借用别人的“轮子”为主，但是用别人的轮子的时候，一定要为更换“轮子”预留出空间。等不太忙的时候，就可以自己造一个了，然后用自己的“轮子”去替换别人的“轮子”。
好了，以上纯属扯淡的个人意见，下面开始进入正题：
个人感觉，造“轮子”就像开发项目一样，不能上来就直接动手就写代码，这样的话，很容易漏下“需求”，造“轮子”就要像做项目一样，按照项目流程一步一步地进行，这样才能保证“轮子”是好用的，引入项目之后，是能够保证项目正常运行滴。
淡扯得有点多了，下面进入正题，简单阐述下对于造“轮子”这件事的个人观点。
1、需求调研
上面提到了，造“轮子”，可以当作是一个简单的项目来进行，既然是做项目，首先就要调研需求了，不过，貌似，大概，可能，这个需求的关键用户就是你自己，好吧，是自己更好，起码沟通没有障碍了，那我们就找个角落自己和自己好好的交流交流，把需求定下来。需要注意的是，好记性不如烂笔头，就算关键用户是自己，也要把需求整理下来。
需求整理的话，推荐用Markdown来写，至于为啥，我觉得来个样式比较有说服力:
需求列表.png
看到木有，有木有感觉还不错，所有的需求直接罗列出来，已经实现了的需求还可以打个对勾，展现效果是不是很不错。而写法也贼简单：
- [x] 功能需求1
- [ ] 功能需求2
- [x] 功能需求3
2、系统设计
需求有了，下一步就要做系统设计了，产品经理要开始做原型图了。不过，问题来了，产品经理呢？这个，貌似还是你自己。
既然还是自己 ，那自己就愉（苦）快（逼）的去开搞吧。
在画原型图之前，我觉得我们有必要整个流程图出来。画流程图的工具，我依然还是推荐Markdown。至于理由的话，请往下看：
流程图.png
效果不错吧，写法上，也不难：
graph TD
A(开始)-->B{是否正确}
B-->|true| C[正确的流程]
B-->|false| D[不正确的流程]
C-->E(结束)
D-->E
3、实现功能
这个没什么好说的，就是按照流程图，按照需求列表，去实现所有的功能就好了。这里唯一需要注意的一点就是：现在先别想着要做成通用的“轮子”，目前的任务，就是把需求列表的功能去实现就好了。不要想着一步到位，就算你对自己的水平很有信心，也不建议一步到位，按部就班才是比较稳妥的方式，毕竟，“轮子”造好了，还要给别人用的，还是稳一点比较好，不然不仅坑了自己，还要坑那些信任你，使用你“轮子”的人。
4、抽取代码，封装通用的“轮子”
功能实现了，最后才是去抽取代码，把自己造的崭新的“轮子”制造成大家都能通用的“轮子”
5、测试
这个就不用多说了，测试这种东西，我是简单粗暴的直接放到自己得项目中，当然，不是正式版本，只是放到测试版中，进行测试，当然，有条件的，还可以找测试的小姐姐帮忙去测一测。
好了，“轮子”制造过程就介绍到这里了。我也开始去制造自己的“轮子”了，以后我的“轮子”都会按照这个流程慢慢发出来的，不过能发出来几个，可就真不敢保证了，以后要准备转小程序和Java后台了，能干多久的Android，真的不好说了，哎。。。。。。。。。
最后，推荐一下比较好用的Markdown编辑器以及上边提到的Markdown语法
工具推荐2个：有道云笔记 和 Typora【有道云笔记是支持上边介绍的流程图语法的，Typora仅支持部分流程图语法】
网友评论