某人谈软件设计.

      所以先获取这些用例，然后编写骨架API。骨架API应该很短很短，也就一页纸的内容吧，一般正好是一页，无需非常精确。你要声明包、类和方法，如果还不清楚他们应该是什么样的话，可以放一句话的描述。不过这不是产品发布要求的那种质量文档。

 

中心思想就是在这个阶段保持敏捷，逐步完善API，使其满足用例，为原始的API添加代码，看是否可以满足需求。真是不可思议，很多事情事后看真是太浅显了，但设计API的时候，甚至是构思用例时，你还是会犯各种错误。用代码实现用例时你会说：“哦，我的天，全都错了。类太多了。这些可以合并，这些需要拆开。”或者类似这样的话。好在API文档只有一页长，改起来也很容易。

 

你对API越来越有信心，代码也就越写越长。但是，核心原则是，先写使用API的代码，然后再写实现它们的代码。因为，如果实现代码被废弃，之前的工作就都白做了。事实上，应该在给出设计规范前写API的代码，否则你可能把时间浪费在给最后完全不需要的东西设计规范上。这就是我设计软件的方法

 

 

 

 

优秀的程序员把问题分块，孤立地去看他们。这样做的理由有几条。比如，你可能会在无意中创造出好用的、可重用的模块。如果你写一个单一的系统，它越来越大，等你想分块的时候，就无法找到清晰的边界，最后系统就变成了一个无法维护的垃圾。所以我断言，无论你是否把自己看成API设计者，把问题分块都是最好的编程方法。