5.编写单元测试

可测试的代码通常意味着在组织结构上具有更合理、更简洁的代码质量。因为它会驱使您去事先管理好各个类之间的关系、各种方法的访问级别、以及其他方面。我甚至发现：即使是小的单元测试也能够促进更快、更便捷的开发进程，进而能够让自己写出更加短、平、快的Java代码。

当然在现实开发工作中，您总会听到一些诸如“我根本没有时间来编写单元测试”或“项目时间节点将至，不要浪费时间些单元测试了”之类的反对意见。这些听起来貌似很合理，但是根据我的经验，在多数情况下，事实并非如此。

如果您没有时间去编写单元测试，那您是否有更多的时间，去修复代码中那些可见、或不可见的bug呢?如果跳过了单元测试，那些仓促完成的代码将无法保证稳定性。特别对于一些新的代码变更而言，您完全无法通过及时的反馈途径，知晓那些新产生的代码是否存在着错误隐患，是否会在将来运行的某个特定场景中产生不可预知的异常问题。

一般而言，Junit和TestNG是两款非常的Java应用、及单元测试框架。而我个人则更喜欢使用TestNG。

6.重构：常见，但也很慢

简洁干练的Java程序代码从来不是一蹴而就的，它往往需要您进行反复地琢磨与改进。通过逐行进行代码重构、和运行各种测试用例，您可以确保自己的更改不会破坏既有代码的正确功能。同样，IDEA极大地提供了对于代码重构的支持，其中包括提取方法(extract method，将某个大的函数拆分为多个小函数)、重命名、内联(inline)等功能。

当然，如果您对代码重构是什么，以及它的作用不太了解的话，Martin Fowler的经典著作《重构：改善既有代码的设计(第2版)，Refactoring: Improving the Design of Existing Code (2nd Edition)》(请详见)是一本您必备的参考书。

7.定期联络客户，以获取他们的反馈

后一点，可能也是重要的：客户花钱让您通过编写代码，来解决他们的问题、满足他们的需求、并解决他们的痛点。然而，您可能在不知不觉中花费了太多的时间，去实现自以为重要、却对客户无关紧要的特殊功能，进而忽略了代码整体的健壮性和可维护性。那么，我们怎么才能够尽早地发现该问题呢?请保持与客户经常联系，以尽早地获取他们的反馈。

话说回来，知易行难，即使是富有经验的产品经理也不一定能在较短的时间内领悟需求的真谛，何况是那些满脑子只注重功能实现的“码农”们呢?

因此，一个实用的建议是：如果您不能直接联络到终用户的话，请尽量与该系统的产品经理、或运维人员进行礼貌、且频繁的沟通。磨刀不误砍柴工，这些时间的投入对于后期时间的节省是值得的。

总结

在过去的多年编程实践和项目应用中，我一直受益于上述七点心得。在此，我希望它们也同样能给您的代码工作带来帮助。祝您编程愉快!