工作效率提升，是所有企业组织都追求的一个目标。高效率意味着用更少到人可以做更多的活儿，赚取更多的利润。员工收入也会有较大提升，有面子；管理层的收 入就更水长船高了。但说起来容易，做起来难。工作效率低下一直是让各个组织的管理者头疼的问题，组织无论大小，无论中外，皆如此。

从大的方面来看，提高效率的策略不会很多，万变不离其中，关键是落实，措施要与自己的组织实际情况匹配。两年前自己曾经写过一篇博文“提升效率不是口 号”，个人觉得那时的观点依旧不过时，长期适用。两年过去了，我们虽然取得了一些成绩，但还远远不够，尤其是当组织情况在持续发生变化的情况下。这里再对 观点做些诠释，plus一些新的想法。

* 领导不彷徨

各级员工都要有明确的目标和方向，领导尤甚。组织的最高领导一级要有明确的业务方向、目标以及组织发展策略。领导是主心骨，如果领导都彷徨，那么下面自然 也跟着彷徨，整个组织就不会有战斗力，效率就更无从谈起。尤其是在大环境不好，业务低迷期，领导更应该作出正确的策略和方向方面的决策。

领导要将方向、目标和策略明确的告知一线Leader，让leader们明确重点投入的方向以及可以投入的方向，以便一线leader可以有的放矢，有计划有节奏的去做，也便于一线leader评估各种人和技术的储备，提前做好准备。

* 适当的紧迫感

如果员工已知的工作只有一项，那很可能出现帕金森现象：在工作中，工作会自动地膨胀，占满一个人所有可用的时间，如果时间充裕，他就会放慢工作节奏或是增添其他事情以便用掉所有的时间。看起来每个人都很忙，但组织效率是低下的。

因此务必要做到让每个员工已知的工作保持在3项左右。当员工意识到三项任务摆在面前时，心中自然会有一定的紧迫感，让员工始终绷紧神经，即便是闲遐时刻也会考虑下一个工作任务中用到的技术我是否做好了准备，从而主动学习和准备。

* 基础设施建设上不能太小气

"基础设施"这个字眼常常出现在新闻报端，中国社会目前依旧出于大规模基础设施建设的阶段中。百度百科里说：“基础设施是指为社会生产和居民生活提供公共 服务的物质工程设施，是用于保证国家或地区社会经济活动正常进行的公共服务系统。基础设施建设具有所谓“乘数效应”，即能带来几倍于投资额的社会总需求和 国民收入。一个国家或地区的基础设施是否完善，是其经济是否可以长期持续稳定发展的重要基础”。在组织个人能力无法快速提升的情况下，适当的基础设施建设 会带来可观的组织效率提升，比如统一的服务器管理、自动化测试基础设施、持续交付工具的开发、体验良好内容丰富的知识管理系统等，让组织人员的工作环境上 了一个“档次”，就好比从中国到美国所感受到的一样，或者从印度到中国所感受到的类似。印度和中国差在哪里？都是50年代建国，人口红利相差不多，但目前 中国却要比印度先进若干年，基础设施水平绝对是一个因素。外商投资除了看重中国的低价劳动力之外，更多是中国的基础设施的完备，据说印度的德里现在还经常 停电呢。同样水平的人在印度和在中国的工作效率显然是不同的，同样的工作在中国一天就完成了，而在印度那边可能还在等啥时候能来电呢^_^。类比组织内， 具有自动化测试环境的前提下，一个项目的验收测试可能在2个小时内就跑完了，而相反，在没有自动化测试基础设施的情况下，可能一个人要做两天，效率高低立 见。

*后勤部门也能诞生将军

现代的工作多是团体作战，这就好比军队：要军事过硬的同时，保障也要给力。也就是说一个军事任务的完成，除了依靠一线冲锋陷阵的将士外，后勤子弟兵的努力一样不可缺少，甚至于在如今的现代战争中，后勤保障直接决定了战争的最后结果。

任何一个公司都有核心业务部门，有从事核心业务研发的同事，也有从事基础设施方面（后勤保证）的人员。要想激发工作热情，提升效率，就要对这些人的工作一 视同仁。工作只有分工不同，没有高低贵贱。其实在很多公司，做基础设施其实更是对能力方面要求很高，更有甚者在一些公司只有一流的程序员才有资格参与基础 设施的设计与开发。因此不要因为基础设施没有带来直接效益而忽视对参与基础设施工作人员的重视。

以上话有些糙，但理不糙，希望能给大家在组织效率提升方面带来些启发。

BTW，这两年自己也持续在组织整体能力和效率提升方面做了些工作：先后推动了组织内部知识管理系统、持续集成、自动代码检查、自动化集成和验收测试、打包与交付以及代码评审流程改进等工作的落地。

本文翻译自Dr. Dobb’s杂志主编Andrew Binstock的"Advice to a new programmer"一文。

总是有太多的建议摆在新手程序员面前，以致他们难于选择从何处开始。然而，所有这些建议都是建构在下面这五条实践的基础之上的。

