怎樣設置開發規範
規範的前提是在保證「正確」的前提下設置的。
對於軟體開發來說（可能不限於此行業），每個公司都有各自的規範。需要開發人員在不同的規範之間進行各種切換。有些規範是天然要遵守的，有些規範卻是模稜兩可。
那麼應該如何設置規範呢？
一、首先，不要創造規範。
為什麼這麼說呢？大多數我們面臨的問題，」前人「都已經面臨過很多次了，甚至成千上萬的人遇到過類似的情況。《設計模式》這本書里有句話很好，」復用以前的經驗而不需要重新發現它「。
我們希望能夠將一些好的規範沿用下來，如果當前自己的項目需要一些訂製的規則，那麼也可以自己創建，並且要做出說明。
比如eslint（ts，js約束）的一些規範，有些規則實踐已經被證明過。因此，我們可以選擇 Airbnb的lint規範，也可以選擇別的規範。然後根據當前項目，進行一些調整。建議不要自己去從零去設計規範。
二、其次，不要過於約束
規範是用來約束某些行為的。對於開發人員來說，規範就是約束開發人員程式碼怎樣寫，流程怎麼做。
對於無法被工具禁止的行為，證明是有存在的必要的。哪些行為是好的，哪些行為是壞的，哪些行為有時又是不得不的呢？對於這些場景，我們應該怎麼去適配我們的規範呢？
讀者不知道是否有這樣的場景：查看別人程式碼，總覺得不夠優雅，貌似換個寫法可以更加」好看「，然後理由是可能是『程式碼塊太長了』，『回調太多了』，等等原因，而太長太多這些問題，都不是一個確定的用語，什麼叫長？什麼叫多？
那麼，這段程式碼是好的還是壞的呢？那麼，我們就應該查閱我們的規範，如果規範裡面沒有明確說明，那麼，這段程式碼是」優雅「的——如果讀者覺得不優雅，那請拿出證據。或許有些場景下，一個邏輯塊裡面的程式碼真的太長了，造成了閱讀困擾。這個時候應該問下對方的意圖，開發時候的上下文，而不是說程式碼是不」優雅「的，了解情況後再做判斷（這個場景有點像code review）。
《法無禁止即可為》
三、劃分規範等級
程式碼書寫的時候，每個人的思路不一樣，實現起來的方式也是不同，並不能要求每個人的方式都是統一的；對一些特性的理解，對一些場景的應用，千人千面。
在保證正確（程式碼運行正常）的情況下，我們應該劃分行為的等級。比如，哪些是明確不能用的，哪些是建議不要用的，哪些是推薦使用的。比如，項目中有人使用了新的技術（可能不是新的，只是在項目裡面用的人少），應該怎樣看待這個情況，是禁止，還是提倡呢？
個人覺得，對於規範應該有保留四個選項：
1. 必須
2. 禁止
3. 建議
4. 不建議
對於必須、禁止，除非屬於行業規範，或者約定成俗，那麼被標記」必須，禁止「的，必須要有說明。
對於建議、不建議，則可以放寬，但是要讓使用規範的人理解其中的含義。
結語
軟體開發不應該是一個靜態的狀態，應該是隨著新技術、新場景動態進步的一個狀態。不應該拘泥一種形式，
做事情，所有的前提，應該統一在一定的規範下，而不應該是一些個人意志。
參考：
《設計模式》第一章引言
《Key words for use in RFCs to Indicate Requirement Levels》
//datatracker.ietf.org/doc/html/rfc2119
