最新消息:

感觉在中小公司,很难不写出屎山代码

编程 eben 1153浏览

第一个版本:

中小公司,一般第一个版本,都是赶工上架,以我的感受,基本都是没需求、没计划、没测试(测试没时间,只能随便试试)、领导马上就要,必须上线的状态。
导致第一个版本,无论如何都是屎山。很难不想着“赶紧先交差”。

后期迭代:

基础是屎山,屎山上加盖的建筑,很难不是屎山。

重构:

我的领悟是,小重构可以,绝对不要大重构。
除非领导要求,但领导能用就行,管 bug 、管功能、很少会管代码是不是屎山。

测试也是人,如果是新事物,比较容易认真测,如果是反复测试过的模块,很难用心测。码农也是人,新功能、新模块、思路清晰。大重构很容易大刀阔斧。

重构很容易重构出许多奇妙的、不易发觉的 bug 。写反而不会写出这样的 bug 。

如果是小重构,屎山代码,靠着小重构,根本无法应对下一波来屎(一年总是能遇到几次马上就要)

中小公司:

考虑到大家的水平比较高,我说的中小公司可能等于大家眼中的小公司。
目前呆过的互联网公司规模最大的 300+人,呆过的传统上市公司规模最大的 2000+人。


我会告诉你上市公司也是这样么


想多了, 大公司也是这样, 而且可能会更臭


时间久了 现在的想法是能用就行,管它是不是屎山的


微软够大吧? windows 的文件管理器就是一坨屎山代码


屎山从来不看公司规模不看国内国外
中小公司是屎山,大公司是屎山脉
其实不止软件行业,制造业也有很多产品,看着像那回事,里面其实也一堆坑


大部分的都是表面光,各种个样的的历史遗留,各种个样的突破规范和魔改。


确实。第一版为了赶工 怎么省事怎么来。
现在有问题回头去看,想重写但又怕重新写出问题。
但因为领导在写第一版的时候说以后有时间再重写,现在已经慢慢重构一些地方


大公司也很难不写出来。

国内公司的现状就是,大部分所谓的领导根本不清楚具体的方案难易程度,无法准确的考核工作成绩。

说个例子,一个对自己代码质量要求非常高的人,经常做需求的时候,设计思考设计原型的时间超过 60%,交付质量非常高,很少有比较严重的 bug 。
另外有一些人,干活毛毛糙糙,思维相对简单,干活急急冲冲而半灌水,出活猛操快,上线后各种问题,又猛操快的去解决自己埋的哪些问题。
虽然,最终,第一种人,整体更高效,但是一来一回,第二类人,第一版交付更早,领导觉得第二类人解决了众多的问题,工作量特别大,特别辛苦,年终考核都是第二类更佳

那第一类人何苦自己想那么多,埋屎谁不会


打破你的思维误区,大公司更是屎山,屎的程度甚至超过你想象


感觉原因还是在于面向 money 编程


流程不规范的话,每个公司都一样。另外项目最一开始就写好单元测试,重构的时候你就知道单元测试有多重要了


另外你还需要有一个足够刚的技术领导,把业务方不合理的需求都怼回去。一个功能最开始做的目标就是能实现目的就行了,不要想做得多复杂,多人性化,后期再慢慢加,不然一开始就做得大而全,很多东西根本用不上,徒增代码复杂性。


其实压根和公司没关系,看公司中高层对码代码这个事情的认知态度
如果领导面向业绩、成果管理,代码好不好看,干不干净,是不是屎山这并不是首要考虑目标,考虑长远?笑话
“东西都还没做出来你考虑那么长远干啥?”


司(6000 多人)也是这样, 我一开始也是和楼上各位一样的想法. 每次需求变动改到吐血, bug 也多, 想花时间重构一下, 甚至自己加班重构, 但是领导不关心, 领导关心的是怎样把屎山卖出来钱, 以及你是否加班去改屎山了.
最近说实话, 我的认知发生了一些变化, 居然有点认可这种做法了. 虽然还在写代码, 但是也没以前那么吹毛求疵了, 差不多就行了, 卖出来钱, 年底有奖金就好, 省点时间回家陪陪老婆孩子. 可能是老了吧…


酒后吐真言第 28 条
( 28 )人死了以后,你想让代码成为你的遗产吗?如果是那样,就花很多时间在代码上面吧,因为那是你的遗产。但是,如果你像我一样,更看重与家人、朋友和生活中其他人相处的时光,而不是写的代码,那就别对它太在意。


