一篇关于程序员性格的文章第1/3页

    每个领域的工程人员都知道工具和他们所用材料的局限性。如果你是一位电机工程师，你就应明白各种材料的导电性和使用电压表的各种方法。如果你是一位建筑师，你就应明白木材、混凝土、钢材的性能。而如果你是一位软件工程师，你的基本建筑材料是人的聪明才智，并且你的主要工具是你自己。建筑师是将建筑物结构进行详细的设计，然后将设计蓝图交给其它人去建造，而你则是一旦当你从细节上对软件作出设计后，软件生成过程也就结束了。 

编程的整个工作就如建造空中楼阁一样——它并不是纯粹的人工活动。于是，当软件工程师研究工具和材料的必需性时，他们发现自己正在研究人的智力、性格，不像木材、混凝土和钢材等可见的东西。 

1  个人性格是否和本书的主题无关

编程工作极强的内部特点使得个人特点异常重要，你想想一天全神贯注地工作八小时有多么困难，你可能有过由于精力过分集中而今天无精打采的体验。或由于上个月过分投入而本月没有一点精神，你也可能在某一天从上午8点工作到下午2点，以致于精神快要坍塌了。有时你从下午2点拼命于到5点，然后花费一周的时间修改你在其间所写的东西。
    人们难以对编程工作进行检查，因为没有人知道你真正干些什么，我们经常有过这样的体验，我们花费8O％的时间进行我们所感兴趣的20％的工作，同时花费2O％的时间生成其余80％的程序。 

    你的老板并不能强迫你成为一个好的程序员，甚至过了很长一段时间你的老板也无法判断你是否是一个称职的程序员，如果你想成为一个高手，你得全靠你自己下功夫。它和你个人性格有关。 

    一旦你自己决定成为一个高级程序员，你发展的潜力是很大的，各种研究发现，创建一个程序所需的时间比可达到10：1，同时也发现调试一个程序的时间，程序实现长度、速度、错误率和所发现错误数对不同的程序员其差别可达10：1。 

你无法改变自己的聪明程度，但是你可在一定程度上改变自己的性格，已发现在程序员成为高级程序员的过程，性格是更有决定意义的因素。 

2  聪明和谦虚

    聪明看起来似乎不是个人性格的一个贡献。它也的确不是。恰巧的是，好的智力是和成为一个好的程序员有着并不严密关系的因素。 

    为什么？难道这并不要求你有一个好的智力吗？ 

    不，你不需这样，没有人真正同计算机一样迅速敏捷。完全理解一个一般的程序需要你有吸收细节的很强的能力，并能同时理解所有细节，你很好地利用你的聪明要比你有多聪明更为重要。 

    在 1972年，Edsger Dijkstra发表一篇论文，名字叫作“谦虚的程序员”。他在此文中主张所有的程序员都应尽力弥补他们很有限制的智力。那些最精通编程序的人往往是那些认为自己的头脑是多么有限的人，他们是谦虚的。而那些最为糟糕的程序员往往是那些拒绝承认自己的能力不适应工作任务的程序员。他们的自我妨碍自己成为优秀程序员，你学到越多的东西来弥补你的大脑，你就越能成为一个好的程序员，你越谦虚，你取得的进步也就越快。 

    许多良好的编程风格的目的是减少你大脑的负担，以下是一些例子： 

Ÿ “分解”一个系统的目的是为了使其更为简单易懂。人们往往易于理解几条简单的信息而不是一条复杂的信息。所有软件设计方法的目的是将复杂的问题分解为简单的几部分，不论你是否使用结构化、自顶向下或是面向对象的设计，以上目标都相同。 

Ÿ 进行评审、检查和测试是弥补人的错误的一种方法，评审方法部份源于“无错编程”，如果你没有任何错误，你就用不看评审你的软件，但是当你知道自己的能力是有限时，你就应和别人讨论以提高你的软件质量。 

Ÿ  将子程序编短一些有助于减少你的工作量。你根据问题而不是计算机科学术语编写程序并使用尽可能高级的抽象思维，有助于减少你的工作量。 

Ÿ 使用各种交谈方式可将你从编程的死胡同中解放出来。 

你也许认为靠聪明能更好地开发人的智力活动，所以你无需这些帮助。你也可能认为使用智力帮助的程序员是走弯路。实际上，研究表明，那些使用各种方式弥补其错误的谦虚的程序员们所编写的程序，既易为自己也易为别人所理解，并且其程序中所含错误也少。实际的弯路是出现错误和影响进度的路。

3  好奇心

一旦你认为自己理解程序的能力是有限的，而且你意识到，进行有效的编程是补偿自己能力的方法时，你就开始了你生涯中漫长的探索过程。 

在变成高级程序员的过程中，对技术的好奇心是很重要的。有关的技术信息变化迅速。许多PC程序员没有在什么机器上编过程，而许多程序员还没有用过电脑的穿孔卡片。技术环境的特定特征每隔5到10年就发生变化。如果你跟不上这种变化，你将面临落伍的威胁。 

    程序员往往很忙碌，以致于他们没有时间对更好地工作或对工作发生兴趣。如果你真是这样，你也不必在意大多，因为许多人都同你一样，以下是一些培养你的好奇心的方法，你真应该好好学一学它。 

    在开发过程中建立自我意识。你对开发过程越了解，不管你是通过对开发过程的阅读或自己的观察得来的，你就越能了解各种修改，并使你所在开发组向一个更好的方向前进。如果分配你的工作任务很少而不能提高你的技能，你也应对此满足。如果正在开发有良好市场前景的软件，你所学的一半知识将会在今后三年内过时，如果你不再学习新知识，你将会落伍。 

