形成一个良好的编程习惯与原则

The Principles of Good Programming
Artima最新文章，作者正在搞C#培训，总结以下几个原理：
1.DRY(拧干代码不要有水分) 不要有重复代码，很多概念实际就是为此存在，比如loops function和classes等等，如果有重复，进行抽象。http://en.wikipedia.org/wiki/Don%27t_repeat_yourself
2.抽象原理，和DRY有关，代码中没一个重要的功能块都应该拧干抽象一下。http://en.wikipedia.org/wiki/Abstraction_principle_(programming)
3.KISS(Keep it simple, stupid!)，简化避免复杂是关键目标，简单代码花费时间短(代码写得少，脑子动得不见得少)，少代码有较少BUGs和更易于修改。(banq:耦合都很高的代码有时很简单，但不易于修改)http://en.wikipedia.org/wiki/KISS_principle
4.避免创造YAGNI，不要增加你不需要的功能：http://en.wikipedia.org/wiki/YAGNI
5.做最简单只要能工作的设计，始终问自己，这样简单设计能够工作吗？http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html
6.不要让我思考，代码应该易于理解。http://www.sensible.com/dmmt.html
7.开闭原则 软件实体如classes类 模块和functions应该开放易于扩展，但是不允许修改，不要写其他人能够修改的类，而是写出人们能够扩展的类(banq:可用面向对象的继承 实现等方法扩展多个子类)。
http://en.wikipedia.org/wiki/Open_Closed_Principle
8.写代码要值得将来维护。http://c2.com/cgi/wiki?CodeForTheMaintainer
8.做最少令人惊讶的事，代码易于理解，名称等各方面不要让人产生惊讶的副作用。http://en.wikipedia.org/wiki/Single_responsibility_principle
9.最少耦合，代码（代码块，函数，类，等等）的任何部分，应尽量减少对其他地区的代码的依赖关系。这是通过使用尽可能少的共享变量 。“低耦合往往是一个结构完善的计算机系统的标志和一个好的设计，高凝聚力相结合，实现更高的可读性和可维护性的总体目标
http://en.wikipedia.org/wiki/Coupling_(computer_programming)
10.最大化凝聚性：相同功能代码应该在同样一个组件中。http://en.wikipedia.org/wiki/Cohesion_(computer_science)
11.隐藏实现细节，隐藏实现细节，将允许改变执行代码组件，而最低限度影响的任何其他使用该组件的模块(实现细节怎么做是战术，做什么是方向战略)http://en.wikipedia.org/wiki/Information_Hiding
12.迪米特Demeter法则 ，代码组件只应该和他们的直接关系联系(直系血缘关系)，如他们继承的父类，包含的对象和参数传递的对象http://en.wikipedia.org/wiki/Law_of_Demeter
13.避免过早优化,除非你的代码比你预期慢，否则不要提早优化，过早优化是罪恶根源，http://en.wikipedia.org/wiki/Program_optimization
14.代码能够重用是好的，重用代码提高代码的可靠性，缩短开发时间。http://en.wikipedia.org/wiki/Code_reuse
15.分散关注：不同功能区域，应该由不同代码和最小重叠的模块组成。(AOP是分散关注典型模式)
16.拥抱变化，这是一本Kent Beck书籍副标题，也被认为是极限编程和敏捷方法在一般的宗旨。最大限度地减少耦合使代码更容易改变。无论你是一个极端编程的医生，这种方法对于编写代码是有道理的。

当软件开始复杂时，软件质量就非常重要。软件质量是软件架构的重要因素之一。软件质量是所有软件工程师在建立新系统或增加新功能时必须考虑的。，而遵循良好编程的原则是保证软件质量的重要途径之一。

摘录：程序员和软件工程师是有区别的，前者只要写出计算机能运行的代码即可，后者不但要计算机能运行，还要能让其他人懂。所以，很显然，软件工程师要比程序员高级，待遇肯定应该高，将“软件工程师”叫成“程序员”简直是侮辱。
让“程序员”见鬼去吧，那是一个已经过去的时代。