※ 引述《keke0421 (zrae)》之铭言： : 觉得好贴切...分享给各位 : 转贴於 https://goo.gl/dEpoJQ <--medium 好读版 : 身为软体工程师，你应该要尽量写出无法维护的程式码，而且绝对不写测试。 : 你应该要知道：在绩效管理下，你愈是认真负责，愈是做到符合专业伦理的要求，你反而 : 看起来绩效愈差。而你大概会有 87% 的比例，会遇到这种绩效管理。 : 举个例子，假如你是警察，你决定要认真抓小偷，於是上个月在你的管区破获了五十起窃 : 盗案，这个月因为你的努力，破获的案件增长到一百件Xo代表什麽呢？这代表看起 : 来你的管区治安变差了，而你应该要为治安变差负责，你才是应该被检讨的对象。於是你 : 知道，警察好像应该要想办法破案，但实际上，你的绩效并不是来自破案，而是吃案。 : 如果你花了半年时间，抽丝剥茧理清了复杂的商业逻辑，建立了清爽明确的抽象层，并且 : 预先额外设想了其他的使用情境，最後开发了一套易於扩充的软体架构，让一个大学刚毕 : 业的新人，都可以在你的架构上不到一个星期就可以开发出新功能。这代表什麽呢？这代 : 表你的绩效很差XA的管理者只会看到，你花了半年才做了一件事清，一个新人刚来 : ，却只需要花上一个星期就可以完成一件事，那还要你来做什麽呢？ : 至於可以轻松开发出新功能的新人，他会怎麽看呢？可以这麽快开发出新功能，当然是因 : 为他自己的功能啊！跟你有什麽关系呢？真的要了解你到底做了什麽，其实只有一个办法 : ，就是要阅读你的程式码，但，放心好了，不会有人会去读的。 : 你要做的事情就是：管理者设定了什麽绩效，你就想办法达成什麽绩效。如果管理者设定 : 的指标是你修好了多少 bug，那麽你就要想办法一开始就在你的程式中制造许多 bug，免 : 得日後需要修 bug 的时候没有 bug 可以修。如果管理者的目标是加速开发，你就应该要 : 不计後果加速开发新功能，明知道是加速迈向毁灭，你也要加速开发。 : 事实上，身为软体工程师，你也根本不用考虑後续维护的问题。如果你在一家公司写了一 : 大堆完全不考虑耦合关系、程式逻辑纠缠不清、命名混乱、使用大量 anti-pattern、到 : 处都是怪气味、效能极差而且宛若天书的程式码，而你开始为了继续维护这样的技术负债 : 感到痛苦的时候，其实只代表一件事情：你已经在这家公司獃得太久，而且还没有升上去 : 当主管。 : 这个时候你就会知道加速开发的好。你完成了这麽多项功能，於是在你想要换工作得时候 : ，你可以写出洋洋洒洒的履历表X洃均A你会把你写了几条单元测试、达成多高的覆 : 盖率这种数字放进履历表里头吗？把力气放在测试这种无助於发展事业的事情上，完全就 : 是在浪费你的时间。 : 你也同时应该感谢Xˇ撅o是谁想出来软体产业园区这种德政，原本制造业的产业园 : 区是让上中下游供应链可以集中在一起，降低运输成本，但软体这一行又没有供应链这种 : 事情，成立园区只是让相互竞争的软体公司其中在一起，唯一降低的就是人员流动的成本 : ，换工作都不用搬家。多好啊你看。 : 如果你有机会高升，开始担任主管，你就会知道，当初写下的那些无法维护的 legacy : code，其实更有助於你担任主管的管理工作。 : 担任主管最重要的工作，不是别的，就是一边把持住自己的位子一边想办法继续往上爬， : 所以主管绝对不可以让部属表现得比自己更优秀，而你当初写的程式码，就是部属事业道 : 路上最好的绊脚石。你除了可以一边抱怨为什麽新功能开发愈来愈慢，一边说嘴当年你只 : 花了多短的时间就写了多少程式码，果然只有你有资格担任大家的主管。 : 当然，总有一天技术负债会大到你的部门什麽东西都做不出来，你的公司什麽服务都拿不 : 出来卖，但是这一点都不会影响你找新工作，你瞧，现在，你的履历表上面，可写着你当 : 过主管呢！拿着这份履历表，你更有机会去别的地方，空降担任更高阶的主管。 : 技术负债从来就不是什麽问题。谁说你制造了技术负债之後，你就得要自己还债？ : 在你的人生中，你不需要要为其他人而活，也不是为了程式码这种死物而活，你真正应该 : 要负责的对象只有你自己；而你知道人是经济而自私的动物，既然你的本性就是贪婪，你 : 就应该成就贪婪。你要舍弃专业才能成就事业，你应该要把握当下的绩效，而不要为了可 : 能不存在的悲剧结果恓恓惶惶。凯因斯不就曾经说过：「In the long run, we are all : dead」？ : 身为软体工程师，你应该放心大胆地创造技术负债。这麽做唯一的风险，就只有在你换工 : 作的时候，也会接手一大笔前人留下来的技术负债。不过，这种事情反正也早就已经发生 : 了。 来个中性分析。 1. 这些招数只有特定情况可用。 A) 主管非资讯专业，可以放任底下的人搞。 (因为不懂细节，只能看成果) B) 接案公司，案子以後改动幅度不大，只要验收过关就好。 (同上，验收不看细节) C) 特殊情况要抢时程 2. 正规一点的软体公司早有应对方式 A) Code Review。 乱写很快就会被盯上 B) Bug Review。 常写出太蠢的bug也会被盯上。 C) Case assign。 依照Bug修复难易度分派任务，简单的bug给菜鸟修，顺便练经验。 避开老鸟自己写bug自己解的情况。 D) Fix review。 Bug 修完check-in前再看一次，避免明显的side-effect 3. 大一点的案子都有相依性，准时完成 > 抢快 4. 用这招或许可以在特定领域成功。 但如果想往软体业前段班的公司移动，好好锻链自己比较实在。 不是不能用，而是要懂得何时能用。 5. 这也证实了软体管理的重要性。 如果你是主管，要怎样管理/带领这样的工程师? 其实是一门有趣的学问。 6. 至於技术债： 当时程的商业价值大於技术债时，用技术债换时间是有意义。例如 Demo 用途 但正式产品、系统或专案这样搞，就自求多福了。 -- 了解更多 【职场没人教的事】 https://www.facebook.com/Work168.net --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 118.160.229.72 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1510476144.A.65F.html