这才是真实情况
反正你只要写的够快上面的就会觉得好棒棒
写的好不好对上面的人对客户又没差
对他们来说搞不好还觉得有bug是很正常的事
所以你一直纠结这个其实没什么用
你大概只有两条路可以选
1.抱紧那位仁兄的大腿
搞不好过没多久他就升team leader再来技术总监或是CTO了
我真的看过这种人写code能力连junior都不如
但因为关系当到eam leader最后把整个team搞垮
换到别的公司之后听说居然升技术总监
这种大腿不抱吗？
2.想办法让他的bug炸死自己
就是有发现重大bug也别帮他修
最好上线后让他炸
并且想办法让他不得不吞下去
出包久了上面的才可能对他的印象是“虽然写的快但问题很多”
他才有可能被干掉
不然你在这边抱怨再多你们还是那位仁兄的垫脚石
虽然很残酷
但人的世界并不是像写程式一样对就是对错就是错
一般工程师最大的错误就是想讲道理
你说你的程式都遵守SOLID测试写满满的？
但真实世界就是懂得满足上面的人才会被看见被重用
※ 引述《yestheway (LKK)》之铭言：
: 大家有没有遇过这样工程师…
: 我们公司最近在开发新的专案，找了一位新来的工程师帮忙一起做。这个人Coding速度真
: 的很快，交给他的功能很快就能做出来。每个sprint下来，他也一直不停的接新ticket和
: 开发新东西。
: 最近这个新专案终于要上线了，结果QA却测出了一大堆bug！！由于数量真的太多了，但
: 又为了承诺客户如期上线，所以只好把我和其他2个工程师也叫来，一起昴下去帮忙解bug
: …
: 结果不去看还好，一下去看他里面的code，真的是非常可怕…又臭又长像流水帐一样，结
: 构也是乱七八糟，很多逻辑明显没有想过或设计过硬干去写出来，没有任何弹性和维护性
: ，大家花了非常多时间再改他的程式，真的改的非常辛苦...
: （对…我们为了赶这个专案，完全skip code review、skip unit tests 等等。二来 这
: 新专案相对独立，不影响现有系统。所以他commit 什么 就merge什么，闹得今天这下场
: 。我们的例子，正好回应前几篇某些人质疑为何要code review......）
: 最后产品虽然如期上线，但这下好了，老板和PM现在超喜欢这个工程师，后面很多v2 要
: 衍生的新功能，都要叫这位工程师来主导开发…
: 我们几个帮忙“收烂摊子”的人，听到真的有种不好的预感…一来害怕又有更多有问题的
: 程式被他写出来，后面又要花更多时间来修改；二来有种功劳你在接，烂摊子我们在收的
: 感觉…
: 我们原本找主管说这些问题，但目前公司大老板想正积极开发这项产品，他们只希望快点
: 见到结果，似乎也不太在乎原有的开发流程了，只想先快点把东西生出来，给客户demo…
: 各位如果面对这种情况，和这样的工程师该怎么办？公司想快速看到成品，找了一个产出
: 快的人，虽然短期快速看得到成果，但却后患无穷…