程序员最头疼的七件事

懂点技术，瞎指挥

 

有人说不懂技术的瞎指挥很可怕，我却是以为懂点技术，而后指手画脚更可怕！

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

任务时间估算

 

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

 

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

 

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

 

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

 

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

 

到客户那儿去演示

 

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

 

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

 

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

 

写文档

 

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

 

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

 

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

 

修改遗留多年的代码

 

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

 

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

 

可以从头开启一个新项目的同窗，仍是挺幸福的，好好珍惜吧。

 

Bug不可(难以)重现

 

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

 

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

 

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

 

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