堅持住啊，還在代碼屎山中爬行的同事們-有解無憂

"There are only two hard things in Computer Science: cache invalidation and naming things."

— Phil Karlton

在計算機領域只有兩件艱難的事情：快取失效和物件命名，

這還真不是一個笑話，寫代碼是比較容易的事情，但是閱讀別人的代碼，那就因人而異了，

好的工程師寫出來的代碼可讀性很高，比如我上家公司的同事旭總，一般的工程師寫出來的代碼就像是一坨屎，比如之前某某幾位同事，

所以我會經常去格式化他們的代碼，如果不幸輪到你繼續在屎代碼上面開發，那就是屎上堆屎了，心疼你，

當然有時候工期緊張，我自己也會寫一些屎代碼shit code，但是每次提交的時候都有一種強烈的愧疚感，希望這些代碼最多存活一個月就消失，不要被人踩到了，

屎代碼是怎么產生的？

要說怎么寫屎代碼，這個我就很拿手了，下面隨便列舉一些常見的屎代碼產生方式：

很不幸，大多數人的專案中，這些常見的屎代碼產生方式是隨處可見的，

畢竟，幾百個人寫屎代碼，就像幾百個人堆積木，堆得歪歪扭扭，搖搖晃晃，亂七八糟，你千萬不能抽里面的積木，指不定抽了一塊就塌了，只能看見哪里覺得不牢靠不停的往那邊填積木，只要不倒就好了，這也是大部分程式員的追求了，

如果想解決代碼高耦合這坨屎，需要有比較好的頂層解耦設計，劃分清楚各自服務的邊界，

如果你一直都只是代碼搬運工，傳說中的cv工程師，那么到這一步還有一些內功需要你去修煉的，

但是好的命名規范確實每個人都可以做到的，不同的語言都有各自的規范，如果所有人都能正確理解那些規范，并且嚴格遵守，同時強制使用ci校驗，就可以保證代碼外表上是美觀的，

這里就以Go語言的命名規范為例講一下怎么寫出人人都想聞的香代碼，

go fmt可以統一不同人的編碼規范，卻沒有辦法格式化出一個好的命名，但是在Go社區中其實一直都存在著一些成文的或者不成文的命名規則，比如：

總之，規則是有的，只是很多程式員選擇直接忽視，比如前面的五條，

還有一些規則是被過渡濫用了，比如第6條，很多同事的命名沿用以前的老風格，在一個struct中大量使用單字符的的變數或者隨心所欲的縮寫，這樣的代碼是完全沒有辦法閱讀的，所謂有追求的程式員，還是得追求一下代碼的品味，

悲觀的說，即使做到了這些也只是你一個人的代碼是優雅的，但是你怎么能保證所有人都有這樣的追求呢？作為個人，除了提建議之外，其實是沒有太多有效的辦法的，

想根治這個問題，只靠某個程式員一直保持優雅代碼是沒什么用的，

你寫10句優雅的代碼，其他10個同事每個人都寫10句屎代碼，這樣算起來，優雅代碼的比例最多只有十分之一，

如果一個團隊想要徹底解決屎上堆屎這個老大難問題，就需要貫徹執行下面兩點方法：

深度悲觀的說，這兩個方法真正執行起來的時候也是難度重重，基本不可能完成，

高質量無論是不是在互聯網行業，都意味著價格昂貴，但又有幾家公司能給得雇傭的起這么多昂貴的程式員呢？

而長遠的目標在資本的壓力之下，也顯得一文不值，代碼規范提升10%的重要性和“明天上線”這個命令比起來，也是低到塵埃的的，然后日復一日，明天又將是明天，規范性最終消失殆盡，屎山越來越高，

說到底，這些都是錢的問題，也是最無解的問題，最終在某一天，屎山崩潰，一切回到原點，

最后，大膽猜測一下，昨天的Google服務崩潰也是因為屎太多了吧，

記得幫我點贊哦！

精心整理了計算機各個方向的從入門、進階、實戰的視頻課程和電子書，按照目錄合理分類，總能找到你需要的學習資料，還在等什么？快去關注下載吧！！！

resource-introduce

念念不忘，必有回響，小伙伴們幫我點個贊吧，非常感謝，

我是職場亮哥，YY高級軟體工程師、四年作業經驗，拒絕咸魚爭當龍頭的斜杠程式員，

聽我說，進步多，程式人生一把梭

如果有幸能幫到你，請幫我點個【贊】，給個關注，如果能順帶評論給個鼓勵，將不勝感激，

職場亮哥文章串列：更多文章

wechat-platform-guide-attention

本人所有文章、回答都與著作權保護平臺有合作，著作權歸職場亮哥所有，未經授權，轉載必究！

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/234996.html

標籤：其他