本文作者 AmiliaY，国内某互联网大厂开发工程师。

笔者校招后在一家 toB 领域的龙头企业工作，当时的主要任务是维护一个基于老系统改造的 SaaS 系统，研发团队主要分了四个大组，我一直在财务组负责财务及预算领域下的子系统，直到后来跳槽到某互联网大厂。

当时的工作，以改 bug 为主，新的项目及需求很少交给我们新人去做，后来想想也确实，毕竟系统中动不动一个.java 文件上万行代码，核心部分的代码都是零几年写的，有些设计连老员工都理不清，把新需求交给校招生做确实太冒险咯。但改 bug 这种事情毕竟没什么成就感，一直都是在解决前人留下的问题，甚至有时会改完一个 bug，又引入一个新的 bug，每天做的最多的事情就是，打断点、消断点、F5、F6、F7、F8。在跟师傅调侃“前人用脚写代码，后人用心改 bug”的同时，也越来越想从零参与一个系统的建设及走向成熟。

后来因缘巧合跳槽到某大厂，参与一个供应链系统的从零到一的建设，入职前想想还有些期待，想着一定要开发一个很棒的系统，能够反转之前的规律，但后来事情的发展 却远远超出了我的预料与期待。

1. 同事突然撂挑子、新团队不融洽、项目赶排期，世事难料下，内心的浮躁、代码与系统的腐化

为了新系统的建设我们组了一个新团队，里面一半新招的员工，一半从其它团队抽调来的，leader 也是从另一个项目比较成熟的团队抽调来的，同时兼顾两个团队。刚开始，大家热情都还比较高，前沿的技术栈，完善的私有云平台，各种轮子应有尽有，且几乎没有什么历史负担。

但随着项目的快速建设，有两个性格相互不对付的同事，矛盾渐渐积累起来，两人均负责同一个服务的开发，经常会因为一些代码上的冲突吵得不可开交，甚至当着 leader 的面差点打起来。眼看提测日期越来越近，他俩的开发进度却让人越来越担心，直到临提测还有 3 天，其中一个资历比较久的同事突然要请几天病假休息，一检查他的开发进度才发现，几乎一大半没完成，很多功能都是写一半放那咯，一些逻辑相对复杂的代码 几乎让人无法阅读接手。

主管一脸黑线的在进度对齐会上分配着任务救火，心中也默默在绩效考核谁背 C 上写下了答案。

我们按照功能和难度，对未完成的任务进行了划分，我分到的是一个难度最高的任务，根据 PM 整理出来的复杂业务逻辑每天计算出一个报表出来。当时看到 PRD 上那一条条复杂的计算逻辑，还有写了一半的，连写的人自己可能过几天都看不懂的代码，还有逐渐紧迫的提测日期，我放弃了自己一贯的坚持，用最快的速度完成了任务，写出了一段直到现在都不想再看一眼的烂代码。

现在回过头思考下这段经历，其实大家的单兵作战能力都不弱，都是从其它一线二线大厂跳过来的，很多都是经验丰富的老兵，导致系统在最开始就腐化的原因是在团队管理上，当新团队的成员因为性格、理念不合，分工不明确谁也不服谁 而发起争执时，leader 看到了火苗，但却并没有及时掐灭。

当时也很困惑为什么会这样呢？现在站在人性的角度看，大概有两个原因吧。第一，老 leader 知道会有一个新 leader 来替代他的位置，他最终还是要回去带自己的老团队，所以对于我们这个新团队的管理就不是很上心咯，反正做的再好过几周也是别人的了。第二，同时带两个团队，忙不过来，自己也是心有余而力不足。

2. 空降的新 leader 与他的左膀右臂，被排挤走的老同事，面向 leader 编程，还是坚守初心

新团队中同事间的不融洽可能还只是噩梦的开始，项目上线后 空降的新 leader 及其左膀右臂，又将原本一盘散沙的团队锤成了精制面粉，有几个实在受不了就彻底地离开了这片是非之地。

与新 leader 的头几个月，几乎每天都像在开批斗大会，我们几个原团队的同事每次一块吃饭都免不了一顿疯狂吐槽，虽然我一直以来都谨记着“不要背后议人”的准则，但有时候憋得实在难受 还是会口嗨几句，但内心其实也慢慢明确，我们最后只有两条路走，要么适应这个新 leader，被同化，要么卷铺盖走人。

