1.给你的代码加注解—每个人都知道这一点，但是总会有人忘记遵守。你有多少次“忘记”加注解了?的却不加文字注解有助于程序的功能性。但是一次又一你返回两星期前写的代码，结果你想不起来那是什么了!如果这个未注解的代码确实是你写的那你就是幸运的了。因为在那些代码中可以唤起你的记忆。不幸的是，大多数的时候代码是别人写的，而且他已将离开了公司!有句谚语是这样说的“自己的事情自己做”。所以为了别人或是我们自己考虑，在你的代码上加上注解吧。
2.别把事情复杂化— 我以前就是这么做的而其我相信你们也一样。开发者喜欢把简单的问题用很复杂的方法来解决。我们介绍EJBs到有五个用户的应用程序中。我们完成一个框架结构那是应用程序所不需要的。我们添加属性文件，目标源方案到本不需要这些东西的应用程序中。为什么我们要这样做呢?一些人是不知道如何去做，而一些人故意这么做是想去学习新的东西，想让我们感兴趣。对于那些不知道如何去做的人，我建议去向经验丰富的编程人员去询问。而对于那些喜欢把应用程序设计搞复杂的人，我的建议还是要更专业一些来处理问题。
3.记住—“少即是多”不见得是件好事。—代码效率是件非常好的事情，但是很多情况下少写几行代码并不能提高代码工作的效率。举个简单的例子：
if(newStatusCode.equals("SD") && (sellOffDate == null || |
查出“if”条件下在做什么是多么简单的事情?现在想象一下写这个代码的人，没有遵守第一个规则-给代码加注解 。如果我们把这个情况分成两个独立的if语句岂不是更简单一些么?现在看一下修改后的代码：
if(newStatusCode.equals("SD") && (sellOffDate == null || |
是不是更清晰了?是的，我们在重复一下。我们有另一个“IF” 和两个额外的括号，但是这个代码更容易读懂了!
4.不要有难懂的代码—开发者经常忘记这一点或是忽略故意忽略这条规则，因为通常我们都在赶时间。但是如果我们能遵守这个规则，我们就不会终止我们所处的形势了。要花多长时间去写入另外一行最后定义的静态变量代码呢?
举个例子：
public class A { |
现在每当我们需要文字“ABC”和一些变量作比较，我们可以参考A.S_CONSTANT_ABC而不是回忆实际的代码是什么。在一个地方不断的修改要比在所有代码中寻找要容易得多。
5.不要发明自己的框架结构—有数以千计的框架结构而其大多数都是开放源。许多框架结构是被用在数以千计的应用程序中的优秀的解决方案。至少在表面我们需要用上新的框架结构。其中最好的也是广发应用的框架结构的例子就是Struts。这个开放源web结果框架是一个非常好的候选者来用于web-based应用程序。请不要用自己版本的Strut,你将会在尝试中死去。但是你必须记住规则2—别把事情复杂化。如果你的应用程序要开发3个screen-请不要用Struts，目前还没有像这样的应用程序的“控制”需求。
6.要对打印线和字符串串联说“不”—我知道在以调试为目，开发者喜欢到处在我们觉得适合的地方添加System.out.println。又自言自语的说一会儿我们会删除这些的。但是我们总是忘记删除这些代码行或者不想去删除它们。我们用System.out.println来进行测试，为什么我们在测试完成后才触及这些代码呢?我们可能会删除一行代码当我们确实要这么做的时候!只要你不要低估System.out.println 的破坏，看以下的代码：
public class BadCode { |
在上面所显示的，你能观察到calculationWithOutPrint()用了0.001204秒运行。相比之下，用了惊人的10.52秒去运行calculationWithPrint() method。
(如果你想要知道如何制作这个的表格，请阅读我的文章题目是"Java Profiling with WSAD" Java Profiling with WSAD)
最好的像避免CPU浪费的方法是去引用像这样的包装方法：
public class BadCode {
public static final int DEBUG_MODE = 1;public static final int PRODUCTION_MODE = 2;
public static void calculationWithPrint(int logMode){
double someValue = 0D;
for (int i = 0; i < 10000; i++) {
someValue = someValue + i;
myPrintMethod(logMode, someValue);
}
}
public static void myPrintMethod(int logMode, double value) {
if (logMode > BadCode.DEBUG_MODE) { return; }
System.out.println(value);
}
public static void main(String [] n) {
BadCode.calculationWithPrint(BadCode.PRODUCTION_MODE);
}
}
String concatenation is another CPU waster. Consider example below:
public static void concatenateStrings(String startingString) {
for (int i = 0; i < 20; i++) {
startingString = startingString + startingString;
}
}
public static void concatenateStringsUsingStringBuffer(
String startingString) {
StringBuffer sb = new StringBuffer();
sb.append(startingString);
for (int i = 0; i < 20; i++) {
sb.append(sb.toString());}}
在以下的数据中能看到该方法用StringBuffer花了.01秒去执行而同时用字符串串联的方法用了.08秒去执行。选择是很明显的。
7.关注GUI—无论听起来有多么荒谬，我要一再指出的是GUI的功能和运行情况和商业客户是同等重要的。GUI是一个成功的应用程序的重要组成部分。IT管理总是忽略GUI的重要性。许多机构省钱的方式是不雇用设计“user-friendly”应用程序有经验的网络设计师。Java开发者不得不依赖于他们自己的HTML技术和在此领域的那点局限性知识。我见过太多的应用程序是 “computer friendly”而不是 “ user friendly”。很少看到有开发者在软件开发和GUI开发两者都同样精通的。如果你是那个不幸的被指定去创建一个应用程序界面的Java开发者，你可以遵循这三个规则：
1. 不要重新发明车轮。寻找现有的有类似接口需求的应用程序。
2. 先创建个雏形。这是非常重要的步骤。客户想要看到他们能得到些什么。这样对你来说是有意的，是因为在你全力以赴工作之前可以得到客户的要求并且可以创建一个应用程序界面，这样可以让客户冷静下来。
3. 带上用户的帽子。换句话说，就是需要从用户的角度来检查应用程序的需求。例如，一个总结性的screen可以用标页的方式来创建。作为一个软件开发人员，允许从应用程序中忽略标记很让人恼火，因为它确实有一点复杂。但是，从客户的角度来看，可能不是很好的解决方案，因为总结的结果可以容纳数百个数据行。
8. 时刻准备文件需求— 每一商业需求都要记录在案。这个在一些童话故事里是正确的，但是远离了现实世界。无论你的开发有多么的时间紧迫，无论你的最后期限要求的多么严格，你必须确保每个商业需求都是被记录在案的。
9.单元测试。单元测试，单元测试—我就不详细的说明什么是做你的代码单元测试的最好方法。我只是想说的是必须要这么做。这是编程中最基本的规则。这是一个首先就不能被忽视的规则。如果你的下一个开发人员可以创建并为你的代码执行测试计划，那是在是太棒了。但是如果不可能，那你必须自己来做。建立一个单元测试计划，遵循以下这些基本规则：
1. 在写代码之前为分类测试写一个单元测试计划。
2. 在单元测试中获取代码注解。
3. 执行一个“有趣的”功能测试所有的公开的方法(也就是说，没有获得者和设置者，除非他们用一些独特方法来进行他们的获取和设置。)
10. 记住—质量，不是数量—不要呆得太晚(如果你不需要这么做)。我理解有时候产品问题，紧迫的最后期限和不希望发生的一些事情会阻止我们不能按时离开工作岗位。但是，经理们是不会感谢和报答他们的员工因为他们总是呆得时间太长，他们感谢员工是因为他们做了高质量的工作。如果你遵循以上所提到的这些规则，你将会发现你产生很少的bug，获得更多的可维护的代码。这是你工作中最重要的部分。
【编辑推荐】
