总结一点平时遇到的吧，随便写写
1. 写程序，错误应该尽早发现
比如@override，实际作用不大，但是如果写上，在编译时期就可以发现错误，如果不行，只能等到运行时期发现错误
写程序应该尽早地发现错误
2. 组合代替继承
设计中一般慎用继承，因为
1. 继承了一个之后，就无法再继承另外一个了
2. 如果父类改了，子类必须修改，子类和父类的耦合性太强
所以很多设计模式中都是用组合来代替继承
比如说A是一个接口，B和C都实现了它，但是D同时想实现B和C的功能怎么办呢，用左边的继承好像办不到
右边的表示，在C里面包含一个B类的属性，通过组合的方式构成新的类
3. 约定大于配置
做项目，首先一定要约定好
4. 90%的书是用来查的而不是用来读的
计算机类的书，90%的是用来查的，而不是用来一点一点读下来的。对于这种书，知道它主要内容，就行了，用的时候查
只有10%的书是用来读的，比如设计模式，算法之类的
5. 程序猿一定要更多地关注业务
写代码就像搬砖，搬一个月和搬一年都是在干同一样的事情。一定要深入了解业务。不能只是停留在代码上
6. 技术，要更多地了解原理
所有的技术都是可以融会贯通的，很多技术的原理其实也都是一样的。
所以，学习一门技术，不要老是用这个技术写啊写，一定要深入到其背后的原理，知道为什么
7. 顺着业务逻辑读程序
当我们在看一个新的项目时，要根据一个完整的业务的顺序来看代码
可以使用bug跟踪
8. 写程序要由小及大
先写程序原型，即没有多少具体功能的程序，然后再在原型的基础上一点点地添加细节功能
程序开发要尽量先写原型，然后迭代式开发
这种模式更自然，可以应对需求的变化，并且不断看到阶段性成果。
学习，做实验等也要是迭代式的
先有脉络，再学细节
9. 设计原则
如果要想写一个项目，最先做的并不是怎么写Struct，怎么写spring，最先做的是想想下面二个东西
1. 界面原型
就是原型系统，静态页面，没有业务实现。这个可以搞清需求分析以及整体业务。
2. 实体类
就是Domain model，也就是数据库表