良好的编程习惯

良好的编程习惯需要遵从如下约束，排名分先后：

　良好的命名、清晰的结构、不十分差劲的算法

一、良好的命名
　　命名很重要，命名应该本着不拍长就怕不清楚的原则，尽量把一个类、方法、变量的含义交代清楚

 下面详述命名：
　　接口的命名
　　接口的命名一般都是前缀 I 加上名词或形容词，实际上.Net Framewrok类库就是这样做的，比如：
　　System.Collections.Generic.ICollection（名词）
　　System.Collections.Generic.IEnumerable（形容词）
　　接口往往用来分装一个或一组行为，实现接口的类意味着它具有了一个或一组行为的能力，所有常用形容词。当实在找不到一
个恰当的形容词时，名词也可以。
　　抽象类
　　抽象类通常不需要加前缀或后缀，也有部分大牛喜欢给抽象类视情况加Base后缀。如下的命名笔者觉得就不错：
　　1、Shape（抽象类）
　　2、Ellipse（具体类）
　　3、Rectangle（具体类）
　　具体类
　　尽量使用名词，不排除个别情况下把一个行为封装为类时使用动词。
　　方法
　　使用动词或动词性短语。

二、清晰的结构
　　基本要求
　　1、if、while等关键字包裹的表达式，即使只有一句，也尽量使用大括号括起来
　　2、尽量避免使用直立人时代的goto语句
　　3、尽量避免过长的方法，把大方法拆分为数个小方法，方法的职能尽量单一
　　4、尽量避免重复代码，将其转移到公共工具中
　　5、尽量避免过大的类，拆分为数个类，各司其职
　　6、适当的注释，注释太多，说明代码本身的表达力可能还有待加强。有些实在难缠的逻辑，可以写详细注释，如果不写注释，离职时请注意不要泄露给擦屁股人自己的地址
　　较高要求
　　熟悉以下常用面向对象的设计原则：
　　1、开放-封闭
　　2、单一职责
　　3、里氏替换
　　4、依赖倒置
　　5、接口隔离
　　再高要求
　　熟悉常用设计模式:
　　1、工厂方法
　　2、抽象工厂
　　3、建造者模式
　　4、单例模式
　　5、设配器模式
　　6、外观模式
　　7、观察者模式
　　8、命令模式
　　9、代理模式
　　10、策略模式
　　使用成熟的设计模式有两个好处：
　　1、这些解决方案已经经受过了考验，用了即使无功，但也不会犯错
　　2、设计模式的名称本来就一种在程序员间流传的概念，基于共同的对概念的认识能够降低沟通成本
　　当然也有坏处，代码的扩展性虽然是好了，但是代码的复杂性也高了，这就要求我们最好熟悉常用的设计模式，这样就得到了
它的好处，规避了它的坏处。
　　必须要注意的是：不要乱用设计模式，只有需求产生了变化，或预见了需求将要发生变化才使用这些模式来封装发生的或可能
发生的变化。有时候再重构代码时也会用到，比如外观模式和设配器模式等。
　　更高要求
　　1、大项目肯定不是一个人能完成的，人多了容易发生混乱，此时需要团队的领袖勇敢地承担起义不容辞的责任
　　2、定期维护代码框架、分层结构。写的时间长了难免乱，领袖人物要定期排除，及时消除臭味
　　3、引导小弟们做代码审查。审查的意义不在于监督，而在于学习和维持良好的态度。学习指通过代码审查学习别人的长处，同时帮助别人进步。保持良好的态度是指如果预知了有人会看自己的代码，那么就会自觉地尽量把代码写工整，即使审查代码的人偷懒没有真真看过，正所谓，如果人人都相信三尺之上有神灵，那么也就没人做坏事了，宗教的积极意义就在于此，扯远了。
　　4、及时更新或委派组员更新文档
　　关于文档，还需多说一句：只有再非常有必要写文档的情况下才写文档。如果写了一大堆可有可无的文档，代码更新后文档也
要及时更新，很难做到的。一个新手面临着一堆和代码脱节的文档只会起误导作用，以代码本身的表达力和口头交流为主，以文档
交流为辅，两手都要抓，一只手硬，一只手软。
三、不十分差劲的算法
　　相信大部人做的项目都是性能不敏感的，只要稍稍注意就能做好。比如该使用分页的地方就使用分页，该根据条件查询数据库
的就别一次都查出来，该优化数据库就优化数据库。
　　此外，压力测试也很有必要，有的性能问题只有在数据量大了的情况下才出现。很多性能问题都是到了生产环境中才暴漏出来
的。
　　代码之外
　　和团队建设比起来，以上只能算是雕虫小技，只起到了一个锦上添花的作用。如何使团队保持活力，保持积极性才是最重要的
，通常也是最容易被领导忽视的，最难做好的，这些已超出笔者能力范围和本文的论述重点，有机会再写。祝大家工作愉快！