如何将问题分成更小的可理解的部分？
我不确定是否可以就该主题提供一般建议，但请尝试。 很难解释我的情况，因为它太复杂了。 这正是问题所在。
我似乎经常遇到这样的情况：我尝试设计项目的某些部分，但它有太多的事情需要考虑，以至于我无法掌握它。
对于如何一次以较小的部分查看我的系统，是否有任何一般性提示或建议？ 如何找到可以单独设计的较小部分？
I'm not sure if it's possible to give general advice on this topic, but please try. It's hard to explain my case because it's too complex to explain. And that's exactly the problem.
I seem to constantly stumble on a situation where I try to design some part of my project, but it has so many things to take into consideration that I'm unable to get a grasp of it.
Are there any general tips or advice on how to look at my system in smaller pieces at a time? How to find smaller portions that could be designed separately on their own?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
创建词汇表。
换句话说，确定对项目领域有意义的术语——不是从程序员的角度，而是从熟悉主题的用户的角度。
然后尽可能将术语定义为精确和离散。 这种形式的良好定义可以作为一种伪代码。
由于您甚至还没有确定问题的范围，因此我将随机选择一个示例。 在文职人事系统中，您可能有如下术语：
等等。 这并不是为了识别功能单元，因为听起来您正在尝试这样做，但这是这样做之前的一个很好的准备步骤，以便您可以用明确定义的术语表达您的功能步骤。
Create a glossary.
In other words, identify the terms that are meaningful to the project domain — not from the programmer's point of view, but from a user's, who is familiar with the subject matter.
Then define the terms as precisely and discretely as you can. A good definition in this form can serve as a kind of pseudocode.
Since you have not identified even the domain of your problem, I'll choose a random example. In a civilian personnel system, you might have terms like:
And so on. This isn't to identify functional units, as it sounds like you are trying to do, but it's a good preparatory step before doing so, so that you can express your functional steps in well-defined terms.
您的主要目标是：
Your key goals are:
自上而下和自下而上地分解问题很有用。
如果您无法将一个大问题分解为两个或多个较小的问题，请尝试考虑需要解决的最小可能问题。 一旦解决了这些问题，当您处理原来的大问题时，您可能会开始寻找将它们组合成更大问题的方法。
It's useful to approach problem decomposition both top-down and bottom-up.
If you're having trouble splitting a big problem into two or more smaller problems, try to think of the smallest possible problems that will need to be solved. Once those are handled, you may start to see ways to combine them into larger problems as you approach your original large problem.
当我发现自己通过最小的调整复制和粘贴代码块时，我意识到这是一个“分区”，然后创建一个类、方法、函数或其他任何东西。
实际上，整个面向对象方法就是它的全部内容。 尝试将您的应用程序视为有形的、可以做事的东西。 编写伪代码来描述事物是什么以及它们的作用，我发现很多这样的“分区”。
When I find myself copying and pasting chunks of code with minimal adjustments I realize that's a "partition" and then create a class, method, function, or whatever.
Actually, the whole object oriented approach is what it's all about. Try thinking of your application as tangible things that do stuff. Write pseudo code describing what the things are and what they do, I find lots of "partitions" this way.
这是一次尝试，有点疯狂的猜测。
人们通常会低估完成这项工作所需的时间。 如果您的项目很大，那么您很可能需要几个人来处理它，因此您可以尝试在规划时考虑到这一点。 现在，一个人可能只负责头部的一个区域，因此您需要向他准确解释他应该执行什么样的任务。
所以我想说你应该尝试写一份工作描述，其中应包含尽可能多的内容，以便一个人认真专注。 重复此操作，直到您将项目分解为您想要的部分。 作为一个好处，您可以准备组建您的团队。 但如果你发现零件很小，也许你仍然可以自己做。
Here's a try, kind of wild guess.
People usually underestimate how long it will take them to do the work. If your project is large, then most likely you'll need several people to work on it, so you can try planning with that in mind. Now a person can be expected to hold just one area in the head, so you'll need to explain to him exactly what kind of task he's supposed to do.
So I'd say you should try to write a job description that should encompass as much as possible for one person to seriously concentrate on. Repeat, until you have broken your project into parts you wanted to. As a benefit, you're ready to assemble your team. But if you find out the parts are small, maybe you'll still be able to do it yourself.