虽然中间也曾动摇过，但我最终选择了继续留在这个团队，努力适应下这个新 leader。看着原团队的同事一个个忍受不了这种折磨而离开，走了接近一半，剩下的同事也开始反抗消极怠工，整个开发工作几乎要停摆了，新 leader 对我们的打压才渐渐缓和下来，开始接受我们的优点和贡献。

在这场新老团队的权力斗争中，我们渐渐忘却了初心，左右为难，被权力东拉西扯的身心疲惫，在这个过程中我也渐渐感受到，会让代码腐蚀的不止懒惰，还有被环境腐蚀的人心，在这样的心境下写出的代码，注定无法支撑一个健壮的系统。

3. “先适应环境，再尝试去改变”，想在职场中稳步前进，这是我当时能想到的最佳策略

其实当时忍耐坚持下来的一个主要原因是“不想让履历难看”，很低俗但也很现实的一个考量。我认为：国内的这个大环境，很多力量都是自上而下的，很少有自下而上的推动问题解决，或满足下层需求，所以我们只能先去适应大环境，拿个小本本把问题清单记下来，当自己有能力掌控环境的一部分时，再去尝试着改变原有一直存在的问题。

这个过程可能比较艰辛，需要执行者很多耐心，但也是我这颗榆木脑袋能够想出的最佳策略咯。

4. 一个接一个倒排期的需求，逐渐浮躁的内心，回过头才发现，我竟也慢慢成为了那个“用脚写代码的前人”

今年的工作中，比较惹人烦的一个特点就是：主 R 的需求中 有接近一半都是倒排期的，所以当面临“长期方案”与“短期方案”的选择时，我几乎都选择了后者。现在反思一下，我真的是无法选择长期方案来开发实现吗？不是，是因为我的内心变得浮躁了，朝阳的望京、三里屯、798、奥林匹克公园等等，我的时间精力花了太多在社交娱乐上 去缓解压力、释放情绪，而不再是精进技术，坚守初心。现在看着自己 GitHub 的 contribution 今年是一片空白，我才意识到自己今年实在是太贪玩咯。听着新来的同事吐槽我原来的设计，我后背一凉，原来“用脚写代码的前人竟是我自己”。

自己在工作中存在的问题我当然是认的，但今年倒排期的需求如此之多，搞得研发团队总是疲于奔命，加班不断，上线后很长一段时间没人用，难道 PM 们的规划就没有问题吗？

团队内最近也反思了这个问题，认为原因主要在于：PM 在 PRD 的编写过程中 更多的是以业务的视角来提出问题，描述问题，充当业务的传话筒，而不是站在 PM 的角度从产品的整体规划上去思考这些需求。对于一些要倒排期的需求，PM 是否认真和业务 argue 过这个需求的优先级？业务认为优先级高的 对于我们整个产品的价值就一定大吗？我们有些需求，提的时候火急火燎，投入大量 RD 开发出来上线后，却很久没人用。

5. 不求无错，但尽人事

自认为足够客观理智，懂得做人做事的我，今年的选择和做的事情都是正确的吗？其实思来想去的多了，我反倒没法给出非黑即白的答案，我现在可能更喜欢把对错看成一个时间轴上的相对概念，我们在 K 线的某几个点做了自认为最正确的选择，但随着 K 线的上下波动，有时候我们会认为自己做了正确的选择，大赚了一笔，有时候又会被连绵不断的阴跌搞的怀疑人生，难道我真的选错了吗？

既然对错本身都是在随着时间、位置等维度变化，那么追求绝对的正确或最正确的选择及行为，可能只会让我们迷失自己。所以，不求无错，但尽人事，也许才是我们面向前路的最佳心态。

也许以后我又会对看不惯的事情，发起 diss，最后又发现小丑竟是我自己，但向好的心，会引导我们做出改变，去对抗那只小丑，做回自己。谨以此文，记录自己这一年来从零到一建设、迭代、优化一个系统的琐碎故事及心路历程，希望明年再翻阅此文时，我已经战胜了几只小丑，然后一脸社死的说“我去年的代码和文章写得真烂啊！”。

长按识别下图二维码，关注公众号「Doocs 开源社区」，第一时间跟你们分享好玩、实用的技术文章与业内最新资讯。