2019獨角獸企業重金招聘Python工程師標準>>>

談談技術規范的制定

幾乎所有的技術企業都會重視技術規范，但這些規范起到的實質作用就好比“請保持室內衛生，不準亂團垃圾，禁止隨地吐痰”。

筆者工作15年，這是15年經歷了很多，也在不同的公司任職過。幾乎每到一家公司都會遇到各種規范，隨著職業發展最后我也成為了規范的制定者，也曾經主持制定過開發規范，運維規范，測試規范等等。

我做過很多規范，文檔無數，技術人員根本不會去看，通過開會向下傳達，開會的人根本沒有心思理會你的規范，規范執行阻力是很大的，效果也差。

終于有一天我意識問題的存在，開始反思，企業是否需要制定這些規范。我發現這與現環境有很大關系，與企業文化有很大關系。http://netkiller.github.io/

有些強制的規范可以通過一些技術手段，避免出現。不會出現也就無需規范！

故事一

例如下面一個小故事，公司某部因為將開發數月的代碼丟失了，導致測試無法進行，領導打發雷霆，某管理層制定了下面的規范，大意為。

定期備份機制

代碼注釋要求

代碼訪問需要更高層的批準

詳細的部署文檔 等等

我認為源碼管理主要有兩種手段，技術手段與管理手段。

我先談談管理手段： 例如通常通過規章制度，責任追究等等手段，要求員工達到規范標準，但通常執行力都會打折，無法達到預期，人的不穩定性因素太多。往往發現員工沒有按照規范操作為時已晚，將該員工辭退也無法挽回公司的損失。http://netkiller.github.io/

就如公司規章制度寫的清清楚楚，要求員工提交代碼到版本庫，但各種原因沒有被執行，當代碼丟失，從上至下追究責任，公司的損失無法挽回。 在舉一個例子，運維工作要求備份數據，A員工負責備份，B 員工負責檢查A員工的備份，結果兩年以后出事了，需要恢復數據，發現A沒有備份，而B在一年前就再沒有檢查A的工作。起初前一年還是按流程備份，后來A發現B不再嚴格檢查工作，備份工作逐漸減少，最后停止了備份，一直相安無事，直到事發。

所以我主張技術手段： 例如源碼如果發布到線上，必須經過版本庫，只能使用自動部署，不允許程序員私自將代碼交給運維手工部署。另外發布代碼的同事，可以不提供生產服務器登陸權限，他只能通過工具發布代碼。 部署流程如下： 源碼(程序員) 提交到development 分支UAT階段 ----> 合并到 testing 分支Beta階段（主管合并，程序員沒有權限）------> master 分支(主管合并) -----> 自動部署系統(運維) ----> 生產服務器。 這樣通過技術手段防止了代碼因員工離職，硬盤損壞等等原因，導致代碼丟失的可能。 代碼發布者也無需對照部署文檔，手動登陸服務器逐條按照部署說明書操作，防止了人員誤操作，也提高了部署效率，節省了人力成本，通常在5分鐘之內可以完成所有部署。

故事二

我再來舉另外一個例子，就是開發中的編碼規范，很多軟件企業都有是不是？

例如要求程序員： if (){} 要寫成 if () { ... } 等等要求不一一列舉，甚至組織代碼評審解決編碼規范問題。

我的建議為什么不在IDE上設置自動格式化，或者在svn/git提交的時候通過hook調用格式化程序。http://netkiller.github.io/

故事三

管理層要求運維每天發送服務器狀態報告，運維人員需要登錄每個服務器或者從cacti等工具中獲得服務器運行狀態數據，然后制作一個報告文檔，每天給各位發送一次。

運維需要一個專職人員做這個報告，這種報告幾乎沒有人看，就像“人民日報” 人民從來不看。

當運維事故該出現的時候還是會出現，老板一個一個罵，扣工資，扣獎金，運維覺得委屈，公司受到損失。平日里的這些工作并不能避免運維事故，也不能改善運維工作。

我覺得很多規范是形式主義。我一向主張實用主義。

通過技術手段可能避免很多沒有意義規范，開發自動化，測試自動化，運維自動化，這是趨勢也是我的努力的目標。

上面僅僅舉了幾個例子，較片面，不能完全表達我的想法，需要更多的溝通，歡迎提出您的意見與建議。

出處?http://netkiller.github.io/

轉載于:https://my.oschina.net/neochen/blog/392762

總結

以上是生活随笔為你收集整理的谈谈技术规范的制定的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。