开发的关键点在于学习，学习可以说是在任何行业永恒的话题，学习什么？如何去学习？就编程而言，学习最终是为了应用，首先要学习到这种应用，然后学习其如何应用，再学为何能这样应用，最后学如何建立或者（根据需要）更改这种应用。
假设你想学习一个开源项目，首先要了解该项目应用的工作机制，熟悉其业务逻辑，懂得其业务核心在哪里，业务边界在哪里，什么地方正常使用无问题，什么地方正常使用可能有问题（所谓的‘坑’），什么地方在某种情况下使用必有问题等等。
然后需要了解其组成原理，即是代码组成。在对代码工作目的充分了解的前提下，从代码源头找起（方法调用部分），学会单元测试，对代码相关位置进行功能验证，对其相应功能分别进行深入，慢慢排除模块干扰（一般来说，为了提高项目的可维护性，都会将模块进行划分，以至于相应的功能具体实现被划分模块的代码掩盖），同时学习该模块的建设，积累经验
最后最终的目的自然是要根据需要更改此项目（或者不需要更改，但最好能有更改的能力，一般项目应用范围难以保证一定在业务需求之内），假设前两点都能正常完成，那么我对于该项目的各个功能的应用点、边界问题、架构划分、具体实现应该有了一定的了解，通常情况下，为了降低功能及模块的耦合度，项目功能的具体实现都是边界狭隘的单面功能，一般边界在一个任务的范围内，如果业务需求要求更改相关具体实现，应该从调用者处改起（不能改变单面功能的实现，而应该在该功能的调用者处增加业务逻辑），但如果调用者处于一个模块内，则最好在该模块外更改，避免模块与模块间耦合度过高。
假设前两点不能正常完成，只要注意到项目的边界范围，如果能解决需求问题，短时间内也没有关系，并且还能快速解决需求，但如果该项目需要长期使用下去，最好能在有空的时候能将相关的耦合度问题（事实上，所有的设计模式要解决的难题，很大程度上就是这个耦合度难题，只不过在实际开发中这个问题有大有小，通常大的都是小的积累起来的，一般最初发现的都是可以解决的）解决掉，不然你所在的项目可能会越来越难改，任何地方稍微动一下，就会出现各种连带问题，到最终就会面临两个选择，项目重构，或者，重建项目。
项目重构是一件非常吐血的事情，本来到了这个地步，改一小点都会造成恐怖后果，何况重构是要大改，这大概是几个星期不眠不休的节奏了。但是不可否认，重构项目是一个非常好的学习机会，可以加深对解耦的理解。
我再简单谈谈新建项目，建一个新的项目，该项目的开展，必定跟建立者的编程基础、开发经验有直接的关系。一个资深的工程师，可以对工程的各个需求完成的效率、工程结构、代码模块、领域知识、资源、实现方案有较强的开展或把控能力，根据公司规模、需求强弱、需求花费、可用人力物力资源在规定时间内进行需求分析、工程规划、代码编写、测试、内部使用测试、上线、迭代需求分析、工程规划......如此这般
说到底，就编程来说，学习分两个点：基础积累，和，经验积累。基础可以说是经验的催化剂，因为任何的编程经验都离不开基础知识，换句话说，所有的功能都是基础知识的应用，当基础知识扎实了，积累经验是水到渠成的过程，学习将变成一种习惯。
关于基础知识（如数据结构、算法、网络等），现在的高级语言大多都已将基础知识进行了封装，但基础仍是必学之重，基础知识学起来或许比较枯燥乏味，我认为在完成一些个项目，对项目有一定的认识后，再去补习缺少的基础也许是一种不错的方式
来源：oschina
链接：https://my.oschina.net/u/1769712/blog/616115