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

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

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

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

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

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

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

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

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

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

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

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

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

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

随着buildc在内部应用的深入，buildc逐渐进入了以内部需求和问题为主要驱动力的演化模式。我们内部的C应用多是后端服务类应用，个人 觉得具有一定代表性。buildc最初就是为了针对这类C应用而设计的。因此我们内部的需求和问题应该也同样具有一定代表性，而这种演化模式在一 段时间范围内还是有意义的。

buildc 0.3.1版本修正了上一版本的若干bug，并增加了两个新功能。

* 提高容错能力

buildc对第三方库的组织结构有着严格的要求，一般是：

package_name/
      version/
         CPU_MODE_OS/
            include/
            lib/

一般来说，第三方库会由组织内特定人员进行管理和维护，第三方库服务器上的目录结构不会出现组织错误的情况。但buildc 0.3.0还是遇到特例了：当某个package的第三级目录为空时，buildc 0.3.0版本会抛出异常。为此，buildc 0.3.1增加了对这块逻辑的容错处理：
     1. 如果目录是空目录，直接略过。
     2. 如果目录存在合法的目录，cpu_mode_os，加入.buildc.repository中
     3. 如果目录中存在合法的目录和不合法的目录，略过不合法的目录。

* 支持命令行变量

有些项目针对不同客户有不同的功能版本，但代码是一份，针对不同客户的Release版本用一些特定的宏开关控制，而这些功能开关需要在编译构建 期指定。比如最初版本的buildc.cfg中的片段如下：

custom_defs = ['-std=gnu99', '-DLOGLEVEL=1', '-DUSE_NM']

后A省的客户希望LOGLEVEL用2级，不需要NM(网管)功能，而B省的客户希望LOGLEVEL用2级同时也使用NM功能，那我们的 custom_defs就需要有多种配置了，例如：

if province == "A":
    custom_defs = ['-std=gnu99', '-DLOGLEVEL=2']
elif provice == "B"
    custom_defs = ['-std=gnu99', '-DLOGLEVEL=2', '-DUSE_NM']
else:
    custom_defs = ['-std=gnu99', '-DLOGLEVEL=1', '-DUSE_NM']

province这个变量可以定义在buildc.cfg中，但每次针对不同省份Release时，需要手工修改province变量的值，这样 十分麻烦。因此我们想到是否可以让buildc像Make那样支持命令行变量呢，就像这样：

buildc config make province="B"

于是乎buildc 0.3.1版本就实现了这个功能，你可以在buildc config make或buildc pack中使用buildc的命令行变量，命令行变量支持var=value形式，其中value支持如下几种值：

var=1
var=on
var="on"

对于var=on，在buildc内部会将var=on转化为var="on"，否则python会提示找不到on的定义。

* 支持指定项目配置文件（buildc.cfg)

当功能开关变得很多时，我们往往很难记住那么多命令行变量，我们可能就会为每个项目保存多个项目构建的配置文件，比如 buildc_for_liaoning.cfg、buildc_for_beijing.cfg等。而以前的buildc只默认支持 buildc.cfg这样一种配置文件，无法支持这类需求，因此buildc 0.3.1增加了指定项目配置文件功能。

如果你要为A省客户发布，你可以敲入buildc config make –config=PATH_OF_CONFIG_FILE，buildc就会加载你指定的配置文件了，而不是默认的buildc.cfg。