全文共1662字,预计学习时长6分钟
图源:unsplash
怎样才能算作是一名优秀的程序员?Martin Fowler如是说:“任何傻瓜都可以编写计算机可以理解的代码。优秀的程序员只编写人类可以理解的代码。”
能够理解问题,以可行的方式向最终用户展示解决方案,并团结协作共同实现这个最终目标,这才能算作是好的程序员。那么问题来了,如何在人数众多的情况下管理如此庞大的代码呢?
这就要求大家去遵守一些原则,让每个成员都编写干净且易于维护的代码。毕竟,敲代码也得讲“基本法”呀~
单一职责
编码一段时间之后,你的代码很可能会将变得笨拙,也许具有执行多种功能的类/模块,最终你将得到成百上千行代码的类。
单一职责就是针对这一问题——程序中的类或模块应该只负责一个特定功能的任务,这有助于保持模块最小且干净。
图源:Mukesh Yadav
迪米特法则
当模块相互依赖时,它们就变得紧密耦合,这意味着一个类将对其他模块产生依赖关系。而紧密耦合降低了代码的灵活性和可重用性。
迪米特法则是由伊恩·荷兰(Ian Holland)1987年在东北大学首次提出。该原理总结如下:
· 每个单元对其他单元的了解应该有限:只了解与当前单元“紧密”相关的单元。
· 每个单元只能与朋友交谈;不要跟陌生人说话。
· 只与直系朋友交谈。
图源:unsplash
该原理可以拥有独立的类和代码,因为依赖性较弱,其之间的关联也更加松散,而你所做的任何更改都应反映在最直接的朋友身上。
干净的代码比聪明的代码好
一些程序员在写代码时会忍不住“炫技”,然而这种看起来很厉害的代码比实际易懂的代码更难理解。
这相当于对于读者来说并不友好,相当于给他们出难题。事实上,只要代码干净且易于理解,没人会真正在乎代码有多聪明。
例如,有些人想用三元运算来执行传统的if-else语句。三元操作是标准编程操作,这当然没问题,但问题出在嵌套三元语句时。
let A = 10;
let B = 3;
let C = 25;(A>B?A:B)// fine(A>B?(A>C?A:C):(B>C?B:C))//notfineif(A>B){
(A>C?A:C)
}else{
(B>C?B:C)
}//better
YAGNI(You Aren’t Gonna Need It)
生活中,人们做一件事时会提前计划并做好准备。但这在编程中不是很适用。YAGNI原则就在谈这一点,永远不要为将来可能需要的功能编写代码。它很可能不需要,这是在在浪费时间。
你可以将这一条其视为对KISS原则的具体应用,同时也是对那些认真遵循DRY原则的人的回应。缺乏经验的程序员通常会尽最大努力避免编写最抽象和通用的代码,避免使自己代码变得笨拙。但是太多的抽象最终会导致无法维护的代码膨胀。
你要做的是,只在看到需要抽象的代码时才抽象代码。相反,不要将DRY原则应用于将来可能会反复编写的代码。
简而言之,就是活在当下,而不是将来。
图源:monkeyuser.com
用正确的工具去运用这些规则
有一些工具可以帮助更轻松地遵循这些原则,例如,前端开发人员使用像Bit.dev这样的云组件中心来发布独立的组件。你需要去寻找这些工具。
那么它们又是如何帮助程序员遵循这些原则的呢?
· 将组件构建为独立的代码段(旨在作为独立代码进行发布,重用和协作),自然使每个开发人员都更加注意单一职责原则。
· 从任何代码库发布组件的自由意味着可以共享和重用更多代码,也免不了遵循DRY原则。这也意味着不会用从不使用的UI组件来构建完整的设计系统,而是遵循YAGNI原则,仅在需要时才构建和发布每个组件。
图源:unsplash
编写干净易懂的代码听起来简单,实际做起来却并不容易。如今,这已经成为一项必不可少的要求了。我们需要不断实践,必须慢慢改变处理问题的方式,并以一种清晰的方式得出解决方案。这不是一夜之间的过渡,而是需要几个月和几个项目的积累。
编程是一项团队合作任务,项目成功与否很大程度上取决于团队表现。在争取不做“猪队友”的基础上,努力去做那个带飞团队的大神吧!
推荐阅读专题
留言点赞发个朋友圈
我们一起分享AI学习与发展的干货
编译组:钟惠、高雪窈
相关链接:
https://blog.bitsrc.io/code-principles-every-programmer-should-follow-e01bfe976daf
如转载,请后台留言,遵守转载规范
推荐文章阅读
长按识别二维码可添加关注
读芯君爱你