在1988到200O年中，美国平均工作人数可增加11％到 19％，计算机系统分析员可增长53％。程序员可增长48％，计算机操作员可增长29％——在现有的1，237，000份工作的基础上再增加 556，000份新工作。如果你在工作中学不到什么，你可试着找一份新工作。 

    实验。了解编程的一个有效途径是对编程和开发过程进行实验，如果你对所用语言的工作过程不甚了解，你可编写一个短程序以检查此特征并看其是如何工作的，你可在调试器中观看程序的执行。用一个短程序而不是一个不甚了解的大程序来测试一个概念是很好的。 

    如果短程序的运算表明程序运行结果并不是你所期望的，这时你应怎么办？这正是你所需要的，最好用一个短程序在有效编程的一个关键方法上迅速制造错误，每次你可从中有所收益，制造错误并不是罪过，没有从中学到什么才是罪过。 

    阅读解决问题的有关方法。解决问题是软件开发中的一个重要活动，Herbert Simon曾报道过人工解决问题的一系列例子。他们发现人们自己通常不能发现解决问题的方法，即使这种方法很容易学到。这意味着即使你想自己创造车轮，你也不能指望成功，你可能设计出方车轮。 

    在你行动之前进行分析和计划。你将会发现在分析和行动之前存在着矛盾，有时你不得不放弃的数据和行动，对大多数程序员来说，问题并不在于过分分析和过分使用。 

    学习成功项目的开发经验。学习编程的一种非常好的方法是向一些优秀程序员学习。Jon Bentley认为你应静心坐下来，准备一杯白兰地，一枝好雪茄烟，然后如同读小说一样阅读程序。实际上可能并不是这样，许多人往往不愿牺牲其休息时间来阅读——500页的源程序，但是许多人往往乐意研究一个高级程序的设计，并有选择地研究一些具体细节。 

    软件工程领域很少利用过去成功或失败的例子。如果你对建筑学有所兴趣，你可能会研究Louis Sullivan，Frank Lloyd Wright和 I.M.Pei的设计图，你也可能会参观他们的建筑物，如果你对结构工程有兴趣，你可以研究 Broolyn大桥，Tacoma Narrows大桥以及其它混凝土、钢铁和木材建筑，你应研究你所在领域中成功或失败的例子。 

    Thomas Kuhn指出，任何成熟的科学，实际上是通过解决问题而发展起来的，而这些问题通常被看作本领域良好工作的例子，并且可用作将来进行工作的例子。软件工程是刚入成熟阶

段的一门科学，在1990年，计算机科学和技术委员会曾指出，在软件工程领域很少有对成功和失败的例子进行研究的文件，在1992年3月的“ACM通信”中有一篇文章主张对别人编程中出现的问题进行研究，总之，学习别人的编程是有重要意义的。 

    其中一个最受欢迎的栏目是“编程拾萃”，它专门研究编程过程中出现的问题，这对于我们是有启发的。 

    你可能有或没有一本研究编程的书，但是你可阅读高级程序员所编写的代码，阅读你所尊敬的程序员的代码，或阅读你并不喜欢的程序员的代码，再将他们的代码和你自己的代码比较。它们之间有何异同？为什么会有差异？哪一个更好？为什么？ 

    除了阅读他人的代码之外，你也应让其它高水平程序员评价你的代码质量，找一些较高水平的程序员评论你的代码，从他们评论中，你可剔除那些带个人色彩的东西而着重于那些重要的东西。这样可提高你的编程质量。 

    阅读手册。手册恐惧症在程序员中很流行。一般来说，手册的编写和组织都不好，但是程序员对手册的恐惧也和他们对书本的过分恐惧有很大关系。手册含有一些重要的东西。所以花费时间阅读手册是值得的，忽视手册中的信息正如忽视一些常见的首字母简略词。 

    现代语言产品一般都带有大量程序库，这时，你花费时间查阅参考手册是值得的，通常提供语言产品的公司，已经编写了许多你可以调用的子程序。如果是这样，你应弄懂有关手册，每隔一段时间阅读一下手册。 

    阅读有关书籍和期刊。你应为自己阅读本书感到幸运。你已经学到了软件工程的许多知识，因为一本书每年都要被许多程序员所阅读，读一些东西可能使你的专业知识向前迈进一步，如果你每二个月阅读一本好的计算机书籍，你的知识将会大大提高并能在同行中脱颖而出。 

4  诚 实

    编程生涯成熟的部分标志是不折不挠地坚持诚实，诚实通常表现在以下几个方面： 

Ÿ 不假装你是一个编程能手 

Ÿ 乐于承认自己的错误 

Ÿ 力图理解编译器警告信息而不是对其置之不理 

Ÿ 对你的程序有一个清晰的了解，而不是进行编译看其是否有错 

Ÿ  提供实际状态报告 

Ÿ  提供实际方案评估，在你的上司面前坚持自己的意见 

最新评论