有许多标准和实践准则可适用于Java开发者，但此处要说的，是每个Java开发者需坚守的基本原则。

   一、为代码加注释。虽然每个人都知道这点，但有时却不自觉忘了履行，今天你“忘了”加注释了吗？虽然注释对程序的功能没什么“贡献”，但过一段时间，比如说两星期之后或者更长，回过头来看看自己的代码，说不定已经记不住它是干什么的了。如果这些代码是你个人的，那还算是走运了，不幸的是，当然了，大多数时候都是别人的不幸，很多时候大家都是在为公司写代码，写代码的人也许早已经离开了公司，但别忘了一句古话，有来有往嘛，为他人，也为我们自己，请为你的代码加上注释。

   二、不要让事情复杂化。程序员有时候总是对简单问题想出复杂的解决方案，比如说，在只有五个用户的程序中引入EJB、对程序实现了并不需要的框架（framework），之类的还有属性文件、面向对象解决方案、多线程等等。为什么要这样做呢？也许我们并不知道是否这样会更好，但这样做也许可以学到一些新东西，或者让自己更感兴趣一些。如果是不知道为什么这样做，建议多请教经验丰富的程序员，如果是为了个人的目的，麻烦让自己更专业一点。

   三、始终牢记——“少即是好（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和两个花括号，但代码的可读性与可理解性就一下子提高了一大截。

   四、请不要硬编码。开发者经常有意“忘记”或忽略掉这点，因为有些时候开发日程逼得实在太紧。其实，多写一行定义静态变量的代码能花多少时间呢？

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就行了，而且在今后需要进行修改时，也可在一处修改，不会翻遍整个源代码逐个修改了。

 五、不要“创造”自己的框架（framework）。确切来说，有数以千计的各种框架存在，而且大多数是开源的，这些框架都是优秀的解决方案，可用于日常程序开发中，我们只需使用这些框架的最新版本就行了，至少表面上要跟上形势吧。被大家广为接受的最为明显的一个例子就是Struts了，这个开源web框架非常适合用在基于web的应用程序中。是不是想开发出自己的Struts呢，还是省点力气吧，回头看看第二条——不要让事情复杂化。另外，如果正在开发的程序只有3个窗口，就不要使用Struts了，对这种程序来说，不需要那么多的“控制”。

   六、不要使用println及字符串连接。通常为了调试方便，开发者喜欢在可能的所有地方都加上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秒，作为对比，方法calculationWithPrint()执行可是用了10.52秒。

要避免浪费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);
}
}

另外，字符串连接也是浪费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秒执行完毕，而使用连接的方法则用了0.08秒，选择显而易见了。

七、多关注GUI（用户界面）。再三强调，GUI对商业客户来说，与程序的功能及效率同等重要，GUI是一个成功程序的最基本部分，而很多IT经理往往都没注意到GUI的重要性。在现实生活中，许多公司可能为了节省开支，没有雇用那些有着设计“用户友好”界面丰富经验的网页设计者，此时Java开发者只能依赖他们自身的HTML基本功及在此领域有限的知识，结果，很多开发出来的程序都是“计算机友好”甚于“用户友好”。很少有开发者同时精通软件开发及GUI设计，如果你在公司“不幸”被分配负责程序界面，就应该遵守下面三条原则：

1、 不要再发明一次轮子，即不做无用功。现有的程序可能会有类似的界面需求。
2、 先创建一个原型。这是非常重要一步，用户一般想看到他们将使用的东西，而且可以先利用这个原型征求用户的意见，再慢慢修改成用户想要的样子。
3、 学会换位思考。换句话来说，就是从用户的角度来审查程序的需求。举例来讲，一个汇总的窗口可以跨页或者不跨页，作为一个软件开发者，可能会倾向于不跨页，因为这样简单一些。但是，从用户的角度来看，可能不希望看到上百行数据都挤在同一页上。

   八、文档需求不放松。每个商业需求都必须记录在案，这可能听上去像童话，似乎在现实生活中很难实现。而我们要做的是，不管开发时间多紧迫，不管最终期限多临近，对每个商业需求都必须记录在案。

   九、单元测试、单元测试、单元测试。关于什么是单元测试的最好方法，在此不便细说，只是强调，单元测试一定要完成，这也是编程中最基本的原则。当然了，如果有人帮你做单元测试自然是最好，如果没有，就自己来做吧，当创建一个单元测试计划时，请遵守以下三条最基本的原则：

1、 先于编写类代码之前编写单元测试。
2、 记录单元测试中的代码注释。
3、 测试所有执行关键功能的公有方法，这里不是指set和get方法，除非它们是以自己独特方式执行set和get方法。

   十、质量，而不是数量。有些时候因为产品问题、期限紧迫、或一些预料之外的事情，导致常常不能按时下班，但一般而言，公司不会因为雇员经常加班而对之表扬和奖励，公司只看重高质量的工作。如果遵守了前九条原则，你会发现自己写出的代码bug少且可维护性高，无形中质量提高了一大步。

