计算机常用的原则

在写代码的时候我们经常会有一些体会和经验所得,这些经验所得其实老早被之前的大神归纳成为原则。最近这一年我就一直在收集各种原则然后不断的运用和实践。

KISS 原则

KISS原则是英语 Keep ISimple, Stupid 的首字母缩略字。

KISS 原则是指在设计当中应当注重简约的原则。总结工程专业人员在设计过程中的经验,大多数系统的设计应保持简洁和单纯,而不掺入非必要的复杂性,这样的系统运作成效会取得最优。

正确的做法应该是当开发者遇到一个问题后,把问题拆分成一个个能够明白的小块,然后进入编码阶段。

  • 好处:

    • 你将可以通过很少的几行代码去解决复杂的问题。
    • 你将可以产出高质量的代码。
    • 当新的需求来了后,你的代码将会更加的灵活。
  • 怎么用:

    • 你不是天才,你的代码 stupid simple , 所以你没必要是天才。
    • 拆解问题。任务拆解为4-12小时的子任务。
    • 每个子任务用一个或者很少的类解决问题。保持类要小不用搞太多 uses case 在里面。
    • 保持方法足够短。30-40 行。
    • 任何场景尝试简单。

DRY 原则

don’t repeat yourself, 直译不要重复你自己。

这个原则其实在工作中特别常用,比如你的代码经常会写重复的,你就可以将它抽成一个函数。

但是我觉得最佳实践是:如果一件事情做了3次,才将它抽成一个函数或做抽象,因为过早的抽象会导致不够普适,不利于代码的维护。

YAGNI 原则

You aren’t gonna need it,YAGNI的意思是“你不需要它”:在必要之前不要做多余的事情。

这个原则主要是告诉我们不要太早的去思考一个问题,降低实现的成本。 虽然和前者有些矛盾,但是我们可以通过我上面提到 3 次重复再尝试抽象来做折中来实践会比较好一些。

单一责任原则

单一职责原则(Single Responsibility Principle),简单来说就是一个类只负责一个职责,而不能负责多个职责。在程序设计中,单一职责原则是一个很重要的原则,因为它能够帮助我们更好的组织代码,更好的管理代码,更好的解决问题。

让每个类做一个事情,而不是让每个类都做一个事情,这样对代码的维护和扩展都会更加方便。

面向接口编程原则

面向接口编程原则(Interface Segregation Principle),简单来说就是尽量使用多的接口,而不是使用多的类。

这样的好处是:将程序分为不同的模块,对外暴露的是上层的接口,而不是下层的类。这样当实现修改的时候,上层的接口不需要修改,只需要修改下层的类就可以了。