每隔几个月，我就会收到一些勤奋有加的新手程序员的求助，他们希望知道如何才能成为一名真正优秀的程序员。在一些程序员论坛上，我也能看到为数不 少的类似问题，这是一个令人鼓舞的趋势。一些最周全的答案往往与我对这个问题的看法相似，这表明在基础的最佳实践上确实存在着某种一致。因此我下 面的建议并非原创，不过也许我的这些补充会提供给你更进一步的理解。

我印象中的新手程序员基本了解编程的原理，写过程序，但大多规模较小且复杂度不一，致力于某个领域的工作或自己或他人个人项目。

编程工作只有一种真正的基础活动，那就是写代码。要想擅于编程，你就必须编写大量的代码。 大量的工作可能成为一种促进你成长的工具，也可能是一些有限技能的重复练习。为了避免成为后者，你应该做到：

阅读大量代码。尤其是阅读大量由卓越程序员编写的代码。记住：不仅读那些坐在大厅里的优秀程序员的代码，更要读那些卓越程序员的。 在开源软件大行其道的今天，做到这些十分容易。当我学习Java时，我读了Tomcat的代码，读了Cruise Control CI服务器的代码。自从那时起，我已经读了大量优秀的代码。

阅读代码时很容易从main函数开始，但这样一来，你很可能会在初始化以及命令行解析代码上花费大量时间。我更喜欢根据源文件名寻找一些令我感兴 趣的功能实现，然后深入阅读这些源文件。理解整个项目或整体设计的来龙去脉并不是关键，做这些会让你感觉筋疲力尽的。阅读代码。查看注释，弄清楚 作者在做什么以及是如何着手做的。

彻底了解你的工具。我认为损耗编程时间最多的不是调试或重写代码，而是因开发人员对其所使用工具的不熟悉而导致的无数碎片时间的损 耗。我所指的工具包括：集成开发环境（IDE）、编程语言、构建系统以及版本控制系统。其中，集成开发环境和编程语言是到目前为止最为重要的。经 过几个星期的练习，你应该知道集成开发环境中的几乎每个按键组合，这样你只有在为了节省按键时间时才使用鼠标。如果你知道按键组合，你就知道了这 些命令。但如果你只使用鼠标，你只会知道菜单，菜单上面有你倾向于点击的相同的一个或两个条目。因此了解集成开发环境是一种不折不扣的纪律。

了解大型编程语言，诸如Java或C++，需要的不仅仅是纪律。它们自身规模庞大，它们的库亦规模庞大。阅读代码是我认为的了解编程语言最好的方式，阅读 那些使用了你所未知特性的代码并寻找机会使用它们。书籍（而不是博客）是另外一个极好的资料来源。了解你目前正在使用的特性的外围，很快你就会发现外围扩 大了。了解版本控制系统和构建系统将让你成为一个理想的团队成员 — 不会因为对重要操作的无知而浪费时间。

动手编码前先规划好你的代码。我认为这是建议列表中最难做的一项，但同时它也可能给你换来最多的益处。我所指的并不是正式的设计 – 在这个阶段正式设计一般不是必要的。不过你确实应该用一种其他方式精心策划一下代码，而不仅仅是将思路放在脑子里。最简单的方法就是编写一个小文档（我经 常使用的是思维导图）：代码的需求是什么？你打算如何实现它？还有哪些目前未知的事情需要去了解？我需要或需要创建什么对象？将这些都写出来。只有在这样 之后开始编码，你才会发现代码变得更加容易编写了，更容易形成文档了，也更容易修改了。将你的笔记保存下来 – 它们将是很好的参考资料。

大量编写代码并进行代码评审。如果你那里不做代码评审，那你就自己来做。找出那些最好的程序员，并且你可以通过某种方式听 到和理解他们给你的有用的建议。别做令人讨厌的人，但也不能因为你害羞，忙碌或自负而回避这个过程。代码评审应该成为你编程人生的一部分。要有创造性。试 试在某个下午与比你更牛的程序员一起做结对编程。重要的是你需要反馈，而这些反馈是你自己无法给予自己的。

编码与写测试并驾齐驱。这也许是这里唯一有争议的一条。它并非是对TDD的认可(译注：测试驱动开发)。但这里要认可的是你的代码 在大多数要面对的场合里都是可以工作的。开始单元测试，并用边缘值测试新代码。例如，当传入一个负数或者是整型数最大值时，你的函数是否还能正常工作？如 果不能，你的函数是否抛出了一个信息详实的异常或只是崩溃退出？如果不是异常，你是否使用了断言(assert)来缩小输入的范围？如果这么做了，那就测 试这个断言。利用之前做的规划编写一些模拟(mock)测试，接下来用这些模拟对象去开始测试你的新代码。这将有助于阐明你当前代码中的设计问题以及即将 实现的对象。保存你的测试代码，在每次签入代码前都运行它们，这些测试将成为后续那些破坏你当前代码的新代码的早期预警系统。

还有许多建议和至理名言可以添加到这个列表中。但这本身就是问题的一部分：过多的建议将导致新手难于知道到底从何处开始。因此，我故意将我的建议缩减到仅 剩五点。如果你能勤奋地运用这五点建议实践，你会很快发现两件事情：你将可以逐步应付更大更重要的任务了，并且当你回首翻看你几个月之前编写的代码时，你 会觉得尴尬。

毫无疑问这两种感受都是你进步的标志。祝你好运！