记住
越少越好
并非总是如此（Keep in Mind –
Less is more
is not always better）
– 高效率的代码是件好事
但很多情况下
并非代码行数越少效率就越高
不要把简单事情复杂化（Do not complicate things） – 我曾经这么做过我相信你也一样开发者都倾向于采用复杂方式解决简单问题我们在一个只有个用户的系统中引入EJB为一个并不需要框架的应用实现一套框架采用属性文件采用面向对象解决方案使用线程而这些根本用不着为什么会这么做？一些人可能不知道有更好的解决方案但另一些人可能故意这样做来学习新知识或仅仅是因为有趣对那些不知道更好解决方案的人要多听有经验程序员的建议对于那些纯粹出于个人目的而将设计复杂化的人我建议你要更加专业一点
不要硬编码（No hard coding please） – 由于时间紧迫开发者总是会忘记或故意忽略这一条然而另一种可能是遵循这条戒律我们就不会陷入时间紧迫的困境定义一个static final 变量增加一行代码又能花多长时间呢？
为代码添加注释（Add comments to your code） – 每个人都知道这一点但不是每个人都会这么做你有多少次忘记添加注释了？确实注释不会为你的程序增加任何函数功能但是有多少次看到周前写的代码你都记不起它是干什么的？你很幸运那些未注释的代码是你自己写的你脑海中还会有残存的印象非常不幸大多时候代码是别人写的并且那个人很可能已经离开公司了有句谚语说的好有来有往互惠互利因此程序员应该体谅彼此（还有你自己）给你的代码加上注释
不要发明你自己的框架（Do not invent your own frameworks） – 不夸张地讲已经有几千个框架存在了大多数还是开源的很多框架都是极完美的解决方案并已被用到成千的系统中我们只要关注最新的流行的框架至少表面上要熟悉一下一个最成功的也是被广泛使用的例子是Struts框架这个开源的web框架是建立web系统的极佳选择不要试图构造你自己的Struts版本会累死的但你必须记住第条（译注原文是第条显然不对）戒律 不要把简单事情复杂化如果你要开发的系统只有个界面就不要用Struts 对于这样一个系统没有足够的需要被控制的东西（译注Struts将界面做MVC划分C即controller所以作者说there isnt much controlling required）
对Print行或字符串说不（Say no to Print lines and String Concatenations） – 我知道为了调试方便程序员喜欢到处用Systemoutprintln 然后对自己说过一会就删掉但我们常常忘记删掉这些行或不愿删掉我们用Systemoutprintln 做测试为什么测完后还要去改代码？这很可能导致误删一行我们需要的代码不要低估Systemoutprintln 的危害
单元测试单元测试单元测试 （Unittest Unittest Unittest） – 我不准备讨论如何单元测试的细节我只是想说这必须要做这是编程中最基本的规则了尤其不能忽略如果你同事能为你的代码创建一个测试计划那就再好不过了如果不能那就要自己做做单元测试计划时遵循下面原则
编码前就写单元测试
保留单元测试的注释
对任何有趣的公共方法都要做单元测试（有趣的是指除了像最常见的getter/setter这类方法外的方法但包含有自己内容的getter/setter 方法）
注意图形用户界面（Pay attention to the GUI） – 无论听上去多荒谬但有一点我注意过多次了图形用户界面（GUI）对于商业用户而言与程序功能及执行效率一样重要GUI对于应用程序的成功至关重要IT管理者（译注这里应该是指程序开发方的IT management）常常忽略GUI的重要性很多公司为了省钱而不雇佣web设计人员而这些设计人员有足够的经验来设计用户友好的应用软件Java程序员不得不依赖他们有限的HMTL知识我见过非常多对计算机友好而非对用户友好的应用程序同时精通软件开发和用户界面开发的开发者非常少见
记住质量而非数量（Remember – quality not quantity） 不要待的太晚（除非有必要）我知道有时因为产品问题截止期限或其他突发事件不能按时下班但经理不会因为你为一般问题待的太晚而感激或奖励你他们会为有质量的工作而感激你如果你遵循上面的列的原则你就会写更健壮的少bug的程序这才是你最应该做的
提前准备需求文档（Always Prepare Document Requirements） – 每项业务需求都记入文档这在童话故事中可能实现而现实中很难做到无论时间多么紧迫无论截止日期如何迫近你必须确保业务需求被记录下来
