为了更好地获取IDEA的服务性能,您最好在自己的电脑上采用固态硬盘(SSD)。就我自己的那台旧式笔记本电脑而言,由于使用的是传统硬盘(HDD),它已无法顺畅地运行IDEA了。因此我个人建议您至少使用一颗256 GB大小的固态硬盘。
2.使用JDK 8或更高版本
JDK 8及其更高版本引入了诸如:lambda表达式(lambda expression,一种匿名函数)、功能接口、流式接口(stream APIs,提供更为可读的源代码实现方法)等许多新的功能,这些都有助于您写出更简短、更高性能的Java代码。
当然,您并不需要去逐一地记住这些功能,因为前面提到的IDEA会帮助您在实际编程的过程中,实现这些功能与服务。
3.使用Maven/Gradle
请使用Maven(一个采用纯Java编写的开源项目管理工具,请参见)或Gradle(一个基于Apache Ant和Maven的项目自动化构建工具,请参见)来管理代码中的依赖关系,以及构建和部署自己的项目。
如果您已经为许多项目建立了可复用各种基本库,那么如果仅仅是内部使用的话,您可以引入Nexus(一种Maven存储库的管理器)来进行管理。否则,您应该将它们直接部署到Maven的中央存储库中。
4.使用Lombok
是时候向setter/getter、hashcode/equals、以及constructors/toString等样板式代码(boilerplate code)说再见了,您只需要一个注解:- @Data - 就能统统搞定了。
Lombok是一款可以通过简单的注解形式,来帮助开发者简化并消除Java代码臃肿的工具(具体请参见)。它不但能够减少您的代码编写量,还能够帮助您打理那些生成的字节码。
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.定期联络客户,以获取他们的反馈
最后一点,可能也是最重要的:客户花钱让您通过编写代码,来解决他们的问题、满足他们的需求、并解决他们的痛点。然而,您可能在不知不觉中花费了太多的时间,去实现自以为重要、却对客户无关紧要的特殊功能,进而忽略了代码整体的健壮性和可维护性。那么,我们怎么才能够尽早地发现该问题呢?请保持与客户经常联系,以尽早地获取他们的反馈。
话说回来,知易行难,即使是富有经验的产品经理也不一定能在较短的时间内领悟需求的真谛,何况是那些满脑子只注重功能实现的“码农”们呢?
因此,一个实用的建议是:如果您不能直接联络到最终用户的话,请尽量与该系统的产品经理、或运维人员进行礼貌、且频繁的沟通。磨刀不误砍柴工,这些时间的投入对于后期时间的节省是绝对值得的。
总结:
在过去的多年编程实践和项目应用中,我一直受益于上述七点心得。在此,我希望它们也同样能给您的代码工作带来帮助。祝您编程愉快!