前言
hi，这里是小榆。最近一位朋友做技术团队管理者，跟我吐槽他新招了一位开发，起初面试的时候无论是技术还是其他方面都挺 ok，于是招了进来。
结果写的代码让人头大，有现成的框架不用，平时也不沟通，喜欢自己闷头造轮子，关键还写的烂，写出来的代码可维护性很低。
举个明显的例子，团队里都是用 MyBatis Mapper 的写法，他一来就上 Spring Data 的写法，跟现有的写法完全不搭，写之前也不说一声，闷头就写了。
现在团队里的成员已经非常反感他了，并且让我们支招有什么办法请走他。
听了这位朋友的反馈，不知道大家身边有没有类似情况，或者这位朋友说的可能是我。
我的经历和反思
从我自己的职业生涯经历来说，这一类程序员可不少，甚至我自己也出现过类似。
刚工作的时候，为了快速完成任务，优先选择自己熟悉的技术栈和代码风格，完成任务好交差，年轻的时候真的太想进步了。
那会也没有人跟我交谈过类似情况，直到后来觉得在别人现成的框架和项目上新开辟自己的技术栈和写法，属实有些景上添花，如果这项目是 ‘shit mountain’，那我无异于在此之上雕花。
并且开发起来不仅耗精力还拖时间，因为很多现成的东西没去了解并不知道可以走捷径，复用一下或者改些参数就可以实现。
之后进入一个新团队，有些团队会有技术文档和指引，这个倒是挺好。没有指引的我几乎优先熟悉现有项目的框架和代码风格，然后再进行功能开发。
有些可能会比较好用的可替代性技术或者覆盖代码范围稍微大点的会和领导沟通进行评估，其余小些问题也不会过多去沟通。
程序员的技术瘾
因为据我所知有些开发团队，大多采用敏捷开发，以完成任务为主，并不会花太多时间去 ‘code review’ ，有些也不会要求成员严格按照一定的技术栈去编码。
所以一般会有一种感觉，就是刚接触现有项目进行二开，细到具体代码发现风格迥异，仿佛看到一堆牛粪上插满了品种各异的鲜花。
我也见过不少程序员，被以往的职业经历塑造了某种思维或者习惯，往往加入新团队就自带某种力量，看不上眼前的一堆 ‘shit code’ ，开始大刀阔斧的造轮子。
关键是没考察过自己的代码对业务或团队是否带来好处，比如说增强了代码可维护性和稳定性；减少了时间和人力成本；增加系统可用性等等。
如果单纯的满足自己的代码风格和技术瘾，不仅把自己搭进去持续性维护还牵连到其他队友跟着受牵连，最不好的结果就是被团队抛弃。
激进，温和派的解决方式
通常作为技术团队管理者，针对这种情况往往会出现两种：一种是劝和派，另一种是劝退派。
劝和派一般是主张约谈，尤其是试用期的时候就可以进行 code review 与其交涉并规范化和限定技术。
造成如今的场面管理者也承担着一部分责任，或者团队文化建设不完善，团队完全可以建立一份新人指引，包含代码规范和技术范围限定，这样也可以避免类似的问题。毕竟不能把问题全部归因于成员一人身上。
另一种是激进的劝退派，成年人的世界没有改变，只有筛选，思维一旦形成并不是一朝一夕就能改变的。与其花时间修复，改变一个成年人的思维，不如直接劝退，省时省力。
管理者伙伴反馈新成员的代码质量问题，是从一开始就在跟进开发的代码质量，但怎么说呢，他年纪比我还大，非常有自己的想法，有时候我说不能这么写得按规范来，他口头上答应了好，但就是不改。
领导不是很关注代码质量，项目也比较紧张，有时候工期紧了也就没细看，好家伙，现在直接搞了个大的，给大家都整无语了。
至于以上情况，我想大家职业生涯中或多或少遇见类似的情况，如果你是管理者你会怎么做呢？
