软件开发之道

1.务必仔仔细细看清该技术的技术文档，切忌概览；

2.对于较难理解的，一定要多看，这个多看不仅仅指一遍遍的阅读技术文档或代码，而且也可以理解为不止某一天看，因为有些知识需要消化，当时看过之后未必能够消化掉，因为需要多看几次、多看几天，还有一个原因就是，在学习时有时会陷进去，而此时可以先放下，理清思绪，或者暂时先不理，等到有时间再处理；

3.对于某些难以理解的算法，借助画图来理解是一种有效的辅助方法；

4.对于未接触过的新技术或其他知识，不妨运用已有的知识进行类比处理，除此之外，可以多参考一些已有的书籍或博客，站在巨人的肩膀上有助于看的更远；

5.处理任何问题，尤其是写代码，务必使头脑保持清晰，不能稀里糊涂的处理，要从代码起始位置了解业务，对于含糊不清的地方，一定要想办法弄清楚，不然做的再多也是徒劳！

6.解决一个问题，应首先清楚要解决的问题是什么，先理解清楚产品需求，有需求文档看需求文档，没有的话找产品经理或其他制定需求的人，不能自己想当然，如果需求都理不清，就很有可能理解错产品需求，做出不符合需求的产品，最终浪费人力、物力、财力；

7.jar包版本不兼容往往引发一些令你抓狂的bug；

8.通过看官方文档来学习是一种非常行之有效的方法，官方文档将对项目背景、项目的实现方法做详细说明，非常容易理解。

9.自己搞不定的问题，可以和别人一起研究，即使你们都不会，但在研究的过程中或许就会有人能找出解决方法，也成为协作，自己强大固然好，但是真的解决不了了，和别人一起研究，说不定就解决了，这个方法称之为：协作；

10.有一个喜欢钻研的朋友也很重要；

11.对于不易理解的概念，要坚信：书读百遍，其意自见；

12.看懂和会实际操作还是有区别的，对于已看懂的知识，实际操作有助于强化理解，对于看不懂的知识，实际操作有助于理解；

13.对于某一项技术或者语言，应主动整理该技术的体系架构，一些技术书的章节目录就是一个很好的参考，但是不能迷信书本，应当根据自己的理解整理出自己的体系架构，例如：Java中的多线程在一些书本中可能只是一个章节，但是就多线程而言，单独写成一本书也不为过，因为涉及的内容太广泛了；

14.对于一个庞大的任务，最好不要一次性完成，要学会对任务进行分解，指定合理的计划，按计划一点一点的完成；

15.牛顿曾经说过：“如果说我看得远，那是因为我站在巨人的肩膀上”。学习技术也是这样，对于某一特定技术，一些大佬已经弄的很透彻了，会录制一些视频放网上，大部分讲的好的都是收费的，如果真的想学习，不要吝惜那点钱，因为，一些知名的大佬的课程是绝对物超所值的；

16.idea添加新的依赖时，如果仓库中已下载下来jar包，但工程里就是加载不到，一般是idea的缓存造成的，此时应选择pom.xml文件进行reimport，在左边maven选项卡reimport，然后重启idea；

17.使用freemarker时，如果请求不能返回页面，可以试着强刷一下页面。

18.开发要遵循低耦合原则，将一切以后可能会发生改变的数据、方法、类、服务等抽取出来，以便到时可以方便的进行修改，最简单的判断方法就是：假设现在要将该应用复制一份，仅仅改变数据表表名，是否可以很快完成复制？如果可以，则此应用的开发大致符合低耦合原则。

19.将所有数据都清空，再重新跑一遍应用，有时会发现一些数据存在时不能发现的bug；

20.应用都需要设计一个统一的请求结果返回类，该类应有以下四个基本属性：是否成功(success)、请求结果码(errorCode)、处理结果(message)、结果数据(data)，也可参考微信官方文档；

21.在进行开发之前，应该先从宏观角度进行大致的规划，抽取具有通用性的方法、变量等，此外，如果是可能会变化的变量，一定要抽取出来，并且，能动态获取的变量，一定不可以硬编码在代码里；

22.在进行业务开发前，要先理清楚业务逻辑，可以用流程图画出来，或者用文字一条一条写出来，务必穷尽所有可能出现的情况；

23.涉及数字、比例的，一定要考虑到边界条件：0；

24.在sql语句里新增判断条件时，切记不要漏掉了连接关键字，例如：AND；

25.org.apache.commons包下有很多常用的工具类，避免重复造轮子；

26.无论再怎么自信你的代码，在上线到生产环境前也要整体测试至少一遍；

27.每一种技术（甚至可以说是各种只是）的学习都是循序渐进的过程，要由浅入深的进行学习，例如：想要研究Java中HashMap的源码，如果直接看源码可能很难看懂，正确的方法是先去看别人写的博客（不要局限于某一篇），然后再结合源码去看，最后彻底脱离别人的博客自己去研究，长此以往，这种学习应是长时间的，每次都会有一些新的发现和理解，正所谓：活到老，学到老，大致就是这个原因了。

​