前言
今天跟大家分享一个在实际软件开发过程中，很有用的一个设计原则即KISS原则(Keep It Simple, Stupid)。
主要想跟大家分享一下其核心理念，重点介绍一下我是怎么利用它来设计软件项目的，以此来降低软件开发的整体复杂性，降低出错率，并使得系统更加易于理解和维护。
我的分享
关于什么是KISS原则，在这里我并不想过多阐述，网上资料也很多，感兴趣的小伙伴，可以深入去了解一下细节。
KISS原则，全称是“Keep It Simple, Stupid”或“Keep It Short and Simple”，是一种设计原则，旨在倡导在系统设计、软件开发、产品设计、通信交流等各个领域中，都应尽量保持简单明了，避免过度复杂化和冗余。 这个原则强调简洁性、直接性和易用性，认为简单的设计往往更加可靠、易于理解和维护
这里，我简单介绍一下其核心思想，一句话说清楚即大道至简。
这个原则认为架构是可以演进的，我们平时做的软件架构，应避免过度设计，尽可能的做到简单、明了，因为只有这样设计出来的系统，才能做到系统运行的较为稳健，不易出错。
OK，再回到我做的项目身上，跟大家做个介绍。我是怎么利用它降低一个需求的功能复杂度，做到快速开发、提测、上线。
事情大致是这样的，我们前段时间，产品提了一个关于协同工单的一个需求。
这个需求要做的功能还不少，跟我们已有的客服工单功能有很多相似性，也有一些不同点。
因为原有的工单功能，业务较复杂，而且请求量和数据量也较大，经过多次迭代后，架构方案会显得比较复杂（当然这也无可厚非，什么阶段填什么坑嘛）。
比如存储层面我们用了Mysql分库分表方案，之后会异步写入ES，工单列表界面数据查询我们直接从ES查询。（其他细节这里就过多展开了）
刚有提到，这次新的协同工单需求功能，和以往的工单功能有很多相似性，如果单从这个角度出发，那是不是代表可以照搬照抄，以往的一系列方案呢，比如Mysql分库分表、ES存储查询等等？
答案是No，还是要具体情况具体分析。
当时，我仔细打听了一下这个业务的实际数据情况。
被告知，这个协同单，每天实际产生的量并不高，一天顶天1000来单，可能更少。
主要都是内部客服人员在界面手动提交产生，它不像外部工单，有超多外部来源➕内部界面提交产生。
所以在这样的背景下，如果用以往的工单方案来做设计，明显不适合，架构显得太过重且复杂。
当时，我就想到了KISS这一原则，用它的思想，做了一下取舍。
存储层面砍掉了ES这座大山，直接走Mysql。mysql也不再需要分库分表了，对于协同工单表，设计成为“宽表”，这样前台界面查询会很方便。
至从这样设计后，很多东西变的极其简单，结合传统MVC开发模式，一下子就将这个需求给搞定了，时间也从原来的毛估1个月降到半个月，而且反响很不错。
小结
今天的分享，已接近尾声，跟大家做个小结。
这次跟大家分享了一个软件设计里较为有名的一个原则—KISS原则。
简单的给大家阐述了其语义，重点跟大家介绍了一下，在实际的软件开发过程中，我是怎么利用它，来指导软件架构设计，以此来降低软件开发的复杂度，做到快速交付需求。
所以，大家平时的软件架构设计中，并不是不是越复杂越好（比如用了很多你认为牛逼的技术），一定是什么阶段才用什么矛。
一定记住，很多复杂架构，真的是被逼到那个绝境，才做的妥协与应对，一开始完全没必要这样，我们做项目重点，还是要尽可能做到简单、在不影响性能、质量的前提下，做到快速交付！
