IT系统设计中的5S原则

Posted 2020-06-13

5S原则：Simple, Solid, Strong, Safe, Smart.

 

Simple

Simple就是简单原则，这里的简单有两个意思，一个是逻辑简单容易理解，另一个是架构简单耦合性弱。

按照模块化设计的方法，通常我们在设计时，首先界定系统的边界，然后在系统内划分模块，然后在模块内划分功能点。

通常在进行自顶向下设计的时候，Simple原则是很容易遵守的，但是有时功能是在慢慢增强的，从一个功能点成长为一个系统，在后期开发的时候往往会对前期的设计进行重构，这是相当痛苦的。

举一个制造系统的例子。

比如车间有一个工位，要求工人做装配的活，装配完成后做质量检查。严格地说，这个工人集成了两个角色：装配工和质检员，但是由于生产技术难度低，对生产节拍要求也低，因此为了节省人力成本，这两个动作由同一个人完成。而对应的IT系统功能将逻辑也统一起来，以方便用户操作。

但是后来生产节拍要求越来越高，为了提升效率，车间招募了新的工人，一个工位变成了两个工位，一个人的活变成了两个人的活，其中一人专门做装配，另一人专门做质检。这时要求IT系统将功能拆分出来，将一个逻辑变成了两个逻辑。

通常为了减少开发的时间，我们可以在原先的完整逻辑中增加若干个IF THEN ELSE的判断，然后让不同的角色执行不同的逻辑块。也就是说，先加载逻辑，再判断执行。

另一种设计思路是，在第一次开发的初期，按照Simple原则进行分析，将装配的逻辑和质检的逻辑分别封闭成逻辑块，在实施的时候根据配置的情况进行组合。对应的，变更前一个用户执行两个角色的逻辑，变更后两个用户各执行对应角色的逻辑。后台的代码只负责各自独立的逻辑，前台的展现则根据配置的情况对逻辑进行组合。

 

Solid

Solid就是逻辑要牢固完整。

业务逻辑的完整可以减少系统的异常，从而提升系统的可用性。

执行Solid原则的一个有效方法是黑箱测试，让用户撰写测试场景，让用户进行接收测试。

开发人员往往想到正常的业务流，而用户则熟悉更多异常的业务流，而对异常业务流的测试可以提升逻辑的完整性。

 

Strong

Strong就是系统要可靠，能够支持多并发性、多用户、大数据量，通过各种方式减少当机时间。

硬件方面，可以通过Cluster、Load Balance等提升系统的可用性。

软件方面，可以通过缓存、读写分离、用户分组、冗余、归档、数据库分区等技术减少计算时间。

保持Strong的一个简单原则是找到并解决瓶颈所在。比如某个系统的瓶颈是跑某个特定的报表，如果几个人在同一个时间段跑此报表，则造成数据库查询长时间等待。解决的办法是从硬件的角度提升数据库的查询效率，或者优先查询语句及表结构，还有一种办法是在用户允许的情况下，对查询请求进行调度，比如提前在空闲的时间段事先在后台执行查询。

 

Safe

Safe就是安全原则，通过各种办法避免系统服务的中断。

在IT系统中，黑天鹅事件(无法预测的异常事件)是难以避免的，解决的办法是不断累积异常处理措施，每当有异常的时候，通过报错、日志、通知等方式将异常处理，从而避免系统服务的中断。

系统在设计的时候，应该规划一个可配置的异常处理模块，这样可避免在重写核心代码的情况下实现异常的及时处理。

 

Smart

Smart就是聪明原则。

现在网络上开源的代码、模块、方法论很多，许多互联网的应用也可以借用到企业系统。

比如Map-Reduce是GOOGLE倡导的方法论，实际上许多包括大量IF THEN ELSE的代码都可以利用Map-Reduce进行逻辑的简化。