程序员枪击事件在我所关注的知识分享公众号和技术群方面传播的比较广。
针对该事件我要谈谈我的看法。
针对该公众号所说的，因注释不写、代码排版差、非驼峰命名和天天git push -f导致该程序员枪击自己的四位同事。
我个人有如下想法，并列出对应的角度分析。
从开发角度看:
注释不写、代码排版差和非驼峰命名的确会导致代码的可维护性差，因为其他同事有的时候根据业务的需求，需要改动你的代码，如果你的代码是这样的，那么就会导致需要改动你代码的同事难以理解你的代码逻辑，从而增加时间成本，也许那一天都在梳理你的代码思路，并打断点debug逆向推导。
另外我个人也觉得，一家软件公司如果是初创公司，一般都会招有经验的开发者，而那些有经验的开发者们，一般像注释、排版、驼峰命名都会注重的。当然了，由于每个人对业务的理解不一样，导致编写的代码行数也不一样，过长，比如一大堆if-else之类的，反而会降低可读性，过短的话，根据实际情况定，如果像一些逻辑验证判断(比如账户验证之类的，那么该长还是要长的)，还是要的。另外，像初创公司一般情况下，至少会有一个经验丰富的项目经理和项目组长，项目经理一般都会要求项目组长制定开发计划，比如同有关人员商议讨论，编写可行性方案文档，如果该文档由项目经理确定后没问题，下面进入需求分析、概要设计、详细设计、编码、测试、上线。这一个过程就是有名的瀑布模型。现在比较流行的是敏捷开发，敏捷开发总的来说与瀑布模型还是有相同点的，只不过驱动开发的方式不同，比如原型驱动开发(做一个静态模板原型给客户看，客户觉得没问题正是他想要的这样，那么就可以继续开发下去，通常情况下，这种方式的好处是客户基本都能满意，就算不满意的话，成本相对于瀑布模型而言低的多。
从人际交往的角度看:
假如是我，如果经常git push -f强制将本地代码提交到远程，那么一定会有同事会说，为什么我之前写的功能没有了，昨天是谁提交的，对于经常性git push -f的人，同事也不是傻子，直接会提醒你不要这么做，会告诉你正常的流程应该是当自己该分支对应的功能开发完毕时，将要提交代码，首先提交到本地仓库 并git merge远程主分支解决对应的冲突，当冲突解决完毕时，再git push 远程仓库master主分支，这是正常流程。如果这位人士真的这么干，那么对于他而言，他将会受到团队的排挤，身处团队不为其他人着想，那么对于他而言，上班将会成为一个地狱，同事的冷眼和领导的批评，最终他的结局将会被开除。
当然了，如果这位人士心理不平衡的话，的确可能会导致他将自己的不快发泄到其他人身上，从而可能引发某种暴力行为。
从团队协作的角度看:
此前我在该篇文章谈谈运维人员谨慎操作系统环境和管理说过，开发的要懂测试和运维，测试的要懂开发和运维，运维要懂开发和测试等，彼此都要熟悉彼此的领域和分工，因为这样会提高整个团队的协作能力。当然了，像产品经理对于开发、测试、运维都多少熟悉和了解，那么实际提需求的时候，彼此换位思考也能降低不少开发成本。但是，往往做不到这样，这也是一个公司里，运维时常沦为背锅户，测试说开发，开发说测试，产品说测试，测试说开发，产品说开发等等，最后可能会出现内部斗争，内部斗争势必会造成团队里部分人会因此受到伤害，一切在于协作，再细分，在于沟通。沟通很重要。良好的沟通，利于良好的协作，良好的协作利于项目开发的良性循环。
从团队领袖的角度看:
通常一般团队的主要负责人是项目经理，然后再是对应的开发组组长。这里我要说说开发组组长，开发组组长的职责不仅仅是项目使用技术的把关，功能模块分配，文档编写，帮助其成员梳理需求并理解需求和其他开发小组对应的负责人共同商议制定良好的开发规范，还有对团队成员必须要熟悉，这个熟悉不单单等同认识，包括编写代码的风格、技术能力、思考问题的方式还有就是性格等，都要了解。有的时候团队的某个成员图痛快，改其他同事的代码，丝毫不与人家沟通，从而提交到线上，导致影响到该同事的正常功能，从而造成不必要的bug,这时测试人员就会提醒开发人员，而开发人员性格一般比较犟，自己已经写好并在之前测试好的功能突然就不行了，这时可能会与测试人员争论一番或者是开发人员之间开始吵架，作为开发组组长而言，这时一定要公平公正耐心的处理好。否则，一旦愤怒不平的种子埋在心里，将会因为生活中的一点小事导致冲突，这种冲突时常表现的形式就是口头冲突，这种口头冲突时常会转化为暴力行为。这也是为什么这个社会犯罪率上升的原因之一。
小结: