怎样才能算作是一名优秀的顺序员?Martin Fowler如是说：“任何傻瓜都可以编写计算机可以了解的代码。优秀的顺序员只编写人类可以了解的代码。”

可以了解成绩，以可行的方式向最终用户展现处置方案，并勾搭协作共同完成这个最终目的，这才能算作是好的顺序员。那么成绩来了，如何在人数众多的状况下管理如此庞大的代码呢?

这就要求大家去遵守一些准绳，让每个成员都编写洁净且易于维护的代码。毕竟，敲代码也得讲“基本法”呀~

单一职责

编码一段时间之后，你的代码很能够会将变得笨拙，也许具有执行多种功用的类/模块，最终你将失掉成百上千行代码的类。

单一职责就是针对这一成绩——顺序中的类或模块应该只担任一个特定功用的义务，这有助于保持模块最小且洁净。

迪米特规律

当模块相互依赖时，它们就变得严密耦合，这意味着一个类将对其他模块产生依赖关系。而严密耦合降低了代码的灵敏性和可重用性。

迪米特规律是由伊恩·荷兰(Ian Holland)1987年在西南大学初次提出。该原理总结如下：

每个单元对其他单元的了解应该有限：只了解与以后单元“严密”相关的单元。

每个单元只能与冤家交谈;不要跟生疏人说话。

只与直系冤家交谈。

该原理可以拥有独立的类和代码，由于依赖性较弱，其之间的关联也愈加松懈，而你所做的任何更改都应反映在最直接的冤家身上。

洁净的代码比聪明的代码好

一些顺序员在写代码时会忍不住“炫技”，但是这种看起来很凶猛的代码比实践易懂的代码更难了解。

这相当于关于读者来说并不友好，相当于给他们出难题。理想上，只需代码洁净且易于了解，没人会真正在乎代码有多聪明。

例如，有些人想用三元运算来执行传统的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准绳运用于未来能够会重复编写的代码。

简而言之，就是活在当下，而不是未来。

用正确的工具去运用这些规则

有一些工具可以协助更轻松地遵照这些准绳，例如，前端开发人员运用像Bit.dev这样的云组件中心来发布独立的组件。你需求去寻觅这些工具。

那么它们又是如何协助顺序员遵照这些准绳的呢?

将组件构建为独立的代码段(旨在作为独立代码停止发布，重用和协作)，自然使每个开发人员都愈加留意单一职责准绳。

从任何代码库发布组件的自在意味着可以共享和重用更多代码，也免不了遵照DRY准绳。这也意味着不会用从不运用的UI组件来构建残缺的设计系统，而是遵照YAGNI准绳，仅在需求时才构建和发布每个组件。

图源：unsplash

编写洁净易懂的代码听起来复杂，实践做起来却并不容易。如今，这曾经成为一项必不可少的要求了。我们需求不断实际，必须渐渐改动处置成绩的方式，并以一种明晰的方式得出处置方案。这不是一夜之间的过渡，而是需求几个月和几个项目的积聚。

编程是一项团队协作义务，项目成功与否很大水平上取决于团队表现。在争取不做“猪队友”的基础上，努力去做那个带飞团队的大神吧!

【编辑引荐】

微信上其实还有很多你不知道的事，Python微信平台开发编写实录

教科书级错误：每个开发人员都犯过的典型错误

经过几段 Java 代码带你了解 RPC

前端开发者不得不知道的18个常用的网站

2020年好用的.NET开发工具

(责任编辑：admin)