Pen and Paper and/or Whiteboards for drafting, a more comprehensive tool for documentation purposes.
I mainly use Class Diagrams and a few sketches with Sequence Diagrams to get most of the relationships right.
About the tools: At work I use Enterprise Architect but personally I find Visual Paradigm for UML a better choice. The latter is much more flexible and allows quick drafting as well.
At VP they also have a version called Agilian for some time now (which I have not yet used) which seems to be even more flexible, allowing sketches to become documentation in no-time... maybe one day this tool will replace my paper sketches (save the trees :P).
I find pen and paper, a whiteboard and possibly some CRC cards to be very useful. Most of the time I think a whiteboard and some stickers or cards with the class and/or module names written on them work best when doing planning and designing as a group. Pen and paper is fine if you are doing the activity alone. Once you have the basic structure set you can always make a pretty UML diagram.
When doing an initial design I like a whiteboard and 1 - 3 other developers to bounce ideas off of. That's usually enough to catch any glaring errors/fix any tricky situations that may arise without dropping the s/n ratio by too much.
Whiteboard for the first 35 or 40 drafts. UML is nice after that, but not particularly necessary. The best documentation after you've hashed out the details is clean code.
It's easy, while in the paper-and-pen (or whatever non-code equivalent you prefer) stage, to overstay, falling prey to the dreaded YAGNI syndrome. How many of us have carefully designed in some "sexy" feature that ended up never being used? (Raises hand. Hands.)
Small iterative test-driven steps and frequent refactoring - let the code tell you what it wants to be.
Most of my projects start out with the only certainty being that we won't end up where we currently think we will. So spending very much time on Big Up-Front Design (or Big Design Up Front if you prefer) is wasteful - better to start with the first thing we want to do and see where we end up.
It kind of depends on where you consider design to end. I read an article a few years back that presented the idea that coding is design - or for the Big Process fans at least it's the back-end of design. It rang true to me and changed forever the way I viewed the stages of the development process. Of course, I've just googled like crazy for the darn thing. Could I find it? Could I heck. Perhaps I dreamed the article and it's all my own idea. Yeah, that'll be it.
I usually start with a empty interface then start writing tests. I then generate the members using refactoring tools. For me unit testing is part of the design.
I find pen and paper very useful, and I try to get as far away from a computer as possible. If I do it on the compy, I'm always too tempted to start programming the solution. That inevitably leads to me changing things later that I would have spotted in the planning phase had I actually spent a good measure of time on it.
发布评论
评论（12）
用于起草的笔和纸和/或白板，一种用于文档目的的更全面的工具。
我主要使用类图和一些带有序列图的草图来获得大部分正确的关系。
关于工具：在工作中，我使用 Enterprise Architect，但我个人发现 Visual Paradigm for UML 是一个更好的选择。 后者更加灵活，也可以快速起草。
在 VP，他们也有一段时间推出了一个名为 Agilian 的版本（我有尚未使用），这似乎更加灵活，可以让草图立即成为文档......也许有一天，这个工具将取代我的纸质草图（拯救树木：P）。
Pen and Paper and/or Whiteboards for drafting, a more comprehensive tool for documentation purposes.
I mainly use Class Diagrams and a few sketches with Sequence Diagrams to get most of the relationships right.
About the tools: At work I use Enterprise Architect but personally I find Visual Paradigm for UML a better choice. The latter is much more flexible and allows quick drafting as well.
At VP they also have a version called Agilian for some time now (which I have not yet used) which seems to be even more flexible, allowing sketches to become documentation in no-time... maybe one day this tool will replace my paper sketches (save the trees :P).
我发现笔和纸、白板以及一些 CRC 卡 非常有用有用。 大多数时候，我认为白板和一些写有类和/或模块名称的贴纸或卡片在作为一个团队进行规划和设计时效果最好。 如果您独自进行这项活动，笔和纸就可以了。 一旦设置了基本结构，您就可以制作漂亮的 UML 图。
I find pen and paper, a whiteboard and possibly some CRC cards to be very useful. Most of the time I think a whiteboard and some stickers or cards with the class and/or module names written on them work best when doing planning and designing as a group. Pen and paper is fine if you are doing the activity alone. Once you have the basic structure set you can always make a pretty UML diagram.
在进行初始设计时，我喜欢使用白板和 1 - 3 个其他开发人员来交流想法。 这通常足以捕获任何明显的错误/修复可能出现的任何棘手情况，而不会导致信噪比下降太多。
When doing an initial design I like a whiteboard and 1 - 3 other developers to bounce ideas off of. That's usually enough to catch any glaring errors/fix any tricky situations that may arise without dropping the s/n ratio by too much.
主要是笔和纸，尽管我偶尔会使用 Visio 画一些粗略的图表。
我想如果有一个精美的工具就好了，但这只是另一件事需要学习。
Mostly pen and paper, although I occasionally break out Visio and just do some rough diagrams.
Would be nice to have a fancy tool I guess, but it would just be another thing to learn.
前 35 或 40 稿的白板。 之后 UML 就很好了，但不是特别必要。 弄清楚细节后最好的文档就是干净的代码。
Whiteboard for the first 35 or 40 drafts. UML is nice after that, but not particularly necessary. The best documentation after you've hashed out the details is clean code.
准备铅笔和纸，或者白板。 任何像钢笔这样的永久性标记，你都会有一个非常混乱的设计！
Go for PENCIL and paper, or a whiteboard. Anything permenant-marking like a pen and you'll have a pretty messy design!
我用笔和纸。
出于所有规划目的，这是最快的方法。
当我使用 UML 包时，我会迷失在布局和微调中。
但这是我的负担..:-)
I use pen and paper.
For all planning purposes, it's the fastest way.
I get lost in layout and finetuning when I use a UML package.
But that is my burden.. :-)
初稿的笔和纸。 Umlet 将其数字化。 它非常小，但它满足了我的需要
Pen and paper for the first draft. Umlet to digitalize it. It's very minimal but it does what I need
OmniGraffle（适用于 Mac OS X 的 Visio 式应用程序），有时。 否则，只需笔和纸即可。
OmniGraffle (Visio-esque app for Mac OS X), sometimes. Otherwise, just pen and paper will do.
在纸笔（或您喜欢的任何非代码等效形式）阶段，很容易停留太久，成为可怕的 YAGNI 综合症。 我们中有多少人精心设计了一些“性感”的功能，但最终却从未被使用过？ （举手。举手。）
小的迭代测试驱动步骤和频繁的重构 - 让代码告诉您它想要什么。
我的大多数项目一开始唯一确定的是我们不会达到我们目前认为的那样。 因此，花大量时间在大型预先设计上（或者大型预先设计，如果你愿意的话） ）是浪费——最好从我们想做的第一件事开始，看看我们最终会得到什么结果。
这在某种程度上取决于您认为设计的终点。 几年前我读过一篇文章，其中提出了这样的想法：编码就是设计——或者对于大流程迷来说，至少它是设计的后端。 这对我来说是真实的，并且永远改变了我看待开发过程各个阶段的方式。 当然，我刚刚疯狂地用谷歌搜索了这个该死的东西。 我能找到吗？ 我可以吗？ 也许这篇文章是我梦到的，这完全是我自己的想法。 是的，就这样了。
It's easy, while in the paper-and-pen (or whatever non-code equivalent you prefer) stage, to overstay, falling prey to the dreaded YAGNI syndrome. How many of us have carefully designed in some "sexy" feature that ended up never being used? (Raises hand. Hands.)
Small iterative test-driven steps and frequent refactoring - let the code tell you what it wants to be.
Most of my projects start out with the only certainty being that we won't end up where we currently think we will. So spending very much time on Big Up-Front Design (or Big Design Up Front if you prefer) is wasteful - better to start with the first thing we want to do and see where we end up.
It kind of depends on where you consider design to end. I read an article a few years back that presented the idea that coding is design - or for the Big Process fans at least it's the back-end of design. It rang true to me and changed forever the way I viewed the stages of the development process. Of course, I've just googled like crazy for the darn thing. Could I find it? Could I heck. Perhaps I dreamed the article and it's all my own idea. Yeah, that'll be it.
我通常从一个空接口开始，然后开始编写测试。 然后，我使用重构工具生成成员。 对我来说，单元测试是设计的一部分。
I usually start with a empty interface then start writing tests. I then generate the members using refactoring tools. For me unit testing is part of the design.
我发现笔和纸非常有用，并且我尝试尽可能远离计算机。 如果我在公司做这件事，我总是很想开始对解决方案进行编程。 这不可避免地导致我后来改变一些事情，如果我实际上花了很多时间的话，我会在计划阶段发现这些事情。
I find pen and paper very useful, and I try to get as far away from a computer as possible. If I do it on the compy, I'm always too tempted to start programming the solution. That inevitably leads to me changing things later that I would have spotted in the planning phase had I actually spent a good measure of time on it.