当你完成了第一组需求和设计后,你要从哪里开始编程?(假设测试将按相同顺序编写,但在代码之前)。
- 入口点
- 框架/支持类
- 实体类
- 先做最简单的事情
- 先做最难的事情
你有什么建议吗?
当你完成了第一组需求和设计后,你要从哪里开始编程?(假设测试将按相同顺序编写,但在代码之前)。
你有什么建议吗?
我从依赖链的最低层开始工作,逐渐向上构建。这样我就可以尽早编译和测试,并在此基础上不断迭代。
我几乎总是从用户界面开始。一旦我清楚地知道输入和输出的内容,我就更容易组织其他所有内容。
我从数据结构开始(数据库表、XTD、数据字典等) 然后是数据如何进出这些结构(数据访问层) 接着是业务对象及其相关逻辑 最后是用户界面和将程序钩子附加到我的业务逻辑
不同的人有不同的解决问题的方法。通常项目的成功与最初采取的方法无关。花时间思考和尝试不同的重点区域,找到适合自己的方法。
编辑:在更抽象的层面上,Paul Graham的这篇文章 提供了关于一种Lisp风格的自下而上的编程方法的深入见解。
我认为您应该从领域模型开始。这在很大程度上将直接从您的需求中提取,并帮助您确定需要创建哪些部分。您的领域模型将驱动您的数据模型,而需求将告诉您必须对领域对象进行哪些操作。
我喜欢先草拟用户界面。
这可以更快地讨论设计和需求是否正确(即使每个人都签署了),避免浪费很多工作。但这也有些危险,因为大多数人认为用户界面是大部分工作的核心,当屏幕看起来几乎完成时却不理解为什么要花费这么长时间来完成。
关于易做与难做事项的优先级:
我尝试先处理那些我认为会更困难的事项。这样,如果出了什么问题,你更有可能得到并能够提前通知。此外,如果某些任务是不可实现的,你也不必浪费时间去处理一堆不再需要的小事项。
在处理桌面/命令行程序时,我通常会像Ted建议的那样从依赖链(树)的顶部(根)开始,以便尽早测试和编译。然后,我逐步向下(向上)添加类和复杂性。
在处理Web应用程序时,我通常采取略有不同的方法: