一个30年老程序员的修炼之道

　　声明：本文来自于微信公众号InfoQ(ID：infoqchina)，作者： Julio Biason，授权站长之家转载发布。

　　本文作者 Julio Biason 从 1990 年开始从事软件开发工作，以下是他从过去 30 年软件开发生涯总结出来的一系列冷笑话式的经验之谈。

　　1 关于软件开发

　　规范先行，然后才是代码

　　在知道要解决什么问题之前，请不要写代码。

　　Louis Srygley 说过：“如果没有需求或设计，编程就成了一门往空文本里添加 bug 的艺术”。

　　有时候，仅仅一两段简单的描述就足以说明一个程序是用来干什么的。

　　每当你停下来，看着代码，并开始思考下一步该做什么的时候，通常是因为你不知道下一步该做什么。这个时候，你需要做的是与同事讨论，或者可能需要重新思考之前的解决方案。

　　用批注的方式把实现步骤写下来

　　如果你不知道从哪里下手，先使用英语(或者你的母语)把程序的流程写下来，然后在批注中添加代码。

　　你也可以把每个批注当成是一个函数，然后用代码实现它们。

　　用好 Gherkin

　　Gherkin 是一种测试 DSL，用来描述“系统处于某种状态，如果发生某个事件，这就是所期望的状态”。即使你不使用测试工具，Gherkin 仍然可以帮你更好地了解你能够从程序中获得哪些东西。

　　单元测试还不够，最好还要有集成测试

　　在我目前的工作中，我们会进行模块和类级别的测试。这些测试可以让我们知道模块或类的行为，但无法让我们知道系统整体的行为——而集成测试可以告诉我们这些。

　　测试让 API 变得更健壮

　　代码是分层的：存储层负责数据持久化，处理层负责转换存储的数据，视图层负责呈现数据，等等……

　　分层测试可以让你更好地了解各个层的 API，知道如何更好地调用各个层：API 会不会太复杂了?要进行一次简单的调用，是否需要保留很多数据?

　　通过命令行运行测试用例

　　命令行对于任何一个项目来说都很重要。在你知道了如何使用命令来执行测试用例之后，就可以进行自动化测试，然后将它们集成到持续集成工具中。

　　做好丢弃代码的准备

　　有很多人在开始使用 TDD 时会感到很恼火，因为他们可能需要重写很多代码，包括已经写好的那些。

　　而这正是 TDD 的“设计哲学”：随时准备好丢弃你的代码。随着对问题研究的深入，你对要解决的问题越来越了解，不管之前写了怎样的代码，它们终究不是解决问题的最终方案。

　　不过你不用担心，代码并不是一堵墙，如果将它们丢弃掉，也算不上是浪费砖块。但花在写代码上的时间确实会一去不复返，不过换来的是你对问题更好的了解。

　　好的编程语言自带测试框架

　　可以肯定地说，如果一门编程语言的标准库自带了测试框架，哪怕这个框架很小，它的生态系统也会得到比那些不提供测试框架的编程语言更好的测试，即使外部为这些语言提供了很好的测试框架。

　　著作权归作者所有。