副标题#e#
对Java开拓者来说，有很多的尺度和最佳实践。本文罗列了每一个开拓人员必需遵从的十大根基法例；假如有了可以遵从的法则而不遵从，那么将导致的是十分悲凉的了局。
1．在你的代码里插手注释
每小我私家都知道这点，但不知何以健忘了遵守。算一算有几多次你“健忘”了添加注释？这是事实：注释对措施在成果上没有实质的孝敬。可是，你需要一次又一次的回到你两个星期之前写的代码上来，大概一辈子都是这样，你必然记不住这些代码为什么会这样。假如这些代码是你的，你还较量的幸运。因为它有大概让你回想起。可是不幸的是，许多时间，这些代码是别人的，并且很有大概他已经分开了公司。
2．不要让工作巨大化
我以前就这么干过，并且我相信所有的人都这么干过。开拓人员经常为一个简朴的问题而提出一个办理方案。我们为仅仅只有5个用户的应用而引入EJBs。我们为一个应用利用框架而它基础不需要。我们插手属性文件，面向工具的办理方案，和线程到应用中，可是它基础不需要这些。为什么我们这样做？我们中的一些人是因为不知道怎么做更好，可是尚有一些人这样做的目标是为了进修新的常识，从而使得这个应用对付我们本身来说做得较量有趣。
3．牢紧记着——“少等于多（less is more）”并不永远是好的
代码的效率是一伟大的工作，可是在许多环境下，写更少的代码行并不能提高该代码的效率。请让我向你展示一个简朴的例子。
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条件想干什么容易吗？此刻，我们再来假设无论是谁写出这段代码，而没有遵从第一条法则——在你的代码里插手注释。
假如我们把这个条件分到两个独立的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”和两对多余的括弧。可是代码有了更好的可读性和可领略性。
4．请不要有硬代码
开拓人员经常有意识的健忘可能忽视这条法则，原因是我们，和一般时候一样，在赶时间。假如我们遵从这条法则，我们大概会赶不长进度。我们大概不能竣事我们的当前状态。可是写一条特另外界说静态常量的代码行又能耗费我们几多时间呢？
这里有一个例子。
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”的时候，我们只需要引用S_CONSTANT_ABC，而不是记着实际的代码是什么。它尚有一个长处是：越发容易在一个处所修改常量，而不是在所有的代码中寻找这个代码
不要发现你本身的frameworks
已经推出了几千种frameworks，并且它们中的大大都是开源的。这些frameworks中间有许多是极好的办理方案，被应用到成千上万的应用中。你们需要跟上这些新frameworks的步骤，最起码是浮浅的。在这些极好的、应用遍及的frameworks中间，一个最好的、最直接的例子是Struts。在你所能想象到的frameworks中，这个开源的web frameworks对付基于web的应用是一个完美的候选者。可是你必需记着第二条法则——不要让工作巨大化。假如你开拓的应用只有三个页面—请，不要利用Struts，对付这样一个应用，没有什么“节制”请求的。
#p#副标题#e#
6．不要打印行和字符串相加
我知道，为了调试的目标，开拓人员喜欢在每一个我们认为适合的处所添加System.out.println，并且我们会对我们本身说，会在今后删掉这些代码的。可是我们经常忘掉删去这些代码行，可能我们基础就不想删掉它们。我们利用System.out.println来测试，当我们测试完成今后，为什么我们还能打仗到它们呢？我们大概删掉一行我们实际需要的代码，仅仅是因为你低估了System.out.println所带来的伤害，思量下面的代码：
#p#分页标题#e#
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秒。对较量而言，运行calculationWithPrint()要领花了令人惊奇的10.52秒。
（假如你不知道怎么获得一个像这样的表格，请参阅我的文章“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);
}
}
按照测试，利用了StringBuffer的谁人要领只花了0.01秒来执行，而谁人利用了字符串相加的要领却花了0.08秒来运行。选择是显而易见的。
7．存眷GUI
不管这听起来有何等好笑，我都要再三地说明：GUI对付贸易客户来说和成果和机能一样重要。GUI是一个乐成的系统的须要的一部门。（可是），IT杂志经常倾向于忽视GUI的重要性。许多机构为了省钱而不招聘那些在设计“用户友好”GUI方面有富厚履历的设计人员。Java开拓人员不得不依赖他们本身的HTML常识，可是他们在这方面的常识十分有限。我看到过许多这样的应用：它们是“计较机友好”，而不是“用户友好”我很少很少能看到有开拓人员既能干软件开拓，又能干GUI开拓。假如你是谁人不幸的开拓人员，被分派去开拓用户接口，你应该遵从以下的三条原则：
一、不要反复发现轮子。寻找有相似用户接口需求的已经存在的系统。
二、首先建设一个原型。这长短常重要的步调。客户喜欢看看他们将要获得什么。这对你来说也是很好的，因为在你尽心尽力而做出一个将要利用户生气的用户接口之前，你就获得了它们的反馈。
三、戴用户的帽子。换一句话说，站在用户的视角查抄应用的需求。譬喻，一个总结页面到底要不要分页。作为一个软件开拓者，你倾向于在一个系统中忽视分页，因为这样使得你有较量少的开拓巨大性。可是，这对付从一个用户的视角来说却不是最好的办理方案，因为小结的数据将会有成百上千个数据行。
8．永远筹备文档化的需求
每一个业务需求都必需文档化。这大概在一些童话故事里才气成真，可是在现实世界却不行能。不管时间对付你的开拓来说是何等紧要，也不管交付日期顿时就要到来，你永远都必需清楚，每一个业务需求是文档化的。
9．单位测试、单位测试、单位测试
我将不会深入地接头哪些什么是把你的代码举办单位测试的最佳要领的细节问题。我将要说的是单位测试必需要做。这是编程的最根基的法例。这是上面所有法例中最不能被忽略的一个。假如你的同事能为你的代码建设和测试单位测试，这是最好不外的事。可是假如没有工钱你做这些事，那么你就必需本身做。在建设你的单位测试打算的时候，遵从下面的这些法则：
一、在写代码之前就写单位测试用例。
二、在单位测试里写注释。
三、测试一切执行“interesting”成果的公有要领（“interesting”的意思长短setters或getters要领，除非它们通过一种非凡的方法执行set和get要领）。
10．记着—质量，而不是数量。
不要在办公室里呆得太晚（当你不必呆的太晚的时候）。我领略有时，产物的问题、紧要的最终期限、意想不到的事件城市阻止我们定时下班。可是，在正常环境下，司理是不会赏识和夸奖那些下班太晚的员工的，他赏识他们是因为他们所做产物的质量。假如你遵从了我上面给出的那些法则，你将会发明你的代码越发少的bug，越发多的可维护性。而这才是你的事情的最重要的部门。
总结
#p#分页标题#e#
在这篇文章里，我给出了针对Java开拓人员的十个重要的法则。重要的不只仅是知道这些法则，在编码的进程中遵从这些法则更为重要。但愿这些法则可以或许辅佐我们成为更好的编程人员和专业人员。