讲讲我的体会,感觉主要还是历史遗留问题(工期,业务增长,业务变更),根本没法动这些代码,只能在需求迭代时逐步小范围的重构。

小公司很多项目演进的过程就是一个试错的过程,很多时候经验不足,项目启动时各种设计不是那么的合理,都会随着业务增长暴露出来, 但是只要能跑,能够缝缝补补,大概率不会选择重构,第一个是时间上不允许,第二个动这块代码会引入更大的风险,这部分代码在不断缝缝补补的过程中,已经面目全非了,文档不全或者注释不全的话,动起来真的是战战兢兢。

很显然,如果盈利不行或者没有技术驱动,基本不会选择重构,重构的风险太大了,说白了,你动这块代码,就不可避免的引入风险,有时候重构可不是重构一个方法,你要重构一个业务流程和基础逻辑,这个工作量很大的,要是没测试,没有历史变更文档,不出问题那才叫奇怪。


都是屎山,解决屎山必然的结果就是出生产 bug 。再修复个几轮 bug ,就会会好很多。然而紧急项目一来,继续堆屎。不过这个新的屎会香一些。

问题来了,出 bug 是要扣钱挨骂的。


自己拉的屎山,又何妨?
最怕的是别人拉的屎山,要你吃;
最最怕的是别人拉的屎山(在职,活的好好的),要你吃;
最最最怕的是别人拉的屎山(在职,活的好好的),要你吃(你还要被迫说:真香!)


相对来说小公司的屎山更好解决一些,因为业务复杂度也许没那么高,输入输出场景也更单一一些
大厂大项目中的屎山,那业务复杂度你很有可能都吃不透,更别想重构了…
之前接手过一个老人的项目,服务端用了 4 种语言:PHP+Python+Go+Lua ,加起来得有差不多 2w 行代码,重构个锤子重构… 能勉强看懂这一坨并且能往前推一推就很不错了…



根据简单的「热力学第二定律」
将一堆代码视为封闭系统的话,屎山代码不会自发地变成不屎山的代码,但不屎山的代码会自发地变成屎山代码
这叫做屎增定律。
因此,必须采用开放系统自外部输入自由能才能达到屎减,也就是说需要程序员对代码做功。


但如果把程序员的心智和代码再视为一个封闭系统,你会发现,程序员对代码做功把屎山代码变成不屎山的代码其实是把屎铲进自己脑壳里去,屎的总量还是没有减少
仍然符合屎增定律
因此,必须需要时刻添加新程序员来装屎。


但程序员们总喜欢产生新的代码,这会导致代码越来越多,从而导致屎增速度也越来越快,所以就需要追加更多的新程序员来装屎。
所以可以论证,一个能够维持存在的软件公司必定是在膨胀的。


但是膨胀不是无极限的。即使把装满了屎的程序员请出去,上述过程仍然以几何级数增长,从而导致最后公司无法维持那么多的程序员存在,结局就是化粪池爆炸。


当然,第三条是有例外的,那就是时不时地把一些代码也切割出去。
这就是 Google 一直在关停项目的必然逻辑根源。


我见过一个我司 NLP 的工程里面集成了钉钉和讯飞的 SDK ,还对外可以支持 web 以及云调用,然后前端的页面部分用 Angular ,部分 Vue ,部分 React ,README 没人维护,注释看了眼来自四个团队长达 6 年的代码,各种分支和冗余代码,真是庞大的屎山,可以说是喜马拉雅的规模了。


有个模块权限功能临时表创建的 sql create select 是写死的,mysql 启用 GTID 后不支持这种写法,组长让我改成先 create ,再 insert 的方式。因为不好确定临时表结构,我就用 select sql 语句解析下确定表结构 并做成了一个公共方法可以解析不同的 select sql 的字段和数据类型,很快测试完毕没毛病。
然后魔幻来了,我的组长说,你这样写太复杂了,不直观,让我直接把字段写死。。。我说不同的临时表表结构不同,每个写死后期如果源表结构或者业务逻辑发生变化手动改很麻烦,而却容易出错。。。他说就按他的来,理由是这样能少执行一条 sql 。。
我被恶心到了,sql 不长表也不大,个人觉得多执行一条对运行速度没有影响,而且既然交给我的活儿,都不信任我做?我都测试完成了,非要按照他的思路再改一遍,还不好改因为写死字段得一个个比对。很难受!
暂且不说让我多干活儿这个事儿,就觉着这种在代码中写死字段名的方式,我实在想不通到底有什么好的。。这些老代码本来就很屎了,硬是让我拉了一坨。。。唉!无奈


