近年来我带队开发出的一坨屎山

微信扫一扫,分享到朋友圈

近年来我带队开发出的一坨屎山

前言、我花费一年时间带队开发出来一坨屎山。

有人说: 烂代码跟一坨屎一样,很多时候就是和一坨屎共处千万别深挖,说不定把哪里挖塌了把你埋了,扔一坨代码到屎山上,达到自己目的,能跑就行了,你还要搞清楚山上的屎哪一坨是谁拉的,拉的人吃了什么,就没什么意思了。

而这坨屎山却不是祖传的,而是我带队开发出来的。以下简称【我的屎山】。

一、目标

经过几个类似项目的经验积累,公司希望开发出一个可复用率较高的产品,用来给每一个项目来客制化的基础产品。

之前已经开发过一版,但其实是根据第一个项目定版,有很多考虑不周的地方,希望这次把这些问题改掉。

1、易用的脚手架

在产品中,要有相关的范例,可能用到的技术范例,新设备的可以使用范例代码。程序启动调试发布的已实践流程。

在项目定制化时,不再需要前期框架搭建,设计完成后能开发。不再需要对新技术调研能直接进入开发。

2、通用的标准化模块

在产品中,要有一些标准模块,这些模块是大部分项目都需要的。

在项目定制化时,希望只有一些小改动就可以实现客户的定制化。希望大部分代码可复用。

3、易上手的代码

希望新人经过简单的业务培训或技术培训,能快速上手修改代码,并完成定制化需求。

二、其他屎山出现的常见原因

参考别人的文章介绍的屎山出现的原因

1、程序员的技能水平。

很不幸,干这行,入门真不需要受多少教育,不客气地说,是个人培训培训就可以上岗了,这些从业人员能够把事情搞定,但是真没有意识做长远考虑,也没能力做长远考虑,写出来的当然是一坨一坨

我的屎山:很幸运,我们组的人员基本都是成手,并且开始之前,我们调研了前一版本出现的问题,并强调了所有需要注意的代码。

2、管理层的短视。

程序员的水平不高,好歹还可以通过培训,通过招募更强的程序员来弥补,但是,如果管理层想要的只有短期目标,“这个功能很简单,怎么实现我不管”,横批“明天上线”,哪怕是一群10x程序员也没法做出高质量的代码啊。管理层的短视,其实已经很难追责了,你可以因为一个管理者没有按期交付功能开除他,但还真很难因为他没有搞出可维护代码而开除他,没救了。

我的屎山:管理层目标很明确,希望产品可复用率高。

3、资本压力。

万恶之首,还是资本,资本想要规模,一声令下,就要公司扩招多一倍程序员,满足场面,招来这么多人又管不好,除了生产垃圾还能怎样;一旦资本寒冬,又是一声令下,裁员一半,大家都没心情过年,来年哪有人有心维护代码质量。

我的屎山:时间固定,第一版3个月,第二版加功能也3个月,第三版第四版要加的功能已经规划,并且有时间预期

三、我们的产品成为屎山的原因

1、我的能力不足

很遗憾我以前基本没带过队,虽然参加过几个从零开始的项目, 且也有意识的长远考虑问题,但实际上考虑不周全,遗留下很多未解之谜。在产品开发过程中我虽然经常参考其他人的意见,但是于事无补。

2、前期需求设计不足

我们的产品完成日期确实是固定的,但对功能的预估不足,需求设计人员只知道想要什么,前期没有努力完善需求,后期开发过程中发现很多情况不自恰,唯有现改代码逻辑。需求设计人员很理想化,希望做一个大而全的产品,所有情况全部实现,使用配置参数作为条件来区分以后产品在各个项目中的定制化,而实际实现中也真是这么做的,导致最后这种配置参数粗略估计超过1000个【if分支超过1000个】,有一些参数其实他自己都没有考虑清楚,这个参数的意义都无法仔细描述清晰。

而这些参数还不只是产品的系统参数,可能是某个逻辑结构的参数,类似mysql的排序规则,可以属于:库,表,字段。

mysql的系统参数也没超过1000个【SHOW VARIABLES 查询发现500多个系统参数】,并且在官方文档中对每一个环境变量都有具体的解释,而且每一个参数都有默认值。有使用范例,有参数选择分析。

而我们的产品大部分参数没有默认值,如果不配置一个具体的值,产品无法启动;并且参数也没有仔细考虑就直接怼上去了,后期出问题都找不到原由只能翻代码。

3、产品定位不准确

产品初期定位是希望项目的快速交付,但实际开发过程中需求设计人员一直在偏向实现需求,遇到分支不仔细考虑,直接加配置参数,从来不参考项目开发组的意见,导致最后项目开发组在使用过程中根本不用标准功能,改动稍微大一点就重写,基本没有表现出配置化的意义。整个产品成了一个黑盒子。

4、为了提高复用率不择手段

需求设计人员以为提高复用率就是把所有业务尽可能覆盖,在产品中把所有可能的情况都实现了,而实际项目中的情况千变万化根本做不到全覆盖,最后导致整个产品代码过于臃肿。

四、重构

有人说: 重构祖传代码就跟迁祖坟一样,稍有不慎就万劫不复

我们这个产品其实是第二次重构了,产品开始前,使用了半个月选定和搭建框架,写工具类,规范命名规则。

最后、结局

最后我们获得了一坨屎山,标准功能都好使,但在实际项目中,可复用率低于10%,大部分开发不想阅读我们像精密仪器一样的代码,只是使用我们的产品作为脚手架,使用其中的工具类,在项目中如果模块的功能差异只要超过30%就重新开发。因为阅读并修改产品的模块,还没有重写一个新模块快速。所谓的可配置成了一句笑话。

程序从头到尾都是我设计的,我了解几乎所有实现细节,但是在交付项目中,好多开发还是不想理解细节,为了速度重写功能,绕开那托屎山。虽然我自己总结出了我们的产品成为屎山的原因,但代价太惨痛了。

微信扫一扫,分享到朋友圈

近年来我带队开发出的一坨屎山

Redmi骁龙865旗舰即将登场:首次采用144Hz LCD屏 极致性价比

上一篇

博雅:窥见间充质干细胞治疗前景 助力临床应用转化发展

下一篇

你也可能喜欢

近年来我带队开发出的一坨屎山

长按储存图像,分享给朋友