这其实是个好机会，越是烂代码烂系统，可发挥的空间越大，越能体现水平。 按照我的经验，接受这种烂代码，可以通过几个步骤来改进完善。

做事之前要先收集收据。两个目的：1. 帮助分析问题，找出大的严重的问题；2. 为将来邀功和吹牛逼准备好基础。 常见的数据包括：构建时间、响应时间、部署频率、新功能开发时间、bug修复时间、服务故障恢复时间、单测覆盖率、部署后回滚频率、生产故障频率等一切对将来你解决问题和吹牛逼有帮助的数据

先根据数据找出那种能短期提升效果的任务。这可以让你很快建立威信，让同事和老板相信你能做好事，给你更多机会。那种要花很长时间的留在后面再做，不然体现不出来能力，老板还不知道你在忙什么 比如够构建时间太长，你可以写一些自动化帮助提升效率，瞬间就可以将部署时间从30分钟提升到3分钟

做某事之前先一定请示老板，要alignment，至少要得到默许。无论是老板还是员工，工作中都不喜欢太多的surprise，无论是惊吓还是惊喜。并且和老板聊之前，带上数据和方案，让老板知道你的想法是基于数据的，而不是基于你的主观想法，带来的收益有都少，时间资源成本又是多少，让老板支持你去做。

每做成一件事之后，不要怕小，都要找机会去演示，展示你的数据提升。像demo会议all hands会议都是露脸的好机会，群发邮件也不错，能让老板帮你邮件是最好的，聪明的老板会主动帮你做这事，毕竟你做好了事情老板脸上也有光，普通的老板在一对一会议中提一下一般也会帮忙。

没做好也没关系，大方承认，然后尝试复盘找出问题，下一个任务可以吸取教训。

一般像这样的烂系统，有些常见的短期提升的任务： 1. 自动化构建，提升构建和部署效率 2. 增加自动化测试，提升测试覆盖率，为将来重构做准备 3. 部分重构，提升代码质量，提升可维护性，提升性能 4. 增加日志和监控，提升故障发现速度，提升故障恢复速度 5. 缩短发布周期，提升部署频率