怎样设置开发规范


规范的前提是在保证“正确”的前提下设置的。

对于软件开发来说(可能不限于此行业),每个公司都有各自的规范。需要开发人员在不同的规范之间进行各种切换。有些规范是天然要遵守的,有些规范却是模棱两可。

那么应该如何设置规范呢?

一、首先,不要创造规范。

为什么这么说呢?大多数我们面临的问题,”前人“都已经面临过很多次了,甚至成千上万的人遇到过类似的情况。《设计模式》这本书里有句话很好,”复用以前的经验而不需要重新发现它“。

我们希望能够将一些好的规范沿用下来,如果当前自己的项目需要一些定制的规则,那么也可以自己创建,并且要做出说明。
比如eslint(ts,js约束)的一些规范,有些规则实践已经被证明过。因此,我们可以选择 Airbnb的lint规范,也可以选择别的规范。然后根据当前项目,进行一些调整。建议不要自己去从零去设计规范。

二、其次,不要过于约束

规范是用来约束某些行为的。对于开发人员来说,规范就是约束开发人员代码怎样写,流程怎么做。
对于无法被工具禁止的行为,证明是有存在的必要的。哪些行为是好的,哪些行为是坏的,哪些行为有时又是不得不的呢?对于这些场景,我们应该怎么去适配我们的规范呢?
读者不知道是否有这样的场景:查看别人代码,总觉得不够优雅,貌似换个写法可以更加”好看“,然后理由是可能是‘代码块太长了’,‘回调太多了’,等等原因,而太长太多这些问题,都不是一个确定的用语,什么叫长?什么叫多?
那么,这段代码是好的还是坏的呢?那么,我们就应该查阅我们的规范,如果规范里面没有明确说明,那么,这段代码是”优雅“的——如果读者觉得不优雅,那请拿出证据。或许有些场景下,一个逻辑块里面的代码真的太长了,造成了阅读困扰。这个时候应该问下对方的意图,开发时候的上下文,而不是说代码是不”优雅“的,了解情况后再做判断(这个场景有点像code review)。
《法无禁止即可为》

三、划分规范等级

代码书写的时候,每个人的思路不一样,实现起来的方式也是不同,并不能要求每个人的方式都是统一的;对一些特性的理解,对一些场景的应用,千人千面。
在保证正确(代码运行正常)的情况下,我们应该划分行为的等级。比如,哪些是明确不能用的,哪些是建议不要用的,哪些是推荐使用的。比如,项目中有人使用了新的技术(可能不是新的,只是在项目里面用的人少),应该怎样看待这个情况,是禁止,还是提倡呢?

个人觉得,对于规范应该有保留四个选项:
1. 必须
2. 禁止
3. 建议
4. 不建议

对于必须、禁止,除非属于行业规范,或者约定成俗,那么被标记”必须,禁止“的,必须要有说明。
对于建议、不建议,则可以放宽,但是要让使用规范的人理解其中的含义。

结语

软件开发不应该是一个静态的状态,应该是随着新技术、新场景动态进步的一个状态。不应该拘泥一种形式,
做事情,所有的前提,应该统一在一定的规范下,而不应该是一些个人意志。

参考:

《设计模式》第一章引言
《Key words for use in RFCs to Indicate Requirement Levels》
https://datatracker.ietf.org/doc/html/rfc2119

本站声明:网站内容来源于网络,如有侵权,请联系我们,我们将及时处理。

  • 分享:
评论
还没有评论
    发表评论 说点什么