[导入]注重实效的程序员--从小工到大师(连载)

自己翻译得很粗糙,大家原谅.

觉得是一本好书,所以想和大家共享,我个人觉得,哈哈,许可证的规定是不尽然的嘛.

第一章注重实效的哲学
什么是注重实效的程序员？我们认为那是某种态度，风格，方法论以及他们的解决方案。他们会对直接问题采取深度思考，总是试图把它放在一个比较大的环境下联系起来思考，总是试图明白那个比较大的环境。毕竟，离开那个所说的大环境，你怎么才能够注重实效？你怎么才能够做出充满智慧的平衡方案，博闻的决定？
另一个他们成功的关键在于，他们对于他们会对所作的事情负担起责任，我们将在猫吃了我的源代码 The Cat Ate My Source Code 中讨论，注重实效的程序员不会坐视他们的项目由于疏忽而崩溃。在Software Entropy 软件熵增中，我们将告诉你怎么样保持你项目的质朴性。
大多数的人发现变化很难以接受，有时候是因为确实有理由支持这么做，而有时候仅仅因为思维的惯性。在Stone Soup 石头汤以及Boiled Frogs煮熟的青蛙中，我们看到一种鼓励变化的策略以及（在平稳的利益中）表述了关于两栖动物忽视了渐进改变的危险而需要警戒的故事。
不理解你工作的大环境中的好处在于，容易理解你做的软件是如何的好。有时候，接近完美是唯一的选择，但是，总是有很多的折衷掺和在内。这我们将在够好的软件Good-Enough Software 中探索之。
当然，你需要具有相当广泛的基础知识以及经验来兑现这些。学习是一个不断的以及正在进行中的过程，在你的知识投资组合Your Knowledge Portfolio 中，我们将讨论一些关于保持学习动力的策略。
最后，没有一个人生活在真空里。我们所有的人都花费大量的时间与其他人进行交互。交流！一节中列出来某些能够使我们交流得更好的方式。

猫吃了我的源代码

所有弱点的重中之重就是害怕公开弱点--J. B. Bossuet, Politics from Holy Writ, 1709

注重实效的一块基石就是根据你职业生涯的步伐，对你自己以及你的行为承担起责任来，对你的项目，并且对你日复一日的工作。一个注重实效的程序员掌控他/她自己的职业生涯，并且不应该害怕承认自己的疏忽以及错误。这不是编程中令人高兴的方面，但是我向你保证，这是会发生的（即使是在最好的项目中）。尽管通过测试，好的文档，以及实实在在的自动化，事情还是出了错，例如，提交得晚了，没有预见到的技术问题出现了等等。
这些事情的发生，以及我们尽可能采用专业的态度对待它们，并试图解决这些问题，这就意味着诚实和坦白，我们可以为我们所拥有的能力感到自豪，但是我们必须诚实对待我们所拥有的缺点--我们的疏忽，又好比我们的错误。

负起责任来

责任就是那些你积极认同的事情。你做了个许诺说可以保证某些事情会被很好地完成，但是你不必直接控制事情的方方面面。除尽力做好你的本职工作之外，你应该分析超越你控制之外的风险的状况，你不需要对一些不可能的状况担负责任，对那些特别巨大的风险也是如此。你要基于你的道德范畴以及判断做出决定。

当你确实对某个结果担负起责任时，你应该被指望一直对此负责。当你犯错（就如我们大家一样）或者判断失误，老实地承认并且尝试提供一些解决办法。

不要抱怨某些人或者某些事情，或者是找个借口。不要在供应商，程序语言，管理以及你的同事面前抱怨所有的问题。所有这些方面都有人在负责，但是现在是你该提供解决方案，而不是借口。

假设有某个对你来说的供应商不能克服的风险，那么你应该有一个意外事故的处理计划。如果磁盘崩溃了--带走了所有你的源代码--并且你还没有备份，那是你的错。告诉你的老板我的代码被猫吃了恐怕是不能过关的。

提示3 提供解决之道，不要找懒惰的借口

在你试图告诉任何人为什么某事不能够被完成之前，是太迟了还是弄糟了，停，听听你自己。告诉你显示器上的橡皮鸭子或者猫，你的借口真的那么站的住，或者只是愚蠢吧？那么对你的老板来言呢？

