作为程序员,要有“刨根问底”的精神:知其然,更要知其所以然!
作者 | Nitesh sharma
译者 | 弯月
责编 | 郭芮
出品 | CSDN(ID:CSDNnews)
以下为译文:
在如今这个时代,每个人都在努力提升资源能力。在Web应用程序方面,我们有Spring、Play和Struts等框架,这些框架可以帮助我们构建具有可扩展性和可管理性的软件。这些框架提供了许多样板代码,所以你无需在应用程序中再写这些代码。
不过,写代码并不难,但是写高质量的代码却很难。
作为开发人员,在日常工作中我们也应该遵循相同的基本原则。我们应该将工作完成得尽善尽美,不能将任何错误留给客户。很多时候,迫于压力开发人员会编写管理不善或复杂的代码。为了编写高质量的代码,有一条经验法则是写出的代码应该让所有人都能当作短语一样阅读。
写代码时应当牢记的事情
多想少写,在写之前深思熟虑;
遵循最佳实践;
使用SonarQube等代码质量工具,或者如果使用eclipse或IntelliJ等IDE的话,也可以使用Sonar插件(SonarLint),这些都可以轻松入手;
尽量编写通用的代码;
不要自行创建API中存在的isEmpty、isNull或isNotNull等方法,许多有名的开源库(比如Apache)都提供了定义良好的方法;
使用IDE的重构工具,并了解其快捷方式:
public void doSomething ( ) {
Line1 ....
Line2 ....
Line3 ....
Line4 ....
Line5 ....
}
如果你想抽取1-4并创建一个单独的方法。常见的做法是:复制,创建一个方法,然后将复制的行粘贴到该方法中;总共需要3-4步。在做这样的任务时,你可以使用IDE的重构工具(而无需复制粘贴)。
重构工具有许多重要的功能,包括:
将一段代码从一个位置移动到另一个位置;
从其他地方抽取一段代码,然后创建一个方法(如上例所示);
重命名文件,变量或方法,注意,如果你手动做这个任务,那么就需要手动修改所有的地方;
尽量编写正确的测试用例(可选)。
编写类
类名应该是名词,每个单词的首字母都应该大写;
在编写新类之前,搜索项目中是否存在这样的文件。很多时候,我们会发现我们以不同的名称创建了相同的文件,这会误导项目和其他开发人员。例如:
已存在 | 新创建 |
AppUtil | ApplicationUtil |
ConfigutationUtil | ConfigurationHelper |
LoggerUtil | LoggerHelper |
通过类名完整地描述的功能;
不恰当的类名 | 恰当的类名 |
PersonRestApi | PersonController |
PersonRest | PersonController |
PersonImplementation | PersonService |
使用适当的访问修饰符;
文件的打包也非常重要,把正确的文件放在正确的地方,不要把常量文件放在util包等错误的地方,正确的地方应该是常量或元数据。
编写方法
方法是动词,所以名称应该采用驼峰式命名法,例如doWhatToDo(),而非doWHatTODO();
一个方法不应该超过30行,如果超过30行则说明过于复杂;
在定义方法之前认真考虑,方法应该具有某些含义,或者应该为特定的任务服务,例如createPerson或sendMail;
一个方法不应该同时执行多个任务,如果方法名为createPerson,那么就应该只创建一个人,不应该再做别的任务。很多人会这样做:
public Long createPerson(PersonVO personVO) {
1.Appointment appointment = trying to getting an appointment from DB.
2.then performing if else over the result of appointment.
.
.
.
.
14.then updating something on the basis of some condition.
15.then finally creating person.
}
很多时候方法都超过了这个限制,开发人员在一个方法中编写100-300行代码,最后只会让代码面目可憎且难以理解。
引发的问题包括:
无法理解代码流;
调试问题;
测试问题;
解决一个bug需要很长时间。
解决方法:
将其他任务转移到别的方法中;
提取方法中的有效代码,然后调用其他方法。
所以,这段代码应该像下面这样:
public Long createPerson(PersonVO personVO) {
appoitnmentValidation();
updatingSomething();
creating person code;
}
编写变量
变量名应该采用驼峰式命名法,例如isTrue、userService、personName以及localServiceRerpository;
不应该使用一个字符的名称,除非在临时情况下;
不应该以_和$开头;
在定义变量名之前认真考虑;
不要使用大写。
编写常量
尽量通过类来定义常量,而不是接口;
定义final类;
在常量类中创建一个私有构造函数,确保没人可以创建实例;
如果你整个服务都会使用唯一的一个常量文件,那么最好通过注释来分段,如下所示:
/**** Cache ****/
public static final String CACHE_NAME = "personCache";
/**** Attributes ****/
public static final String NAME = "name";
public static final String MOBILE = "mobile";
/**** Configuration ****/
public static final String APP_NAME = "PersonDemo";
public static final String APP_VERSION = "1.0";
如此可以方便搜索整个文件。
常量名应该非常具体,应该全部使用大写,并利用下划线来分割,例如APP_NAME,而非appName。
编写逻辑
避免使用多个嵌套的If else,这会增加代码的循环复杂度;
尽量编写通用的代码;
不要仅仅利用log来记录异常,应当抛出正确的消息或异常,而不是只输出异常。
什么是“通用代码”?
在很多项目重构的时候,我们都会发现一些本不应该存在的冗余代码。
假设我们有一个邮件草稿的POJO类,它的成员会在发送邮件时被使用。那么,发送邮件所需的步骤有哪些?
我们需要通过设置数据来创建一个POJO对象;
我们需要编写发送邮件的代码。
那么最终的代码行数为:
对象创建——1行:
MailDraft mailDraft = new MailDraft();
设置数据——3行:
mailDraft.setTo();
mailDraft.setBody();
mailDraft.setMessage();
发送邮件的逻辑至少需要4行,所以总共有9-10行代码。
如果我们需要在多重条件或事件中发送邮件,那么情况会怎样?我们需要相同的逻辑,而且通常我们会发现开发人员在每个地方都重复了相同的步骤,并创建一个拥有某些特定代码的方法,于是冗余开始层层叠加。
但是,如果我们将创建草稿和发送邮件的代码提出来,放到另一个方法中,那么每个方法都可以调用这段代码,于是每个方法都省却了10行代码,我们就无需一次又一次地重复这段代码了。
不要匆匆忙忙地赶代码。如果情非得已,那么也要记得加注释:
TODO:需要重构。
原文:https://dzone.com/articles/its-not-too-late
作者:Nitesh sharma, 高级软件工程师@GlobalLogic。
本文为 CSDN 翻译,如需转载,请注明来源出处。
热 文 推 荐
☞ “拼多多”惊爆重大 Bug!程序员的眼泪,羊毛党的狂欢
☞ 漫画:如何用栈实现队列?
print_r('点个好看吧!');
var_dump('点个好看吧!');
NSLog(@"点个好看吧!");
System.out.println("点个好看吧!");
console.log("点个好看吧!");
print("点个好看吧!");
printf("点个好看吧!");
cout << "点个好看吧!" << endl;
Console.WriteLine("点个好看吧!");
fmt.Println("点个好看吧!");
Response.Write("点个好看吧!");
alert("点个好看吧!")
echo "点个好看吧!"
点击“阅读原文”,打开 CSDN App 阅读更贴心!
![640?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/4b2b95350a1aa373154a340982983484.png)