总结

 

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

 

 

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

 

posted on 2014-12-18 20:40  飞鸟快跑  阅读(150)  评论(0编辑  收藏  举报