只要是在公司里写的代码,很难在规模扩大以及多人合作的情况下不出现混乱的代码。想起曾经的老梗: 让为客机开发控制系统的程序员去乘坐跑着自己程序的飞机,其中有 80%的人觉得不安全而选择不去,还有 20%的人欣然前往,因为他们心里很清楚这玩意压根飞不起来


大厂也是如此。
曾供职于某业内前三大厂。
该厂某产品是 A 语言的开源框架基础上进行二次开发。
多轮迭代后硬生生的二开成了 B 语言。非常残暴。。。


Oracle 传说是屎山之王
Windows 下很多应用层的管理器是屎山,包括 IE 。NT 内核还是不错的相对来说好得多


不可否认,随着时间的推移,质量再高的代码也会被下线。
软件工程师生产代码其实就是在传递价值。

大公司的工程师更倾向于花大量时间在软件设计,代码组织上。因为只有这样才能传递更多的价值给用户。
小公司的工程师则更倾向于在有限时间内产出更多的可运行软件。毕竟小公司死的速度太快了,工程师当然需要尽快地传递价值。
那么请思考下:一个没有任何人使用的软件,那这个软件算存在吗? 那写这个软件的人那段时间存在吗?


有点点强迫症,自认为是对自己代码比较负责的,之前也给项目内的同事做过 code review 。总体感受就是,shit 山是无法避免的。

追求完美是不现实的。代码开发是要解决实际问题,而需求是不断变动的。你无法预测到两三年后的功能需求,打补丁是在所难免的。
你无法保证自己每一段代码都是“完美的”,你也无法保证每个同事都对自己有高要求。即使你能保证自己的设计思路一致,别人再接手的时候,也不能再次还原你的想法。时间久了就夹杂着每代开发不同的“想法”在里面了。

反正我已经看开了。之前卡同事的代码卡得比较严。现在只要别歪得太离谱,我会先给过。
搞 code review 是累活,不少团队 leader 嘴上说着要有追求,要规范 blahblahblah ,等到评绩效的时候就对你的付出视而不见。
我会尽量保持对自己的要求,跟同样有兴趣的同事交流。至于其他人,我真的管不着了


代码也有两种:
1 ,有人用:BUG 很多,不断改,熵越来越大;
2 ,没人用:完美

技术往往就是将一小木船,改为战舰,然后改为潜艇,再改为飞机,最后改为战争堡垒(堡垒中间还得来个伊甸园)。

所以通常人越少,架构越好,因为没有人力可以浪费在无关精要的功能和需求上;人少的时候很多人都能独挡一面,知道一项东西的来龙去脉,做出合理的设计,人一多就没法设计了—-大家都有自己的思想。

为了兼顾大家的思想,我们设计出框架,框架解决了大部分问题,这时候有部分同学理解不够,没有跟上来,

后来分布式来了,异步来了,我们需要采用分布式的和异步的框架,但是这时候大部分同学跟不上了。。。

当然,将一首航行中的战舰改为潜艇,不是每个程序员的能掌握的。


很久很久以前,有十几年了吧,我在一家公司做网站,我们的工作是做模板站的,一般一个员工一个月能出三五个模板站就不错了,必经还要跟客户进行沟通。我们团队就有一个同事一个月能做十几个,当然一个月工资收入也很高。在一次团建中,团队领导还表扬他,让我们跟他学习,提升效率。但是,我发现一个有趣的现象,每进来一个实习的员工基本上都是在处理他的屎,提成他拿走了,也得到领导了信任了。说白了,中层领导能看不到吗?但是,领导为什么对他做的事情置若罔闻,说白了还是利益。本质上,他和领导的利益是站在一起的。

 


质量差的代码就像肿瘤,外部边界清晰的模块,是良性肿瘤,可以随时切掉。
外部边界模糊的是恶性肿瘤,无药可救,只能尽量延长生命。

是这样, 所以一个不朽的架构在诞生之初就是伟大的, e.g. UNIX, PLAN9, 而现今码农写的业务可能都是朝生夕死, 连婴儿期都没过去业务就没了. Cloud NAIVE 仿佛就是个池塘, 专门孵化孑孓. 孑孓死了直接被系统降解回收, 孑孓变成了苍蝇, 也自然不在池子里再部署了.

我们 Cloud NAIVE 程序员别说领域驱动设计了, 连设计模式早都不用了. 面向啥切面搞, 微服务重写一遍都比想个设计模式快. FAAS 才是未来


转载请注明:落伍老站长 » 感觉在中小公司,很难不写出屎山代码