懂点技术，瞎指挥

有人说不懂技术的瞎指挥很可怕，我倒是觉得懂点技术，然后指手画脚更可怕！

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

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

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

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

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

这一点我不想多说，相信大家都深有体会。

虽然敏捷软件开发的方式对这个问题有一定的改善，但是无法根治，尤其是当客户觉得这个东西就是好，一定要实现的时候，程序员基本上是无能为力的。

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

任务时间估算

我工作了这么多年了，遇到任务的时间估算，或者项目的工期估算还是头疼。

主要有两方面原因，一个是内因，即软件固有的复杂性，软件工程发展了这么多年，我们努力地让系统的各个模块独立，关注点分离，高内聚，低耦合。

但是还是没有办法像搭积木那样去开发软件。很多细节纠缠在一起，难以准确估算。还有一个很大的风险是：一个你预料不到的，很小的问题就能把你死死地拖住，让你耗费大量的精力。

另外一个原因就是外因，人和项目的因素。你把任务时间估算得多了，有人会挑战你，怎么需要这么长时间?  估算的少了，自己就默默加班忍受吧。

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

到客户那儿去演示

为了做好一个演示，在公司把系统调试了很多遍，把演示的步骤一步步都准备好了，到了客户那里，可能是手贱点了一个什么东西，然后，系统崩溃了，演示进展不下去了。

经历过两次这样的事情后，每次演示我都变得战战兢兢，如履薄冰，不敢越雷池一步，严格按照脚本来走。

现场演示一个不成熟的产品确实是让人挺崩溃的事情。写到这儿，我不由得想起来老罗在台上满头大汗地演示TNT的场面......

写文档

代码好不容易写完了，刚刚喘口气，准备开始下一个工作，领导说，把文档也补一下，接口参数的含义都写上 ，程序员心里通常都会不爽，有所抵触，结果就是草草地写个文档出来。

为什么这样呢，因为实现功能的那些代码才是体现自己价值的，能够赚钱的工作，文档看起来只是附加品而已。工作做完了，谁愿意多干活呢？再说了，工作量估算的时候把写文档时间算进去了吗？ 你都不给我时间，现在还让我写，不是让我加班吗？

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

修改遗留多年的代码

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

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

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

Bug不可(难以)重现

人世间最痛苦的事就是明明有个Bug在我的眼前，我却无法重现它。

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

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

只用一行代码就Fix了这个Bug，但是重现的过程竟然长达一个多月！

【本文为51CTO专栏作者“刘欣”的原创稿件，转载请通过作者微信公众号coderising获取授权】