YoYo
2021-12-13T00:47:31+00:00
换了工作，负责是一个很老很老的系统，九十年代就有的系统，asp的页面，页面脚本用的是VBScript来写的，而且一直在修修补补用了这将近20年，项目十分庞大，大概有1000多个功能。
感觉一直做这个，以后出去可能都找不到工作，想翻新重做系统一方面是人手不够，而是领导层也不愿意翻新，觉得现在也用的很稳定，用户用的也习惯。
但作为我是真不愿意继续维护这东西，一方面是与时代脱节，二个里面的代码十分混乱，经过了好多代人的修改，要改也不是容易的事情，所以也是领导层不想动的原因。但没办法又必须要有人维护，头疼。
应对陈年屎山的最好方法就是放弃重构的想法，在上面只做必要的修修补补
不要重构
不要重构
不要重构
别尝试重构。直接打补丁上去就完事了。有空余时间自己搞个自己玩的项目练手。工作没那么多让你练习的场景。还是业余时间才是关键。
不要重构，说服领导新功能开个新项目做，和旧项目通信尝试仅限于数据库层，当有功能要更新也想办法把新版本放到新项目上，我现在公司这边就是这样做的，用了大约三年时间，旧项目已经没几个功能还在对外服务了。
“虽然不知道为什么能运行起来，不过既然跑起来了那还是不要动他了”
我重做过几百个功能的，很难受好吧。
如果不是领导要求重做，能不重做就不重做。
另外你说你不想维护，但是重做的第一步就是你要把屎山吃透了。要不你咋重做？逮住人问需求？别闹了，顶多给你说清楚主要工作的流程，一些几百年不用一次的功能，他们自己也就只能碰到了才想起来。
所以，你就只能把屎山吃透了，带着你从代码里梳理出来的东西，找相关人员核对需求。然后做你的新架构。
如果需要迁徙数据，请把迁徙数据的代码提前写好。
功能不要一起全出了，搞个试用版，做完一块就让你们领导推给相应用户去试用。(所以领导不想做，你这块就做不了)
最后上线之后老系统不要停，双系统运行一段时间。新的没问题了，老系统也别删，没准啥时候你就要翻翻。
面对这类系统的正确做法其实是跑路。
但不是绝对的。
微软的excel项目一样是一个超大的跨年代屎坑。
所以你还是要衡量下，这单位给你的收益，对比未来规划，是否划得来？
第二种选择，保留后端的数据库，重新构建前台展示框架和处理业务逻辑的后端框架。
所有新需求，都在新的框架上实现。只与原项目公用一个数据库。这样新需求和老需求不冲突，也解决了你们技术栈的问题。
看你们有多少人力，和领导层多少意愿了。
老项目里多搞点阻塞，把性能拖慢，用户不爽了，老板自然会让你重新做了。
[quote][pid=575195459,29938437,1]Reply[/pid] Post by [uid=39310071]Edwinhu233[/uid] (2021-12-21 11:33):
应对陈年屎山的最好方法就是放弃重构的想法，在上面只做必要的修修补补
不要重构
不要重构
不要重构[/quote]一语惊醒梦中人，刚接了一个老项目，里面各种不合规范的代码看得人直呼快重构[s:ac:喷]
只要钱给够, 什么都是闲事.
钱不给够, 快点跑路.
请放弃重构屎山，继续在上面拉粑粑即可[s:ac:茶]
[quote][pid=575204994,29938437,1]Reply[/pid] Post by [uid=60476117]ly4236[/uid] (2021-12-21 12:03):
我重做过几百个功能的，很难受好吧。
如果不是领导要求重做，能不重做就不重做。
另外你说你不想维护，但是重做的第一步就是你要把屎山吃透了。要不你咋重做？逮住人问需求？别闹了，顶多给你说清楚主要工作的流程，一些几百年不用一次的功能，他们自己也就只能碰到了才想起来。
所以，你就只能把屎山吃透了，带着你从代码里梳理出来的东西，找相关人员核对需求。然后做你的新架构。
如果需要迁徙数据，请把迁徙数据的代码提前写好。
功能不要一起全出了，搞个试用版，做完一块就让你们领导推给相应用户去试用。(所以领导不[/quote]确实，我们这边上线给用户不是自己说了算，还要测试，需求也不是自己和用户谈，要需求去谈，但需求和测试都相当业余，很头疼。
你这辈子饭票应该不用愁了。不过可能也没有机会调岗或者升迁。。。