将谈话在你的脑海中过一遍。其他人会怎么说？他们会不会说，“你有没有试过这种方法...”或者“你是不是考虑到那种？”你怎么反应呢？在你过去告诉他们坏消息之前，还有没有什么你可以尝试一下的呢？有的时候，你已经知道他们要说什么，那么，何不让他们省下些唾沫。
替代借口，提供解决之道。不要说不可能做到，解释一下，什么可以用来挽救现在的情形。代码不得不被丢弃？看看重构的价值（参见重构）。你是不是需要花些时间在原型上，来决定最佳方法以继续（参见原型与记事贴）？你需不需要介绍一种更好的测试方法（参见代码轻松测试以及残忍测试）或者自动化（参见普遍存在的自动化）来避免缺陷再度发生？或者你需要额外的资源。不要害怕要求，或害怕承认你需要帮助。
尝试将懒惰的借口在你的脑海中冲刷掉，在你将它们大声说出来之前。如果你不得不将它们说出来，首先告诉你的猫。毕竟，小小的Tiddles是打算接受羞耻的...

相关联的章节包括：
原型和记事贴
重构
代码轻松测试
普遍存在的自动化
残忍测试

挑战
你是如何反应，当某人--例如银行出纳，自动售货机，职员--告诉你一个懒惰的借口？你会怎么想他们或者他们的公司？

软件熵增

当软件开发免疫于几乎所有的物理规则时候，熵重重地击中我们。熵是一个物理名词，指代在某个系统中大规模的“无序”。不幸地是，这条热力学的规则保证，熵在宇宙中趋向于无穷。当软件中的无序增加的时候，程序员称之为“软件腐烂”。

有很多的因素促使软件腐烂。其中最重要的因素看来就是，当工作在某个项目中，心理学，或者文化上的因素。即使你是团队的一员，你的项目心理也是一桩很脆弱的事情。尽管具有很好的计划以及很好的人，一个项目仍然可能在其生命周期中毁坏并且衰变。当然也存在其他的项目，尽管存在巨大的困难以及不断的挫折，却成功地超越无序并且最终相当成功。

有什么不同？

在城市内，一些建筑干净并且漂亮，而另一些则破败不堪。为什么？研究者在某些犯罪的地区以及衰败的市内发现出一种吸引人的触发机制，一种将某个干净，完整无缺的，有人居住的建筑很迅速地转变为某个充满醉汉的并且被人遗弃的物体的机制。

一扇破窗

一扇破窗，放在那里一段时间无人修理，向居住在这建筑中的人慢慢地灌输着一种被遗弃的感觉--就是当权者已经已经不再关心这栋建筑。所以，另一个窗也破了。人们开始乱扔垃圾。涂鸦开始出现。一系列的结构性的破坏开始了。在相关短的一段时间内，这栋建筑物被破坏的程度远远超过产权人想要修理它的热情，遗弃的感觉最终成为遗弃的现实。

“破窗理论”赋予纽约以及其他一些大城市警察局防微杜渐的灵感。它确实起作用：在破窗，涂鸦以及其他小的侵害上保持优势，能够降低一系列犯罪水平。

提示4 别和破窗生活在一起

别放任“破窗”（糟糕的设计，错误的决定，或者乱七八糟的代码）不管。看到一个解决一个。如果没有足够的时间将它合理地修复，那么在黑板上写上，公示出来。也许你可以注释出这段令人不愉快的代码，或是显示个“没有实现”的信息，或用合适的虚拟数据替代一下。采取点行动避免进一步更大的损失并且显示出你正熟练掌握着情况。

我们看得很清楚，功能性的系统一旦有窗开始损坏就恶化得很快。还有其他因素促使软件腐烂，并且我们还将在其他一些地方遇到它们，但是忽视加速软件腐烂的因素要超越其他的因素。

你也许会想，没有人会有时间去收拾项目中破碎的玻璃。如果你继续这么想的话，那么你最好有准备得到一个垃圾，或转移到另外的地方去。不要让熵得逞。

灭火

