最让程序员烦恼的10件事

1. 6 个月后再看自己的代码 别打喷嚏，我发现了一个 bug。

你有没有回过头去看看自己以前写的代码，有没有情不自禁地捶胸顿足？有没有在懊恼自己当初怎么会这么傻逼，写出这种垃圾玩意！删掉，删掉，通通删掉！

2. 与其他程序员的相处 程序员经常和其他程序员合不来。不要装的很惊讶，内心早承认了吧，亲爱的程序员们。关于这方面的事例我随口就可以列出十大条，甚至可以另外单独写篇博客，所以在本文中我仅列出几个之所以会和同事难以好好相处的常见原因：

脾气暴躁，态度不友好。 不明白什么时候该去讨论系统的架构，什么时候该开工。 无法进行有效的沟通，使用易于误解的专业术语。 自己的事情处理不好。 对代码库和项目兴致缺缺。

3. 含糊不清

“哎呀，我的网站出问题了”、“XX 功能不正常”，这种指向性不明确的要求最 痛苦了。我特别讶异的是，当我们要求那些非程序员重现问题时，他们竟然会愤怒不已。难道他们不知道，仅仅一句“电脑坏掉了，快点修复一下”，我们是没办法开始工作的，我们需要更多的信息。

软件的运行，在大多数情况下，是有迹可循的。我们也喜欢这种方式。请迁就我们， 帮助我们找出是在哪一步出现的问题，而不是简单一句“修复”。

4. 硬件（总是被当成修电脑的）

任何一个程序员要是被叫去调试数据库服务器上一种奇怪的宕机现象，或者去解决

RAID 驱动器不能正常工作的问题，而最后发现却是硬件的原因，orz 都会痛苦不已。话说，不知道哪里来的误解，人们竟然会以为程序员这种整天捣鼓电脑的家伙，肯定知道如何修电脑。好吧，有些程序员确实会修（大概是他们大学 时泡妹子修炼的技能？），但是，我敢打包票，大多数程序员是不知道的，或者对程序被编译成机器码后是如何工作的毫不关心。

我们关心什么呢？我们关心的是我们做出来的东西是否符合需求，这样我们才能集 中精力去解决更高级别的任务.

5. 缺少文档的程序 好吧，我从来没有说过我们程序员是说一套做一套的人。程序员经常被要求在项目中用到第三方的类库和应用。这使得我们不得不需要文档。但是正如我在上面那条说的那样，程序员痛恨写文档。真是个矛盾又纠结啊！

当我们需要使用一个第三方类库是，却不知道至少有一半的 API 有什么用，没有什么比这个更让人崩溃了。知道函数 poorlyNamedFunctionA ()和

poorlyButSimilarlyNamedFunctionB ()的区别不？当我访问 PropertyX 时是不是需要先做一个 null 测试？如果缺少文档，我估计我得通过自己的测试和错误报告才能知道结果，哦，my god！

6. 写文档

没错，的确有很多文档生成工具，但我的经验告诉我，这些工具都是只适合生成

API 文档，以供其他程序员参考。如果你开发的软件是很多人在日常生活中都会用到的，那么你最好写一些即使外行人也能理解的文档（例如，应用程序如何工作、故障诊断指南等等）。

好吧，有些程序员可不乐意干这事儿。大家经常做的是，快速浏览开源项目，然后开始不断的搜寻文档来获取帮助。

我敢打保票的说，不管在哪里，几乎所有的程序员被要求写文档时，都会说：“不能让其他人去写吗？”

7. 管理层不懂编程 当然，也会有例外，此点标题仅为个人遭遇，如有雷同，纯属巧合。 首先我们要承认，管理不是个简单活。下属会讨厌你：他们脆弱的内心有时也会

受伤。并且要保持一大群人的团结和凝聚力几乎就像是座山一样的任务。然 而，任务艰巨并不意味着管理者能不对他们的下属有一个基本的了解。当管理层无法把握工作理念，就会使员工出现范围蔓延，超出完成期限，感到挫折心情沮丧等 等状况。这是很多程序员在日常工作中经常抱怨和焦虑的根本原因。

8. 范围蔓延 维基百科将范围蔓延定义为“在项目范围内不受控制的变化”。范围蔓延会使得

一个相对简单的请求延伸成一个极为复杂和耗时的任务。它就是运用一些看似方便无害的要求蔓延范围，一步一步破坏项目的时间表：

版本1：显示所在位置的地图 版本2：显示所在位置的三维地图 版本3：显示所在位置的三维地图，精确到可以作为飞行导航

9. 各种打搅

在大多数情况下，程序员的思绪比起法拉利更像是火车，需要慢慢启动，也就是说我们得酝酿一下才能进入状态。但是一旦我们全身心投入的时候，就会高效完成很多令人啧

啧称赞的代码。只是很不幸的是，这是很难达到的境界，因为我们的思路总是不断受到客户和同事的打搅

10. 注释说明“是什么”，而不是“为什么” 入门级编程课程教导学生要学会频繁且尽早地注释。不可否认在学习编程的起步阶段这方法的确是相当有效的（即使看到最简单的代码行都像天书）。然而许多程序员即使已经从一只小菜鸟长大成一位计算机牛人，也还是把这个习惯给延续了下来。

r = n / 2; // Set r to n divided by 2 // Loop while r – (n/r) is greater than t while (abs ( r – (n/r) ) > t) { r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r) } 看明白上面的代码是啥意思没？ 四个字：云里雾里。

上述问题就是，虽然有很多注释，但是却没有说明为什么要写这些代码。下面将上述相同的代码换用另一种注释，那效果就大大不同了。

