从业30年得出的软件开发经验（上）
极客时间编辑部
讲述：杜力大小：2.06M时长：04:30
1. 规范先行，然后才是代码
在知道要解决什么问题之前，请不要写代码。因为“如果没有需求或设计，编程就成了一门往空文本里添加 bug 的艺术”。
每当你停下来，看着代码，并开始思考下一步该做什么的时候，通常是因为你不知道下一步该做什么。这个时候，你需要做的是与同事讨论，或者可能需要重新思考之前的解决方案。
2. 用批注的方式把实现步骤写下来
如果你不知道从哪里下手，先把程序的流程写下来，然后在批注中添加代码。你也可以把每个批注当成是一个函数，然后用代码实现它们。
3. 单元测试还不够，最好还要有集成测试
在我目前的工作中，我们会进行模块和类级别的测试。这些测试可以让我们知道模块或类的行为，但无法让我们知道系统整体的行为——而集成测试可以告诉我们这些。
4. 测试让 API 变得更健壮
代码是分层的：存储层负责数据持久化，处理层负责转换存储的数据，视图层负责呈现数据，等等。分层测试可以让你更好地了解各个层的 API，知道如何更好地调用各个层。
5. 做好丢弃代码的准备
有很多人在开始使用 TDD 时会感到很恼火，因为他们可能需要重写很多代码，包括已经写好的那些。而这正是 TDD 的“设计哲学”：随时准备好丢弃你的代码。不过，不管之前写了怎样的代码，它们终究不是解决问题的最终方案。你浪费了写代码的时间却换来了对问题更好地了解。
6. 好的编程语言自带测试框架
可以肯定地说，如果一门编程语言的标准库自带了测试框架，哪怕这个框架很小，它的生态系统也会得到比那些不提供测试框架的编程语言更好的测试，即使外部为这些语言提供了很好的测试框架。
7. 想得太长远是一种浪费
你在写代码时想到的未来的问题，可能永远都不会出现，而你不得不去维护一大堆在未来可能永远都用不上的代码，甚至重写所有代码。问题要一个一个解决，解决完眼前的，再解决下一个。到了某个时刻，你可能会从解决方案中找到某种模式，而这些模式才是用来解决“所有问题”的良方。
8. 写文档很重要
谁都知道，给函数、类或者模块编写文档是一件苦差事，但这也是在给未来的你省下很多麻烦。代码的文档实际上是一种契约：文档里怎么写的，这个函数就是用来做什么的。如果后面你发现代码和文档不匹配，那么就是代码有问题，而不是文档有问题。
9. 如果一个函数文档里出现了“和”逻辑，那就一定有问题
一个函数应该只做一件事情。在给函数编写文档时，如果你发现需要用到“和”逻辑，那说明这个函数所做的事情不止一件。这个时候需要把函数拆成多个，不要在文档里出现“和”逻辑。
10. 在修改接口时要小心
上面提到了重命名函数，如果调用函数的代码完全处在你的控制之下，那么这么做就没什么问题，你只需要把需要修改的地方找出来，然后改掉它们就可以了。
但如果被重命名的函数是作为库的一部分暴露给外部，那就不能随意修改了。因为这样做会影响到所有调用函数的代码，而这些代码不在你的掌控之下，修改函数名只会给这些代码的主人带来大麻烦。
你可以新增一个函数，然后把旧函数标记为已弃用。经过一些版本发布之后，就可以慢慢将旧函数去掉。
以上就是今天的内容，除了上述 10 点以外， Julio Biason 还建议程序员不要将布尔类型作为参数；通过命令行运行测试用例；不要去修改项目以外的东西等等，其余的经验及建议将在下篇文章中呈现。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
臧萌我也就听了十几遍
收起评论