对比而言，有一个故事，是关于Andy认识的，某个令人讨厌的富人的。他的家相当的完美，漂亮，摆放着无价的古董，以及艺术品，等等诸如此类的东西。一天，一条挂毯由于挂得离他客厅的壁炉过近，而着了火。当消防队打算冲入拯救他的房屋的那天，就在消防队员拖动他们那条巨大，脏兮兮的水龙带进入房子之前，他们停住了，就在大火燃烧中，从前门到火源之间铺起了垫子。

他们不想弄脏地毯。

一个相当极端的例子，请相信，这就是一直伴随软件的方式。一个破窗--一段设计得很糟糕的代码，某个错误的管理决定，必须伴随整个团队的项目开发过程的决定--就是一切衰落的起点。如果你发现你工作于一个有好几个破窗的项目中，那么很容易就滑向一种思维方式--其余的代码都是废代码，我也只不过跟着做而已。这种观点不会介意该项目是否会变得好起来。在原始的引发出破窗理论的实验中，一辆被废弃的汽车放在那里一个星期没有人碰。但是一旦一个窗户坏了，在数小时内，车辆就被剥坏，并且弄个底朝天。

相关联的章节包括：
石头汤和煮熟的青蛙
重构
注重实效的团队

挑战

石头汤和煮熟的青蛙

三个从战场回到家乡的士兵非常饥饿。当他们看到前面有个村子的时候，他们的精神上来了--他们确信村民可以提供他们一顿饭。但是当他们来到村子的时候，他们发现门和窗户都是锁着的。经过数年的战争，这里的村民缺乏食物，并且将他们拥有的食物都藏了起来。

士兵没有被这样的状况所难倒，他们煮了一壶水，并且很小心地在其中放了三块石头。感到惊奇的村民出来观看。

“这是石头汤”士兵们解释道。“你们就放这东西？”村民们问道。“绝对地--当然有人说如果放少许胡萝卜会更好些...”一个村民跑了出去，很快从他的储藏品中拿来了一篮胡萝卜。

几分钟后，村民们又问“就这样了？”

“恩，”士兵们说，“一些马铃薯能够使它更有营养。”有跑出去一个村民。
在接下来的一个小时里，士兵们列出了需要加入的，能够使汤更好的要素：牛肉，韭菜，盐，以及香草。每次都有不同的村民跑去拿来他们私人贮藏。

很明显，他们弄出来很大一锅热气腾腾的汤。士兵们去掉了石头，和所有的村民一起吃了一顿数月以来他们中的任何人都没有享受过的实惠的饭。

有一些道德问题存在于石头汤这个故事中。村民被士兵哄骗了，士兵们利用了他们的好奇心，从村民那里得到了食物。但是，更重要的是，士兵们扮演着催化剂的角色，把村民们聚集起来生产一些他们个人无法完成的东西--一个互相促进的结果。很显然，大家都有好处。

时常地，你或许想要仿效这些士兵们。

你也许处于这么个情形中，你确实知道该做什么和怎么做。整个系统就出现在你的眼前--你知道那是对的。而当要求许可来处理这整个事情的时候，你遭遇到的无非是拖延和白眼。人们会形成委员会，预算需要通过，并且事情变得复杂起来。每个人都在捍卫自己的资源。这被称作“启动疲劳”。

是时候把石头拿出来了。设计那些你能够合情合理要求到的。把它开发好。一旦你弄完了，给别人看，让他们大为惊异。然后，你说，“当然，如果我们在往这里加点什么就会更好”。假装这并不重要。坐回去等着他们开始问你，你原来设想要加入些什么功能。大家会发现很容易加入并且达到成功。让他们能够看到未来并且你将和他们一起做成。

提示5 成为改变的催化剂

村民那方

另一方面，石头汤故事也是关于逐渐地欺骗。村民们过于关注于紧密、细小的部分。只考虑石头而忘记了其余部分。我们每天都倾心于此。事情就这么悄悄地过去了。

我们总是看到这样的状况。项目慢慢地并且无情地失去控制。大多软件灾难都开始于很小的事情，太小了，我们没有注意，并且大多数项目在某天某个时刻超速运转。系统特征慢慢离特征规范书越来越远，当一个又一个补丁加入代码中，直到有一天，原始设计就什么也没有留下。一些小事情的积累，总能破坏士气，团队。

提示6 记住大的环境

