程序员最头疼的七件事

640.jpg

懂点技术,瞎指挥

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

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

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

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

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

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

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

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

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

任务时间估算

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

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

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

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

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

到客户那儿去演示

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

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

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

写文档

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

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

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

修改遗留多年的代码

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

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

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

Bug不可(难以)重现

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

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

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

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


未经允许请勿转载:程序喵 » 程序员最头疼的七件事

点  赞 (1) 打  赏
分享到: