程序員槍擊事件引起的背後思考

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

針對該事件我要談談個人見解。

 

針對該公衆號所說的，因註釋不寫、代碼排版差、非駝峯命名和每天git push -f致使該程序員槍擊本身的四位同事。

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

從開發角度看:

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

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

 

從人際交往的角度看:

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

固然了，若是這位人士心理不平衡的話，的確可能會致使他將本身的不快發泄到其餘人身上，從而可能引起某種暴力行爲。

 

從團隊協做的角度看:

此前我在該篇文章談談運維人員謹慎操做系統環境和管理說過，開發的要懂測試和運維，測試的要懂開發和運維，運維要懂開發和測試等，彼此都要熟悉彼此的領域和分工，由於這樣會提升整個團隊的協做能力。固然了，像產品經理對於開發、測試、運維都多少熟悉和了解，那麼實際提需求的時候，彼此換位思考也能下降很多開發成本。可是，每每作不到這樣，這也是一個公司裏，運維時常淪爲背鍋戶，測試說開發，開發說測試，產品說測試，測試說開發，產品說開發等等，最後可能會出現內部鬥爭，內部鬥爭勢必會形成團隊裏部分人會所以受到傷害，一切在於協做，再細分，在於溝通。溝通很重要。良好的溝通，利於良好的協做，良好的協做利於項目開發的良性循環。

 

從團隊領袖的角度看:

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

 

 小結:

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

但願能給你們帶來幫助。