人类可以理解。”能够理解一个问题，将解决方案以可行的方式呈现给最终用户，并共同努力实现这个最终的Goal，这才算得上是一个优秀的程序员。那么问题来了，这么庞大的代码，人多势众，怎么管理呢？这就需要大家遵守一些原则，这样每个成员都能写出干净易维护的代码。毕竟敲代码要讲“基本法”~经过一段时间的单一职责编码，你的代码很可能变得笨重，也许类/模块执行多种功能，最终你会得到数百个或数千行代码的类别。单一职责就是针对这个问题——程序中的一个类或模块应该只负责一个特定的功能任务，这有??助于保持模块的最小化和清洁。Dimit定律当模块相互依赖时，它们会变得紧密耦合，这意味着一个类将依赖于其他模块。紧耦合降低了代码的灵活性和可重用性。Demeter定律最早由东北大学的IanHolland于1987年提出，其原理概括如下：每个单元对其他单元的了解应该是有限的：只有那些与当前单元“密切”相关的单元。每个单元只与朋友交谈；不要和陌生人说话。只与直系亲友交谈。原则是拥有更松散相关的单独类和代码，因为依赖性较弱，并且您所做的任何更改都应该反映在您最直接的朋友中。干净的代码优于智能代码。有的程序员在写代码的时候忍不住要“炫耀”，但是这种看起来很强大的代码，其实比其实很容易理解的代码更难理解。这相当于对读者不友好，相当于给他们出了难题。事实上，没有人真正关心代码的智能程度，只要它干净且易于理解即可。比如有人想用三元运算来实现传统的if-else语句。三元运算是标准的编程运算，这当然没问题，但是嵌套三元语句时问题就来了。letA=10;letB=3;letC=25;(A>B?A:B)//很好(A>B?(A>C?A:C):(B>C?B:C))//notfineif(A>B){(A>C?A:C)}else{(B>C?B:C)}//betterYAGNI(YouArentGonnaNeedIt)在生活中，人们做一件事计划提前做好准备。但这在编程中不是很适用。YAGNI原则谈到了这一点，永远不要为将来可能需要的功能编写代码。它可能不需要，而且这是浪费时间。您可以将此视为KISS原则的具体应用，同时也是对那些认真对待DRY原则的人的回应。没有经验的程序员通常会尽力避免编写最抽象和通用的代码，并避免使自己的代码变得笨拙。但是太多的抽象最终会导致无法维护的代码膨胀。你所做的是，只有当你看到需要抽象的代码时，才抽象代码。反之，不要将DRY原则应用于以后可能重复编写的代码。简而言之，活在当下，而不是未来。使用正确的工具来应用这些规则。有一些工具可以帮助您更轻松地遵循这些原则。比如前端开发者使用像Bit.dev这样的云组件中心来发布独立的组件。您需要找到这些工具。那么他们如何帮助程序员遵循这些原则呢？将组件构建为独立的代码片段（旨在作为独立代码发布、重用和协作）自然使每个开发人员更加注重单一职责原则。从任何代码库自由发布组件意味着可以共享和重用更多代码，并且不可避免地遵循DRY原则。这也意味着不要用从未使用过的UI组件构建一个完整的设计系统，而是遵循YAGNI原则，仅在需要时构建和发布每个组件。来源：unsplash编写干净易懂的代码听起来很简单，但实际做起来并不容易。今天，这已成为一项基本要求。我们需要不断练习，我们必须慢慢改变我们处理问题的方式，并以清晰的方式得出解决方案。这不是一夜之间的过渡，而是几个月和几个项目的积累。编程是一项团队合作的任务，项目的成功很大程度上取决于团队的表现。在努力不做“猪队友”的基础上，努力做带飞队的高手！
