程式設計師槍擊事件引發的背後思考

程式員槍擊事件在我所關注的知識分享公眾號和技術群方面傳播的比較廣。

針對該事件我要談談我的看法。

針對該公眾號所說的，因註釋不寫、程式碼排版差、非駝峰命名和天天git push -f導致該程式設計師槍擊自己的四位同事。

我個人有如下想法，並列出對應的角度分析。

從開發角度看:

註釋不寫、程式碼排版差和非駝峰命名的確會導致程式碼的可維護性差，因為其他同事有的時候根據業務的需求，需要改動你的程式碼，如果你的程式碼是這樣的，那麼就會導致需要改動你程式碼的同事難以理解你的程式碼邏輯，從而增加時間成本，也許那一天都在梳理你的程式碼思路，並打斷點debug逆向推導。

另外我個人也覺得，一家軟體公司如果是初創公司，一般都會招有經驗的開發者，而那些有經驗的開發者們，一般像註釋、排版、駝峰命名都會注重的。當然了，由於每個人對業務的理解不一樣，導致編寫的程式碼行數也不一樣，過長，比如一大堆if-else之類的，反而會降低可讀性，過短的話，根據實際情況定，如果像一些邏輯驗證判斷(比如賬戶驗證之類的，那麼該長還是要長的)，還是要的。另外，像初創公司一般情況下，至少會有一個經驗豐富的專案經理和專案組長，專案經理一般都會要求專案組長制定開發計劃，比如同有關人員商議討論，編寫可行性方案文件，如果該文件由專案經理確定後沒問題，下面進入需求分析、概要設計、詳細設計、編碼、測試、上線。這一個過程就是有名的瀑布模型。現在比較流行的是敏捷開發，敏捷開發總的來說與瀑布模型還是有相同點的，只不過驅動開發的方式不同，比如原型驅動開發(做一個靜態模板原型給客戶看，客戶覺得沒問題正是他想要的這樣，那麼就可以繼續開發下去，通常情況下，這種方式的好處是客戶基本都能滿意，就算不滿意的話，成本相對於瀑布模型而言低的多。

從人際交往的角度看:

假如是我，如果經常git push -f強制將原生代碼提交到遠端，那麼一定會有同事會說，為什麼我之前寫的功能沒有了，昨天是誰提交的，對於經常性git push -f的人，同事也不是傻子，直接會提醒你不要這麼做，會告訴你正常的流程應該是當自己該分支對應的功能開發完畢時，將要提交程式碼，首先提交到本地倉庫 並git merge遠端主分支解決對應的衝突，當衝突解決完畢時，再git push 遠端倉庫master主分支，這是正常流程。如果這位人士真的這麼幹，那麼對於他而言，他將會受到團隊的排擠，身處團隊不為其他人著想，那麼對於他而言，上班將會成為一個地獄，同事的冷眼和領導的批評，最終他的結局將會被開除。

當然了，如果這位人士心理不平衡的話，的確可能會導致他將自己的不快發洩到其他人身上，從而可能引發某種暴力行為。

從團隊協作的角度看:

此前我在該篇文章ofollow,noindex" target="_blank">談談運維人員謹慎作業系統環境和管理 說過，開發的要懂測試和運維，測試的要懂開發和運維，運維要懂開發和測試等，彼此都要熟悉彼此的領域和分工，因為這樣會提高整個團隊的協作能力。當然了，像產品經理對於開發、測試、運維都多少熟悉和了解，那麼實際提需求的時候，彼此換位思考也能降低不少開發成本。但是，往往做不到這樣，這也是一個公司裡，運維時常淪為背鍋戶，測試說開發，開發說測試，產品說測試，測試說開發，產品說開發等等，最後可能會出現內部鬥爭，內部鬥爭勢必會造成團隊裡部分人會因此受到傷害，一切在於協作，再細分，在於溝通。溝通很重要。良好的溝通，利於良好的協作，良好的協作利於專案開發的良性迴圈。

從團隊領袖的角度看:

通常一般團隊的主要負責人是專案經理，然後再是對應的開發組組長。這裡我要說說開發組組長，開發組組長的職責不僅僅是專案使用技術的把關，功能模組分配，文件編寫，幫助其成員梳理需求並理解需求和其他開發小組對應的負責人共同商議制定良好的開發規範，還有對團隊成員必須要熟悉，這個熟悉不單單等同認識，包括編寫程式碼的風格、技術能力、思考問題的方式還有就是性格等，都要了解。有的時候團隊的某個成員圖痛快，改其他同事的程式碼，絲毫不與人家溝通，從而提交到線上，導致影響到該同事的正常功能，從而造成不必要的bug,這時測試人員就會提醒開發人員，而開發人員性格一般比較犟，自己已經寫好並在之前測試好的功能突然就不行了，這時可能會與測試人員爭論一番或者是開發人員之間開始吵架，作為開發組組長而言，這時一定要公平公正耐心的處理好。否則，一旦憤怒不平的種子埋在心裡，將會因為生活中的一點小事導致衝突，這種衝突時常表現的形式就是口頭衝突，這種口頭衝突時常會轉化為暴力行為。這也是為什麼這個社會犯罪率上升的原因之一。

小結:

上述列出的四個角度，從開發、人際、團隊協作到團隊領袖等，有些是本人的親身體會，有些來自同學們的親身經歷，當然了，還有些來自平時的閱讀感觸。

希望能給大家帶來幫助。