前言
在討論程式之前，先想像一下，如果一塊沒有良好都市計畫的土地，最後會發展成什麼樣子？
由於沒有良善的規劃，隨著人口增加，越來越壅擠的住宅空間，越來越雜亂的市容，原有道路交通設施的供給不足，天天都在塞車。即便要進行都市更新或是新建重大交通設施，要面臨的將是巨大的成本與溝通。
這就是都市計劃不良善帶來的結果。那我想寫程式也是一樣的道理，尤其是大型系統，如果沒有妥善的規範(Standards or Rules)，長期下來累積的各種workaround寫法或legacy code，寫出來的程式就像危樓一樣，岌岌可危卻不知道如何改建。
所以寫程式需要麽樣的規範？
很多人聽到寫程式還要受到規範，會覺得不是那麼開心，覺得受到限制，不能隨心所欲撰寫。但其實適度的規範，反而可以促進創意及效率，尤其是需要團隊合作的時候，更能感受到規範帶來的效益，為什麼？
框架
先從框架開始來討論。程式框架(Framework)通常伴隨著自己的生態系及社群，這些生態系有固定的用法及習慣，而其實這些默契或習慣，就是一種規範。
比如說，框架通常會規範Controller、Model、Router、View，⋯⋯等區塊，要怎麼放置或被使用，而這樣的規範，對程式撰寫來說，是比較高層級的抽象概念，也就是這樣的概念，形塑出「框架」，把每個區塊區隔開來。當然程式碼在你手上，愛怎麼改都可以，但是如果破壞了框架的習慣，硬是把Controller的程式放在Model裡面，對於其他人來說，就是怪怪的。
也就是這樣的分區、分層，讓開發者可以專注於某個區塊、層級，而不用過度擔心其他問題，因為人的大腦是有限的，要同時處理過多訊息，總是會混亂。
舉例來說，在處理View的時候，通常不用管資料庫是怎麼儲存的，商業邏輯是怎麼運作的，可以專注於怎麼把拿到手的資料，呈現給使用者看，並且針對呈現出來的樣式進行優化，因為不受到其他因素的干擾，所以可以有更大的空間實踐創意。而專注於View的開發者，也會針對View的需求，設計出專屬的工具、來增進工作效率。
也不是說，沒有框架就沒有規範，應該換個方面來講，通常成熟的框架，大概就已經把某一類型的應用，整理成比較好的規範了。所以不一樣的框架，通常就是為了解決不一樣的問題，大概就像是一樣都是把土地分區，但不同區域之中，也不同著重的點，就像花園城市、高科技園區、軟體園區這樣的感覺吧，一樣都是蓋一堆房子，但是這些房子的用途不一樣。
框架雖然限制了一些用法，但這些規範，卻帶來一些的好處，讓系統可以用健全的方式變大、變複雜，讓工程師可以更專注的解決問題。因此，就開發上來說，沒有框架，就要自己去想辦法訂出規範，否則最好還是一開始就使用框架。
程式碼
那至於真正實作的程式碼，也是有一些規範。在同一專案或公司裡面，通常會由技術負責人或是資深員工與同事討論後，制訂出這樣的標準及規範：
- 程式碼命名的的方式，變數、函式、類別等。
- 分類：程式碼要怎麼放。
- 函式庫的使用方式。
- ⋯⋯
如果說框架是劃分一個特定區域的使用方式的話，程式碼就是每個區域裡面蓋出來各式住宅或設施吧？
蓋房子也不是隨便蓋蓋，比如說每戶人家裡的插座應該都是一樣的吧？同樣的110V的插座，你家可以使用，在我家一定也可以使用，大家不用為了不同的規格去設計一大堆轉接頭或是重新研究插座怎麼使用。
也因為大家家裡都適用110V的插座，家電廠商在設計電器的時後只要符合這個標準就好。民眾也知道買回來的電器都能直接使用。
回過來程式碼，這就是為什麼寫程式的時候會有所謂的命名傳統(convention）或是模式(pattern)。因為這些東西都是大家了解且熟悉的，所以可以大大減少彼此之間的溝通成本以及降低合作時的摩擦。
同樣的，為什麼會制定出程式開發規範？就是為了減少「意外」發生，為什麼他寫的程式，我不能用、我看不懂？可能就是因為他沒有按照規範開發。
很多人在討論如何寫出好的程式碼，不外乎效能要好、要有可維護性、可擴充性、bug很少等等，這些我都認同。只是我想補充一點是，在一個團隊中，程式碼是人寫出來的，所以每個人對於「好」的認知都有誤差，因此透過適度的規範，來管理這些誤差，確實可以有效地提升團隊合作的效率。
規範是萬能的嗎？
規範當然不是萬能的，因為我們不能把所有事情都變成規範，那就會像是政府單位一樣，處理事情綁手綁腳的，甚至會反過來討價還價：「沒有這樣的規定，我不做。」或是需要重構改革的時候與既有規範牴觸，而造成程式開發流程僵化。
所以訂製規範的時候需要抓到剛剛好就好。
畢竟制定規範是為了能解決程式碼無法被妥善管理的問題，也是為了能夠讓之後的開發流程，更容易擴充及維護。如果過度制定規範，變成SOP狂人，那反而違背初衷了。