我们从来不会对于真诚感到厌倦。但是有人说如果你把一只青蛙扔到沸水里，它会很快跳出来。然而，如果你把青蛙放在凉水里，然后慢慢地加热，青蛙不会察觉到慢慢增加的温度并且会一直待在那里，直到被煮熟。

注意青蛙的问题和破窗问题（第二节讨论过的）是具有不同之处的。在破窗理论里，人们失去了制止混乱的意愿因为他们感到没有其他人关心这事情。而青蛙只不过没有意识到改变。

不要像青蛙一样。在大的环境上留个心眼。不断地回顾发生在你周围的事情，不仅仅是做好你自己的。

相关联的章节：
软件熵增
巧合编程
重构
需求陷阱
注重实效的团队

够好的软件

欲速则不达--King Lear1.4

有一个老（式）的笑话，是关于一个美国公司向一家日本生产商定购100,000集成芯片的。作为规范书的一个部分，规定次品率为万分之一。几个星期后，定购的货物来了，一个很大的箱子里包含着成千上万的IC，还有个小箱子，里面就是10个芯片，小箱子上贴了个标签，上面写着：这些是次品。

只要我们确实这么控制质量，那么什么都好办了。但是现实世界不会让我们做到如此真正的完美。尤其是没有缺陷的软件。时间，技术，以及急躁都合谋起来阻止我们做到完美。

然而，这并不令人灰心丧气。就如Ed Yourdon在IEEE软件上的一篇文章所描述的那样，你可以训练你自己写出那种够好的软件--对你的用户、未来的维护者，或者仅仅是对得起自己心灵的平静。你会发现你很有效率并且你的用户也很高兴。你也会发现你的程序事实上比那些缺乏深思熟虑的，短视的软件要好。

在我们更深入之前，我们需要对于我们所谈论的东西进行限定。短语“够好”并不意味着臃肿和错误的代码。系统必须要吻合用户的需求才能被视为成功。我们通常提倡用户们被给与一个机会来参与这样的过程，即决定什么时候你的产品够好的机会。

在协定中包括你的用户们

通常你在为其他人写软件。你会从他们那里得到需求。但是，你有没有经常性地询问他们，他们想要怎样好的软件？有时候那没有什么好选择的。如果你做起搏器，太空穿梭机，或底层库那么肯定有广泛散落在一定区域范围内的需求，这些需求是严格的，你也不会有太多的其他选择。然而，如果你做一款新产品，那么就会有不同的约束。市场部的人有承诺要遵守，显然的最终用户已经根据交付时间表作了一些计划，并且你的公司当然还有现金流的约束。如果忽略这些人的需求，简单地在程序上加入新的功能或者不止一次地改善代码，那是不专业的。我们不提倡恐慌：这相当于不专业地去承诺不可能的时间范围并且不顾基本的工程学角度来迎合截止时间。

做系统的范畴和限定，应该根据系统的需求部分来详细制定。

提示7 限定某个需求问题

经常性的你会处于一种协定的状况中。令人惊奇的是，很多用户宁可立即使用一个粗糙的版本，也不愿意等待一年来使用一个功能丰富的版本。很多预算挺紧的IT部门将会同意这种观点。伟大的软件是现在挺好将来更完美的。如果你早早地给与你的用户们使用你的软件，他们的反馈将引导你达到一个明显优化的解决方案（参见追踪者的子弹）。

知道什么时候该停

在一些方面，编程就像绘画。开始的时候，你有一块空白的画布和一些没有加工过的基本材料。你将通过科学，艺术和工艺的混合方式来决定怎么处理它们。你将勾画出全部的轮廓，并且画上背景，然后描绘细节。你将不时地回顾你所画完的东西，并且使用标准的眼光来衡量之。常常，你会把画布丢弃并且从头开始。

艺术家会告诉你，如果你不知道什么时候该停下来，那么所有的努力都会白费。如果你不停地添加层，不停地添加细节，绘制的作品就会消失在挥动的画笔中了。

不要通过过度修饰和过度精细来糟蹋一个相当完美的程序。继续，让你的代码在它自己的位置上呆会儿，或许它并不完美。不要担心。它永远也不会完美。（在第六章里，我们将讨论在不完美的世界中编写代码的哲学。）

