程式員槍擊事件引發的背後思考

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

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

針對該公衆号所說的，因注釋不寫、代碼排版差、非駝峰命名和天天git push -f導緻該程式員槍擊自己的四位同僚。

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

從開發角度看:

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

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

從人際交往的角度看:

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

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

從團隊協作的角度看:

此前我在該篇文章

談談運維人員謹慎作業系統環境和管理

說過，開發的要懂測試和運維，測試的要懂開發和運維，運維要懂開發和測試等，彼此都要熟悉彼此的領域和分工，因為這樣會提高整個團隊的協作能力。當然了，像産品經理對于開發、測試、運維都多少熟悉和了解，那麼實際提需求的時候，彼此換位思考也能降低不少開發成本。但是，往往做不到這樣，這也是一個公司裡，運維時常淪為背鍋戶，測試說開發，開發說測試，産品說測試，測試說開發，産品說開發等等，最後可能會出現内部鬥争，内部鬥争勢必會造成團隊裡部分人會是以受到傷害，一切在于協作，再細分，在于溝通。溝通很重要。良好的溝通，利于良好的協作，良好的協作利于項目開發的良性循環。

從團隊領袖的角度看:

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

 小結:

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

希望能給大家帶來幫助。