只要代码足够乱,老板就不可能开了我

本文标题党,酸奶爸爸是反对这种观点的,特此声明。

一开始拥护啥(因为什么)让你把代码写的这么复杂?

新产品需要快速上线

产品经理:竞对出了新产品,我们也要马上跟进,新立的项目,我不管你们技术怎么实现,总之老板就是要尽快上线。

程序猿:尽快是多快呢,这都快下班了。

产品经理:今晚加班,明早上线。

于是乎,命名规则里夹杂着拼音。前台后台一套代码。别说服务化了,MVC根本都没有,界面业务数据库逻辑都混合在一个函数里了。更别提什么服务化,未来业务扩展了。

矛盾爆发

项目上线后,如果业绩不理想。那么最终关停新项目,回收服务器,代码被丢在git仓库的角落无人问津。如果业绩炸裂了,那么程序猿们的悲惨命运就要开始了,大概率这个阶段业务需求会源源不断的提来,根本没有时间来重构代码,于是只能在现有的小平房上加盖摩天大楼。

破解之法

功能需求,新立的项目不要做的大而全,只做最核心的功能。如若不然,竞争对手死没死不知道,自己先把自己搞死了。程序架构不要太先进,微服务等架构是用户日活百万千万阶段需要做的架构。立项初期只要能够应对日活过万的需求变更就可以了。好的规范要从项目的第一行代码就要实施,命名规范、核心业务的文档、单元测试等等。

职场小萌新,看不到长远的未来

微信公众号比较火,我们公司也要以公众号的形态呈现,新事物年轻人接收比较快,于是这个需求就交给了组内的职场萌新来做。过一段时间小程序也火了,再过一段时间又要上马企业微信。大概率这些后续的腾讯系需求都会由这位职场萌新来做。

矛盾爆发

由于职场萌新经验不足,开发公众号需求只关注当下业务与公众号的接口,不会考虑未来的小程序和企业微信的扩展。所以代码里充斥了各种switch-case,数据库表里充斥了各种type。加班与延期是不可避免,工作日常也大概率被各种bug缠身而无暇新功能开发。如果这位职场萌新扛不住离职了,那就是悲剧的开始。

破解之法

技术经理与组内老鸟有不可推卸的责任,如果能够及时codereview,至少能保证职场萌新所搭建的楼不会歪。公司要上一个市面上流行的技术或业务,未来肯定要大规模上新需求,这里就需要老鸟们的技术经验与业务远见。毕竟如果职场萌新的楼歪了,恰巧又离职跑路了,那么这座歪了的楼大概率会由组内老鸟接手,因为市场已经爆发,大老板已经感受到职场萌新开发周期delay的痛了。

程序猿老油条,我的代码无人可以接手

公司业务平稳,日常新增需求也很常规,但就是有这种老油条型程序员将代码写的无比复杂,不同业务之间耦合度很高。

矛盾爆发

别人计划开发一周的需要,因为涉及老油条的代码,看代码就要看3天。这种乱麻型的代码,不知道哪些需求线上在用,哪些需求线上已经下线,搞得测试同学都得跑一遍,都很痛苦。上线之后往往是按下葫芦浮起瓢,好不容易开发2周上线,后续2~3天各种线上bug报出来,各种补丁文件上线,搞得OP同学也很痛苦。

但是在老板眼里却是另外一番景象,老油条每天加班,每天帮助同事解决bug,每天上线补丁解决线上问题,办公室一派欣欣向荣的景象。于是老板疯狂招人。

直到某天,代码实在改不下去了,线上天天出bug,公司业务高度依赖线上操作,老油条跑路。公司,卒。

破解之法

这种老油条是公司的毒瘤,它不同于新项目的赶工期,也不同于职场萌新的经验不足,而是主观要将代码写烂。这样做短期会保住自己的饭碗,长期看是逆势而为。老油条把青春与经历都花在了办公室厚黑上,而没有精进技术,违背客观规律的行为终将被时代淘汰。

解决之法:开掉。

写在最后

好的代码是为了提高未来的效率,这里的效率不只是编码的效率,还有沟通的效率。接收人不问原作者就能快速读懂业务逻辑,新需求开发能够尽量少的修改现有业务逻辑。开发规范,设计模式等这些前人大牛留下的精华不是在无病呻吟的。用同样的人力支撑更大的业务规模才是王道,该重构就重构,痛一阵是必要的。

我一直深信:加班能解决的问题,一定有其他方式解决。

相关推荐

发表评论

路人甲

网友评论(0)