相关联的章节
追踪者的子弹
需求陷阱
注重实效的团队
伟大的异常

你的知识组合投资

投资于知识永远会有最佳回报--Benjamin Franklin

哈，老好的Ben Franklin--永远精通于精炼的说教。为什么，如果我们能够早睡早起，我们将会是伟大的程序员--对不对？早起的鸟儿有虫吃，那么早起的虫子呢？

在此，Ben真的击中要害。你的知识和经验是你最重要的职业资产。

不幸的是，它们会是过期的资产。你的知识过期了会由于新的技术，新的语言以及新的环境被开发出来。市场变化的力量会使得你的经验被废弃并且显得与此变化毫无联系。看看Web时代的飞速发展，真的很快。

由于你的知识价值开始下降，对于你公司和客户而言，你的价值也同时下降。我们大家都不希望看到这样的事情发生。

你的知识组合投资

我们看上去要考虑程序员们知晓的关于编程方面的所有因素，他们工作的应用程序域，以及他们的经验就是他们的知识投资组合。管理知识投资组合很像管理财务投资组合。

1、严肃的投资者有固定周期投资的习惯
3、聪明的投资者在保守投资和高风险，高回报的投资之间取得投资组合的平衡
2、多样化投资是长期投资的成功关键
4、投资者试图买低卖高来取得最大的回报
5、投资组合应该周期性地调整和重新平衡之。

想要在你的职业生涯中获得成功，你必须使用这些同样的指导性条款来管理你的知识投资组合。

建立你的投资组合

·有规律的投资。就如金融投资一样，你必须有规律地投资你的知识投资组合。即使很小的投资量，但是这种习惯要比数量重要得多。一些达成目标的例子将会在下一节里列示出来。

·多样化经营你知道越多不同的事情，你得到的价值越多。作为一条底线，你需要知道你现在工作中使用的技术上里里外外的细节。但不要仅仅到此结束。从事计算机工作变化相当迅速--现在的热门技术在将来也许少有用处（或者根本没有用处）。越多的技术你感到轻松胜任，你就越能够调整好以应对变化。

·管理风险。技术总是伴随着相当多的风险，这些技术中，存在低风险高回报的，当然也有低风险低回报的。把你所有的钱都投资在高风险的股票，那些有可能顷刻倒塌的股票上，这，不是个明智的选择，当然，谨慎地考虑是否要投资所有的股票也可能导致丧失可能成功的机会。不要把所有的鸡蛋都放在一个篮子里，更何况是你的技术“鸡蛋”。

高抛低吸学习那种刚刚浮现出来的技术，而不要等到该技术变得流行起来再去学习，这就好比发现某个被低估价值的股票那样。在Java刚出现的时候就学习Java或许有些风险，但是，这样做的回报对于早期适应它的人来说就是，现在这些人都是该领域的专家。

·回顾和重新平衡这是一个动态的行业。你上个月投资的一项热门技术也许这个月就变得很冷门。或许，你需要对于你一段时间不使用的数据库技术拿出来刷刷灰。又或者你尝试了另一种语言而因此一个更好的职位向你张开了怀抱...

所有的这些指导性的条款中，还有一条最容易做到的就是：

提示8 有规律地投资你的投资组合

目标
现在你有了这些指导性的条款来告诉你，该在你的知识投资中加上些什么和在什么时候添加进去，那么怎么才是捕获智力投资，并且来充实你的投资的最佳方式呢？这里是一些建议：

·每年至少学习一种新语言不同的语言通过不同的方式解决同一个问题。通过学习不同的方法，有助于你拓宽思路并且避免钻牛角尖。另外，学习多种语言现在相当得快，这要感谢在Internet上那些能够免费得到的，丰富的软件（参见第267页）

·每季度看一本技术书籍书店里充斥着关于你现在工作的项目相关联的技术书籍。一旦你有了一个月读一本书的习惯，你掌握了你现在使用的技术，拓展开来学习一些和你项目没有关系的东西也是很有好处的。

·阅读非技术书籍电脑是为人使用的，记住这一点相当的重要。人们需要你去满足他们。不要忘了人性方面的平衡。

·上些课在你所在地的学院或者大学里找些令人感兴趣的课程，或许下次机遇就在那里。

