中国软件开发工程师之痛及我的感受

本来已经转载，但我想加上自己的感受时发现不能编辑。就用这种方式转载了。
就目前我的工作内容而言，技术已经没有任何可以学习的了。就像一个建筑师（architect 同架构师）,建筑图已出。公司不过是在复制一个又一个同样的盒子。建筑师的作用只是
保证造下一个盒子时别出错。最近做了一个pro c转化Oracle storedProcedure，五年前我做的比这个需求复杂。唯一不同的Oracle升级了。那又怎么样，用不到分析函数，用不到nosql。我的技术还是一个程序员级别，连程序设计员都不敢自称。虽然前一个proc是我设计的，那时是设计师，现在不是。只有一个目标bug-〉0，郁闷。

以下为转载：
中国软件开发工程师之痛 2013-07-23 08:31:13

分类： IT职场

在近期的一次会议上，有高层谈到之前在中国觉得自己做得很牛，但与美国同行接触后却发现与人家存在很大的差距，这一点我在外企工作时也有过同样的体会。真正与外国同行接触后才会知道什么是差距，在这篇文章中我从软件开发工程师的角度以“痛点”的形式来谈一谈我所认为的差距。

技能之痛

相当数量的软件开发工程师（后面简称为工程师）认为除了与编码相关的内容外，其他技能都不重要。在这种意识的引导下，很容易出现的一个普遍现象是技术能力不错，但开发能力却不行。这种现象的另一种表现是：单干可以，合作不行。

技术能力是指个体对某些技术知识掌握的深度和广度，而开发能力除了包含技术能力外，还涵盖个体在项目运作过程中所需掌握的其他能力。

高效的团队一定离不开通过知识管理将个体所掌握的知识通过分享而沉淀下来。分享途径无外乎通过一定形式的文字和（或）图，这就要求工程师掌握使用象Word、PowerPoint、Excel、Visio（和UML）这类工具的基本能力，并具备良好的写作与表达能力。表面看来这种能力与编码能力无关，因而也得不到工程师的普遍重视，也因此成了一个痛点。其实，写作与表达能力与编程水平息息相关，因为它们都在考验我们的逻辑思维和概念能力。忽视掌握必要工具软件的工程师难道以为编程语言是知识分享的万能工具？

个体具备良好的沟通能力是项目顺利运作的基石。不良沟通表现为：工程师在团队合作中更多采用被动询问而非主动汇报、不会辩论、对于他人指出的错误表现得“自尊”和狡辩而非感谢或承认、对于被邀请的各类审查活动（如设计审查、代码审查、文档审查）不是积极响应而需别人催促。在团队中，如果技术管理者不能很好地引导，个体沟通能力的缺乏很容易在团队中引发“一言堂”或“无政府主义”问题，工作效率低下则是必然。

专业精神之痛

不少工程师对于自己的职业缺乏精神上的追求，工作起来不求专业，只求“代码能工作就行”。这类工程师容易将经验与资历等同，以为工作年份越长就越有经验，实则不然。工作年份越长资历是越老，但如果专业水准没有在过程中不断提高的话，所获得的经验很可能趋零。

什么是专业？专业是指我们应以业内所广泛达成的共识去从事软件开发活动。这里的“业内”并非只指“国内的”，而是指“国际的”；“专业”也并非单指技术内容（比如，编程语言、算法等），还包含软件项目运作中的其他各个方面（比如，开发方法、建模工具、流程、质量保证手段等）。要做到专业做事一定离不开不断地学习，只有这样才能了解行业的动向。

软件行业虽然没有“银弹”，但仍存在不少有效改善开发质量与效率的方法。只有抱着专业做事的态度去工作，我们才有可能去实践这些方法，并在实践过程中思考这些方法的内涵与不足，进而为自己的工作量体裁衣。千万不要认为“反正业内没有银弹，我要去学那么多方法干什么？”

强调专业做事的根本目的，是使我们的做事方法更科学。与我所了解的美国、俄罗斯这些国家的工程师相比，我国工程师的专业化还有很长的路要走。

速度之痛

除非你完全认可中国近些年以GDP为导向的经济发展策略，否则很可能得反思一下软件行业所鼓吹的“唯快不破”策略，尤其是互联网领域。

在商业环境中，“快”能获得很多竞争优势，这毋庸置疑。工程师的价值虽得（最终）体现在商业产品上，但千万不要忘记了我们始终是一名工程师，在实现商业价值的道路上不断提高自己的专业水准无论如何都不应被忘记。工程师始终要明白，公司的发展与自身的职业发展并非完全统一。如果在公司的发展过程中我们的专业水准并没有“水涨船高”，那除了说明我们在吃老本外，还表明我们很可能是在“拖后腿”。在这种情形下，即使公司蒸蒸日上地给我们发薪水，但从个体职业发展的角度说来，公司发展其实与我们“一毛钱关系都没有”。我想不致于有人认为自己以后只会在这一家公司干吧！如果真是那样想，你能保公司几十年存在？届时万一得无奈地离开公司，单薄的专业水准又如何在人才市场与他人竞争？

对“唯快不破”的误解所带来的不良后果是，有些工程师为了快速实现软件功能而忽略了专业精神。他们一味地为了速度而筑下高额的“技术债”，甚至在“速度”的幌子下过得心安理得。

如果将“唯快不破”改为“唯效率与质量不破”或许更不容易形成误解。一说到“快”，给人的感觉往往是投入更多的时间就能达成目的，容易让人忽视做事的方法与效率。与之不同的是，强调效率需要我们考量投入时间的产出比，且暗示做事的方法只有对路才能获得效率；强调质量则提醒我们尽量别做“豆腐渣”之事，而这隐含的内容是我们必须专业做事，即使欠下了“技术债”它也时刻提醒着我们那是一定要还的。

软件行业的长期被动加班成为了速度之痛的一个缩影，它让不少工程师过着有工作没生活的日子。软件行业要避免偶尔、短期的加班是不可能的，但长期的被动加班绝对是个问题。不重视效率与质量的“勤劳”除了是在浪费外，更是一种透支将来的短视行为。

视野之痛

视野之痛体现在工程师在从事技术工作时，忽视了解国外的发展状况。他们因为不知道同质开源项目的存在而走上“重新发明轮子”的道路，甚至发明出“三角形的轮子”；也因为对英文资料缺乏阅读的耐心而不去了解相关国际标准、订阅开源项目的mailing list和专业网站的newsletters等。

狭窄的视野很容易让人自满，以为软件开发就是那么简单，最后导致成长慢、意识与技能“不入流”。

以我的经验来看，工程师如果不能很好地阅读英文资料则要达到高技术水平实在很难，视野狭窄也恐成必然。另外，编程活动中的命名环节其实对我们的英语水准提出了一定的要求，不然很容易动名词不分而写出只有自己容易读懂的程序，或常出现命名时找不到合适的单词去精确表达程序意图。

持续发展之痛

以上各痛点的最终结果又给我们带来了持续发展之痛。其表现为：少有人会在项目中通过文档提升开发效率；鲜有人会持续改善软件的设计质量；大部分人只关注短期完成工作，而忽视短期行为所带来的高额隐性成本。

持续发展之痛使得工程师很难轻装上阵，工作精力过多花费在重复、低级的琐事上，而非用于学习和思考。最终结果是将工作变成了“青春饭”，辛苦但却看不到美好的未来。

所有痛点可以归结为意识的陈旧，或虽有意识却无力于将其转变为能力！（注：意识是一种行为，而非能力）