程序员删库到跑路的思考

作为程序员，日常工作中需要面临和解决各种各样的问题，随着问题越来越复杂，需求越来越多，慢慢会超出个人心智负担，终有一天你会厌倦，期望自己能脱离苦海(删库跑路)。个人最近一直在思考这个问题，当我们面对这些问题越来越力不从心的时候，应该怎样做才能让自己稍微解脱点。程序员最主要的日常工作就是完成需求，那么我们何不从需求的角度来探讨下这个问题：我们提出了一个需求，这个需求就是让我们轻松点、不那么累。

需求过于复杂

业务需求的复杂性会让我们抓狂，特别是产品经理从不会提炼需求，只是简单的转达运营的各种诉求，从没考虑实现上的可行性和复杂性，认为画个原型图描述下业务流程就算是完成了产品的工作。产品是运营和技术中间的屏障，如果不能剔除一些无效的信息，拒绝一些不合理的要求，那么就会给技术人员工作带来更大的困难：需要从各种信息中筛选有效的剔除无效的，需要指出不合理的部分，还需要反复沟通让产品理解我们的面临的困难，在无尽的扯皮中消耗自己的精力和耐心。
我们很难寄希望于短期内提高产品同事的水平，但是我们也应该表达出我们的意见，产品同事应该在需求梳理上做的更好，"人人都是产品经理"我个人认为这是希望每个人都能以产品的思维来思考问题，但是并不是说每个人都真正具备产品思维，这种思维的培养需要刻意练习，而不是靠提一大堆需求就能自然而然产生的。这个只能寄希望于公司更加注重培养产品同事的产品思维。另外一点要提的是，需要警惕公司产品职能架空，公司业务完全运营导向化。这种情况下产品和技术的意见无足轻重，只需要完成运营提的需求就好了。产品是最靠近公司战略方向的部门，运营部门基于产品定位实现运营策略，技术实现产品实物或者运营工具，产品的重要性不言而喻。

系统各种各样的bug

bug会伴随技术人员的整个工作生涯，我们不得不分出一部分精力来应对这些可恶的bug。bug的产生有各种各样的原因，但是都给我们带来了痛苦，我们不得不回顾那些一坨坨的代码，如果是你写的那你还庆幸点，如果不是你写的还特别复杂，那你只能感叹太难了：不得已的情况下你做了部分修改，你也不知道能不能奏效，你只能心里默默祈祷。

1.技术人员水平参差不齐

不同的人实现同一个需求，短期来看效果是一样的，长期来看可能就有所不一样。随着时间的流逝，代码跑过的case越来越多，一旦出现意想不到的边界情况，bug就产生了。这种情况下我们希望整个技术部门的同事能在实现需求的时候多思考点，这个方案是否还有没考虑到的边界情况，而不是认为只需要主逻辑跑通就好了。提高技术同学的思维严谨性是有必要的，特别是在一些关乎安全性的功能上。我认为技术部内部有必要发出这样的声音，来提醒每一位技术同学。

2.业务需求冲突

为了实现新的需求，我们在原有代码上加了一坨又一坨的东西。指不定哪天就因为业务冲突，导致原有的功能出现了问题。为了解决这个问题，我们得清楚导致新旧需求的冲突的根因是什么，我们需要反复理解代码背后的业务逻辑，也许这些代码是一两年前写的，那真的是太痛苦了。需求冲突是没有达成一致性的体现，在产品设计之初就应该考虑一些准则，确保提的需求都可以围绕一些基本性原则，而不是漫无目的，各有各的想法。

3.没有充分的测试

我目前所在公司是没有专职测试的，所以只能靠自己自测，另外一方面靠产品测试。没有专职测试是出于公司节奏的考虑，每天都在改动，每天都在上线。我们也有写单元测试和接口测试，但是这并不充分。测试需要完备的测试用例，一条条执行，显然我们并没有。所以有的技术上线的功能bug少点，有的多点，没有专职测试进行兜底。我并不希望说一定要引入专职测试来解决这个问题，我们是可以通过其它手段如把控上线代码质量来缓解这个问题的。

技术债务

由于各种各样的原因，我们欠下了很多很多的技术债务，这些债务越来越多，我们在系统上的改造成本会越来越大，最终会压垮我们自己。每一个业务最初的需求都是很简单的，随着时间的流逝，这个业务越来越复杂，我们在原有的代码上改造再改造，终于有一天，这些代码变成了庞然大物，每一次去修改它都是一种折磨。也许你进入一家新公司，接手前人的代码都有这样的体会，但是这些代码的可能创造者包括你我，所以在技术债务压垮一切前我们是否能主动采取行动，来偿还这些债务，我们可以先跟主管或者负责人沟通，甚至是老板沟通，让他们理解我们面临的痛苦，获取到他们的支持后我们内部再达成一个一致性的重构方案，来彻底根除我们的痛苦。也许你会说重构非常困难，我认为当你把重构提到一个高度来思考，慢慢地你会发现也许也并不是很难，我们需要一个循序渐进的过程而不是立马推翻一切重新做。我希望大家都能理解，每一家公司都有技术债务的，所以每家公司每个技术工作者都应该有偿还技术债务的探索，否则我们只能任由一切往不可控的方向发展，只能当痛苦达到临界点时选择逃避。

人员流动

实现需求的人最懂代码该如何改，当实现需求的人离职了甚至当时的产品也离职了，那么后人接手过来改的话需要了解这个需求大的背景和它牵涉到的代码，也许是一点点小的改动，但是我们不得不付出巨大的精力来了解这一些，有可能还需要反复沟通，了解细节。所以我们一方面希望保证人员的稳定性，另一方面该思考如何减轻这种"流动"带来的痛苦。人员为何流动，这是我们需要关注的，考虑其动因我们再看是否能解决这些问题，但是需要注意的一点是当提出离职时那估计是不可挽回的，这意味着离职临界点已经达到了，所以我们需要尽可能早点意识到他们所面临的问题，帮助他们摆脱目前的困境。你并不能指望员工主动并且真诚的跟你说出他们面临的痛苦，他们只会默默心里承受，到达临界点时再提出离职，所以需要中上层主动了解。如何减轻"流动"带来的痛苦，我认为保证代码质量是有必要的，复杂功能的产品文档和架构设计文档也是有必要的，定期地优化复杂核心功能模块也是有必要的，这些都能尽可能保证我们接手到的不是烫手山芋。

结语

我们程序员并不是无所不能的，我们的精力也是有限的，当所有的事情需要的精力超出我们所拥有的，带给我们的将是持续的痛苦，大浪淘沙，有的人从此深陷泥潭唯有通过跑路解脱，有的主动寻求方案来减轻自己的痛苦。