·参加本地用户团体不要仅仅看看和听听，确实地加入其中。隔阂会是你职业生涯的致命伤，找找那些不在你公司工作的人，确实了解他们的一些想法。

·尝试使用不同的环境如果你仅仅工作在Windows上，在家里玩玩Unix（免费的Linux非常适合）。如果你习惯于使用makefiles和编辑器，尝试IDE，反之亦然。

·保持先进性（哈哈）订阅一些商贸杂志和其他一些周刊（参见262页的一些推荐）。选择其中那些包含的技术和你项目不同的杂志。

·得到连线想要知道一种新的语言或者其他技术的里里外外的细节？新闻组是一个很棒的方式来找到其他有经验的人是如何做的以及他们使用的术语，诸如此类的。浏览报纸，商业网站，还有其余你能够找到的信息源。

持续不断的投资很重要。一旦你对那些新语言或者数码技术感到舒服，继续。学学另一个。

别管你是不是在你的项目中使用过这些技术，或者有没有把它们放在你的简历上。学习的过程会拓展你的思路、拓展你做事的新方式和可能性。交叉性联系思维相当的重要，尝试将你学到的课程中的知识应用到你的工程上。即使你的工程不使用那些技术，也许你能够从中取取经。比如，熟悉面向对象会让你撰写简单的C程序起来完全不同。

学习的机会

于是你如饥似渴地阅读，你成为你所处领域中开发的佼佼者（不是件容易事），有人来问你个问题。你对于这个问题所知甚少，只能如实相告。

不要仅此而已，作为对于你个人的挑战来找到那个答案。询问高手。（如果你在办公室里找不到高手，你可以在Internet上找到：参见the box on on the facing page）搜索Web。去图书馆。

如果你不能够自己找到答案，找到那个能找到答案的人。不要让自己放松。和别人交谈可以建立你自己的人际网络，你也许很惊奇会发现在别人那里找到答案以及解决方案。并且原来的投资变得越来越大...

所有的阅读和研究都需要时间，然而时间永远是不够的。所以你要提前计划。活到老就要学到老。在等待医生或者牙医的时间里，你也可以抓紧时间阅读--但是记得带上你自己的杂志，否则很有可能你会翻阅到已经被人翻得破损不堪的，1973的文章，关于Papua New Guinea的那篇。

判断性的思考

最后一个要点就是批判性的思考关于你听到和读到的东西。你需要确保在你的投资组合中的知识是精确的和不为所动的，即使是任何推销员和媒体的大肆宣传，也不能动摇它们。清楚知道坚持自己教条的狂热分子只提供一种答案--它也许能也许不能适用于你或者你的项目。

千万不要低估重商主义的力量。不是搜索引擎列出来的点击热门第一条就是合适的；内容提供商为此花了大价钱才能排到首位。书店把一本书放在首要位置展示并不意味着那是本好书，甚至不一定畅销，它们是因为有人付了钱才被放在那里的。

提示9 批判性地分析你所听到的和所阅读到的

不幸的是，没有进一步的简单的答案。但是伴随你广泛的资产，并且通过应用一些评判性的分析于你将读到的技术洪流般的出版物，你会理解这复杂的答案。

关心与照料高手们

伴随着全球性对于Internet的采用，高手突然之间就在你的Enter键旁出现。所以，你怎么找到那么个高手，你怎么让高手和你交谈呢？

我们发现一些窍门。

·确定你要问的东西，并且尽可能地详细化你的问题。

·仔细地结构化提出你的问题，并且最好礼貌一些，不时去查看一下答案。挑出一些关键的词语并且在Web上搜索之。查看合适的FAQ（那里列着经常问到的问题和答案）。

·你要决定提问是否公开。世界性的新闻组是遇到关于任何主题的专家的好地方，但是有些人天生对这些公开的团体感冒。作为另一种选择，你可以直接向高手发送电子邮件。上述任何一种方式，请使用些意味深长的标题。（“需要帮助！！！”不要停）

·休息休息并且有些耐心。大家都很忙，并且有的时候需要几天才能搞到一个明确的答案。

最后，请向给你反馈的人致谢。如果你看到别人问你能够回答的问题，参与进去并且做好回答。

交流！

