总结

 

总结一点平时遇到的吧，随便写写

 

 

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，也就是数据库表