I try to split the problem usually into two different issues:
who is involved (this are good candidates for classes)
what is happening (similarly, this tends to be good methods, and also things that one might want to focus on to establish performance requirements).
For example: when searching for the cheapest car inside a set of possible cars, I'd identify 'cheapest' as something that probably wants to be a separate function, as I may want to change the conditions later, or apply it to SUVs as well, and 'car' and 'set of cars' sounds like good candidates for classes that I'd need in the problem domain.
To establish those:
search for verbs in the problem description: those make methods
search for nouns in the problem description: those make classes
find the constraints, and what they are relevant for: is cheapest a property of something, or rather a result of an operation?
Eventually I move from drawing those relationships further to pseudo-code and small prototypes to play around and learn what other unknown constraints appear in the problem description.
For this kind of thing, I usually sketch out the basic UIs, chart out (boxes on paper) a domain model and a database schema. I always start on paper and then if I feel it is necessary I export to visio/basalmiq.
For simple program, I will use paper and pencil to draw a sketch of its UI, make some annotations on it. It can help me to clarify my idea and confirm my design.
If the program is bigger (more like a complete product I mean), you may need to collect some feedback from others, since one man's thought can not cover everything. The hand drawn sketch still works, invite more people to review it and give you some suggestions, thus you can polish your design a lot. However if your friend is not around you may need to fax the papaer sketch to them (or maybe scan the paper sketch and send via email).
There are some tools that can help you to create UI prototype, some of them even allow you to run simulation of the UI (like Axare and ForeUI), that will be very useful to collect feedback from others.
It is largely depends on number of things and the most important one is what are you making.
1) The first step to me is to declare what are you making. Sound, simple? sometime is not. List down what you want the program to do. List what is the must-have, what is nice-to-have and what is ok-to-have (not much trouble to include).
2) The second step is to (at your best) identify what is the weakest link for the success of your project. If you are writing WebDB, what you should worry is web UI (transition from a page to another) and data model. If you are writing game, the rules of the game will be important. Or if the game is highly interfactive, then you should think of the interaction the flow of the game.
What you identified here is what you should spend time design it on paper.
Since identifying that will likely to require experience and you may not have (if you do, you will already know what to do, right :-D), you may come back to review it once in a while as project progress.
3) To avoid over-engineering, focus on modeling for understanding as oppose to modeling as documenting.
4) Once you understand more, try to create a small program to check if it is possible. If you, identify other critical but risky part.
5) Start small but always think about extension. To me, it is OK to think big but it is risky to do big.
Those are what I do. Hope it will give you some idea. :-D
There is nothing like a mini-notepad inside a jacket pocket, to mind dump as soon as possible, I personally switch between mini-UML and dot points. Quick, Simple, Always Accessible.
edit: And I always have a page/area dedicated to specific use cases and actions. This allows me to come back and check if the system can handle each of these.
I'd use UML not because it's the defacto industry standard but because it helps you organize and document your thoughts as you explore a domain (whether personal or business). A free tool is ArgoUML.
I'd mock UIs as another aid in figuring and communicating what you think you'd like to do in your system. A great free one is Balsamiq Mockups.
And I'd focus on behavior first and data last. See Rebecca Wirfs-Brock's writings.
i find sketching out the UI first is very help in finding out exactly what functionality is required. Then I like to make a list for each UI element and what it should do. Once this is done I generally write out a database schema...
In my opinion, you should stick with your final goal, In most cases, the final goal is to deliver your result to your customer, your boss, your colleague.
so all you have to do should be consistent with the goal. release it and deliver it.
I don't think designing on a paper is a good idea, it made you too lazy to do some practical work. Actually most project was too late to enter into coding phase, many stupid designers or architect were arguing the details that never existed in the war-room for a few weeks. they delayed the project.
actually you should learn more thoughts about test-driven development, it doesn't mean you should completely follow the mode, it is a thought to teach you how to effectively commit yourself in deliver the results.
Finally, I think test-driven is the most effective way to keep your commit into delivering qualified results to customers.
I am a big fan of using SketchFlow to create wireframes and mock ups which really helps the over all design process of web/desktop apps. You can see it and touch it and prove that your ideas will actually work. I also like the mind-mapping (MindMeister) mentioned else where. Lately I try to avoid BDUF (big design up front) specifications these days!
For small code projects I like to just go in and code a version 0, create all the classes I think I'm going to need and try and somewhat get them working together. I then stop and start over completely. This usually creates a much better project.
Software is like art, in that it is creative and there are limitless possibilities in the way to solve a problem. As programmers we often jump into the code before designing. Design starts before even looking at technical solutions. These are some steps that should be taken first to help limit the scope of the design.
Define your goals. These may be your own or may be given to you by a business manager/product manager.
Identify resource constraints. This could be time, money, hardware or even programming languages that you can use.
Research environmental constraints that are from the industry or environment your software will be a part of. For example regulations or what users are willing to accept.
Worry about the future (but don't drive yourself crazy). To the best of your ability make the design scalable from a software level and a functionality level.
Then start iterating. It is important to try things out and start iterating on design. You will never be able to anticipate everything so you try your best and then move forward.
I wrote a blog post that describes these in more detail using examples from unconventional fields, but applies well to software:
发布评论
评论（13）
我通常尝试将问题分为两个不同的问题：
例如：当在一组可能的汽车中搜索最便宜的汽车时，我会将“最便宜”识别为可能想要成为单独函数的东西，因为我可能想稍后更改条件，或者将其应用到 SUV好吧，“汽车”和“一组汽车”听起来像是我在问题领域中需要的课程的良好候选者。
建立这些：
最终，我从进一步绘制这些关系转向伪代码和小型原型，以尝试并了解问题描述中出现的其他未知约束。
I try to split the problem usually into two different issues:
For example: when searching for the cheapest car inside a set of possible cars, I'd identify 'cheapest' as something that probably wants to be a separate function, as I may want to change the conditions later, or apply it to SUVs as well, and 'car' and 'set of cars' sounds like good candidates for classes that I'd need in the problem domain.
To establish those:
Eventually I move from drawing those relationships further to pseudo-code and small prototypes to play around and learn what other unknown constraints appear in the problem description.
对于这种事情，我通常会勾画出基本的 UI，绘制出（纸上的方框）域模型和数据库模式。我总是从纸上开始，然后如果我觉得有必要，我会导出到 visio/basalmiq。
For this kind of thing, I usually sketch out the basic UIs, chart out (boxes on paper) a domain model and a database schema. I always start on paper and then if I feel it is necessary I export to visio/basalmiq.
对于简单的程序，我会用纸和铅笔画出它的UI草图，并在上面做一些注释。它可以帮助我澄清我的想法并确认我的设计。
如果程序更大（我的意思是更像是一个完整的产品），您可能需要收集其他人的一些反馈，因为一个人的思想无法涵盖所有内容。手绘草图还是有效的，邀请更多的人来审阅它并给你一些建议，这样你就可以打磨你的设计了。但是，如果您的朋友不在身边，您可能需要将纸质草图传真给他们（或者扫描纸质草图并通过电子邮件发送）。
有一些工具可以帮助您创建 UI 原型，其中一些甚至允许您运行 UI 模拟（例如 Axare 和 ForeUI），这对于收集其他人的反馈非常有用。
For simple program, I will use paper and pencil to draw a sketch of its UI, make some annotations on it. It can help me to clarify my idea and confirm my design.
If the program is bigger (more like a complete product I mean), you may need to collect some feedback from others, since one man's thought can not cover everything. The hand drawn sketch still works, invite more people to review it and give you some suggestions, thus you can polish your design a lot. However if your friend is not around you may need to fax the papaer sketch to them (or maybe scan the paper sketch and send via email).
There are some tools that can help you to create UI prototype, some of them even allow you to run simulation of the UI (like Axare and ForeUI), that will be very useful to collect feedback from others.
这很大程度上取决于很多事情，最重要的是你在做什么。
1）我的第一步是声明你在做什么。听起来，简单吗？有时不是。列出您希望程序执行的操作。列出什么是必须具备的、什么是最好拥有的以及什么是可以拥有的（包含起来并不麻烦）。
2) 第二步是（尽力）确定项目成功的最薄弱环节。如果您正在编写 WebDB，您应该担心的是 Web UI（从一个页面转换到另一个页面）和数据模型。如果您正在编写游戏，游戏规则将很重要。或者，如果游戏具有高度交互性，那么您应该考虑游戏的交互流程。
您在此处确定的内容是您应该花时间在纸上设计的内容。
由于确定这一点可能需要经验，而您可能没有（如果您这样做，您就会已经知道该怎么做，对吧:-D），因此您可能会随着项目的进展偶尔回来回顾一下它。
3) 为了避免过度设计，专注于理解建模，而不是文档建模。
4）了解更多后，尝试创建一个小程序来检查是否可行。如果您这样做，请确定其他关键但有风险的部分。
5）从小事做起，但始终考虑扩展。对我来说，大胆思考是可以的，但做大事却有风险。
这些就是我所做的。希望它能给你一些想法。 :-D
It is largely depends on number of things and the most important one is what are you making.
1) The first step to me is to declare what are you making. Sound, simple? sometime is not. List down what you want the program to do. List what is the must-have, what is nice-to-have and what is ok-to-have (not much trouble to include).
2) The second step is to (at your best) identify what is the weakest link for the success of your project. If you are writing WebDB, what you should worry is web UI (transition from a page to another) and data model. If you are writing game, the rules of the game will be important. Or if the game is highly interfactive, then you should think of the interaction the flow of the game.
What you identified here is what you should spend time design it on paper.
Since identifying that will likely to require experience and you may not have (if you do, you will already know what to do, right :-D), you may come back to review it once in a while as project progress.
3) To avoid over-engineering, focus on modeling for understanding as oppose to modeling as documenting.
4) Once you understand more, try to create a small program to check if it is possible. If you, identify other critical but risky part.
5) Start small but always think about extension. To me, it is OK to think big but it is risky to do big.
Those are what I do. Hope it will give you some idea. :-D
没有什么比夹克口袋里的迷你记事本更好的了，为了尽快转储头脑，我个人在迷你 UML 和点点之间切换。快速、简单、始终可用。
编辑：我总是有一个专门用于特定用例和操作的页面/区域。这让我可以回来检查系统是否可以处理这些问题。
There is nothing like a mini-notepad inside a jacket pocket, to mind dump as soon as possible, I personally switch between mini-UML and dot points. Quick, Simple, Always Accessible.
edit: And I always have a page/area dedicated to specific use cases and actions. This allows me to come back and check if the system can handle each of these.
我使用 UML 并不是因为它是事实上的行业标准，而是因为它可以帮助您在探索某个领域（无论是个人领域还是企业领域）时组织和记录您的想法。 ArgoUML 是一个免费工具。
我将模拟用户界面作为另一种帮助，帮助您确定和传达您希望在系统中执行的操作。 Balsamiq Mockups 是一款很棒的免费软件。
我会首先关注行为，最后关注数据。请参阅丽贝卡·维尔夫斯-布洛克 (Rebecca Wirfs-Brock) 的著作。
祝你好运！标记
I'd use UML not because it's the defacto industry standard but because it helps you organize and document your thoughts as you explore a domain (whether personal or business). A free tool is ArgoUML.
I'd mock UIs as another aid in figuring and communicating what you think you'd like to do in your system. A great free one is Balsamiq Mockups.
And I'd focus on behavior first and data last. See Rebecca Wirfs-Brock's writings.
Best of luck! Mark
我的一些“技巧”：
我首先使用思维导图（例如 MindMeister）。
然后，我找到可能的“难点”并做一些轻量级原型设计
Some of my "tricks":
I first use mind-mapping (e.g. MindMeister).
Then, I find the probable "difficult spots" and do some lightweight prototyping
我发现首先绘制 UI 草图对于准确找出所需的功能非常有帮助。然后我喜欢为每个 UI 元素及其应该执行的操作列出一个列表。一旦完成，我通常会写出一个数据库模式......
i find sketching out the UI first is very help in finding out exactly what functionality is required. Then I like to make a list for each UI element and what it should do. Once this is done I generally write out a database schema...
这是我做事的顺序：
1）用铅笔写一个伪代码。如有必要，您可以在这里与自己和他人集思广益。
2）编写概述目标的算法以及您将如何实现这些目标。
3）如果项目较小，简单且清晰，则可以省略此步骤。否则，绘制该应用程序的流程图。
4）最后，使用您的算法和流程图作为指导开始编码。
This is the order of how I do things:
1) Write a pseudocode in pencil. This where you can brainstorm ideas with yourself and others if necessary.
2)Write the algorithm outlining the objectives and how you will go about accomplishing those objectives.
3)If the project is small, simple and clear to you, you can ommit this step. Else, draw up a flow chart of th application.
4)Lastly, Start coding using your algorithm and flow chart as your guide.
在我看来，你应该坚持你的最终目标，在大多数情况下，最终目标是将你的结果交付给你的客户、你的老板、你的同事。
所以你所要做的一切都应该与目标一致。释放它并交付它。
我不认为在纸上进行设计是一个好主意，它会让你懒得做一些实际工作。事实上，大多数项目都来不及进入编码阶段，许多愚蠢的设计师或建筑师在作战室里争论了几周不存在的细节。他们推迟了该项目。
实际上你应该了解更多关于测试驱动开发的思想，这并不意味着你应该完全遵循该模式，它是一种教你如何有效地致力于交付结果的思想。
最后，我认为测试驱动是让您致力于向客户提供合格结果的最有效方法。
In my opinion, you should stick with your final goal, In most cases, the final goal is to deliver your result to your customer, your boss, your colleague.
so all you have to do should be consistent with the goal. release it and deliver it.
I don't think designing on a paper is a good idea, it made you too lazy to do some practical work. Actually most project was too late to enter into coding phase, many stupid designers or architect were arguing the details that never existed in the war-room for a few weeks. they delayed the project.
actually you should learn more thoughts about test-driven development, it doesn't mean you should completely follow the mode, it is a thought to teach you how to effectively commit yourself in deliver the results.
Finally, I think test-driven is the most effective way to keep your commit into delivering qualified results to customers.
我非常喜欢使用 SketchFlow 创建线框和模型，这确实有助于网络/桌面应用程序的整体设计过程。你可以看到它、触摸它，并证明你的想法确实可行。我也喜欢其他地方提到的思维导图（MindMeister）。最近我尽量避免使用 BDUF（大设计预先）规格！
I am a big fan of using SketchFlow to create wireframes and mock ups which really helps the over all design process of web/desktop apps. You can see it and touch it and prove that your ideas will actually work. I also like the mind-mapping (MindMeister) mentioned else where. Lately I try to avoid BDUF (big design up front) specifications these days!
对于小型代码项目，我喜欢直接编写版本 0，创建我认为需要的所有类，并尝试让它们一起工作。然后我停下来完全重新开始。这通常会创建一个更好的项目。
For small code projects I like to just go in and code a version 0, create all the classes I think I'm going to need and try and somewhat get them working together. I then stop and start over completely. This usually creates a much better project.
软件就像艺术一样，具有创造性，并且解决问题的方式有无限的可能性。作为程序员，我们经常在设计之前就开始编写代码。设计甚至在考虑技术解决方案之前就开始了。这些是应首先采取的一些步骤，以帮助限制设计范围。
我写了一篇博客文章，使用非传统领域的示例更详细地描述了这些内容，但也适用于软件：
像爱因斯坦和米开朗基罗一样设计
Software is like art, in that it is creative and there are limitless possibilities in the way to solve a problem. As programmers we often jump into the code before designing. Design starts before even looking at technical solutions. These are some steps that should be taken first to help limit the scope of the design.
I wrote a blog post that describes these in more detail using examples from unconventional fields, but applies well to software:
Design like Einstein and Michelangelo
