分享在Java中生成文件的10项建议-java-编程

大家都知道编程人员，php，javascript是最难搞的，不过懂得人却乐在其中，但是不懂的就惨了，下面是笔者在编程当中发现的一些问题，权当是经验之谈。

前期准备工作（包括相关工具或所使用的原料等）

java程序

详细的具体步骤或操作方法

记住 "越少越好"并非总是如此(Keep in Mind – "Less is more" is not always better)。 – 高效率的代码是件好事，但很多情况下，并非代码行数越少效率就越高。

不要把简单事情复杂化(Do not complicate things)。 – 我曾经这么做过，我相信你也一样。开发者都倾向于采用复杂方式解决简单问题。我们在一个只有5个用户的系统中引入EJB,为一个并不需要框架的应用实现一套框架，采用属性文件、采用面向对象解决方案、使用线程，而这些根本用不着。为什么会这么做？一些人可能不知道有更好的解决方案，但另一些人可能故意这样做来学习新知识，或仅仅是因为有趣。对那些不知道更好解决方案的人，要多听有经验程序员的建议。

不要"硬编码"(No hard coding please)。 – 由于时间紧迫，开发者总是会忘记或故意忽略这一条。然而另一种可能是，遵循这条戒律，我们就不会陷入"时间紧迫"的困境。定义一个static final 变量，增加一行代码，又能花多长时间呢。

为代码添加注释(Add comments to your code)。 – 每个人都知道这一点，但不是每个人都会这么做。你有多少次"忘记"添加注释了？确实，注释不会为你的程序增加任何函数功能。但是，有多少次，看到2周前写的代码，你都记不起它是干什么的？你很幸运，那些未注释的代码是你自己写的，你脑海中还会有残存的印象。非常不幸，大多时候，代码是别人写的，并且那个人很可能已经离开公司了。

不要发明你自己的框架(Do not invent your own frameworks)。 – 不夸张地讲，已经有几千个框架存在了，大多数还是开源的。很多框架都是极完美的解决方案，并已被用到成千的系统中。我们只要关注最新的流行的框架，至少表面上要熟悉一下。一个最成功的、也是被广泛使用的例子是Struts框架，这个开源的web框架是建立web系统的极佳选择，不要试图构造你自己的Struts版本，会累死的。如果你要开发的系统只有3个界面，就不要用Struts. 对于这样一个系统，没有足够的需要被"控制"的东西(译注：Struts将界面做MVC划分，C即controller,所以作者说there isn't much "controlling" required)。

对Print行或字符串说不(Say no to Print lines and String Concatenations)。 – 我知道为了调试方便，程序员喜欢到处用System.out.println ,然后对自己说过一会就删掉。但我们常常忘记删掉这些行或不愿删掉，我们用System.out.println 做测试，为什么测完后还要去改代码？这很可能导致误删一行我们需要的代码。不要低估System.out.println 的危害。

单元测试，单元测试，单元测试 (Unit-test. Unit-test. Unit-test)。 – 我不准备讨论如何单元测试的细节，我只是想说这必须要做。这是编程中最基本的规则了，尤其不能忽略。如果你同事能为你的代码创建一个测试计划，那就再好不过了;如果不能，那就要自己做。做单元测试计划时，遵循下面原则：编码前就写单元测试；保留单元测试的注释；对任何"有趣的"公共方法都要做单元测试。

注意图形用户界面(Pay attention to the GUI)。 – 无论听上去多荒谬，但有一点我注意过多次了：图形用户界面(GUI)对于商业用户而言与程序功能及执行效率一样重要。GUI对于应用程序的成功至关重要。Java程序员不得不依赖他们有限的HMTL知识。我见过非常多对"计算机友好"而非对"用户友好"的应用程序，同时精通软件开发和用户界面开发的开发者非常少见。

记住：质量，而非数量(Remember – quality, not quantity)。 - 不要待的太晚(除非有必要)。我知道有时因为产品问题，截止期限或其他突发事件，不能按时下班。但经理不会因为你为一般问题待的太晚而感激或奖励你;他们会为有质量的工作而感激你。如果你遵循上面的列的原则，你就会写更健壮的、少bug的程序。

提前准备需求文档(Always Prepare Document Requirements)。每项业务需求都记入文档。这在童话故事中可能实现，而现实中很难做到。无论时间多么紧迫，无论截止日期如何迫近，你必须确保业务需求被记录下来。

注意事项

写程序只能脚踏实地去做，不要走捷径，万一代码写成却运行不了，那就麻烦了。

经验内容仅供参考，如果您需解决具体问题(尤其法律、医学等领域)，建议您详细咨询相关领域专业人士。