[b]10 Commandments for Java Developers[/b]
翻译在后面
首先感谢下原著和辛勤的译者
[url=http://article.yeeyan.org/compare/92681/55697]转自http://article.yeeyan.org/compare/92681/55697[/url],
[url=http://space.yeeyan.org/u/92681]原译者的blog [/url]
There are many standards and best practices for Java Developers out there. This article outlines ten most basic rules that every developer must adhere to and the disastrous outcomes that can follow if these rules are not followed.
1. Add comments to your code. – Everybody knows this, but somehow forgets to follow it. How many times have you "forgotten" to add comments? It is true that the comments do not literally contribute to the functionality of a program. But time and time again you return to the code that you wrote two weeks ago and, for the life of you, you cannot remember what it does! You are lucky if this uncommented code is actually yours. In those cases something may spark your memory. Unfortunately most of the time it is somebody else's, and many times the person is no longer with the company! There is a saying that goes "one hand washes the other." So let's be considerate to one another (and ourselves) and add comments to your code.
2. Do not complicate things. – I have done it before and I am sure all of you have. Developers tend to come up with complicated solutions for the simplest problems. We introduce EJBs into applications that have five users. We implement frameworks that an application just does not need. We add property files, object-oriented solutions, and threads to application that do not require such things. Why do we do it? Some of us just do not know any better, but some of us do it on purpose to learn something new, to make it interesting for ourselves. For those who do not know any better, I recommend reaching out to the more experienced programmers for advice. And to those of us that are willing to complicate the design of an application for personal gains, I suggest being more professional.
3. Keep in Mind – "Less is more" is not always better. – Code efficiency is a great thing, but in many situations writing less lines of code does not improve the efficiency of that code. Let me give you a "simple" example:
if(newStatusCode.equals("SD") && (sellOffDate == null ||
todayDate.compareTo(sellOffDate)<0 || (lastUsedDate != null &&
todayDate.compareTo(lastUsedDate)>0)) ||
(newStatusCode.equals("OBS") && (OBSDate == null ||
todayDate.compareTo(OBSDate)<0))){
newStatusCode = "NYP";
}
How easy is it to figure out what this "if" condition is doing? Now imagine that whoever wrote this code, did not follow rule number 1 – Add comments to your code.
Wouldn't it be much easier if we could separate this condition into two separate if statements? Now, consider this revised code:
if(newStatusCode.equals("SD") && (sellOffDate == null ||
todayDate.compareTo(sellOffDate)<0 || (lastUsedDate != null &&
todayDate.compareTo(lastUsedDate)>0))){
newStatusCode = "NYP";
}else
if(newStatusCode.equals("OBS") && (OBSDate == null ||
todayDate.compareTo(OBSDate)<0))
{
newStatusCode = "NYP";
}
Isn't it much more readable? Yes, we have repeating statements. Yes, we have one extra "IF" and two extra curly braces, but the code is much more readable and understandable!
4. No hard coding please. – Developers often forget or omit this rule on purpose because we are, as usual, crunched for time. But maybe if we had followed this rule, we would not have ended up in the situation that we are in. How long does it take to write one extra line of code that defines a static final variable?
Here is an example:
public class A {
public static final String S_CONSTANT_ABC = "ABC";
public boolean methodA(String sParam1){
if (A.S_CONSTANT_ABC.equalsIgnoreCase(sParam1)){
return true;
}
return false;
}
}
Now every time we need to compare literal "ABC" with some variable, we can reference A.S_CONSTANT_ABC instead of remembering what the actual code is. It is also much easier to modify this constant in one place rather then looking for it though out all of the code.
5. Do not invent your own frameworks. – There are literally thousands of frameworks out there and most of them are open-source. Many of these frameworks are superb solutions that have been used in thousands of applications. We need to keep up to date with the new frameworks, at least superficially. One of the best and most obvious examples of a superb widely used framework is Struts. This open source web framework is a perfect candidate to be used in web-based applications. Please do not come up with your own version of Struts, you will die trying. But you must remember rule number 3 – Do not complicate things. If the application that you are developing has 3 screens – please, do not use Struts, there isn't much "controlling" required for such an application.
6. Say no to Print lines and String Concatenations. – I know that for debugging purposes, developers like to add System.out.println everywhere we see fit. And we say to ourselves that we will delete these later. But we often forget to delete these lines of code or we do not want to delete them. We useSystem.out.println to test, why would we be touching the code after we have tested it? We might remove a line of code that we actually need! Just so that you do not underestimate the damage of System.out.println, consider the following code:
public class BadCode {
public static void calculationWithPrint(){
double someValue = 0D;
for (int i = 0; i < 10000; i++) {
System.out.println(someValue = someValue + i);
}
}
public static void calculationWithOutPrint(){
double someValue = 0D;
for (int i = 0; i < 10000; i++) {
someValue = someValue + i;
}
}
public static void main(String [] n) {
BadCode.calculationWithPrint();
BadCode.calculationWithOutPrint();
}
}
In the figure below, you can observe that method calculationWithOutPrint() takes 0.001204 seconds to run. In comparison, it takes a staggering 10.52 seconds to run the calculationWithPrint() method.
[img]http://dl.iteye.com/upload/attachment/396539/02d39508-13c6-3106-8a29-84da4f0d6c2c.jpg[/img]
(If you would like to know how to produce a table like this, please read my article entitled "Java Profiling with WSAD" [url=http://www.developer.com/java/ent/article.php/3598166]Java Profiling with WSAD [/url])
The best way to avoid such CPU waste is to introduce a wrapper method that looks something like this:
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());
}
}
In the following figure you can see that the method that uses StringBuffer takes .01 seconds to execute where as the methods that use string concatenation takes .08 seconds to execute. The choice is obvious.
[img]http://dl.iteye.com/upload/attachment/396541/71820d35-d6f6-326d-973c-42c47c6d1fa4.jpg[/img]
7. Pay attention to the GUI. – No matter how absurd it sounds; I repeatedly observe that GUI is as important to the business clients as functionality and performance. The GUI is an essential part of a successful application. Very often IT management tends to overlook the importance of GUI. Many organizations save money by not hiring web designers who have experience in design of "user-friendly" applications. Java developers have to rely on their own HTML skills and their limited knowledge in this area. I have seen too many applications that are "computer friendly" rather then "user friendly". Very rarely I have seen developers that are proficient in both software development and GUI development. If you are this unlucky Java developer who has been assigned to create an application interface, you should follow these three rules:
1.Do not reinvent the wheel. Look for existing applications that have similar interface requirements.
2.Create a prototype first. This is a very important step. The clients like to see what they are going to get. It is better for you also because you are going to get their input before you go all out and create an application interface that will leave the clients cold.
3.Put the user's hat on. In other words, inspect the application requirements from the user's perspective. For example, a summary screen can be created with paging and without. As a software developer, it might be temping for you to omit paging from the application because it is so much less complicated. But, from the client's perspective, it might not be the best solution because the summary results can hold hundreds of rows of data.
8. Always Prepare Document Requirements. – Every business requirement must be documented. This could be true in some fairy tale, but it is far from that in the real world. No matter how time-pressed your development is, no matter how tight the deadlines, you must always make sure that every business requirement is documented.
9. Unit-test. Unit-test. Unit-test. – I am not going to go into any details as to what is the best way to unit-test your code. I am just going to say that that it must be done. This is the most basic rule of programming. This is one rule that, above all, cannot be omitted. It would be great if your fellow developer could create and execute a test plan for your code, but if that is not possible, you must do it yourself. When creating a unit test plan, follow these basic rules:
1.Write the unit test before writing code for class it tests.
2.Capture code comments in unit tests.
3.Test all the public methods that perform an "interesting" function (that is, not getters and setters, unless they do their getting and setting in some unique way).
10. Remember – quality, not quantity. - Do not stay late (when you do not have to). I understand that sometimes production problems, urgent deadlines, and unexpected events might prevent us from leaving work on time. But, managers do not appreciate and reward their employees because they stay late on regular basis, they appreciate them because they do quality work. If you follow the rules that I outline above, you will find yourself producing less buggy and more maintainable code. That is the most important part of your job.
Conclusion
In this article I covered ten critical rules for Java Programmers. It is not merely important to know these rules, it is also important to follow them. Hopefully, these rules will help all of us become better programmers and professionals.
Java程序员有许多应遵循的守则或最佳实践方式。本文概述了每个开发者最应该遵循的10条守则或戒律，如果不遵循它们，将会导致灾难性后果。
1. 为代码添加注释（Add comments to your code）. – 每个人都知道这一点，但不是每个人都会这么做。你有多少次“忘记”添加注释了？确实，注释不会为你的程序增加任何函数功能。但是，有多少次，看到2周前写的代码，你都记不起它是干什么的？你很幸运，那些未注释的代码是你自己写的，你脑海中还会有残存的印象。非常不幸，大多时候，代码是别人写的，并且那个人很可能已经离开公司了。有句谚语说的好：“有来有往，互惠互利”，因此程序员应该体谅彼此（还有你自己），给你的代码加上注释。
2. 不要把简单事情复杂化（Do not complicate things）. – 我曾经这么做过，我相信你也一样。开发者都倾向于采用复杂方式解决简单问题。我们在一个只有5个用户的系统中引入EJB，为一个并不需要框架的应用实现一套框架，采用属性文件、采用面向对象解决方案、使用线程，而这些根本用不着。为什么会这么做？一些人可能不知道有更好的解决方案，但另一些人可能故意这样做来学习新知识，或仅仅是因为有趣。对那些不知道更好解决方案的人，要多听有经验程序员的建议。对于那些纯粹出于个人目的而将设计复杂化的人，我建议你要更加专业一点。
3. 记住 － “越少越好”并非总是如此(Keep in Mind – "Less is more" is not always better). – 高效率的代码是件好事，但很多情况下，并非代码行数越少效率就越高。看下面这个“简单”的例子：
if(newStatusCode.equals("SD") && (sellOffDate == null ||
todayDate.compareTo(sellOffDate)<0 || (lastUsedDate != null &&
todayDate.compareTo(lastUsedDate)>0)) ||
(newStatusCode.equals("OBS") && (OBSDate == null ||
todayDate.compareTo(OBSDate)<0))){
newStatusCode = "NYP";
}
指出这个if条件是什么有多困难？再设想一下，写这段代码的人并没遵循第1条 － 为代码添加注释。
把if条件分解成2个if语句不是更容易理解吗？现在让我们看一下修改过的代码：
if(newStatusCode.equals("SD") && (sellOffDate == null ||
todayDate.compareTo(sellOffDate)<0 || (lastUsedDate != null &&
todayDate.compareTo(lastUsedDate)>0))){
newStatusCode = "NYP";
}else
if(newStatusCode.equals("OBS") && (OBSDate == null ||
todayDate.compareTo(OBSDate)<0))
{
newStatusCode = "NYP";
}
这样可读性不是更好吗？的确，我们写了重复语句；的确，我们多写了一个if和2个大括号；但是代码确实更加易读、更加容易理解了！
4. 不要“硬编码"（No hard coding please）. – 由于时间紧迫，开发者总是会忘记或故意忽略这一条。然而另一种可能是，遵循这条戒律，我们就不会陷入“时间紧迫”的困境。定义一个static final 变量，增加一行代码，又能花多长时间呢？譬如：
public class A {
public static final String S_CONSTANT_ABC = "ABC";
public boolean methodA(String sParam1){
if (A.S_CONSTANT_ABC.equalsIgnoreCase(sParam1)){
return true;
}
return false;
}
}
现在，每次需要比较字符串“ABC”与某个变量的时候，我们只要引
用 A.S_CONSTANT_ABC 即可，而不必记住它本身是什么。对这个常量的修改也非常方便，改一个地方即可，而不必在全部代码中查找。
5. 不要发明你自己的框架（Do not invent your own frameworks）. – 不夸张地讲，已经有几千个框架存在了，大多数还是开源的。很多框架都是极完美的解决方案，并已被用到成千的系统中。我们只要关注最新的流行的框架，至少表面上要熟悉一下。一个最成功的、也是被广泛使用的例子是Struts框架，这个开源的web框架是建立web系统的极佳选择，不要试图构造你自己的Struts版本，会累死的。但你必须记住第2条（译注：原文是“第3条”，显然不对）戒律 —— 不要把简单事情复杂化。如果你要开发的系统只有3个界面，就不要用Struts. 对于这样一个系统，没有足够的需要被“控制”的东西（译注：Struts将界面做MVC划分，C即controller，所以作者说there isn't much "controlling" required）。
6. 对Print行或字符串说不（Say no to Print lines and String Concatenations）. – 我知道为了调试方便，程序员喜欢到处用System.out.println ,然后对自己说过一会就删掉。但我们常常忘记删掉这些行或不愿删掉，我们用System.out.println 做测试，为什么测完后还要去改代码？这很可能导致误删一行我们需要的代码。不要低估System.out.println 的危害，看下面代码：
public class BadCode {
public static void calculationWithPrint(){
double someValue = 0D;
for (int i = 0; i < 10000; i++) {
System.out.println(someValue = someValue + i);
}
}
public static void calculationWithOutPrint(){
double someValue = 0D;
for (int i = 0; i < 10000; i++) {
someValue = someValue + i;
}
}
public static void main(String [] n) {
BadCode.calculationWithPrint();
BadCode.calculationWithOutPrint();
}
}
下面表格可以看出，calculationWithOutPrint() 方法执行时间是0.001204 s. 作为对比，calculationWithPrint() 方法居然需要令人难以置信的10.52 s来执行！
[img]http://dl.iteye.com/upload/attachment/396539/02d39508-13c6-3106-8a29-84da4f0d6c2c.jpg[/img]
(若你想知道怎么做一个这样的表，请阅读我的另一篇文章"Java Profiling with WSAD" [url=http://www.developer.com/java/ent/article.php/3598166]Java Profiling with WSAD [/url])
为了避免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)连接是另一种CPU浪费方式，看下面的例子：
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只要花 0.01 s 而使用String 连接需要0.08 s，选择哪种应该很明显了。
[img]http://dl.iteye.com/upload/attachment/396541/71820d35-d6f6-326d-973c-42c47c6d1fa4.jpg[/img]
7. 注意图形用户界面（Pay attention to the GUI）. – 无论听上去多荒谬，但有一点我注意过多次了：图形用户界面（GUI）对于商业用户而言与程序功能及执行效率一样重要。GUI对于应用程序的成功至关重要。 IT管理者（译注：这里应该是指程序开发方的IT management）常常忽略GUI的重要性，很多公司为了省钱而不雇佣web设计人员，而这些设计人员有足够的经验来设计“用户友好”的应用软件。Java程序员不得不依赖他们有限的HMTL知识。我见过非常多对“计算机友好”而非对“用户友好”的应用程序，同时精通软件开发和用户界面开发的开发者非常少见。 如果你是一位不幸被指派做界面开发的Java程序员，你要遵循下面3条规则：
[size=xx-small]1[/size].不要重新发明轮子。去看那些类似应用系统的界面。
[size=xx-small]2[/size].首先建立一个原型。这一步非常关键。客户喜欢提前看到他们要用的东西。同样你可以得到他们的反馈，而不是你辛辛苦苦做出来一个客户不喜欢的东西。
[size=xx-small]3[/size].试戴用户的帽子。换句话说，站在用户的角度查看需求。譬如，一个统计的界面可以分页，也可以不分页。作为开发者，很可能会忽略分页，因为这会减少很多麻烦；而站在客户角度，这就不是一个好的方案，因为数据可能多达几百行。
8. 提前准备需求文档（Always Prepare Document Requirements）. – 每项业务需求都记入文档。这在童话故事中可能实现，而现实中很难做到。无论时间多么紧迫，无论截止日期如何迫近，你必须确保业务需求被记录下来。（译注：这条明显悖于敏捷开发的观念，大家要独立思考，甄别是非）
9. 单元测试，单元测试，单元测试 （Unit-test. Unit-test. Unit-test）. – 我不准备讨论如何单元测试的细节，我只是想说这必须要做。这是编程中最基本的规则了，尤其不能忽略。如果你同事能为你的代码创建一个测试计划，那就再好不过了；如果不能，那就要自己做。做单元测试计划时，遵循下面原则：
1.编码前就写单元测试
2.保留单元测试的注释
3.对任何“有趣的”公共方法都要做单元测试（“有趣的”是指除了像最常见的getter/setter这类方法外的方法，但包含有自己内容的getter/setter 方法）
10. 记住：质量，而非数量（Remember – quality, not quantity）. - 不要待的太晚（除非有必要）。我知道有时因为产品问题，截止期限或其他突发事件，不能按时下班。但经理不会因为你为一般问题待的太晚而感激或奖励你；他们会为有质量的工作而感激你。如果你遵循上面的列的原则，你就会写更健壮的、少bug的程序。这才是你最应该做的。
结论
本文中我总结了Java程序员最应注意的10项守则。仅仅知道是不够的，还要遵循它们。希望这些守则能让我们做更加专业的程序员。
翻译在后面
首先感谢下原著和辛勤的译者
[url=http://article.yeeyan.org/compare/92681/55697]转自http://article.yeeyan.org/compare/92681/55697[/url],
[url=http://space.yeeyan.org/u/92681]原译者的blog [/url]
There are many standards and best practices for Java Developers out there. This article outlines ten most basic rules that every developer must adhere to and the disastrous outcomes that can follow if these rules are not followed.
1. Add comments to your code. – Everybody knows this, but somehow forgets to follow it. How many times have you "forgotten" to add comments? It is true that the comments do not literally contribute to the functionality of a program. But time and time again you return to the code that you wrote two weeks ago and, for the life of you, you cannot remember what it does! You are lucky if this uncommented code is actually yours. In those cases something may spark your memory. Unfortunately most of the time it is somebody else's, and many times the person is no longer with the company! There is a saying that goes "one hand washes the other." So let's be considerate to one another (and ourselves) and add comments to your code.
2. Do not complicate things. – I have done it before and I am sure all of you have. Developers tend to come up with complicated solutions for the simplest problems. We introduce EJBs into applications that have five users. We implement frameworks that an application just does not need. We add property files, object-oriented solutions, and threads to application that do not require such things. Why do we do it? Some of us just do not know any better, but some of us do it on purpose to learn something new, to make it interesting for ourselves. For those who do not know any better, I recommend reaching out to the more experienced programmers for advice. And to those of us that are willing to complicate the design of an application for personal gains, I suggest being more professional.
3. Keep in Mind – "Less is more" is not always better. – Code efficiency is a great thing, but in many situations writing less lines of code does not improve the efficiency of that code. Let me give you a "simple" example:
if(newStatusCode.equals("SD") && (sellOffDate == null ||
todayDate.compareTo(sellOffDate)<0 || (lastUsedDate != null &&
todayDate.compareTo(lastUsedDate)>0)) ||
(newStatusCode.equals("OBS") && (OBSDate == null ||
todayDate.compareTo(OBSDate)<0))){
newStatusCode = "NYP";
}
How easy is it to figure out what this "if" condition is doing? Now imagine that whoever wrote this code, did not follow rule number 1 – Add comments to your code.
Wouldn't it be much easier if we could separate this condition into two separate if statements? Now, consider this revised code:
if(newStatusCode.equals("SD") && (sellOffDate == null ||
todayDate.compareTo(sellOffDate)<0 || (lastUsedDate != null &&
todayDate.compareTo(lastUsedDate)>0))){
newStatusCode = "NYP";
}else
if(newStatusCode.equals("OBS") && (OBSDate == null ||
todayDate.compareTo(OBSDate)<0))
{
newStatusCode = "NYP";
}
Isn't it much more readable? Yes, we have repeating statements. Yes, we have one extra "IF" and two extra curly braces, but the code is much more readable and understandable!
4. No hard coding please. – Developers often forget or omit this rule on purpose because we are, as usual, crunched for time. But maybe if we had followed this rule, we would not have ended up in the situation that we are in. How long does it take to write one extra line of code that defines a static final variable?
Here is an example:
public class A {
public static final String S_CONSTANT_ABC = "ABC";
public boolean methodA(String sParam1){
if (A.S_CONSTANT_ABC.equalsIgnoreCase(sParam1)){
return true;
}
return false;
}
}
Now every time we need to compare literal "ABC" with some variable, we can reference A.S_CONSTANT_ABC instead of remembering what the actual code is. It is also much easier to modify this constant in one place rather then looking for it though out all of the code.
5. Do not invent your own frameworks. – There are literally thousands of frameworks out there and most of them are open-source. Many of these frameworks are superb solutions that have been used in thousands of applications. We need to keep up to date with the new frameworks, at least superficially. One of the best and most obvious examples of a superb widely used framework is Struts. This open source web framework is a perfect candidate to be used in web-based applications. Please do not come up with your own version of Struts, you will die trying. But you must remember rule number 3 – Do not complicate things. If the application that you are developing has 3 screens – please, do not use Struts, there isn't much "controlling" required for such an application.
6. Say no to Print lines and String Concatenations. – I know that for debugging purposes, developers like to add System.out.println everywhere we see fit. And we say to ourselves that we will delete these later. But we often forget to delete these lines of code or we do not want to delete them. We useSystem.out.println to test, why would we be touching the code after we have tested it? We might remove a line of code that we actually need! Just so that you do not underestimate the damage of System.out.println, consider the following code:
public class BadCode {
public static void calculationWithPrint(){
double someValue = 0D;
for (int i = 0; i < 10000; i++) {
System.out.println(someValue = someValue + i);
}
}
public static void calculationWithOutPrint(){
double someValue = 0D;
for (int i = 0; i < 10000; i++) {
someValue = someValue + i;
}
}
public static void main(String [] n) {
BadCode.calculationWithPrint();
BadCode.calculationWithOutPrint();
}
}
In the figure below, you can observe that method calculationWithOutPrint() takes 0.001204 seconds to run. In comparison, it takes a staggering 10.52 seconds to run the calculationWithPrint() method.
[img]http://dl.iteye.com/upload/attachment/396539/02d39508-13c6-3106-8a29-84da4f0d6c2c.jpg[/img]
(If you would like to know how to produce a table like this, please read my article entitled "Java Profiling with WSAD" [url=http://www.developer.com/java/ent/article.php/3598166]Java Profiling with WSAD [/url])
The best way to avoid such CPU waste is to introduce a wrapper method that looks something like this:
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());
}
}
In the following figure you can see that the method that uses StringBuffer takes .01 seconds to execute where as the methods that use string concatenation takes .08 seconds to execute. The choice is obvious.
[img]http://dl.iteye.com/upload/attachment/396541/71820d35-d6f6-326d-973c-42c47c6d1fa4.jpg[/img]
7. Pay attention to the GUI. – No matter how absurd it sounds; I repeatedly observe that GUI is as important to the business clients as functionality and performance. The GUI is an essential part of a successful application. Very often IT management tends to overlook the importance of GUI. Many organizations save money by not hiring web designers who have experience in design of "user-friendly" applications. Java developers have to rely on their own HTML skills and their limited knowledge in this area. I have seen too many applications that are "computer friendly" rather then "user friendly". Very rarely I have seen developers that are proficient in both software development and GUI development. If you are this unlucky Java developer who has been assigned to create an application interface, you should follow these three rules:
1.Do not reinvent the wheel. Look for existing applications that have similar interface requirements.
2.Create a prototype first. This is a very important step. The clients like to see what they are going to get. It is better for you also because you are going to get their input before you go all out and create an application interface that will leave the clients cold.
3.Put the user's hat on. In other words, inspect the application requirements from the user's perspective. For example, a summary screen can be created with paging and without. As a software developer, it might be temping for you to omit paging from the application because it is so much less complicated. But, from the client's perspective, it might not be the best solution because the summary results can hold hundreds of rows of data.
8. Always Prepare Document Requirements. – Every business requirement must be documented. This could be true in some fairy tale, but it is far from that in the real world. No matter how time-pressed your development is, no matter how tight the deadlines, you must always make sure that every business requirement is documented.
9. Unit-test. Unit-test. Unit-test. – I am not going to go into any details as to what is the best way to unit-test your code. I am just going to say that that it must be done. This is the most basic rule of programming. This is one rule that, above all, cannot be omitted. It would be great if your fellow developer could create and execute a test plan for your code, but if that is not possible, you must do it yourself. When creating a unit test plan, follow these basic rules:
1.Write the unit test before writing code for class it tests.
2.Capture code comments in unit tests.
3.Test all the public methods that perform an "interesting" function (that is, not getters and setters, unless they do their getting and setting in some unique way).
10. Remember – quality, not quantity. - Do not stay late (when you do not have to). I understand that sometimes production problems, urgent deadlines, and unexpected events might prevent us from leaving work on time. But, managers do not appreciate and reward their employees because they stay late on regular basis, they appreciate them because they do quality work. If you follow the rules that I outline above, you will find yourself producing less buggy and more maintainable code. That is the most important part of your job.
Conclusion
In this article I covered ten critical rules for Java Programmers. It is not merely important to know these rules, it is also important to follow them. Hopefully, these rules will help all of us become better programmers and professionals.
Java程序员有许多应遵循的守则或最佳实践方式。本文概述了每个开发者最应该遵循的10条守则或戒律，如果不遵循它们，将会导致灾难性后果。
1. 为代码添加注释（Add comments to your code）. – 每个人都知道这一点，但不是每个人都会这么做。你有多少次“忘记”添加注释了？确实，注释不会为你的程序增加任何函数功能。但是，有多少次，看到2周前写的代码，你都记不起它是干什么的？你很幸运，那些未注释的代码是你自己写的，你脑海中还会有残存的印象。非常不幸，大多时候，代码是别人写的，并且那个人很可能已经离开公司了。有句谚语说的好：“有来有往，互惠互利”，因此程序员应该体谅彼此（还有你自己），给你的代码加上注释。
2. 不要把简单事情复杂化（Do not complicate things）. – 我曾经这么做过，我相信你也一样。开发者都倾向于采用复杂方式解决简单问题。我们在一个只有5个用户的系统中引入EJB，为一个并不需要框架的应用实现一套框架，采用属性文件、采用面向对象解决方案、使用线程，而这些根本用不着。为什么会这么做？一些人可能不知道有更好的解决方案，但另一些人可能故意这样做来学习新知识，或仅仅是因为有趣。对那些不知道更好解决方案的人，要多听有经验程序员的建议。对于那些纯粹出于个人目的而将设计复杂化的人，我建议你要更加专业一点。
3. 记住 － “越少越好”并非总是如此(Keep in Mind – "Less is more" is not always better). – 高效率的代码是件好事，但很多情况下，并非代码行数越少效率就越高。看下面这个“简单”的例子：
if(newStatusCode.equals("SD") && (sellOffDate == null ||
todayDate.compareTo(sellOffDate)<0 || (lastUsedDate != null &&
todayDate.compareTo(lastUsedDate)>0)) ||
(newStatusCode.equals("OBS") && (OBSDate == null ||
todayDate.compareTo(OBSDate)<0))){
newStatusCode = "NYP";
}
指出这个if条件是什么有多困难？再设想一下，写这段代码的人并没遵循第1条 － 为代码添加注释。
把if条件分解成2个if语句不是更容易理解吗？现在让我们看一下修改过的代码：
if(newStatusCode.equals("SD") && (sellOffDate == null ||
todayDate.compareTo(sellOffDate)<0 || (lastUsedDate != null &&
todayDate.compareTo(lastUsedDate)>0))){
newStatusCode = "NYP";
}else
if(newStatusCode.equals("OBS") && (OBSDate == null ||
todayDate.compareTo(OBSDate)<0))
{
newStatusCode = "NYP";
}
这样可读性不是更好吗？的确，我们写了重复语句；的确，我们多写了一个if和2个大括号；但是代码确实更加易读、更加容易理解了！
4. 不要“硬编码"（No hard coding please）. – 由于时间紧迫，开发者总是会忘记或故意忽略这一条。然而另一种可能是，遵循这条戒律，我们就不会陷入“时间紧迫”的困境。定义一个static final 变量，增加一行代码，又能花多长时间呢？譬如：
public class A {
public static final String S_CONSTANT_ABC = "ABC";
public boolean methodA(String sParam1){
if (A.S_CONSTANT_ABC.equalsIgnoreCase(sParam1)){
return true;
}
return false;
}
}
现在，每次需要比较字符串“ABC”与某个变量的时候，我们只要引
用 A.S_CONSTANT_ABC 即可，而不必记住它本身是什么。对这个常量的修改也非常方便，改一个地方即可，而不必在全部代码中查找。
5. 不要发明你自己的框架（Do not invent your own frameworks）. – 不夸张地讲，已经有几千个框架存在了，大多数还是开源的。很多框架都是极完美的解决方案，并已被用到成千的系统中。我们只要关注最新的流行的框架，至少表面上要熟悉一下。一个最成功的、也是被广泛使用的例子是Struts框架，这个开源的web框架是建立web系统的极佳选择，不要试图构造你自己的Struts版本，会累死的。但你必须记住第2条（译注：原文是“第3条”，显然不对）戒律 —— 不要把简单事情复杂化。如果你要开发的系统只有3个界面，就不要用Struts. 对于这样一个系统，没有足够的需要被“控制”的东西（译注：Struts将界面做MVC划分，C即controller，所以作者说there isn't much "controlling" required）。
6. 对Print行或字符串说不（Say no to Print lines and String Concatenations）. – 我知道为了调试方便，程序员喜欢到处用System.out.println ,然后对自己说过一会就删掉。但我们常常忘记删掉这些行或不愿删掉，我们用System.out.println 做测试，为什么测完后还要去改代码？这很可能导致误删一行我们需要的代码。不要低估System.out.println 的危害，看下面代码：
public class BadCode {
public static void calculationWithPrint(){
double someValue = 0D;
for (int i = 0; i < 10000; i++) {
System.out.println(someValue = someValue + i);
}
}
public static void calculationWithOutPrint(){
double someValue = 0D;
for (int i = 0; i < 10000; i++) {
someValue = someValue + i;
}
}
public static void main(String [] n) {
BadCode.calculationWithPrint();
BadCode.calculationWithOutPrint();
}
}
下面表格可以看出，calculationWithOutPrint() 方法执行时间是0.001204 s. 作为对比，calculationWithPrint() 方法居然需要令人难以置信的10.52 s来执行！
[img]http://dl.iteye.com/upload/attachment/396539/02d39508-13c6-3106-8a29-84da4f0d6c2c.jpg[/img]
(若你想知道怎么做一个这样的表，请阅读我的另一篇文章"Java Profiling with WSAD" [url=http://www.developer.com/java/ent/article.php/3598166]Java Profiling with WSAD [/url])
为了避免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)连接是另一种CPU浪费方式，看下面的例子：
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只要花 0.01 s 而使用String 连接需要0.08 s，选择哪种应该很明显了。
[img]http://dl.iteye.com/upload/attachment/396541/71820d35-d6f6-326d-973c-42c47c6d1fa4.jpg[/img]
7. 注意图形用户界面（Pay attention to the GUI）. – 无论听上去多荒谬，但有一点我注意过多次了：图形用户界面（GUI）对于商业用户而言与程序功能及执行效率一样重要。GUI对于应用程序的成功至关重要。 IT管理者（译注：这里应该是指程序开发方的IT management）常常忽略GUI的重要性，很多公司为了省钱而不雇佣web设计人员，而这些设计人员有足够的经验来设计“用户友好”的应用软件。Java程序员不得不依赖他们有限的HMTL知识。我见过非常多对“计算机友好”而非对“用户友好”的应用程序，同时精通软件开发和用户界面开发的开发者非常少见。 如果你是一位不幸被指派做界面开发的Java程序员，你要遵循下面3条规则：
[size=xx-small]1[/size].不要重新发明轮子。去看那些类似应用系统的界面。
[size=xx-small]2[/size].首先建立一个原型。这一步非常关键。客户喜欢提前看到他们要用的东西。同样你可以得到他们的反馈，而不是你辛辛苦苦做出来一个客户不喜欢的东西。
[size=xx-small]3[/size].试戴用户的帽子。换句话说，站在用户的角度查看需求。譬如，一个统计的界面可以分页，也可以不分页。作为开发者，很可能会忽略分页，因为这会减少很多麻烦；而站在客户角度，这就不是一个好的方案，因为数据可能多达几百行。
8. 提前准备需求文档（Always Prepare Document Requirements）. – 每项业务需求都记入文档。这在童话故事中可能实现，而现实中很难做到。无论时间多么紧迫，无论截止日期如何迫近，你必须确保业务需求被记录下来。（译注：这条明显悖于敏捷开发的观念，大家要独立思考，甄别是非）
9. 单元测试，单元测试，单元测试 （Unit-test. Unit-test. Unit-test）. – 我不准备讨论如何单元测试的细节，我只是想说这必须要做。这是编程中最基本的规则了，尤其不能忽略。如果你同事能为你的代码创建一个测试计划，那就再好不过了；如果不能，那就要自己做。做单元测试计划时，遵循下面原则：
1.编码前就写单元测试
2.保留单元测试的注释
3.对任何“有趣的”公共方法都要做单元测试（“有趣的”是指除了像最常见的getter/setter这类方法外的方法，但包含有自己内容的getter/setter 方法）
10. 记住：质量，而非数量（Remember – quality, not quantity）. - 不要待的太晚（除非有必要）。我知道有时因为产品问题，截止期限或其他突发事件，不能按时下班。但经理不会因为你为一般问题待的太晚而感激或奖励你；他们会为有质量的工作而感激你。如果你遵循上面的列的原则，你就会写更健壮的、少bug的程序。这才是你最应该做的。
结论
本文中我总结了Java程序员最应注意的10项守则。仅仅知道是不够的，还要遵循它们。希望这些守则能让我们做更加专业的程序员。
扫一扫
2387
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
