程序猿最艰巨的任务跟编写代碼没得几个关系。编码是逻辑构思的一种实践，这跟程序猿日常工作中的其他任务比起来相对简单。如果你觉得自身還是1个技术水平普通的程序猿，在你真正的能进入到顶尖高手行列前，请保证你已经战胜了下述晋升的阻碍。

1. 解释你在干什么

解释软件开发过程是1个很艰难的事情。那些非程序猿岗位的人或许了解许多有关编程的事情，但很显然，他们不会编程。对于他们而言，我们的生活只是在一间漆黑的房间内趴到键盘前消耗着咖啡。

你会在你的朋友、亲人和同事中遇上这样的人，他会觉得编码并不是1个合理的岗位。

2. 形象的说出软件解决方案

依据某些简短的要求——一般是一知半解的，你需要设计出数据结构，软件架构，代碼算法，通信协议，以及别的任何针对商业问題的解决方法各种构成。并且你必须用某种外行人听的懂的用语将它们表达出来，并需要在要求的時间里提交给客户。

非常少有程序猿能做到这些。

3. 评估工期

这是程序猿痛苦的本源。在开发任务没有完成以前，你是絕對没有可能确定完成这个任务需要的時间。或许程序跟之前写的很类似，但环境变了，问題变了，限定条件变了。

工作经验会提供一定的辨别力，但多数的程序猿都习惯于低估问題難度。这其中的缘故是他们只考虑到编码这方面的要素，而忽视了这个任务清单上的其余事务。

应对1个问題可能会有一万种解决方法，一万种写法。接手其他人写的代碼，代表你要花很多的時间在无数的代碼行里探寻，了解当时原作者的基本思路。并且，要是是1个不相信注释和文档的程序猿留下来的半个工程项目，麻烦事就更大了。

5. 软件边界的模糊蔓延和让人吐血的奇怪功能需求

尽管敏捷开发方法给软件范围的膨胀提供了一定的预备空间，但这并没有带来任何的功效——特别是在是当你碰到某些由一时兴起的怪念头形成的功能需求。你知道这样做一定会失败。你的团队判断这样做一定会失败。但客户认为不错，而当失败不可避免的出現时，全是你的错，因为是你没有了解他们的真正意图。

6. 在缺少优化和过度优化之间找到平衡点

复杂的软件永遠不会作到极致；总会有一些更好的实施方案。你完全可以不停的优化下去，这就是说为啥软件项目从来都没有提早完工的。

而另一面，“这样就行——我之后会优化它的”这类心态也是普遍的。代碼今日好使，但你知道明日可能会出現麻烦或不能用。当然了，你是不需要去修改它的，它将会交给下一个倒霉鬼程序猿。

7. 测试你的代码

单元测试你也写了，软件也提交了测试组，但Bug仍旧存有……

软件是复杂的，将会含有成百上千行代碼。系统中或者存有千万的各类交互和逻辑路径；你不可能彻底测试它们。

相似的，软件会在不一样的条件下跟不一样的平台上的不一样的软件交互。你不可能所有的都测到。

学习从来不是一个人的事情，要有个相互监督的伙伴，工作需要学习C/C++或者为了入行、转行学习C/C++的伙伴可以私信回复小编“学习”领取全套免费C/C++学习资料、视频

写出好的单元测试是一种乏味且艰辛的工作。理想状况下，测试应当在着手开发设计前就早已写好——但你如何向客户解釋为何4个礼拜结束了依然没有能用的软件？

单元测试并不能覆盖每个问题点。在理想的世界里，应该有一个独立的团队来写测试并积极的去发现问题。不幸的是，对大多数项目来说，这样成本太高，时间不够，于是用开发团队来写测试程序。而开发团队潜意识的会避免很多极端的边界情况。

程序员喜欢用符合逻辑的方式处理所有问题。但用户很少是这样的。他们会发现你永远意想不到的问题。

8. 写软件文档

给代码写文档是一项费力耗时的工作。很少有程序员擅长这个、喜欢这个的，并且很少有程序员会花时间去读它们。

9. 处理IT问题

你每天都在研究技术。你也许是一个HTML或PHP程序员，但你很可能会遇到一些例如硬盘损坏、驱动冲突或软件崩溃的问题。解决这些事情不是你的主要责任，但是，除非你解决了这些问题，否者你将无法继续你的开发工作。

不幸的是，对于IT圈外的人来说，程序员应该是软硬件都精通的人。当他们遇到了问题，他们自己不花时间就解决，直接会找你。不论是遇到什么问题：你是用计算机的，你一定知道如何将预算表导入Sage，如何配置Oracle，或为何在他们的黑莓手机上发不出邮件。

当然了，这些打搅绝对不能成为你完不成工作的理由，也没有报酬，不是吗？

10. 处理人的问题

上面的这些难题都可以总结为“人的问题”。很少有外行人会去建议1个飞行员如何开飞机或建议一个电器工程师如何布线。但很多人却会兴致勃勃的勇敢的建议如何开发软件。

我相信对于这些人没有什么好办法。你需要接受这样的事实：这世界上有一半的智商是低于平均水平的！

.
.
.

如有侵权，请联系删除