I work from the lowest level in the dependency chain to the highest. That way I can have something to compile and test early, and then I can build on it as I go.
I almost always start with the User Interface. Once I know exactly what's coming in and what's going out, I find it easier to organize everything else.
It seems like everyone who's posted an answer to this question names a different place to start. The wide variation in starting points is a perfect illustration of where you should really start: wherever your ideal starting point is.
Different people have different ways of approaching problems. Often the success of a project is independent of the initial approach that one takes. Take time to think about and try different areas to focus on first and find out what's right for you.
EDIT: On a more abstract level, this article by Paul Graham offers good insight on a Lisp-style, bottom-up approach to programming.
I start with my Data Structures (DB tables, XTD, Data Dictionaries, etc) Then how the data will get into and out of said structures (Data Access layer) Then the Business Objects with their associated logic Finally, the User Interface and attaching those programmatic hooks to my business logic
Personally, I think you should start with the domain model. This will, in large part, be pulled directly from your requirements, and will help you identify what pieces you'll need to create. Your domain model will drive your data model, and the requirements will tell you what has to be done to the domain objects.
It must depend on what you are creating. I am working on a windows mobile application and started form the bottom up, working on classes and various data abstractions and then plugged it all together with a gui and it was a nightmare. You just can't show people (non-developers) code and convince them that you are 40% done, they need to see some sort of GUI. If I could go back, I'd mock up the GUI first.
But when it comes to data-driven websites, I start with the data purely because the web pages that allow you to manipulate them depend on knowing what the data will look like and how you might interact with it.
As an aside, I'm interested in "easiest" and "hardest" things because I think the natural human tendency is to think easy things will be easier than they are and hard things will be harder than they turn out to be!
That gets the discussion out of the way more quickly about how the design and requirements were all wrong (even if everyone signed off on them) and saves a lot of wasted effort.
This is a bit dangerous however, because most people assume that the UI is the bulk of the work and won't understand why it is taking so long to finish when the screens look almost final.
I try to do what I think will be harder items first. This way if things go wrong, you're more likely to get and be able to give advanced notice. Also, if it turns out that something is unachievable, you don't waste you time on a bunch of small things that were dependent and are no longer needed.
I would tend to write and test the supporting framework classes first. I find that if I don't, I end up writing too much code before compiling and testing. Also, writing them first means that you'll be more inclined to make them full abstractions, rather than half-baked ones that are too incestuously coupled to the code using them. If you haven't written the higher level code when you write the supporting classes, you'll avoid accidentally introducing circular dependencies.
That said, when I'm writing the support classes, I will at least have already written snippets of code that show examples of how they are to be used in the higher-level code.
Working with desktop/command line programs, I usually do what Ted suggested and start at the top (root) of the dependency chain (tree), in order to have something to test and compile early. I then add classes and complexity step by step down (up) the chain (tree).
Working with web applications I usually take a somewhat different approach:
I tend to start by building a rough html shell to give an idea of what the site should look like.
Then I start with the simplest functionality (in many cases it has been a guestbook or blog-like input/display data kind of thing) where I start by setting up a table in the database, map it to my data provider (Entity Framework if I'm in .Net) and get the site to access the data (no input functionality yet!).
When the page is getting data correctly (I test by putting random stuff in the db manually) I start working on the input part of this section of the site.
Once one section of the site (for example the guestbook) is done and working exactly as I want it to, I go on to the next part and start over at 1 again.
The best place to start, imho, is with the data schema and then domain model and then any business logic between the model & the interface and then the interface.
Depending on the technology and development paradigm you use, it will serve as a natural extension of your business requirements into the coding world as it should, ideally, represent the bulk of your requirements.
Really, what you need to consider is what you're building, the design pattern you used to architect your solution, the relevant technologies being used and how they inter-relate (or not) and their dependencies.
Start with the piece that is the limiting factor - if you cannot build an adequate Domain Model without a data schema, then start with the schema.
If you have a rather intelligent database (all the tables, integrity and rules built into the stored procedures that do all the error checking and validation) with a rather ignorant middle tier (all it does is pass data along) design then the bulk of the work and the functionality lies in the back ....
If you have a rather simple database (just the tables and fields) and a very smart middle tier (all the logic, validation and integrity checking done here) ... the bulk of the functionality is in the middle ...
Now it's a matter of preference. I like progress so i start with the "easiest" thing to build - the "simplest" part of the application. For me, this helps crystalize the whole process at the code level for me - to see pieces falling into place at a relatively frequent rate.
BUT I ALWAYS leave the dazzly front-end to the last (or i get someone else to do it - which i'd prefer).!!
It's as much an art as it is a science ... every project is different unless you're just repeating a pattern with the same technologies and processes - in which case, bust it down to a science and make sure you take lessons away from each project so that you can compose a more efficient process going forward.
I prefer to start with the higher level (architectural) parts as they will better define what you specifically need at the lower levels. If you start at the lower levels then you usually end up bastardizing the higher levels to fit with the way you decided the lower levels should work. So in essence, you make your job harder by starting at the lower levels and your design becomes harder to understand. The higher level application code is the part that you want easy to understand, so it makes more sense too me to start there and ensure it works exactly how you want it to.
This usually means starting with the UI and adding functionality as the UI is built.
EDIT: If you don't know how something is going to work at the higher level you are working at; then create a method for that higher level piece to call and push the work off to the lower level modules. This does wonders for me in simplifying my code.
I agree with the general consensus so far that you start at the lowest level, the data layer, of your application and build from there. To me it makes perfect sense because the business logic is built on top of the data layer and the front end is built on top of the business logic etc.
However, just considering one more thing - your customer. Unfortunately, the customer needs to see visible changes to know that you are doing something. And you will be surprise that even technical managers tend to fall into this mindset too.
So I try to make sure that at each iteration some thing is done to the UI as well, so in a sense the application is built in vertical lines. That is, some data, some business logic, some UI, show the customer. Repeat.
Whenever possible, I'd start with a path through the whole app. Work generously with stubs. This helps to clarify the overall architecture of the program.
When that's done, I strongly recommend to work on the hardest part next. (Hardest part aka the most risky part aka the part where you have the least information about.)
Why? Because you need time to find all that missing information and if you cannot get this part working, the other parts have been wasted.
I like to start by writing the framework, and then letting the other pieces fall together.
For instance, I will usually write a class which I know will be needed, then interface it once i have some desired functionality...then will carry on to the surrounding functionality.
I like doing things this way, because if feels like stream of conciousness, and when things are clicking it is very satisfying.
When developing a Django application, I would define the models first, hack together some just-adequate templates, code the view functions and finish the remaining work on UI. All these steps inevitably overlap a bit (like making changes to Model classes while coding views), but this would be the general road map for me.
发布评论
评论（16）
我从依赖链的最低级别到最高级别工作。 这样我就可以尽早编译和测试一些东西，然后我就可以在它的基础上进行构建。
I work from the lowest level in the dependency chain to the highest. That way I can have something to compile and test early, and then I can build on it as I go.
我几乎总是从用户界面开始。 一旦我确切地知道什么进来了，什么出去了，我发现组织其他事情就更容易了。
I almost always start with the User Interface. Once I know exactly what's coming in and what's going out, I find it easier to organize everything else.
似乎每个发布此问题答案的人都指定了不同的起点。 起点的巨大差异完美地说明了您应该真正从哪里开始：无论您的理想起点在哪里。
不同的人有不同的处理问题的方法。 通常，项目的成功与最初采取的方法无关。 花时间思考并尝试首先关注的不同领域，找出最适合您的领域。
编辑：在更抽象的层面上，Paul Graham 的这篇文章提供了对 Lisp 风格、自下而上的编程方法的深入见解。
It seems like everyone who's posted an answer to this question names a different place to start. The wide variation in starting points is a perfect illustration of where you should really start: wherever your ideal starting point is.
Different people have different ways of approaching problems. Often the success of a project is independent of the initial approach that one takes. Take time to think about and try different areas to focus on first and find out what's right for you.
EDIT: On a more abstract level, this article by Paul Graham offers good insight on a Lisp-style, bottom-up approach to programming.
我从数据结构（数据库表、XTD、数据字典等）开始
然后数据如何进出所述结构（数据访问层）
然后是业务对象及其相关逻辑
最后，用户界面并将这些编程挂钩附加到我的业务逻辑中
I start with my Data Structures (DB tables, XTD, Data Dictionaries, etc)
Then how the data will get into and out of said structures (Data Access layer)
Then the Business Objects with their associated logic
Finally, the User Interface and attaching those programmatic hooks to my business logic
就我个人而言，我认为你应该从领域模型开始。 这在很大程度上将直接从您的需求中提取，并将帮助您确定需要创建哪些部分。 您的领域模型将驱动您的数据模型，需求将告诉您必须对领域对象执行哪些操作。
Personally, I think you should start with the domain model. This will, in large part, be pulled directly from your requirements, and will help you identify what pieces you'll need to create. Your domain model will drive your data model, and the requirements will tell you what has to be done to the domain objects.
它必须取决于您正在创建的内容。 我正在开发一个 Windows 移动应用程序，并从自下而上开始，处理类和各种数据抽象，然后将它们与 GUI 一起插入，这是一场噩梦。 你只是无法向人们（非开发人员）展示代码并让他们相信你已经完成了 40%，他们需要看到某种 GUI。 如果我可以回去，我会先模拟 GUI。
但当谈到数据驱动的网站时，我从数据开始纯粹是因为允许您操纵它们的网页取决于了解数据的外观以及您如何与其交互。
顺便说一句，我对“最简单”和“最难”的事情感兴趣，因为我认为人类的自然倾向是认为简单的事情会比实际情况更容易，而困难的事情会比结果更难！
It must depend on what you are creating. I am working on a windows mobile application and started form the bottom up, working on classes and various data abstractions and then plugged it all together with a gui and it was a nightmare. You just can't show people (non-developers) code and convince them that you are 40% done, they need to see some sort of GUI. If I could go back, I'd mock up the GUI first.
But when it comes to data-driven websites, I start with the data purely because the web pages that allow you to manipulate them depend on knowing what the data will look like and how you might interact with it.
As an aside, I'm interested in "easiest" and "hardest" things because I think the natural human tendency is to think easy things will be easier than they are and hard things will be harder than they turn out to be!
我喜欢从设计 UI 开始。
这样可以更快地摆脱关于设计和需求为何都是错误的讨论（即使每个人都签署了它们），并节省了大量无用的精力。
然而，这有点危险，因为大多数人认为 UI 是大部分工作，并且不明白为什么当屏幕看起来几乎是最终版本时还要花这么长时间才能完成。
I like to start by roughing out the UI.
That gets the discussion out of the way more quickly about how the design and requirements were all wrong (even if everyone signed off on them) and saves a lot of wasted effort.
This is a bit dangerous however, because most people assume that the UI is the bulk of the work and won't understand why it is taking so long to finish when the screens look almost final.
回复：简单与困难项目的优先顺序：
我尝试先做我认为较难的项目。 这样，如果出现问题，您更有可能收到并能够提前发出通知。 另外，如果事实证明某件事无法实现，你不会把时间浪费在一堆依赖且不再需要的小事情上。
http://www.businessballs.com/rocks.htm
Re: Easy vs Hard item precedence:
I try to do what I think will be harder items first. This way if things go wrong, you're more likely to get and be able to give advanced notice. Also, if it turns out that something is unachievable, you don't waste you time on a bunch of small things that were dependent and are no longer needed.
http://www.businessballs.com/rocks.htm
我倾向于首先编写和测试支持框架类。 我发现如果不这样做，我最终会在编译和测试之前编写太多代码。 此外，首先编写它们意味着您将更倾向于使它们成为完整的抽象，而不是与使用它们的代码过于耦合的半生不熟的抽象。 如果您在编写支持类时没有编写更高级别的代码，那么您将避免意外引入循环依赖项。
也就是说，当我编写支持类时，我至少已经编写了代码片段，这些代码片段显示了如何在更高级别的代码中使用它们的示例。
I would tend to write and test the supporting framework classes first. I find that if I don't, I end up writing too much code before compiling and testing. Also, writing them first means that you'll be more inclined to make them full abstractions, rather than half-baked ones that are too incestuously coupled to the code using them. If you haven't written the higher level code when you write the supporting classes, you'll avoid accidentally introducing circular dependencies.
That said, when I'm writing the support classes, I will at least have already written snippets of code that show examples of how they are to be used in the higher-level code.
使用桌面/命令行程序时，我通常按照 Ted 的建议进行操作，并从依赖链（树）的顶部（根）开始，以便尽早测试和编译某些内容。 然后，我沿着链（树）逐步向下（向上）添加类和复杂性。
在使用 Web 应用程序时，我通常会采取稍微不同的方法：
Working with desktop/command line programs, I usually do what Ted suggested and start at the top (root) of the dependency chain (tree), in order to have something to test and compile early. I then add classes and complexity step by step down (up) the chain (tree).
Working with web applications I usually take a somewhat different approach:
恕我直言，最好的起点是数据模式，然后是领域模型，然后是模型和模型之间的任何业务逻辑。 接口，然后是接口。
根据您使用的技术和开发范例，它将作为您的业务需求到编码世界的自然延伸，因为理想情况下它应该代表您的大部分需求。
实际上，您需要考虑的是您正在构建的内容、用于构建解决方案的设计模式、正在使用的相关技术以及它们如何相互关联（或不相互关联）以及它们的依赖性。
从限制因素开始——如果没有数据模式就无法构建足够的领域模型，那么就从模式开始。
如果您有一个相当智能的数据库（所有表、完整性和规则都内置在执行所有错误检查和验证的存储过程中），而中间层（它所做的只是传递数据）设计相当无知，那么大部分工作和功能位于后面......
如果你有一个相当简单的数据库（只有表和字段）和一个非常智能的中间层（所有逻辑、验证和完整性检查都在这里完成）......大部分功能位于中间......
现在这是一个偏好问题。 我喜欢进步，所以我从构建“最简单”的东西开始——应用程序的“最简单”部分。 对我来说，这有助于在代码级别上具体化整个过程 - 看到各个部分以相对频繁的速度落实到位。
但我总是把令人眼花缭乱的前端留到最后（或者我让其他人来做——我更喜欢）。！！
它既是一门艺术，也是一门科学……每个项目都是不同的，除非您只是使用相同的技术和流程重复一个模式 - 在这种情况下，请将其分解为一门科学，并确保您从中汲取教训每个项目，以便您可以制定更有效的流程。
干杯
The best place to start, imho, is with the data schema and then domain model and then any business logic between the model & the interface and then the interface.
Depending on the technology and development paradigm you use, it will serve as a natural extension of your business requirements into the coding world as it should, ideally, represent the bulk of your requirements.
Really, what you need to consider is what you're building, the design pattern you used to architect your solution, the relevant technologies being used and how they inter-relate (or not) and their dependencies.
Start with the piece that is the limiting factor - if you cannot build an adequate Domain Model without a data schema, then start with the schema.
If you have a rather intelligent database (all the tables, integrity and rules built into the stored procedures that do all the error checking and validation) with a rather ignorant middle tier (all it does is pass data along) design then the bulk of the work and the functionality lies in the back ....
If you have a rather simple database (just the tables and fields) and a very smart middle tier (all the logic, validation and integrity checking done here) ... the bulk of the functionality is in the middle ...
Now it's a matter of preference. I like progress so i start with the "easiest" thing to build - the "simplest" part of the application. For me, this helps crystalize the whole process at the code level for me - to see pieces falling into place at a relatively frequent rate.
BUT I ALWAYS leave the dazzly front-end to the last (or i get someone else to do it - which i'd prefer).!!
It's as much an art as it is a science ... every project is different unless you're just repeating a pattern with the same technologies and processes - in which case, bust it down to a science and make sure you take lessons away from each project so that you can compose a more efficient process going forward.
Cheers
我更喜欢从较高级别（架构）部分开始，因为它们会更好地定义您在较低级别上具体需要的内容。 如果你从较低的级别开始，那么你通常最终会破坏较高的级别，以适应你认为较低级别应该工作的方式。 因此，从本质上讲，从较低级别开始会使你的工作变得更加困难，并且你的设计会变得更难以理解。 更高级别的应用程序代码是您希望易于理解的部分，因此从那里开始并确保它完全按照您想要的方式工作也更有意义。
这通常意味着从 UI 开始，并在构建 UI 时添加功能。
编辑：如果您不知道某些事情将如何在您正在工作的更高级别上工作； 然后为该较高级别的块创建一个方法来调用并将工作推送到较低级别的模块。 这对我简化代码来说确实有奇迹。
I prefer to start with the higher level (architectural) parts as they will better define what you specifically need at the lower levels. If you start at the lower levels then you usually end up bastardizing the higher levels to fit with the way you decided the lower levels should work. So in essence, you make your job harder by starting at the lower levels and your design becomes harder to understand. The higher level application code is the part that you want easy to understand, so it makes more sense too me to start there and ensure it works exactly how you want it to.
This usually means starting with the UI and adding functionality as the UI is built.
EDIT: If you don't know how something is going to work at the higher level you are working at; then create a method for that higher level piece to call and push the work off to the lower level modules. This does wonders for me in simplifying my code.
我同意到目前为止的普遍共识，即您从应用程序的最低级别（数据层）开始，并从那里进行构建。 对我来说，这是非常有意义的，因为业务逻辑构建在数据层之上，前端构建在业务逻辑之上等等。
但是，只考虑一件事 - 您的客户。 不幸的是，客户需要看到明显的变化才能知道您正在做某事。 你会惊讶地发现，即使是技术经理也往往会陷入这种心态。
因此，我尝试确保在每次迭代时也对 UI 进行一些操作，因此从某种意义上说，应用程序是在垂直线中构建的。 也就是说，一些数据、一些业务逻辑、一些UI，向客户展示。 重复。
I agree with the general consensus so far that you start at the lowest level, the data layer, of your application and build from there. To me it makes perfect sense because the business logic is built on top of the data layer and the front end is built on top of the business logic etc.
However, just considering one more thing - your customer. Unfortunately, the customer needs to see visible changes to know that you are doing something. And you will be surprise that even technical managers tend to fall into this mindset too.
So I try to make sure that at each iteration some thing is done to the UI as well, so in a sense the application is built in vertical lines. That is, some data, some business logic, some UI, show the customer. Repeat.
只要有可能，我都会从整个应用程序的路径开始。 慷慨地使用存根。 这有助于阐明程序的整体架构。
完成后，我强烈建议接下来处理最困难的部分。 （最难的部分又称为最危险的部分，又称为您掌握的信息最少的部分。）
为什么？ 因为你需要时间来找到所有缺失的信息，如果你不能让这部分工作，那么其他部分就被浪费了。
Whenever possible, I'd start with a path through the whole app. Work generously with stubs. This helps to clarify the overall architecture of the program.
When that's done, I strongly recommend to work on the hardest part next. (Hardest part aka the most risky part aka the part where you have the least information about.)
Why? Because you need time to find all that missing information and if you cannot get this part working, the other parts have been wasted.
我喜欢从编写框架开始，然后让其他部分整合在一起。
例如，我通常会编写一个我知道需要的类，然后在我拥有一些所需的功能后对其进行接口......然后将继续处理周围的功能。
我喜欢用这种方式做事，因为感觉就像意识流，当事情进展顺利时，我会感到非常满足。
I like to start by writing the framework, and then letting the other pieces fall together.
For instance, I will usually write a class which I know will be needed, then interface it once i have some desired functionality...then will carry on to the surrounding functionality.
I like doing things this way, because if feels like stream of conciousness, and when things are clicking it is very satisfying.
作为一名熟练程序员，我的看法是：
在开发 Django 应用程序时，我会首先定义模型，将一些适当的模板组合在一起，对视图进行编码功能并完成 UI 上的剩余工作。 所有这些步骤不可避免地会有些重叠（例如在编码视图时对模型类进行更改），但这将是我的一般路线图。
My take as a journeyman programmer:
When developing a Django application, I would define the models first, hack together some just-adequate templates, code the view functions and finish the remaining work on UI. All these steps inevitably overlap a bit (like making changes to Model classes while coding views), but this would be the general road map for me.