吐槽一下工作中的项目代码

[deving]

刚入公司试用期还未过，做移动系统的，无论事系统架构还是业务逻辑都太过于复杂，而且之前写的代码逻辑相当混乱，感觉前人写的代码像是中学写作文，想到哪写到哪的样子，导致跟踪一个业务就要很久（也许是个人能力问题，但是一同进来的人也是这种情况），无爱了。不知道大伙接触的项目会不会这样？想跟领导说分手了

[test0x01]

乱是有点。但是说复杂，你还没见过更复杂的。通信系统本来就就是很复杂的，业务逻辑多，协议多，并发多，随机性强，不允许出错

[deving]

@test0x01 现在的项目对并发倒不是有很高的要求，因为不是面向普通消费者的

[hitsmaxft]

我手里的系统四年间重构第二遍了。几乎所有的内容都通过框架约束。业务层老老实实写代码就行了。

这种系统都是人员流动，层次参差不齐造成的。除了渐进+大版本重构别无他法。

如果领导没这个思路，那会一直糟糕下去。

[deving]

@hitsmaxft 老系统用了十来年了，公司已经发布了新版系统了，感觉重构是不现实的，里面的逻辑太多，而且多个人的逻辑纠结在一起，分不清谁是谁，维护起来特费劲

[mhycy]

@deving 要不是做的是移动系统还以为看见同事了

[hitsmaxft]

@deving 重构重写都是手段。让原来很难维护的老系统下线才是目的。如果不行，那就早点找法子甩手呗。

[deving]

@mhycy 呵呵，你现在做的项目代码也这么乱呀？

[mhycy]

@deving 有过之而无不及，事业单位的项目，天天改需求

[newtonisaac]

@mhycy 事业单位的程序员，五体投地。。。

[mhycy]

@newtonisaac 一般事业单位都是外包给私人公司干活

[deving]

@hitsmaxft 用了十几年，每年向移动那十来个亿的项目，不是随便能换的

[hitsmaxft]

@deving 下金蛋的鹅嘛，反正缺个人维护而已

[CarlWangCn]

历史问题是什么公司都存在的, 个人觉得最重要的是, 从自己开始写的代码自己努力写好, 不要一段时间后回来看了想骂自己, 另外如果好的建议和实践经验能够吸收采纳(无论是自己提给别人的还是别人提给自己的), 那么代码就会越写越好. 如果好的建议不能够听取, 只知道一味的抱怨历史代码有多烂, 而不从自己开始改善,那么最终自己也会写出让后来者骂娘的历史代码

[deving]

@CarlWangCn 说得是

[deving]

@mhycy 在事业单位？好不？

[deving]

@hitsmaxft 是呀，每天都在搞需求，感觉技术的东西落下了

[mhycy]

@deving 我现在待的那公司是给事业单位打工的私企。。。。囧

[ciwonderful]

唉。擦屁股项目。。已经擦惯了。