标签：设计规范 理由 怎么 href 就是 了解情况 了解 com 并且
规范的前提是在保证“正确”的前提下设置的。
对于软件开发来说（可能不限于此行业），每个公司都有各自的规范。需要开发人员在不同的规范之间进行各种切换。有些规范是天然要遵守的，有些规范却是模棱两可。
那么应该如何设置规范呢？
为什么这么说呢？大多数我们面临的问题，”前人“都已经面临过很多次了，甚至成千上万的人遇到过类似的情况。《设计模式》这本书里有句话很好，”复用以前的经验而不需要重新发现它“。
我们希望能够将一些好的规范沿用下来，如果当前自己的项目需要一些定制的规则，那么也可以自己创建，并且要做出说明。
比如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
标签：设计规范 理由 怎么 href 就是 了解情况 了解 com 并且
原文地址：https://www.cnblogs.com/wyy5552/p/14855773.html
