首先我们会先提出这个问题,如果你向 10 个人问这个问题,尽管可能答案不同,但是少有一点应该是一致的。而对我个人而言,一个优秀的程序员应该是一个能够充分理解需求,并能提出可行性解决方案通过团队协作向最终用户展示成果。而说到团队协作,就涉及到代码的可维护性,那么你该如何管理庞大的代码库?如果放任团队成员提交随意的代码,那么在项目中无论在 bug 修复还是新增功能,都将很难完成。
如果想要实现可维护这个目标,那么团队中的每个成员都应该保证提交整洁且可维护的代码。那么您应该让你的团队成员遵守一定的编码原则。遵守这些原则,可以使你和其他人的协作变得更容易。所以团队成员应该遵循什么样的规则呢?
童子军是美国社会针对未成年人的一种教育实践制度,加入童子军的小朋友都要学习并遵守一些规则,然后获得各种各样的勋章。其中一条规则是离开宿营地前进行清扫活动的原则,简洁明了:
Leave the campground cleaner than you found it.
假设某个小朋友来到某个宿营地,不幸发现地上有两处垃圾,然后他自己在接下来的日常活动中也制造了一处垃圾。那么当他离开时,不仅要清理掉自己的垃圾,还有处理早先小朋友留下的两处垃圾。而不是去寻找是谁丢的。应把注意力放在为下一个露营者创造更好的环境。
这个原则放到软件生产中则意味着让 check in 比 check out 时更整洁,至少不要让代码变得更糟糕。
(图片来源于网络)
尽量在项目的开发过程中减少产出重复的代码、方法和类,多数的设计模式根本目的是为了减少代码重复,尽可能将重复使用的代码抽象封装,是提高代码的可重用性和可维护性的最佳方式之一。
这里功能独立的意思是指,函数或方法尽可能简单,功能尽可能独立。
换句话来讲就是,一个方法最好只做一件事,如果你觉得你的代码过于复杂,该怎么做?抽方法。
初级程序员最常犯的错误就是在一个方法中包含了很多种要做的工作,这可能会在软件的生命周期带来灾难。
程序员作为社会中最聪明的群体之一,往往在写代码时也会产出一些炫技的代码块,这部分代码块过段时间再去看,就像谜一样存在于程序中,虽然很简洁,但并不易读。
例如:有些人在程序中喜欢使用三目运算而非 if-else,虽然本身使用三目运算符没有问题,但存在嵌套情况时,那么对于后面的维护者就是一场噩梦,例如如下代码:
(A>B?(A>C?A:C):(B>C?B:C))
其实上面的代码等同于,显然下面的格式更易懂
if(A>B){ (A>C?A:C) }else{ (B>C?B:C) }
迪米特法则是 1987 年秋天由 lan holland 在美国东北大学一个叫做迪米特的项目设计提出的,它要求一个对象应该对其他对象有最少的了解,所以迪米特法则又叫做最少知识原则。它的意义旨在降低类和类之间的耦合,避免发生由于耦合度过大造成的因为一个类发生变化,而对另一个类造成影响。
YAGNI 原则是指在开发时只需要将应用程序必需的功能包含进来,而不要试图添加任何其他你认为可能需要的功能。开发过程中为了应对将来可能的提出的需求,提前开发一些功能进去,我们通常会花不少时间成本在这些过度设计的功能开发上,但可能未来的两三年内这个设计根本没有用到。应把更多的精力花在更重要的功能开发上,适度假设未来需求的规划,加速后期功能迭代和代码维护。
虽然上面提了很多原则和规范,但这些规范需要在长期在工作中的实践才能有更深的理解的。希望您能从本文中了解一些基础,最后,希望大家都能写出优美、规范的代码。
1
wysnylc 2020-04-23 10:18:24 +08:00 1
不要重复常识
|
2
wr410 2020-04-23 10:25:23 +08:00 1
不要过于教条,规定什么不能做就可以了,而不要去规定什么东西是能做的,那样你不如去写个代码生成器好了。
|