新入职被安排维护前人留下的'史前'项目,怎么防止砸键盘？

老项目是 php 框架 tp3.1 写的

重构

@xeis 项目耦合度太高了，都写在一起，而且现在 v 层还在用传统模板语法，php，js，搞在一起，想哭

幸好只是维护..开发咋整 你都不知道有没有写公共方法~
不过我觉得砸键盘倒是不用 tp 至少还是有序可循的..

重构
哦不，换框架重做！

走人吧～
我页经历过类似项目。

@Light3 要是按规范写也还好~

@66beta 主站~太庞大了

@roys 搞得我都怀疑自己了

换 HHKB，砸之前想一想价格

@UnisandK 我竟然无言以对....

没法，截断一个模块出来，看看能不能一个个模块重构。
大项目一个人要重构太难。

给你备多个键盘以防之

@scys 嗯嗯

@Adamla ......

@Adamla 会砸掉更多的键盘。。

windows 运行里输入 osk

慢慢理，维护还好说吧，

直接把键盘砸掉避免之后再费劲砸

@dream7758522 不明觉厉

@chinvo ...

@Marlon 目前只能这样了

删库跑路

如果浏览器兼容不用怎么考虑的话，可以尝试一下前端直接强上 Vue 进行渲染

告诉老板 要么涨工资 要么走人……

写新的 > 额外津贴 > 走人

维护啥？改 bug ？那就慢慢改咯。烂项目改动耗时自然偏多，平时改一个 Bug 半天，换上烂项目改一个 Bug 要两周，这很正常的。心态放平，慢慢做就是了。跟上司或者老板说清楚情况，让他们充分了解工作的难点，给你充足的时间，我觉得就足够了。毕竟是按照时间发你工钱的，同样的时间，同样的收入啊。

建议要求立项重做，好歹有个盼头。维护恶心的老代码除了培养耐心之外对个人提升没什么益处，远不如维护设计合理的项目或者开发有挑战的新项目。
如果不答应的话，除非薪水特别诱人，还是走人吧。

看看你的上级人怎么样，人不行的话，果断走人

你是没有接手过更加糟糕的，一个仓库的 php 项目，维护了 5 年多，里面有用三种框架来实现不同的功能。

再把代码恶化一下。
等着下一个接盘侠。

以我多年经验，换一家很大可能也是这样的，骚年

…………没什么啊，就当学习一下反面教程就好了。

维护还好点，开发新功能才要你命

@66beta #5 跟框架关系不大，完全取决与人
前几天还见了一个用 Laravel 写的像狗屎一样的项目呢
变量随意命名 $a $b $k $v，class 文件里带个 function

我觉得那些劝你走人的都是在搞笑，工作中肯定会碰到遗留代码的。所谓的重写，其实也就是在造新的遗留代码罢了。大家都看过 重构 那本书，这是实践的好机会。当然，重要的是要管理好老板的预期，把事情说的严重一点。

@cxh116

我们的主站版本还在 3.1 之前，不过我只是个新人，还在做基础工作，涉及不到源代码。这里就祝福一下你啦。

@t123yh 私下跟前端讨论过，为什么不搞分离，他说不想碰，最令我惊讶的是一个前端归产品部管，上级不懂技术，部门聚餐都是跟产品设计一起

@TuxcraFt 老板压根儿不懂技术，传统行业转型的

理理逻辑也是程序员的工作之一。 注释先别管，万一别人有用呢

@cxbig 我现在想法是坚持到明年跳槽季吧，想转前端了，说实话自己能力吧也有欠缺，能力和工作氛围是匹配的

@msg7086 嗯，差不多一天一个 bug，难的话

@cmonday 是的，耐心真的被虐很多次，但是也不否认项目里有很多值得学习的地方

劝走的真是够了，讲道理工作中给前人擦屁股基本上避无可避，逃得了这家逃不了下家。说说我的经历吧，前阵子刚把一个全用 Shell 和 Perl 拼起来的烂摊子收拾完毕，用 Python 重写，搞完系统性能提高了 300 倍（没错是 300 倍，主要是前面的摊子实在太烂，随便加个多线程然后并行计算就能提速）。刚接盘时全局变量满天飞，各种 function1，function2，function3 简直马勒戈壁，Perl 的那些我了个去的#$%，当时我也很绝望啊，还好坚持下来了，为啥能坚持？是因为上家辞职闪人就是接了个要把 demo 速度拉上生产环境上线的烂项目，当时走的那叫一个潇洒，裸辞近一个月才找到这家，没想到还是坑，还好填平了。
PS：偶尔逛了下拉钩，发现上家 HR 还在招接盘侠。推荐楼主看下这本书《凤凰项目:一个 IT 运维的传奇故事》，我是很收鼓舞的

@rason 嗯

既定事实，基本没办法再修改风格的了。只能按照：先在小部分进行优化，确保之前的没错误。一点一点迁移到新架构中。。。
反正，这事情很漫长的。楼主你遇到一点事情就这样，和我三年前差不多情况。不过那时候我没打算辞职。只想着重构他。

@ivlioioilvi

@xomix 是的，我现在在里面编码都开着 psr 文档，要求自己按规范来

@cmonday 嗯

@zlhsvc 是的

多买几个键盘旁边放着，省得砸坏了没得用。

一边砸键盘一边慢慢改吧。这都走人的话还真没多少工作合适的了。维护老代码是再常见不过的工作内容了啊。

@klgd 嗯，人的因素会大一些，但是用结构好的框架本身会限制编码者遵循规范从而引导项目朝着良性发展

