七件“逼疯”过程序员的事件，你遇见的那件最糟心

那七件“逼疯”过程序员的事件，可以说你是都经历过啊！

一、懂点技术，瞎指挥

有人说不懂技术的瞎指挥很可怕，我倒是觉得懂点技术，然后指手画脚更可怕！有个国企的项目，甲方负责人李总是个局里的二把手，不知道什么时候了解了一点编程的技术， 每次开需求会都是和我们大谈如何开发软件，他的口头禅就是： 这个需求，用个SQL从数据库一选不就出来了？！你们怎么得开发一周？！别想蒙我！

唉，他怎么能考虑到用SQL的like是效率极低的， 数据量大了是要崩溃的，我们得建立全文索引，需要用一套基于搜索的解决方案才行。

甲方的技术实力看起来这么“强悍”， 不懂技术的乙方负责人只好和稀泥：我们回去再评估一下。

懂技术的程序员在下面大眼瞪小眼。

二、代码都写玩完了，需求变了

这一点我不想多说，相信大家都深有体会。虽然敏捷软件开发的方式对这个问题有一定的改善，但是无法根治，尤其是当客户觉得这个东西就是好，一定要实现的时候，程序员基本上是无能为力的。

必须得改！ 不想改? 还想不想干了！

三、任务时间估算

我工作了这么多年了，遇到任务的时间估算，或者项目的工期估算还是头疼。主要有两方面原因，一个是内因，即软件固有的复杂性，软件工程发展了这么多年，我们努力地让系统的各个模块独立，关注点分离，高内聚，低耦合。

但是还是没有办法像搭积木那样去开发软件。很多细节纠缠在一起，难以准确估算。还有一个很大的风险是：一个你预料不到的，很小的问题就能把你死死地拖住，让你耗费大量的精力。另外一个原因就是外因，人和项目的因素。你把任务时间估算得多了，有人会挑战你，怎么需要这么长时间? 估算的少了，自己就默默加班忍受吧。

如果是项目倒逼工期，那任务估算就是一个摆设了。

四、到客户那儿去演示

为了做好一个演示，在公司把系统调试了很多遍，把演示的步骤一步步都准备好了，到了客户那里，可能是手贱点了一个什么东西，然后，系统崩溃了，演示进展不下去了。经历过两次这样的事情后，每次演示我都变得战战兢兢，如履薄冰，不敢越雷池一步，严格按照脚本来走。现场演示一个不成熟的产品确实是让人挺崩溃的事情。写到这儿，我不由得想起来老罗在台上满头大汗地演示TNT的场面......

五、写文档

代码好不容易写完了，刚刚喘口气，准备开始下一个工作，领导说，把文档也补一下，接口参数的含义都写上 ，程序员心里通常都会不爽，有所抵触，结果就是草草地写个文档出来。为什么这样呢，因为实现功能的那些代码才是体现自己价值的，能够赚钱的工作，文档看起来只是附加品而已。工作做完了，谁愿意多干活呢？再说了，工作量估算的时候把写文档时间算进去了吗？ 你都不给我时间，现在还让我写，不是让我加班吗？

如果想把工作做得漂漂亮亮，既有优雅的代码，又有完善的文档，必须得给文档工作留出时间才行。

六、修改遗留多年的代码

如果有对web前端感兴趣web前端程序员，可来我们的web前端技术学习qun的哦:7280，

32879里面免费送web前端的视频教程噢！

我自己是一名从事了6年web前端开发的全栈工程师，辞职目前在做线上教育讲师，创了一个交流裙，每晚都会在裙内直播，今年年初我花了一个月整理了一份最适合2018年学习的web前端干货，从最基础的HTML+CSS+JS+html5到Vue，node等各种框架都有整理，送给每一位学习web前端的小伙伴，这里是web前端学习者聚集地，欢迎初学和进阶中的小伙伴。

为了实现一个新功能，我得修改六七个文件，其中包括一个长达5000行的JSP，三个500行的函数，2个没人问津的存储过程，做这一切的时候，还得小心翼翼地不能破坏老功能，此中酸爽滋味，不知道别的行业能否体会得到?

你说这遗留代码烂吧，但是人家可以工作，你想重写吧，一是没有时间，二是重写了能保证每个犄角旮旯的业务点都覆盖吗？ 所以只能采用渐进重构的道路，慢慢地把他改好。

能够从头开启一个新项目的同学，还是挺幸福的，好好珍惜吧。

七、Bug不可(难以)重现

人世间最痛苦的事就是明明有个Bug在我的眼前，我却无法重现它。 四五年前，我们有个运行良好的应用突然出了状况，一到下午两点左右就会毫无征兆地崩溃，查看了日志，根本没有报任何错误。在测试环境中想尽了一切办法进行模拟，总是无法重现。

这样的现象持续了一个多月，感觉就要绝望的时候发现了蛛丝马迹，北京时间的下午两点，是意大利的早上8点，那个时候，意大利的用户会登录系统，有些特殊属性的用户做了一个操作，触发了一个年久失修，普通用户根本走不到的代码分支，导致系统直接退出。只用一行代码就Fix了这个Bug，但是重现的过程竟然长达一个多月！

以上七件都遇到过你也算是老人了，说说你的故事吧！