近日，在 V2EX 社群的“分享發現”板塊，爆出了一則名為《蝦米 mac 客戶端發現個好玩的註釋》帖子。該帖一出，迅速引發了強烈討論，相信你已經有所耳聞。
本著“闡述事情經過，不看熱鬧不搞事”的原則，我們一起基於事實做出總結和思考。
1. 事情經過
事情起於 V2EX 上一則名為《蝦米 mac 客戶端發現個好玩的註釋》的帖子，帖子原址為 www.v2ex.com/t/407653?p=1，截圖如下：
看到這兒，肯定有人質疑了：居然能看到如此清晰的原始碼？
先彆著急，在這兒給大家簡單科普下：
蝦米 mac 客戶端是基於 Electron 框架搭建的，由於沒有對 release 程式碼做混淆和壓縮保護，所以提取出來的跟原始碼沒有區別。
具體的檢視和分析流程，感興趣的可以自行查閱，就不再貼出來了。總之就是在 Mac 客戶端上，通過檢視應用包內容，找到 app.asar 檔案，然後使用文字檢視軟體開啟，就可以看到。由於官方在第一時間刪除了相關注釋併發版，所以現在已經看不到了。當然，這不是重點。
2. 網友看法
事實在這兒擺著了，網友們也紛紛表達了作為局外人的看法。
來自業內的網友：
作為一名碼農，深知程式碼、文件、註釋這種東西不光你的同事領導會看，在你離職的幾年後都有不認識的人會看到，深表惶恐，哪敢亂寫？
這其實反應了現代軟體工程的一個現狀——閱讀並理解別人的程式碼是如此麻煩，以至於從中型專案開始，系統的一個模組的程式碼往往只有寫它的那個工程師認真看過，其他人處於人人手頭一攤事的狀態，也沒法去認真審閱，中間自然存在巨大的個人‘發揮’空間。
這程式碼居然能過 review ？
也有透過現象看本質的：
在此次事件中, 也有人看出了編譯型語言的“優越性“, 暴露了解釋型語言的不足。編譯型語言需要專門的直譯器進行“翻譯”，普通使用者無法直接查閱程式碼的含義。
更有類似文科生的觀點：
此次事件，表明了編譯型語言的優越性，暴露了解釋型語言的不足。充分說明了，現階段程式開發的主要矛盾，是日益增長的開發需求同編譯型語言開發速度低下之間的矛盾。
3. 後續進展
此次事件之後嗎，蝦米客戶端連夜過審程式碼，刪除蝦米音樂客戶端中的不當用語，修復了檔案混淆失效的 BUG，並及時更新了版本。
而對於大家關心的誰來背鍋的問題，最終在知乎有一位程式設計師站出來公開道歉了，由於匿了，所以是誰也不得而知，我們也沒必要知道，截個圖就過了吧。
4. 個人觀點
人非聖賢，孰能無過。
作為程式設計師的我，可能天生老實，每每看到這類事情，總會想到這句聖賢之語。
但就事論事，我們可以不做吃瓜群眾，看熱鬧不嫌事大，但我們至少應該有自己的觀點。
往小了說，是程式設計師小哥對待工作不嚴謹，在程式碼中加入了不當的註釋。PS：話說回來，那些從不加註釋的同學才更可怕…
往大了說，就可以上升到個人品行問題，公司價值觀問題。
總之，工作態度問題也好，個人品行和公司價值觀也罷，事情已經過去了，相應的彌補措施和道歉已經落實，我們窮追已然沒有任何意義。
回過頭來，作為局外人，我們是否應該有一些借鑑和思考呢？否則我們和吃群眾有何兩異？
-
正如《黑客與畫家》一書中所說的，“程式寫出來是給人看的，附帶能在機器上執行”，所以，請認真對待你寫的每一行程式碼，每一句註釋。
-
如果有可能，請推行或配合 Code Review，能在開發階段發現許多不規範或者顯而易見的問題。假若條件不允許，也請在提交前，自行 Review 所做的修改。
-
認真對待發版，對自己的產品負責，正如對自己的孩子一樣，悉心、謹慎。試想，如果蝦米的程式設計師做好了這一點，就不會有著一系列事件，當然，事情發生了，再小的問題，哪怕只是無須有的註釋，都會釀成大禍。
-
最後，敬畏程式碼，敬畏使用者，對一切人、事保始終持敬畏之心。
