收集的一些，以示警戒

在Stack Overflow上有这样的一个贴子《What’s your most controversial programming opinion?》，翻译成中文就是“你认为最有争议的编程观点是什么？”，不过，在400多个主回贴，以及上千个所有回贴中，好像并不是很有争议，而是令人相当的茅塞顿开，下面罗列一些，希望对你有帮助。

1） The only “best practice” you should be using all the time is “Use Your Brain”.

唯一的“Best Practice”并不是使用各种各样被前人总结过的各种设计方法、模式、框架，那些著名的方法、模式、框架只代表赞同它们的人多，并不代表它们适合你，你应该更多地去使用你的大脑，独立地思考那些方法、模式、框架出现的原因和其背后的想法和思想，那才是“Best Practice”。事实上来说，那些所谓的“Best Practice”只不过是限制那些糟糕的程序员们的破坏力。

2）Programmers who don’t code in their spare time for fun will never become as good as those that do.

如果你对编程没有感到一种快乐，没有在你空闲的时候去以一种的娱乐方式去编程，那么你只不过是在应付你的工作，这样下来，就算是你是一个非常聪明，非常有才华的人，你也不会成为一个优秀的编程员，要么只会平平凡凡，要么只会整天扎在技术中成为书呆子。当然，这个观点是有争议，热情和能力的差距也是很大的。不过我们可以从中汲取其正面的观点。

3）Most comments in code are in fact a pernicious form of code duplication.

注释应该是注释Why，而不是How和What，参看《惹恼程序员的十件事》，代码告诉你How，而注释应该告诉你Why。但大多数的程序并不知道什么是好的注释，那些注释其实和代码是重复的，毫无意义。

4）XML is highly overrated

XML可能被高估了。XML对于Web上的应用是不错的，但是我们把其用到了各种地方，好像没有XML，我们都不会编程了。

5）Not all programmers are created equal

这是那些junior经理爱犯的错，他们总是认为，DeveloperA == DeveloperB，只要他们的title一样，他们以为他们的能力、工作速度、解决问题的方法，掌握的技能等等都是一样的。更扯的是，在某些时候，就算是最差的程序员，他们也会认为其比别人强十倍。

6）”Googling it” is okay!

Google只会给你知识，并不会教给你技能。那里只有“鱼”，没有“渔”，过度使用Google，只会让你越来越离不开它，你越来越不会自己去思考、探索、钻研。如果KFC快餐是垃圾食品对我们的身体没有好处，那么使用Google也一种快餐文化对我们的智力发展没有好处。

7）If you only know one language, no matter how well you know it, you’re not a great programmer.

如果你只懂一种语言，准确的说，如果你只懂一类语类，如：Java和C#，PHP和Perl，那么，你将会被局限起来，只有了解了各种各样的语言，了解了不同语言的不同方法 ，你才会有比较，只有了比较，你才会明白各种语言的长处和短处，才会让你有更为成熟的观点，而且不整天和别的程序在网上斗嘴争论是Windows好还是Unix好，是C好还是C++好，有这点工夫能干好多事了。世界因为不同而精彩，只知道事物的一面是有害的。

8）Your job is to put yourself out of work.

你的工作不应该保守，那种教会徒弟，饿死师父的想法，不但是相当短浅的，而且还是相当脑残的。因为，在计算机世界里，你掌握的老技术越多，你就越没用，因为技术更新的太快。你对工作越保守，这个工作就越来越离不开你，你就越不越不能抽身去学新的东西，你也就越来越OUT了。记住：If you can’t be replaced then you can’t be promoted!

9）Design patterns are hurting good design more than they’re helping it.

很多程序员把设计模式奉为天神，他们过度的追求设计模式以至都都忘了需求是什么，结果整个系统设计被设计模式搞得乱七八糟，我们叫这种编程为“设计模式驱动编程”，正如第一点所说，如果你不懂得用自己的大脑思考的话，知其然，不知所以然的话，那么你不但得不到其好处，反而受其所累。

10）Unit Testing won’t help you write good code

准确地说，我们可以认为这是Test-Driven开发，其实，这种开发就是先写单元测试用例，这样的开发方式的主要目的是，为了防止你不会因为一个改动而引入Bug，但这并不会让你能写出更好的代码。这只会让你写出不会出错的代码。同第一点，这样的方法，只不过是防止糟糕的程序员，而并不是让程序员或代码质量更有长进。反而，Unit Test会成为程序员为自己代码做辩解的一种托辞。


原文地址：http://www.iteye.com/news/25059

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来执行！




(若你想知道怎么做一个这样的表，请阅读我的另一篇文章"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)连接是另一种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，选择哪种应该很明显了。



7. 注意图形用户界面（Pay attention to the GUI）. – 无论听上去多荒谬，但有一点我注意过多次了：图形用户界面（GUI）对于商业用户而言与程序功能及执行效率一样重要。GUI对于应用程序的成功至关重要。 IT管理者（译注：这里应该是指程序开发方的IT management）常常忽略GUI的重要性，很多公司为了省钱而不雇佣web设计人员，而这些设计人员有足够的经验来设计“用户友好”的应用软件。Java程序员不得不依赖他们有限的HMTL知识。我见过非常多对“计算机友好”而非对“用户友好”的应用程序，同时精通软件开发和用户界面开发的开发者非常少见。 如果你是一位不幸被指派做界面开发的Java程序员，你要遵循下面3条规则：

1.不要重新发明轮子。去看那些类似应用系统的界面。
2.首先建立一个原型。这一步非常关键。客户喜欢提前看到他们要用的东西。同样你可以得到他们的反馈，而不是你辛辛苦苦做出来一个客户不喜欢的东西。

3.试戴用户的帽子。换句话说，站在用户的角度查看需求。譬如，一个统计的界面可以分页，也可以不分页。作为开发者，很可能会忽略分页，因为这会减少很多麻烦；而站在客户角度，这就不是一个好的方案，因为数据可能多达几百行。
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项守则。仅仅知道是不够的，还要遵循它们。希望这些守则能让我们做更加专业的程序员。

原文地址：http://www.iteye.com/topic/889075