我相信做检查要比俯瞰强--Mae West, Belle of the Nineties,1934

也许我们能够从West先生那里学到一堂课。这不仅仅是你已经得到的，也是你怎么包装的。拥有最好的主意，最好的代码，或者最多的团队并不意味着任何结果，除非你能够和其他人沟通。一个好的主意如果没有有效的沟通将会是个孤儿。

作为开发人员，我们不得不在很多层面上进行沟通。我们花费很多时间在开会，聆听并且交谈。我们和最终用户一起工作，试图理解他们的需求。我们撰写代码，是为了使我们的意图能够和机器沟通并且纪录下我们的思想为将来下一代的开发人员做好准备。我们撰写提议和备忘录以请求那些被证明为正确的资源，报告我们的状态，并且建议新的方法。并且我们每天工作于我们的团队来提倡我们的想法，修改现有的惯例，并且建议一些新的。我们每天的大部分时间都在进行沟通，所以我们需要把它弄得好点。

我们已经找到一些有用的主意，并把它们列在了一起。

知道你想要说什么

也许使用在商业上比较正式的沟通方式中最困难的部分就是弄清楚你究竟想要什么。科幻作者在开始之前会就他们所写的书进行详细划分，但是人们撰写技术文档的时候常常很高兴地坐在键盘旁边，键入“1 介绍，”并且开始打他们头脑里出现的下一个想法。

对你所想说的进行些计划。先写个纲要出来。然后问问你自己，“是不是覆盖了我想说的所有事情？”精炼到确实如此。
这种方式或许不仅仅适用于撰写文档。当你将面对一个重要的会议或者和主要客户通电话时候，草草地记下你想要沟通的内容，并且计划几个应对他们的策略。

了解你的听众

你沟通的时候只不过在传递信息。为了做到这点，你需要理解需要，利益，以及听众的接受力。我们都开过这样的会议，一个开发人员犹如表演者一样，通过长长的独白，试图通过说明某项不可思议的技术的优点，往市场部的副主席的眼睛里抹些光彩。这不是沟通：那不过是说话，并且令人讨厌。

一张关于你听众的强有力的精神上图片。离合诗般的智慧，看图1.1，或许会有所帮助。
图1.1 智慧的离合诗--理解一个听众
你想让他们学到什么？
你已经说的部分中他们感兴趣在什么地方？
他们有多久经世故？
他们想要多少的细节？
你想要谁拥有这信息？
你是怎么激发他们聆听你的兴趣？

你想要建议一个基于Web的系统，以便让你的最终用户能够递交缺陷。你能够通过不同的方式来表达该系统，基于你的用户。最终用户会很高兴，因为他们在24小时内都可以提交缺陷，而不必等在电话旁边。你的市场部门使用这个要素来进行促销。支持部门的主管会有两个理由值得高兴：少了些雇员，问题的提交都是自动的。最后开发人员会高兴于得到基于Web的客户端--服务器结构的经验和一个新的数据库引擎。通过对不同团体合适的定位，你将得到他们对于你项目的喜悦和支持。

选择你的时机

现在是周五下午6点，接下来的一周审核人员会来。你上司最小的儿子在医院里，外面倾盆大雨，不加班回家肯定是恶梦一场。现在可能不是要求她帮我的PC升级内存的好时机。

作为你的听众需要听到理解的部分，你需要搞清楚他们做事的优先级别。如果一个经理正为丢失了一些源代码而遭到她上司的责备，这就意味着你有了一个很好的听众来倾听关于你对源代码方面的一些知识。使你所说及时并且有关联，就如紧密联系着的上下文。有时候所有的开始就是从这么一个简单的问题“现在是不是谈论这个的好时候...?”开始的。

选择一种风格

调整你专递信息的风格来适合你的听众的胃口。一些人想要是正式的“确实事实”的简报。另一些喜欢在切入正题之前有些天南地北的神聊。当要写文档时候，一些人希望收到很大范围的报告，而另一些期望简单的备忘录或者电子邮件。别犹豫，问。

记住，无论如何，你是沟通中的另一半。如果有人说他们需要关于某事一段描述而你不能够发现任何方式能够将几页纸缩到一段文字中，就告诉他们事实。记住，这种反馈也是一种形式的沟通。

