维护一个烂系统是怎么样的一种体验？
程序员文章站
2024-01-30 22:30:52
...
不少在银行 IT 部门工作的小伙伴，向我吐槽。自己维护的系统很 SB， 框架老旧能力薄弱，编程语言语法繁琐，很多 bug。。。。但是公司因为安全和成本考虑，迟迟不更新
走人的时候暗自庆幸；
两年以后忽然从这个傻逼系统得到灵感（或者教训），颇有感慨；
三年后后悔维护的时候自己抱怨太多，而行动太少；
五年后意识到自己怒气值高的原因不是因为系统傻逼，而是自己驾驭不了；
八年后再次需要维护“傻逼”系统；
十年后方才领悟，“这个世界的本质是混乱不可知，而非有序可测“；
甚至技术新旧的界限也开始模糊。
其实是，自己不够谦虚敬畏。
Working Effectively with Legacy Code
The Software Craftsman: Professionalism, Pragmatism, Pride
Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman 有幸经历过这样的事情。
该系统是一个投资下单系统，客户是全国各大证券公司，在某细分领域里市场占有率有80%。当初少不更事，一听金融行业好，就来到了这个公司。久了便发现跟想象中完全不是一个事。
当时系统已经上线了约莫八年。烂系统都是如此类似——框架落后，文档缺失，功能冗余，版本管理混乱。最早的一批开发者又走得一个不剩，期间换过4,5批人，思路都不一样。就连代码注释都寥寥无几，或者写得只有当事人自己看得懂。后来的人只敢往里加代码，不敢轻易改代码。一切以稳定第一，性能兼顾，代码优雅易读什么的统统靠边站。
那些说重写项目的人讲得轻松，复杂的项目多了去，不比学生成绩管理系统（许多人的毕业设计）。就该系统来说，其之复杂，规模，都不是一个人可以一肩挑的。修改离职人员的代码更是难上加难。最后光有技术还不够，大量的业务逻辑必须具备一定证券期货知识才能着手（为此我还考了证券从业资格证）。
不光系统烂，公司当时的管理方式也很有问题。公司的销售员毫无业务水平，只知道收钱，不仅承担不起售前的工作，更令人称奇的是把程序员的电话直接留给客户，有需求直接致电程序员帮改。天大的笑话啊！我来给不是软件行业的人解释一下后果：
1.不合理的需求要挡，至少要经过小组分析。许多程序员不论什么需求埋头就做，危害很大。
2.重复造*，或者客户要三轮车就照做三轮车，可明明有现成的轿车却不用。
3.打乱开发计划，客户的需求无穷无尽，永远在做手边上嚷嚷最响的需求而不是真正迫切的需求。
4.过多的客制化，导致项目没有办法整合成一套通用版，导致日后维护更加困难。
有个别同事完全没有认清到危害，反而傻X兮兮地以为跟客户混了个脸熟，觉得自己身价倍增。可气可叹。
《软件随想录》和《项目百态》是两本好书，公司的管理方式以及系统缺陷在这两本书里都有体现。我在这家公司干了不到一年就走人了，在阅读这两本书的过程中时常会心一笑，有种怒其不争却又暗暗庆幸的滋味。 部分反对第一的答案：有些系统就是很傻叉不用难为自己，有些是技术人员的因素，有些是太过古老技术落后，有些是管理人员的因素。
有些项目的复杂来自需求内容，而另一些复杂度就是来自于人的脑残，后一种复杂就是软件理论要消除的。
软件工程理论的存在，目的就在于降低软件项目的人的因素，降低复杂度，使参与的人更容易达成需求，减少bug，减少延期。
换句话说，软件理论的存在就证明了世界上有多少项目成了大坑。
狄杰斯特拉说面向对象简直是*，因为他是大神，而且不需要像我等一样跟三五个坑爹队友去趟一个需求各种变化的大坑，但是我们不是大神，趟别人坑的同时，自己还在随手埋着地雷，随机地炸着别人或者自己。
面对大坑，你可以挑战自我，也可以甩手不干——如果你水平还不错找个工作一点也不难——但是不承认他是大坑就有问题了，如果是程序猿自己这么想，可能会把自己的职业生涯弄到很不开心 ，如果是项目经理这么想，会把你手下的程序猿弄到很不开心。
敬畏不解决问题，明明就是个大坑就敬畏地躲远点，如同股市明知道熊样还不割肉止损，那就别抱怨套牢。
也许多年之后想起你的青春，会觉得当初那个问题好简单啊，但相信我第一你很少会对一个烂泥项目有一个清楚印象，第二论后悔的概率，还是被套牢的后悔药更难吃 以多数人的水平不需要好的构架。能在平庸甚至糟糕的系统设计里面尽量把自己分担的模块做到稳定，易用，易维护即可。
反过来想，写了一个好的框架，搭了一个还算可以得架子，然后被维护人员搞得乱七八糟，再反过来维护系统的人说啊呀这个系统设计得真烂，那可就真的烂下去了。 祝贺你，你都干出国家*的感觉了 笑年郎，那些烂代码都是有故事的。不小心你会成为后续故事的角。 正在维护一个傻逼系统；
这个傻逼系统以前没有人维护；
这个傻逼系统目前只有我维护；
我应聘的时候告诉我，很快会切换系统，把这个傻逼系统切换到一个牛逼的系统；
我当初傻逼了，信了这个话；
所有人都觉得这个系统傻逼；
我提出过N个让它不那么傻逼的方案，大家看了都说好；
上一条的结果要花点钱，大家都表示这件事等等再说；
上一条的结果是系统依旧傻逼；
傻逼系统虽然傻逼，但是不用这个傻逼系统会显得更傻逼，所以公司不能不用；
这个傻逼系统也成了大家甩锅的好借口，虽然很多时候它是无辜的；于是我觉得我在大家眼里也是个傻逼；
一个傻逼的我，如何拯救一个傻逼的你……
以上写于2015年5月8日
------------------------------------------------------------------------------------------------
下面更新于2016年5月19日
没想到整整一年之后我会再更新！
更新的原因是我要离职了。
大家可能会关心这个傻逼系统怎么样了？答案是它依旧坚强而倔强的存在着！
其实关于这个系统我有很多故事可以说，但是上次答题的时候删删减减，最终还是决定用戏谑的方式说出来。我的工作本不是运维，但是在这个工作岗位上充分体验了运维的苦逼！我多次联合业务部门领导一起上报预算方案，却每次被不同的原因所取消！我曾经越两级，以辞职为代价推动项目（越级乃职场大忌，所以我当时一手拿着项目方案，一手拿着辞职报告），最终项目顺利获批，但公司却在项目刚启动时横生和项目无关的波折，最终波及到该项目，导致项目停止！
最终在今年我心灰意冷，拒绝了公司的挽留，决意离开！
我有时会觉得荒谬，因为如果我离职了，很有可能这个系统就切换了。因为几年间，系统越来越笨重，历史冗余数据越来越多，和windows7的莫名其妙的版本冲突（系统设计基于XP）逐渐出现，供应商也逐渐放弃了该产品系列的支持。一直是我们在修修补补，扶着前行。业务、财务、数据库、系统基本上只有我一个人可以贯通了解，我这一撤，公司连接替者都找不到！
公司这时的最优选择是什么？花大价钱招募一个团队来运维？我觉得不是！公司的最优选择是：切换系统，既解决了运维的问题，又解决了系统的历史遗留问题！换句话说，我离职的影响是实现了我在职时最大的心愿！ 见过再model层，拼html 拼javascript的。不能说傻吧，谁没年轻过啊。 真正牛逼的程序员是凤毛麟角，难得一遇的。但是如果一个项目真的是由一个牛逼的程序员团队打造的，以题主的能力很可能难以在这样一个团队里立足。
所以还是好好提升自己为主。大的框架不好改，就从局部的小模块开始，慢慢改。子子孙孙无穷尽也。
然后为什么要说它烂？因为这特么的不是我做的，3个月就上线的互联网XX系统，你觉得可能不烂么？
好了，不开玩笑，真的还好了。
下面分析分析为什么烂，不想看分析过程的可以直接跳到最后，看斜体字，那是我真实的感受。
3.最后说体会：
（前排说话的同学安静一下了，不要打扰后面睡觉的同学。最重要的重点来了。）
我把事情分为天灾和人祸。
对于天灾，我们除了努力解决问题以外，还可以闭上嘴。你解决的问题越来越多，有一天你回首发现原来你已经走了那么远了，这证明你能力成长了，可以跟老板药家鑫，额，不是，可以跟老板谈心，额，我的意思是谈薪水。所以，你看明白了，就应该感谢它！
对于人祸，我坚持的原则是：再一再二，不能再三再四，不然这个人就应该走！如果他不走，你要么忍，要么走！
至于发脾气，抱怨。。。。。
当然，必须是允许的啊！！！！！！
不把情绪发泄出去，会影响我的工作的啊！
没情绪的那是死人！
至于向谁发泄，反正我从来不跟我老婆发泄，因为我打不过她！
反正黑锅总是要有人背的，当然肯定不能老板背，VP你也惹不起。所以，我建议多去健健身，以免向测试、产品发泄的时候打不过他们：）
以上！
回复内容：
在职的时候怒气值高，各种讽刺挖苦；走人的时候暗自庆幸；
两年以后忽然从这个傻逼系统得到灵感（或者教训），颇有感慨；
三年后后悔维护的时候自己抱怨太多，而行动太少；
五年后意识到自己怒气值高的原因不是因为系统傻逼，而是自己驾驭不了；
八年后再次需要维护“傻逼”系统；
十年后方才领悟，“这个世界的本质是混乱不可知，而非有序可测“；
甚至技术新旧的界限也开始模糊。
其实是，自己不够谦虚敬畏。
Working Effectively with Legacy Code
The Software Craftsman: Professionalism, Pragmatism, Pride
Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman 有幸经历过这样的事情。
该系统是一个投资下单系统，客户是全国各大证券公司，在某细分领域里市场占有率有80%。当初少不更事，一听金融行业好，就来到了这个公司。久了便发现跟想象中完全不是一个事。
当时系统已经上线了约莫八年。烂系统都是如此类似——框架落后，文档缺失，功能冗余，版本管理混乱。最早的一批开发者又走得一个不剩，期间换过4,5批人，思路都不一样。就连代码注释都寥寥无几，或者写得只有当事人自己看得懂。后来的人只敢往里加代码，不敢轻易改代码。一切以稳定第一，性能兼顾，代码优雅易读什么的统统靠边站。
那些说重写项目的人讲得轻松，复杂的项目多了去，不比学生成绩管理系统（许多人的毕业设计）。就该系统来说，其之复杂，规模，都不是一个人可以一肩挑的。修改离职人员的代码更是难上加难。最后光有技术还不够，大量的业务逻辑必须具备一定证券期货知识才能着手（为此我还考了证券从业资格证）。
不光系统烂，公司当时的管理方式也很有问题。公司的销售员毫无业务水平，只知道收钱，不仅承担不起售前的工作，更令人称奇的是把程序员的电话直接留给客户，有需求直接致电程序员帮改。天大的笑话啊！我来给不是软件行业的人解释一下后果：
1.不合理的需求要挡，至少要经过小组分析。许多程序员不论什么需求埋头就做，危害很大。
2.重复造*，或者客户要三轮车就照做三轮车，可明明有现成的轿车却不用。
3.打乱开发计划，客户的需求无穷无尽，永远在做手边上嚷嚷最响的需求而不是真正迫切的需求。
4.过多的客制化，导致项目没有办法整合成一套通用版，导致日后维护更加困难。
有个别同事完全没有认清到危害，反而傻X兮兮地以为跟客户混了个脸熟，觉得自己身价倍增。可气可叹。
《软件随想录》和《项目百态》是两本好书，公司的管理方式以及系统缺陷在这两本书里都有体现。我在这家公司干了不到一年就走人了，在阅读这两本书的过程中时常会心一笑，有种怒其不争却又暗暗庆幸的滋味。 部分反对第一的答案：有些系统就是很傻叉不用难为自己，有些是技术人员的因素，有些是太过古老技术落后，有些是管理人员的因素。
有些项目的复杂来自需求内容，而另一些复杂度就是来自于人的脑残，后一种复杂就是软件理论要消除的。
软件工程理论的存在，目的就在于降低软件项目的人的因素，降低复杂度，使参与的人更容易达成需求，减少bug，减少延期。
换句话说，软件理论的存在就证明了世界上有多少项目成了大坑。
狄杰斯特拉说面向对象简直是*，因为他是大神，而且不需要像我等一样跟三五个坑爹队友去趟一个需求各种变化的大坑，但是我们不是大神，趟别人坑的同时，自己还在随手埋着地雷，随机地炸着别人或者自己。
面对大坑，你可以挑战自我，也可以甩手不干——如果你水平还不错找个工作一点也不难——但是不承认他是大坑就有问题了，如果是程序猿自己这么想，可能会把自己的职业生涯弄到很不开心 ，如果是项目经理这么想，会把你手下的程序猿弄到很不开心。
敬畏不解决问题，明明就是个大坑就敬畏地躲远点，如同股市明知道熊样还不割肉止损，那就别抱怨套牢。
也许多年之后想起你的青春，会觉得当初那个问题好简单啊，但相信我第一你很少会对一个烂泥项目有一个清楚印象，第二论后悔的概率，还是被套牢的后悔药更难吃 以多数人的水平不需要好的构架。能在平庸甚至糟糕的系统设计里面尽量把自己分担的模块做到稳定，易用，易维护即可。
反过来想，写了一个好的框架，搭了一个还算可以得架子，然后被维护人员搞得乱七八糟，再反过来维护系统的人说啊呀这个系统设计得真烂，那可就真的烂下去了。 祝贺你，你都干出国家*的感觉了 笑年郎，那些烂代码都是有故事的。不小心你会成为后续故事的角。 正在维护一个傻逼系统；
这个傻逼系统以前没有人维护；
这个傻逼系统目前只有我维护；
我应聘的时候告诉我，很快会切换系统，把这个傻逼系统切换到一个牛逼的系统；
我当初傻逼了，信了这个话；
所有人都觉得这个系统傻逼；
我提出过N个让它不那么傻逼的方案，大家看了都说好；
上一条的结果要花点钱，大家都表示这件事等等再说；
上一条的结果是系统依旧傻逼；
傻逼系统虽然傻逼，但是不用这个傻逼系统会显得更傻逼，所以公司不能不用；
这个傻逼系统也成了大家甩锅的好借口，虽然很多时候它是无辜的；于是我觉得我在大家眼里也是个傻逼；
一个傻逼的我，如何拯救一个傻逼的你……
以上写于2015年5月8日
------------------------------------------------------------------------------------------------
下面更新于2016年5月19日
没想到整整一年之后我会再更新！
更新的原因是我要离职了。
大家可能会关心这个傻逼系统怎么样了？答案是它依旧坚强而倔强的存在着！
其实关于这个系统我有很多故事可以说，但是上次答题的时候删删减减，最终还是决定用戏谑的方式说出来。我的工作本不是运维，但是在这个工作岗位上充分体验了运维的苦逼！我多次联合业务部门领导一起上报预算方案，却每次被不同的原因所取消！我曾经越两级，以辞职为代价推动项目（越级乃职场大忌，所以我当时一手拿着项目方案，一手拿着辞职报告），最终项目顺利获批，但公司却在项目刚启动时横生和项目无关的波折，最终波及到该项目，导致项目停止！
最终在今年我心灰意冷，拒绝了公司的挽留，决意离开！
我有时会觉得荒谬，因为如果我离职了，很有可能这个系统就切换了。因为几年间，系统越来越笨重，历史冗余数据越来越多，和windows7的莫名其妙的版本冲突（系统设计基于XP）逐渐出现，供应商也逐渐放弃了该产品系列的支持。一直是我们在修修补补，扶着前行。业务、财务、数据库、系统基本上只有我一个人可以贯通了解，我这一撤，公司连接替者都找不到！
公司这时的最优选择是什么？花大价钱招募一个团队来运维？我觉得不是！公司的最优选择是：切换系统，既解决了运维的问题，又解决了系统的历史遗留问题！换句话说，我离职的影响是实现了我在职时最大的心愿！ 见过再model层，拼html 拼javascript的。不能说傻吧，谁没年轻过啊。 真正牛逼的程序员是凤毛麟角，难得一遇的。但是如果一个项目真的是由一个牛逼的程序员团队打造的，以题主的能力很可能难以在这样一个团队里立足。
所以还是好好提升自己为主。大的框架不好改，就从局部的小模块开始，慢慢改。子子孙孙无穷尽也。
我之所以匿名是因为我现在就是在维护着一个烂系统，而我不想让我的同事或者上级看到我对目前系统的看法，以免影响军心。好了，首先说一下我目前的职位，是架构师。
然后为什么要说它烂？因为这特么的不是我做的，3个月就上线的互联网XX系统，你觉得可能不烂么？
什么？你问我感受？我感受很好啊，有责任都是前任的，我是接盘侠。
好了，不开玩笑，真的还好了。
下面分析分析为什么烂，不想看分析过程的可以直接跳到最后，看斜体字，那是我真实的感受。
- 先说说为什么烂：
- 因为要赶时间窗口，必须要在这个时间段上线，否则过了这个村就没这个店了（嗯，嗯，那谁，X总，你怎么不早点跟我说？）
- 产品人员没时间细想（也许是没能力），很多都是拍脑袋，系统中各个业务维度都交织在一起，牵一发动全身。
- 研发人员没时间动脑子（也许是没能力），很多都是怎么快怎么来，什么安全、性能、扩展、健壮性都是狗屁，能开发完的才是产品，上不了线的永远是原型。
- 测试人员没时间仔细测试（也许是没能力），你们需求、研发一天改三次。我前脚报了的bug，后脚你们就把需求改了。什么安全、性能、扩展、健壮性都是狗屁，能测试完的才是产品，上不了线的永远是原型。
- 没有架构师或者说没有好的架构师（这个是最主要的原因， ，这也是我存在的理由），还特么架构师？别跟我哔哔那些有的没的，产品开发不完，你哔哔的再多也没用。
- 高层管理人员瞎指挥（有积极性是好的，不过要量力而行，可不要贪杯哦），您的专业是忽悠，额，不是，是指引方向，不是软件开发也不是产品设计，术业有专攻。忽悠我不如您，额，不是，指引方向我不如您，但是软件开发和产品设计还是请相信我们专业人员的。
- 一个字改
- 再一个字拆
- 再一个字想
- 最后一个字忍
- 最后一个字（真的最后一个字）钱！
画外音：为什么不说详细点？
我：说详细了，我还混个屁啊，交点学费先
3.最后说体会：
（前排说话的同学安静一下了，不要打扰后面睡觉的同学。最重要的重点来了。）
我把事情分为天灾和人祸。
对于天灾，我们除了努力解决问题以外，还可以闭上嘴。你解决的问题越来越多，有一天你回首发现原来你已经走了那么远了，这证明你能力成长了，可以跟老板药家鑫，额，不是，可以跟老板谈心，额，我的意思是谈薪水。所以，你看明白了，就应该感谢它！
对于人祸，我坚持的原则是：再一再二，不能再三再四，不然这个人就应该走！如果他不走，你要么忍，要么走！
至于发脾气，抱怨。。。。。
当然，必须是允许的啊！！！！！！
不把情绪发泄出去，会影响我的工作的啊！
没情绪的那是死人！
至于向谁发泄，反正我从来不跟我老婆发泄，因为我打不过她！
反正黑锅总是要有人背的，当然肯定不能老板背，VP你也惹不起。所以，我建议多去健健身，以免向测试、产品发泄的时候打不过他们：）
以上！
下一篇： 对SQL数据库定期进行收缩_MySQL