You don't understand the meaning of a "design pattern" - it simply means something that's been done before that someone has perhaps put a name to. So for example, sorting an array and then using binary search on it is a design pattern - I must have used it hundreds of times in the past, and when I'm designing a small application that needs a search, it's one of the first things I think of. Such patterns are used by experienced programmers on both the smallest projects, and on the largest.
My experience has been that 90% of the time, jumping straight to code is a bad idea. Even on small projects, I end up wasting time because we implemented things incorrectly or didn't plan well enough for XYZ failure case. Coding without a plan is usually a bad idea.
I'm not saying you have to use UML or write a 300 page spec, but I find that use cases and error conditions are critical to plan out before writing any code.
When it comes to design patterns, the answer is yes take the time to think about them and diagram out where they can be useful... and where they are not useful. For a small project a week might be overkill but some planning will produce better code which is easier to maintain and is more useful in the long run.
Your question is wrongly worded. You're not asking about design patterns, you're asking about formal design, producing design documents before starting to code. But again, you can have good design without having explicit design documents, and you can have design documents without having to do them before you start coding. Generally:
If you find that you're producing code that is hard to maintain, your design is probably bad
Spending some thoughts on design before starting to code can lead to better design
Writing explicit design documents mainly helps coordinating larger teams on larger problems and is typical for "heavy" processes - you seem to be thinking about that kind of thing when you talk about "overkill"
An alternative (that often yields better results than doing a lot of upfront desing) is to start coding and develop the design along with the code, refactoring as you go whenever you notice a flaw in your current design. This kind of thing is known as an "agile process"
But that still means you have to spend time thiking about and improving the design rather than coding exclusively towards required functionality - but it will lead to much better code that containes fewer bugs and can be changed more easily and with fewer side effects.
And you still want to have some sort of documentation of the design to help people understand your code better (and even the person who wrote the code often needs that help when they come back to it for a bugfix 6 monts later). This doesn't have to be fancy; a sentence or two explaining what each major unit of code (e.g. classes) does, and an overview document that gives you a broad idea of how it all fits together (this may contain an UML diagram or two).
Design patterns are not something you "decide to use". They come naturally, if you are experienced enough to see them. And they are not overhead - the amount of code to add is rather small.
It's about scale really. In larger projects you'll save time by doing the "boring" analysis, whereas on smaller ones you could actually extend the overall time. (Having said that, even the smallest task will benefit from some upfront thinking/doodling time)
Either way, I'd say don't bend your approach simply to accomodate patterns. They are like any other tool, and not some panacea whose inclusion will guarantee success.
The old saying goes that "if you have a hammer, then everything starts to look like a nail", meaning that if you know of design patterns, you keep trying to fit them in, even when you might not need them. Keep in mind, that in terms of coding design patters, singleton, factory, etc... are very lightweight in terms of their time to implement and shouldn't really be anything to mention to management.
However, analysis and "diagramming" as you put it, is very valuable. If its a small project, then it will take a small amount of time, nothing to worry about. Often, a quick analysis and "pre-thought" will highlight any issues earlier than while simply cutting code.
Bozho said how it should be ... but in the hands of most people, design patterns turn into hammers in search for a nail ... in the end they solve problems such as closing a bottle of coke by putting nails into the screw top, so they have something to hammer on ... in the end, the actual problem is not solved, because although the screw top is now again fixed to the bottle, the bottle still alows its content to escape ...
design patterns are not to be thought of as the components to build a design from ... design patterns are solutions to common problems that emerge within the process of design ...
your question seems to rather be, whether or not you should take the time to design your software, or whether you should just try to deliver software that seems to solve the problem, as fast as you can ... you shouldn't do the latter ... sometimes it is sufficient to actually design on the fly and this is ok, as long as:
you have figured out a way to keep dependancy low and interfaces small
you have a consistent way how responsibility is distributed (and hopefully it's not the usage of a god object)
you produce readable code with sensible naming
you provide comments about what you did, why you did it and which parts seem to need review
once you take these habits, you are not really slower, but your software turns much more maintainable ... also, for small problems, it sometimes makes more sense to just try to solve them through implementation and then learn from what went wrong and reimplement them with that knowledge ... it may turn out to be faster and includes a learning process, unlike top-down approaches ...
If you succeed in actually dividing a project into such independant small problems and can define interfaces how to access functionality provided by the respective solutions, then your design is actually perfect and you needn't get into details further ...
发布评论
评论（7）
你不理解“设计模式”的含义——它只是意味着在有人命名之前已经完成的事情。例如，对数组进行排序，然后对其使用二分搜索是一种设计模式 - 我过去一定使用过它数百次，当我设计一个需要搜索的小型应用程序时，它是第一个我想到的事情。经验丰富的程序员在最小和最大的项目中都会使用此类模式。
You don't understand the meaning of a "design pattern" - it simply means something that's been done before that someone has perhaps put a name to. So for example, sorting an array and then using binary search on it is a design pattern - I must have used it hundreds of times in the past, and when I'm designing a small application that needs a search, it's one of the first things I think of. Such patterns are used by experienced programmers on both the smallest projects, and on the largest.
我的经验是，90% 的情况下，直接跳到代码并不是一个好主意。即使在小型项目中，我最终也会浪费时间，因为我们错误地实施了事情，或者没有针对 XYZ 失败案例做好足够的计划。没有计划的编码通常是一个坏主意。
我并不是说您必须使用 UML 或编写 300 页的规范，但我发现用例和错误条件对于在编写任何代码之前进行规划至关重要。
当谈到设计模式时，答案是肯定的，花时间思考它们并找出它们在哪里有用......以及它们在哪里没用。对于一个小项目来说，一周可能有点过大，但一些计划会产生更好的代码，更容易维护，从长远来看更有用。
My experience has been that 90% of the time, jumping straight to code is a bad idea. Even on small projects, I end up wasting time because we implemented things incorrectly or didn't plan well enough for XYZ failure case. Coding without a plan is usually a bad idea.
I'm not saying you have to use UML or write a 300 page spec, but I find that use cases and error conditions are critical to plan out before writing any code.
When it comes to design patterns, the answer is yes take the time to think about them and diagram out where they can be useful... and where they are not useful. For a small project a week might be overkill but some planning will produce better code which is easier to maintain and is more useful in the long run.
你的问题措辞错误。您不是在询问设计模式，而是在询问正式设计、在开始编码之前生成设计文档。但同样，您可以在没有明确的设计文档的情况下拥有良好的设计，并且您可以拥有设计文档而无需在开始编码之前进行设计。一般来说：
Your question is wrongly worded. You're not asking about design patterns, you're asking about formal design, producing design documents before starting to code. But again, you can have good design without having explicit design documents, and you can have design documents without having to do them before you start coding. Generally:
设计模式不是您“决定使用”的东西。如果你有足够的经验来看到它们，它们就会自然而然地出现。而且它们不是开销——需要添加的代码量相当小。
Design patterns are not something you "decide to use". They come naturally, if you are experienced enough to see them. And they are not overhead - the amount of code to add is rather small.
这确实与规模有关。在较大的项目中，您可以通过进行“无聊”的分析来节省时间，而在较小的项目中，您实际上可以延长总体时间。 （话虽如此，即使是最小的任务也会受益于一些预先思考/涂鸦时间）
无论哪种方式，我想说不要仅仅为了适应模式而改变你的方法。它们就像任何其他工具一样，而不是某种能够保证成功的灵丹妙药。
It's about scale really. In larger projects you'll save time by doing the "boring" analysis, whereas on smaller ones you could actually extend the overall time. (Having said that, even the smallest task will benefit from some upfront thinking/doodling time)
Either way, I'd say don't bend your approach simply to accomodate patterns. They are like any other tool, and not some panacea whose inclusion will guarantee success.
俗话说“如果你有一把锤子，那么一切都开始看起来像钉子”，这意味着如果你了解设计模式，你就会不断尝试将它们融入其中，即使你可能不需要它们。请记住，就编码设计模式而言，单例、工厂等...在实施时间方面非常轻量级，不应该向管理层提及。
然而，正如你所说，分析和“图表”是非常有价值的。如果它是一个小项目，那么它会花费很少的时间，无需担心。通常，快速分析和“预先思考”会比简单地削减代码更早地突出显示任何问题。
The old saying goes that "if you have a hammer, then everything starts to look like a nail", meaning that if you know of design patterns, you keep trying to fit them in, even when you might not need them. Keep in mind, that in terms of coding design patters, singleton, factory, etc... are very lightweight in terms of their time to implement and shouldn't really be anything to mention to management.
However, analysis and "diagramming" as you put it, is very valuable. If its a small project, then it will take a small amount of time, nothing to worry about. Often, a quick analysis and "pre-thought" will highlight any issues earlier than while simply cutting code.
Bozho说应该如何……但在大多数人手中，设计模式变成了寻找钉子的锤子……最终他们通过将钉子插入螺旋盖来解决诸如关闭一瓶可乐之类的问题，所以他们有一些要锤炼的东西......最终，实际问题并没有解决，因为虽然螺旋盖现在再次固定到瓶子上，但瓶子仍然允许其内容物逸出......
设计模式不是被认为是构建设计的组件...设计模式是设计过程中出现的常见问题的解决方案...
您的问题似乎是，您是否应该花时间设计您的设计软件，或者您是否应该尝试尽可能快地交付似乎可以解决问题的软件...您不应该做后者...有时实际上即时设计就足够了，这是可以的，只要：
一旦你养成这些习惯， 哪些部分似乎需要审查，你并没有真正变慢，但是你的软件变得更加可维护......而且，对于小问题，有时尝试通过实现来解决它们，然后从错误中学习并用这些知识重新实现它们更有意义。 .. 与自上而下的方法不同，它可能会更快并且包括学习过程...
如果您成功地将项目实际划分为如此独立的小问题，并且可以定义如何访问各个解决方案提供的功能的接口，那么你的设计实际上是完美的，你不需要进一步了解细节......
Bozho said how it should be ... but in the hands of most people, design patterns turn into hammers in search for a nail ... in the end they solve problems such as closing a bottle of coke by putting nails into the screw top, so they have something to hammer on ... in the end, the actual problem is not solved, because although the screw top is now again fixed to the bottle, the bottle still alows its content to escape ...
design patterns are not to be thought of as the components to build a design from ... design patterns are solutions to common problems that emerge within the process of design ...
your question seems to rather be, whether or not you should take the time to design your software, or whether you should just try to deliver software that seems to solve the problem, as fast as you can ... you shouldn't do the latter ... sometimes it is sufficient to actually design on the fly and this is ok, as long as:
once you take these habits, you are not really slower, but your software turns much more maintainable ... also, for small problems, it sometimes makes more sense to just try to solve them through implementation and then learn from what went wrong and reimplement them with that knowledge ... it may turn out to be faster and includes a learning process, unlike top-down approaches ...
If you succeed in actually dividing a project into such independant small problems and can define interfaces how to access functionality provided by the respective solutions, then your design is actually perfect and you needn't get into details further ...