使它看上去很好

你的主意很重要。它们需要一辆外观漂亮的运输工具来传送到你的听众那里，这样做值得。

很多开发者（包括他们的经理）当开始写文档的时候，就独自一人在那里浓缩提炼。我们认为那是个错误。任何厨师会告诉你，在厨房辛苦努力数小时的结果往往会毁在糟糕的表达上。

现今没有理由弄出外表难看的打印文档。现代的字处理器（拥有排版系统，例如LaTex和troff）能够生产出足以令人晕眩的输出文档。你所需要做的仅仅就是学习几个命令。如果你的字处理器支持风格页，用它们。（你的公司或许已经定义了你可以使用的风格页。）学习一下怎么样设置页眉和页角。看看包含在包裹中的实例文档上的风格和排版。检查拼写，起先使用自动的，而后使用手动的。 After awl, their are spelling miss steaks that the chequer can knot ketch. After All,there are spelling mistakes that the checker cannot catch.
毕竟，总有拼写错误是检查者不能发现的。

包含你的听众

我们经常发现我们弄出来的文档，最后总没有产生他们的过程来得重要。如果可能，尽可能早的包含你文档的阅读者。得到他们的反馈，并且写上他们的想法。你会建立很好的工作关系，并且你可能在此过程中产生出很好的文档。

做一个倾听者

有一个技巧你一定要用上，就是如果你想让人们听你说：首先听他们说。即使在那些你已经拥有了所有的信息的状况下，即使是在一个正式的会议，你站在20个西装革履的家伙面前--如果你不听他们说，他们也不会听你的。

鼓励人们通过提问进行谈话，或者使他们总结你说的内容。使会议成为一个对话框，这样你将更有效率地使他们赞同你的观点。谁知道，或许你还能学到点东西。

给与人们反馈

如果，你问某人一个问题，他们没有反应时候，你会感觉他们很不礼貌。但是，你有多少次没有给别人回复电子邮件、请求信息的备忘录以及请求的某项行动？在每天匆忙的生活中，这很容易忘记。应该总是回复电子邮件以及语音邮件，即使回复很简单“我将稍后回复你。”和人们保持信息将会使得别人对你偶尔的疏忽产生谅解，并且使得别人感到你没有忘记他们。

提示10 总共就是你说什么和你怎么说

除非你在真空中工作，否则你需要能够与人沟通。越有效的沟通也会使你成为越有影响力的人。

电子邮件沟通

我们所说的每件关于沟通的事情，只要关于书写方面，几乎可以等同于电子邮件。电子邮件已经发展成为对内对外的重要沟通工具。电子邮件被用来讨论合同，平息争论，也可以作为法庭上的证据。但是由于某些原因。那些哪怕连发送一片破旧纸片都没有过的人是很高兴嘲笑整个世界充斥着调皮外观的电子邮件的。

我们对于电子邮件的提示很简单：

·在你点发送按钮前先校验。

·检查拼写

·保持格式简洁。有些人通过普通字体阅读邮件，所以使用ASCII格式的图片，而且你因为做这个图片花了大量的功夫，在他们看来就像母鸡抓痕一样。

·仅当你知道你的收件人能够阅读，否则不要使用rich-text或者HTML。平常的文字总是最通用的。

·引用尽量要简短。没有人希望收到一封包含他们自己发出的电子邮件内容100行的内容后面，仅仅只是加上“我同意”几个字。

·如果你引用别人的邮件的内容，确定把引用的内容标示出来，并且在正文里引用（比作为附件好）。

·别在电子邮件里争论（发怒）除非你想这些内容被送回给你。

·在发送之前检查收件人列表。最近，Wall Street周刊的一篇文章描写一名雇员在部门里散布对老板的批评，但根本没有意识到老板也在收件人的列表里。

·归档和组织你重要的邮件，无论是你收到的还是发送出去的。

作为其他方面的例子，微软和Netscape雇员发现在1999年的法庭调查中，电子邮件也包含在内。因此，当你要写回忆录或者报告的时候，请给你的电子邮件以足够的关注。

总结

·知道你想说什么

·了解你的听众

·选择你的时机

·选择一种风格

·使它看上去不错

·包含你的听众

·做一个好的聆听者

·回馈别人