跟我比惨吗？手上还有个 tp3.2 的就项目，代码看的我想打人，真的是用 tp 不可怕，写的那么烂才是真的可怕

@jadetang 是的，不可能都是新需求

哈哈哈哈哈

@FYK 如果你是处在项目没定性阶段很幸运，至少可以一路看到整个项目是如何臃肿起来的

@caijihui11 之前看过有人讨论过，为什么一些人喜欢留注释代码，好像是 防御性开发，我也忘记了怎么说

重构也很有成就感啊。看一件事慢慢完成，和看一件事慢慢变好，对我来说都挺好的

@ferstar 哈哈，理解你在填坑中的心情，现在情况是 bug 接踵而来，一个压一个，他们根本不关心代码是如果优雅，只要结果就是你解决了 bug

有注释都不错了，你要知道没有注释的老项目，会让你哭。

其实更坑的是你老板不知道。。。。所以有机会的话先跟老板诉诉苦吧，起码让她知道你干了啥。。。这样再难怼出来也算有价值的。

所以是所有逻辑都写在控制器 然后模型没有一行代码的那种项目吗 ..

那些说重构的，你们给 PO 主写测试？

你看过一份 20 多 M 的 c 文件吗没有注释

@allgy 给老板讲清楚状况, 加钱加时间加 leader, 然后必须让他知道你的辛苦

维护性的工作，不要说的那么夸张，况且才四五年前的，主要算史前那一些运营商的项目都是大爆炸时代的了，不要听上面的人瞎扯，轻易的去重构，先熟悉透了做合理的小块修改，以前有个同事，年轻人太冲动，有个维护的项目跑着 100 万级别的用户，让他别乱动他非要去改一个不太熟悉地方，结果造成大面积用户无法使用，投诉电话打爆了

如果除了接盘别无选择的话：

1. git init && git commit --all
2. 按自己喜欢的风格全文格式化代码，然后 git commit
3. 如果可以，移除掉所有未被实际使用的引用（没开发过 PHP，一些 IDE 应该有这个功能）
4. 如果可以，整理出所有模块的依赖情况和业务线（如果这个项目存在业务线的概念相对独立的功能链）
5. 从被依赖数最小的模块开始整理业务逻辑 & 注释 & 重构，注释写输入输出即可
5.1. 如果可能，配合一点简单的单元测试（为了防止 Willow 无意点火饥荒梗）
6. 调整作息，保证稳定的工作节奏，非工作时间果断避开所有跟这个项目有关的事情
6.1. 心态决定一切

当然，如果你有别的选择，或者实际情况已经明显超出了你的能力范围，或者老板要求明天就上线，或者有任何其他重要因素促使你拒绝 take this shit，珍爱生命，果断走人（丢锅）

管理好上级预期，列一个计划并随时更新，让上级了解你工作的艰巨，以及你付出的努力。。

当一天和尚，撞一天钟，反正按时间领薪水的。。

@Felldeadbird 嗯，有时候其实没有太多选择，自己也是个普通人，只能凭这个吃饭，不是什么的大神，随便跳就有橄榄枝

@abujj

@rswl

@ferstar 才来没多久，老板面都见不到

@nicevar 嗯，很多 bug 就是被前人生生改出来的

刚工作的时候，都会不爽

等工作一段时间发现，这就是工作的主旋律。

@SilentDepth 嗯，感谢给出这么详细的建议

@jswh 好痛苦....

@PazuLee 见不到老板人...

@cxh116 还好你是 PHP，我们维护过 C#同样操蛋的项目。。。。

@2ME 差不多，根本没有严格遵循 mvc

@wolffn 是的

@qiqico 嗯

问个镜像问题：项目第一个 /批开发者，如何避免后人接手的时候产生此类情绪？

我现在就是团队的后段项目第一个开发者，尽量完善一些代码和注释，尽量规范化，但是业务变更有时候是很快的，项目要跟上进度需求很容易产生一些逻辑混乱的代码。。。这种事情又需要怎么避免呢。。。

@silov 上线之后优化代码

说走人的，你们都不维护项目吗？

@silov 最基本的开发手册需要有，还有就是可以完成功能后重构优化不好的代码

有能力和权力就直接改。没能力或者没权力就走。抱怨不解决问题。

对于 Append 我跟你说，单个回复里可以回复很多人，不需要一层一层回，避免触发 1800 大法。

要不要来一次重构啊，多爽

@pandago @allgy

开发手册基本的是会整理，不过完善的没有

至于优化重构，说起来是很轻松的，有精力、有机会自然也会一点点去做，但是公司初创阶段产品经常会会很频繁的跟着业务变动，很难抽得出时间做那么好，老板可不会给你时间等你优化架构什么的，而烂摊子本身就是这么一点点问题积累出来的。。。。。。

以前我也老吐槽，这谁留下的代码这么烂。。。现在跟前端同事老调侃，以后进入公司的开发会不会也这么吐槽我们，看来几乎是不可避免的，只能说尽我们所能的去做好吧。。。。

@msg7086 学到了

@silov 加油

忍 或者 滚，

慢慢把坑填好~~ 我填了好几次坑了 反正能用 稳定运行

我真觉得我是个好人把代码都重构了恶心的代码自己都看不下去

我也经历过类似项目，维护过的人最后都离职了

不是好正常的事情？如果做不了赞同忍或滚，所有工作都是自己分析衡量是否可以做，是否决定做，决定就不要考虑太多，抱怨无法解决问题，尽力解决问题，尽力后无法解决自己觉得无法接受了那就滚，只是别滚到同样的坑~忌抱怨心态

胃镜做起来多爽（滑稽）