// square root of n with Newton-Raphson approximation r = n / 2; while ( abs ( r – (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); } 是不是好多了！虽然我们还是没有完全理解这段代码是什么意思，但是至少我们精简了代码，清爽多了。

写注释是为了帮助读者理解代码。这里假设，所有阅读代码的人都已经对 for

循环如何运行有了基本的了解。他们可能不清楚的是，你的代码如何奏效或者你为什么选择这条路径来实现。

第二篇：程序员的工作总结

工作总结

1 完成的主要工作

1.1 工程部PDA运维系统

我是4月末来到公司的，来到公司的初期主要是对工程部PDA运维系统进行了解，并对PDA以后可能用到的一些技术进行研究，而后对现有的项目进行修改。系统包括3个主要功能模块，一个次要模块，主要模块有工单管理、消息管理和系统升级。 工单管理的修改

系统升级可下载单个的文件,可同过一个文件升级

PDA上线之前主要在有线的5个站点做实施工作，第一次做实施，以为只是简单的教用户怎么用就可以了，但是真正做起来才知道，针对不同的用户需要用不同的角度去讲解，特别是年龄大的，要多讲几遍才行。

PDA上线以后工作主要集中在PDA的维护和修改上，由于距离上次实施时间较长，所以又进行了一次实施。每个站点使用PDA的时间不同，花费在每个站点上的维护和实施时间较长,在实施和维护期间每个站点都提出了不同的问题，针对不同的问题修改了很长时间，其中修改最多的模块主要集中于工单管理模块和系统升级模块。 系统在所有站点都开始使用以后主要针对站点提出的不同的问题进行解决和系统的改进，经过改进的系统很稳定,问题基本出现在

由于信号不好的原因导致升级失败，由于卡停机导致系统不能正常登录。还有几次是因为网络原因导致系统不能使用

1.2 有线BOOS系统

PDA运维项目稳定后主要做了些boos系统中的一些功能，数据库数据的批量转移，

百万条数据的批量的转移功能。

宽带系统的的咨询查询，根据用户地址和时间进行查询， 修改宽带大客户ATM资料查询功能

BOOS系统网上营业厅缴费的遗漏查询

网上营业厅二期产品卡消费

修改了付费频道#5@p打印功能

全网稽查中主工单的打印。

2 收获到的东西

2.1 经验上的收获

来到公司8个月，学到了很多东西，不仅仅学到了学校里没有的技术，还学到了技术以外的更多的东西。

刚来公司的时候我一直想做java方面的项目，但是张总却让我做.net的项目，我很不解，感觉违背了当初的意向。通过和张总的谈话让我懂得，做一个好的软件不在于语言，而是软件本身的质量，软件能不能给用户的使用带来方便、软件的界面是否简单大方，不让人

反感，软件是否稳定，容易维护、容易扩展。利用语言做软件只是一个程序员的基础，更重要的是能发现问题、认识问题、解决问题，做一个好的软件应该设身处地的站在用户的角度考虑怎么样才能更有利于用户的使用。

通过pda系统的实施也学到了不少的东西，由于是第一次做实施，没有什么经验可言，把实施看的很简单。通过本次实施我点的思想也有所改变，我认为实施主要是沟通，实施就是站在别人的角度去思考问题，只有站在别人的角度去思考才能在短时间内教会用户使用。软件的实施，并不是一件很容易的事，由于用户的年龄和文化层次不同，我们要了解不同的人，针对不同的人实行不同的培训方法，。还有一些人只是单纯的听讲，碰到不会的不懂的问题不问，对于这种人要更细心的耐心的讲解，通过本次实施，自己也积累了一些经验，相信在以后的实施工作中，我会做的更好。

综上所述，主要总结出以下几点。

（1） 语言只是做软件的一种工具，更好的软件是站在客户的立场上用心的设计，让用户使用更方便、更快捷。

（2） 利用技术实现软件的功能只是软件的表面，认识问题、分析问题、解决问题才是最重要的。

（3） 养成总结与反思的习惯，并有意识地提炼日常工作成果，在实施上要认真的总结工作经验，为以后的实施工作打基础。

（4） 不论是做事还是做程序，一定要有清晰的思路，要认真仔细的去做，要有耐心和心信。

2.2 程序上的收获

代码规范，注重交流

刚来到公司的时候代码不规范，该加注释的不加注释，经过同事杜明月的指导和代码对比发现了自己的不足，进而意识到代码书写的规范与否会直接影响代码的易读性，进而影响到软件开发的效率。经过一段时间的修正，体会到如果自己写的代码很烂会让下一个改你程序的同事很是头疼，所以一定要提高自己的素质，首先应该注意的要条理清楚、思路明晰、代码规范。

软件开发不是一个人的事，在团队中技术与交流同等重要，交流是团队开发的基石，技术水平是项目坚固的保证。

测试不马虎

一次系统升级，由于是刚刚改好的程序就要上机，就没有好好测试，结果升级后部分PDA出现了闪屏问题，造成了麻烦。经过那次升级意识到测试可能不一定需要很高的技术含量。但却是个考验细心，严谨的任务。 甚至有的时候感到很繁琐枯燥。 但这个保证软件质量的一个重要过程。

掌握进度，随时汇报

在做程序的时候以后都应该时刻提醒自己反应情况，提出自己遇到的困难需要哪些帮助.遇到不会的,不懂的应该及时问.

我认为我适合的工作 ,因为我对手机很感兴趣,所以首先要开发

手机端的软件,同时也开发其他的项目,因为开发其他项目的同时也会了解更多的业务,也会提高自己的综合水平,我这个人又比较喜欢说话,喜欢交朋友.所以在开发程序以外,我也希望自己多做些实施方面的工作,这样即能更好的了解需求又有助于提高自己的语言表达能力.