前言一个轻量简洁的软件架构是非常重要的，它可以让我们花最少的成本来满足业务需求。那么如何保持它的轻量和简单呢？所以今天给大家分享的秘诀，就是三个重要的指导原则，KISS原则，YAGNI原则和DRY原则。大家都知道并了解吗？KISS原则KISS原则，英文全称Keepitsimpleandstupid。核心思想是尽可能简单。KISS原则指导我们在设计软件时尽量保持简单，使用一些适合业务的成熟技术方案。另外，站在用户的角度，你在设计的时候，应该想一想如何让自己的架构设计简单易用。比如你开发的框架接入成本是不是很低，甚至是零？没有破解业务代码？不仅在软件架构设计层面，在代码层面，都要处处体现KISS原则。代码可读性和可维护性是衡量代码质量的两个非常重要的标准。KISS原则是保持代码可读性和可维护性的重要手段。代码足够简单，这意味着它易于阅读和理解，而且bug更难隐藏。即使确实出现了错误，修复起来也相对简单。来看看下面三种验证IP是否合法的实现方式，哪一种最“KISS”，你觉得哪一种最多？方法一、方法二、方法三，方法一代码量最少，正则表达式本身也比较复杂。编写一个完全没有错误的正则表达式是非常具有挑战性的；另一方面，并??不是每个程序员都精通正则表达式。.对于不太了解正则表达式的同事来说，理解和维护这个正则表达式是比较困难的。这种实现方式会导致代码的可读性和可维护性差。因此，从KISS原则的设计初衷来看，这种实现方式并不符合KISS原则。第二种方法使用StringUtils类和Integer类提供的一些现成的工具函数来处理IP地址字符串，逻辑清晰，可读性好。方法三没有使用任何工具函数，而是对IP地址中的字符进行逐一处理，判断是否合法，容易出错，不易理解。总结：整体来说，第二种方式更符合KISS原则。并不是代码越少越好，还要考虑代码是否逻辑清晰、易懂、足够稳定。那么如何写出符合KISS原则的代码呢？不要使用同事可能不理解的技术来实现代码。比如前面例子中的正则表达式，还有一些编程语言中过于高级的语法。不要重新发明轮子，而是要善于利用已有的工具库。经验证明，如果自己实现这些类库，出现bug的概率会更高，维护成本也会更高。不要过度优化。不要过度使用一些技巧和技巧（例如，用位运算代替算术运算，用复杂的条件语句代替if-else，使用一些太底层的函数等）来优化代码，牺牲代码的可读性.YAGNI原则的英文全称是：YouAin'tGonnaNeedIt。中文的大体意思是你根本不需要这样做。核心思想是不要过度设计。那么什么是过度设计呢？比如你的应用还处于单体应用的阶段，那么这个时候我就在想怎么去做分布式事务，或者你的数据库还是单体的时候，我就在想。数据异构怎么办，即使你的业务逻辑不复杂，你也要考虑怎么用工作流引擎或者规则引擎。再比如现在图数据库很流行，所以你想在自己的项目中引入图数据库。这些是什么？说白了，叫做面向简历的编程，说白了，它是什么？脱裤子放屁，多此一举。提倡面向未来的架构是什么意思？就是规划你未来的技术发展路线，当这一天需要到来的时候，你有能力去实现。而不是说你现在把以后不需要的东西搬到自己的项目中去。所以不要为了技术而依赖技术。让科技服务于商业。遵循YAGNI原则。过度设计是一场灾难。DRY原则DRY原则，英文全称是Don'tRepeatYourself，直译就是不要重复自己。这里的重复是什么意思？这是否意味着代码完全相同？其实不是，我是从逻辑重复、功能语义重复和代码执行重复的实现来理解重复的意义的。下面看下实现逻辑重复的例子：验证用户名和验证密码上面两种方法的代码逻辑虽然重复了，但是它们的语义并不重复，一个用于验证用户名，一个用于验证用户名来验证Password，所以符合DRY原则。如果我们强行将它们封装到isValidUsernameOrPassword()方法中，不符合单一职责原则。如果有一天密码验证逻辑发生变化怎么办？所以并不代表同样的代码就一定违反DRY原则。相反，有时代码不一样，恰好违反了DRY原则。功能语义重复，直接提到例子。项目中不同的同事写了两种验证IP的方法，因为他们不知道。代码1代码2虽然两段代码的实现逻辑没有重复，但是语义重复，也就是函数的重复，我们认为违反了DRY原则。我们应该在项目中统一一个实现思路，在所有用于判断IP地址是否合法的地方统一调用同一个函数。否则哪天验证规则改了，很容易只改其中一个而漏掉另一个，就会出现莫名其妙的bug。代码执行重复让我们看下面的登录代码示例。你有没有注意到邮件的验证逻辑被执行了两次？我们也可以认为这种重复执行违反了DRY原则。说了这么多，有没有什么好的方法可以提高代码复用性，保证DRY原则呢？使用现成的轮子，不要轻易造轮子。其实写代码最重要的是动脑筋。使用方法时，首先检查是否有现成的轮子。别看它，就在那里造轮子。降低代码耦合对于耦合度高的代码，当我们想复用其中一个函数，将这个函数的代码抽离到一个独立的模块、类或函数中时，往往会发现牵一发而动全身。移动一点点代码会涉及很多其他相关代码。因此，高耦合的代码会影响代码的复用性，我们应该尽量减少代码耦合。满足单一职责原则前面说过，如果职责不够单一，模块和类都设计得大而全，那么依赖它的代码或者它所依赖的代码就会更多，这样会增加代码的耦合度。根据以上几点，也会影响代码的复用性。相反，越细粒度的代码，代码的通用性越好，越容易被复用。模块化这里的“模块”不仅仅指由一组类组成的模块，也可以理解为单个类或函数。我们必须善于将功能独立的代码封装成模块。独立的模块就像积木一样，更容易复用，可以直接用来构建更复杂的系统。业务逻辑和非业务逻辑分离意味着与业务无关的代码更容易复用，越是业务专用的代码越难复用。因此，为了复用与业务无关的代码，我们将业务逻辑代码和非业务逻辑代码分离，抽取到一些通用的框架、类库、组件等中。一般代码下沉从分层的角度来看，越低代码越通用，就会被更多的模块调用，越要设计成可复用的。一般来说，代码分层后，为了避免交叉调用造成的调用关系混乱，我们只允许上层代码调用下层代码和同层代码之间的调用，并防止下层代码调用上层代码。因此，对于公共代码，我们尽量下沉。继承、多态、抽象、封装在讲面向对象的特性时，我们提到通过继承可以将公共代码抽取出来到父类中，子类可以复用父类的属性和方法。利用多态性，我们可以动态地替换一段代码的部分逻辑，使代码具有可重用性。另外，抽象和封装，如果从更广的层面而不是从更窄的层面来理解面向对象的特性，越抽象，对具体实现的依赖越少，越容易重用。将代码封装成模块，隐藏变量细节，暴露不变的接口，越容易复用。一些设计模式，例如应用程序模板，也可以提高代码的可重用性。比如模板模式是利用多态性实现的，可以灵活替换部分代码，整个流程模板代码可以复用。综上所述，本文介绍了在软件工程领域维护简单架构设计的三个原则。事实上，所有这些原则都是为了实现一个非常简单的目标。尽一切努力保持简单。简单轻量级的软件设计非常重要。的。