作者：皮特*柯林斯
翻译：草儿

刚刚收到一个谷歌文章提示，来自一个关于OSGi的博客。作者是Jilles van Gurp，首先对OSGi表示赞美然后提到这个工具。他的主要问题是必须在Eclipse插件开发环境里一个一个在Manifest中增加输入 ，这时一些人会抱怨manifest的格式繁杂。我非常同意他的观点。 Bnd这个工具基本上考虑到他所有的要求。

好了，使用Bnd工具 你的祈祷再次生效了。这个工具有一个wrap函数能够为你做这个工作。然而，实际上因为很多JAR文件的依赖极端繁杂，所以这个可能变得困难。通常创建一个可选输入或者忽略输入从而bundles是可安装的是必要的。当你分析一个JAR文件时（Bnd能够帮你处理这个工作），你总会吃惊的看到很多无用的依赖出现。

最后，我讨厌必须处理繁杂的manifest文件的想法。我注意到要求manifest文件要以空行作为结束的缺陷依旧存在（如果这个遗漏了怪异的事情就发生了）。这个和在makefiles文件要用tab代替空格一样烦人。

啊哈哈，确实很麻烦，但是你使用Bnd后就不会在为这些小事而烦躁了。一个.bnd文件是一个属性文件。它能处理不限长度的行，使用反斜杠\扩展到下一行，没人会关心最后一行。你也能增加注释。Bnd读取这些属性文件，它用在Manifest类中建立的Java生成一个有效的manifest。以这种方式校验所有的头都为正确的值。.bnd文件看起来是多么简单：

  Export-Package: aQute.service.*

Import-Package: javax.servlet.http;version="[2,3)", *

但是，Jilles还没有说完关于OSGi的批评：

• Bnd也被以Felix Maven-bundle 插件形式用在Maven构建工具中，。
• Bnd 也是一个eclipse插件, 它在为.bnd 文件 和 .jar 文件的上下文菜单里增加了入口。
• 你能添加来自系统文件的任何地方或者来自一个URL的资源。这并不需要先创建所有资源的目录结构, JAR在运行中构建。
• 资源能够包含被代替的变量引用。
• 你能够很容易得在你的JAR文件中从类路径上添加包。如果你用另一个bundle的一小部分而不想创建额外的依赖，这个用起来非常方便。
• Bnd也能在输出中创建uses语句 。这uses语句表明使用什么包。整个架构使用这些信息创建一致的类空间。
• 你能内联其他的JAR文件或者目录。
• 更多的功能.

我没有说Bnd是完美无缺的。我希望我能花一些时间以我喜欢的方式对它进行扩展：处理依赖的图形编辑器；更好的分析支持；集成Eclipse构建器等等。

其中：

Execution Environment：

Bundle 应用所倚赖运行的 Java 执行环境，如 J2SE-1.4、CDC-1.0 等都是可用的执行环境。

Modules：

模块层定义了 Bundle 应用的加载策略。OSGi 框架是一个健壮并且严格定义的类加载模型。在大多数 Java 应用中，通常只有一个单独的 ClassPath，它包含了所有的 Java 类文件和资源文件，OSGi基于Java技术，对于每个实现了 BundleActivator 接口的 Bundle 应用，为它生成一个单独的 ClassLoader，使得 Bundle 应用的组织更加模块化。

Life Cycle：

生命周期层可以动态地对 Bundle 进行安装、启动、停止、升级和卸载等操作。该层基于模块层，提供了一组 API 来控制 Bundle 应用的运行时操作。

Service Registry 和 Services：

OSGi 服务层定义了一个集成在生命周期层中的动态协作模型，是一个发布、动态寻找、绑定的服务模型。一个服务通常是一个 Java 对象实现了特定的服务接口，并且通过服务注册，被绑定到 OSGi 的运行环境中。Bundle 应用可以注册发布服务，动态绑定服务，并且在服务注册状态改变时，可以接受到事件消息等。

Security：

OSGi 的安全管理是基于 Java2 安全体系的，贯穿在 OSGi 平台的所有层中，它能够对部署在 OSGi 运行环境中的 Bundle 应用进行详细的管理控制。

2、Bundle 生命周期的状态分析

在一个动态扩展的 OSGi 环境中，OSGi 框架管理 Bundle 的安装和更新，同时也管理 Bundle 和服务之间的依赖关系。一个 Bundle 可能处于以下六个状态，如图 2 所示：

INSTALLED：安装完成，本地资源成功加载。

RESOLVED：依赖关系满足，这个状态意味该Bundle要么已经准备好运行，要么是被停止了。

STARTING：Bundle正在被启动，BundleActivator的start()方法已经被调用但是还没有返回。

STOPPING：Bundle正在被停止，BundleActivator的stop()方法已经被调用但是还没有返回。

ACTIVE：Bundle 被成功启动并且在运行。

UNINSTALLED：bundle被卸载并且无法进入其他状态。

Bundle接口定义了getState()方法来返回Bundle的状态。