1，让设计而不是纯编码占据你大多数时间。
尽管我们最终的工作是编码，但是请不要让编码占据你太多时间。良好的设计十分有必要。要在设计阶段模拟自己所能模拟的场景，每一种情况都可能影响到最终的设计。良好的设计会导出良好的结构和清晰的需求。
事实上，要求在设计之前获得所有明确的需求是不可能的。require的细化包括那些未知的需求的猜测应该是在设计阶段而不是在编码阶段。我们常常认为编码才是项目的开始，这是个十分错误的观点，设计才是项目真正的开始。对设计的漠视只会让你在编码阶段不断的怀疑你结构的合理性（如果你对代码质量很在乎的话）。
像你的同伴介绍你的设计，他必定会有让你意想不到的好主意。
编码只是对设计的实现。一个好的java程序员可以在2天之内实现一个中型项目的所有编码。如果你在编码上花去台多时间，请确认是否需要再看一遍《Think in Java》.对于采用的开源项目或者其他的第三方产品，对于 他们的研究应该是在项目准备阶段而且应该不会花去你太多时间。英语不行？那是另外一回事了。
事实上，在刚过去的项目中，是谈论和变更需求占据了大部分时间。
2，单元测试
单元测试的重要性已经不容我在这里瞎掰了。单元测试会战用你很多时间吗？至少我不是这样认为。即使你由于项目时间紧张的原因安排不出单元测试的时间，你也应该在编码阶段尽量使你的代码容易进行单元测试。
如果你习惯于某个方法体里面有众多的功能，习惯于写一些重复的代码，那么你会越来越习惯于此，等到某一天需要单元测试的时候，你会发现你的测试和集成测试相差无几。
并不是你写的每一个方法都需要测试。最好的测试当然是类似jtest那样的专业工具生成的测试样例。不过就目前来看，笔者更倾向于“正确性测试”--即构建正确的数据来验证他的功能。毕竟，构建测试样例成本很高。
3，重构
重构意味着代码中存在功能细化或者代码重用的部分。这是一个听起来让人心烦的词。不要认为逻辑正确的代码就是好代码，这也是我们做那么多“功利者“听起来“无用功”的原因。激进和极端的“功利者”总是漠视
代码的维护和更新成本，尽管他们一遍又一遍的维护和更新。就笔者经历来看，重构没有想象中的复杂，如果对自己所作的东西足够了解，很容易找到该分割的部分或者该合并的部分。重构不是坏事，是一个考验自己的很好的挑战。
4，注释和格式化。
如果你的代码写出来不是让别人看得，那么你或许可以无视这一条。代码就像一块陆地，格式就是道路，注释就是路标。“好的代码是那种让人看得懂得代码”。不要用时间很紧欺骗自己，养成好的习惯，now!
5,日志
log4j真是个好东西，很精巧的东西，实现了强大的功能。在本人另一篇文章里面提到了log4j的主要配置。eclipse的插件log4e基本上提供了log4j的所有应用。在生产者完成以后，消费者分析数据靠的最主要的是log.这里的消费者可能就是你api的使用者。在我的关于异常的那篇文章里提到，有时候我们会采用“异常转译“，前提是我们需要记录低级异常到日至文件供高层分析。关于log4j的配置，笔者建议对方法的入参和返回值得主要信息进行跟踪，对于异常
点，我们更应该打印相关的变量信息。
6，不要轻易相信别人给你的东西。
标题有点吓人，意思是，对从外面传过来的值进行合法性检查。或许你需要访问数据库，或许你需要接受别人传过来的参数，或许你利用了第三方的产品等等，你都需要对他们返回的数据进行合法性检查。等到要使用的时候才发现别人
传给你的数据是个null是一件很恼火的事，不是吗？所以请提高警惕性。不要让IllegalArgumentException过于寂寞。