您在编程过程中使用哪些图表技术（而非工具）？
您在编程时使用哪些图表技术可以帮助您 或者其他人了解您的程序或设计。 我不是在谈论一个人的 最喜欢的工具，尽管一个好的工具可能会极大地帮助一个人 绘制图表。
我在这个问题中的目的是找到简单有用的图表技术 人们实际上使用并找到新的东西来学习。
您使用流程图、数据流程图、ER 图等吗？
网络上充满了推荐！ 但真正的程序员、设计师、 和代码维护人员在日常工作中实际使用。
感谢您的反馈意见
What diagramming technique(s) do you use while programming to help you
or others understand your program or design. I am not talking about a person's
favorite tool, though a good tool probable helps a person greatly with
diagramming.
My intent in this question is to find the simple useful diagramming techniques
people actually use and find new ones to learn.
Do you use flow-charts, Data Flow Diagrams, ER diagrams, etc?
The web is full of recommendations! But what do real programmers, designers,
and code maintainers actually use in their day to day work.
Thanks for your feedback
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（13）
如果有一个棘手的算法，例如将多个数据流关联到一个新流，那么我通常会使用流程图来计算该算法。
如果解决方案需要了解状态，则还可以使用状态图。
这些是我最常用的。
在进行数据仓库设计时，我绘制星型模式来计算如何存储数据。 在进行事务性数据库设计时，我使用实体关系图来处理数据存储。
在设计 UI 时，我只是画出草图。 一旦我开始解决 UI 的某些部分并想要尝试某些区域，我将制作一个模板，打印一份副本，然后将其用作处理子部分的指南。 对于配色方案，可以方便地使用 gimp 制作图形，并为设计的每一部分设置图层，然后对每个图层进行着色以找到正确的平衡。
If there is a tricky algorithm for something such as the correlation of multiple data streams into a new stream then I will generally use a Flow Chart to work out the algorithm.
If the solution requires knowledge of state then a State diagram is also used.
Those are the ones I use most.
When doing Data Warehouse design I draw Star Schemas to work out how to store the data. When doing Transactional DB design I use Entity Relationship diagrams to work our data storage.
When designing a UI I just sketch it out. Once I start to get some parts of the UI worked out and want to play with some areas I will make a template, print out a copy copies and then use that as a guide to work on sub-sections. For colour schemes, it can be handy to make a graphic using the gimp and have layers for each piece of the design and then play with the layers colouring each one to find the right balance.
我们真正用的是什么？ 也许其他人实际上创建了正式的图表，但大多数情况下我只是在一张纸上涂写气泡、方框和线条。
What do we really use? Maybe other people actually create formal diagrams, but for the most part I just scribble bubbles, boxes and lines on a sheet of paper.
我使用白板进行建模，所以我想“白板建模语言”将是我的答案。
I use a whiteboard for modeling, so I guess "whiteboard modeling language" would be my answer.
我将为我正在设计的任何大于几个类的东西绘制一个 UML 类图。 绘制类图让我花时间思考设计，而不是直接深入代码，并且总是能产生更好的结果。
对于更大、更复杂的体系结构，我发现序列图是传达行为的好方法，特别是对于多线程系统。
I will do a UML Class diagram for anything i'm designing that is bigger than a couple of classes. Drawing a class diagram makes me take time out to think over the design instead of ploughing straight into the code and always produces a better result.
For bigger and more complicated architectures I find that Sequence diagrams are a good way to communicate behviour, especially for multi-threaded systems.
我使用图表作为快速理解遗留代码的一种方式。 创建图表需要一些工作，但最终总是有回报的。
通常我使用类图来了解全局。 有时，如果一段代码非常难以理解，则序列图甚至数据流图。
在设计阶段，我使用类图，并且经常使用状态图。 如果类行为与其状态不同，则状态图是完美的。
I use diagrams as a way to quickly understand legacy code. It takes some work to create the diagram, but it always pays of in the end.
Normally I use class diagrams to get the big picture. Sometimes sequence diagrams and even dataflow diagram if a piece o code is extremely hard to understand.
In the design phase I use class diagrams, and often state diagrams. State diagrams are perfect if a class behaviour differs with its state.
我经常使用序列图（画在纸上）。 我发现它们为我提供了一个很好的视觉表示，即我们应用程序中各种系统和组件之间的方法调用和信息的逻辑流。
I use Sequence Diagrams a lot (drawn on paper). I find they give me a nice visual representation the logical flow of method calls and information between various systems and components in our applications.
对于任何比 shell 脚本更大的项目，我都会在纸上和白板上使用 ER 和类图。
流程图，仅当我需要向非程序员解释流程时（或者如果这是一个非常复杂的流程并且我需要先理解它）。
我的前老板常说“这家伙就是喜欢画画”。
I use ER and class diagrams on paper and whiteboard for any project that's bigger than a shell script.
Flow charts, only when I need to explain a process to a non-programmer (or if it's a really complicated process and I need to understand it first).
My old boss used to say "the guy just loves drawing stuff."
我有一个我使用和开发的主要产品的流程图。
我的团队还经常在白板上使用 UML 图草图，同时设计新的零件供我们实施。 它们对于创建设计模式和对所需类的高级结构进行建模非常有用。 不过，这些从来都不是完整的 UML...
I have a Flow chart of the main product I work with and develop.
My team also often uses UML diagram sketches on white-boards while designing new parts for us to implement. They're very useful in creating design patterns and modeling the high-level structure of the classes which will be needed. These are never full blown UML though...
用于讨论的白板。
笔和纸，减少临时记录。
“要实现的事物”的代码存根。
经过测试和工作的代码（带有广泛的注释）供后代使用。
Whiteboard for discussions.
Pen and paper for less temporary record.
Code stubs for 'Things to impelement'.
Tested and Working code (with extensive comments) for posterity.
我在 AJAX 开发环境中工作，我编写的大多数后端代码的工作方式就像关系数据库和前端 javascript（用户界面）之间的管道。 因此，我最常用的“图表”是 JSON 对象，用于描述数据如何在数据库和接口之间来回传递。 它们是简单、通用且易于理解的数据结构。
例子：
I work in an AJAX development environment, and most of the backend code I write works like a pipe between a relational database and the frontend javascript (user interface). So, the most used 'diagram' per say that I use are JSON objects to describe how data should be passed back and forth between the database and the interface. They are simple, universal and easy to understand data structures.
Example:
我绘制 UML 类、对象和序列图的混用版本。 虽然我尝试忠实于语法，但我更关心表达特定功能背后的主要思想。 所以，我会写一些东西，请同事看一下，如果看起来足够清楚，我们甚至可以扫描它并将其发布在我们的 Wiki 中。
然后，当我们实际上有一些时间来处理文档时（而且几乎没有），我将使用 BOUML 并将涂鸦重新绘制成正确的图表。
现在，将所有内容放在上下文中，我在一个相对较小的团队（5 名开发人员）工作，用 Java 制作交易和产品配置平台。 我们有两种产品，然后我们还可以根据客户的要求进行定制。 作为一个紧密联系的社区，几年来周转率较低（零），我们主要将文档用作我们自己的剩余部分。 在这种设置中，上述方法效果很好。
I draw bastardized versions of UML class, object and sequence diagrams. While I try to be true to the syntax, I am much more concerned about expressing the main idea behind particular feature. So, I'll draw up something, ask a colleague to take a look, and if it seems clear enough, we might even scan it and post it in our Wiki.
Then, when it so happens that we actually get some time to work on the documentation (and that is almost never), I'll use BOUML and redraw the scribbles into a proper diagram.
Now, to put is all in context, I'm working at a relatively small team (5 developers), making trading and product configuration platforms in Java. We have our two products that we then additionally customize to customer's requests. Being a close-knit community, with low (zero) turnaround for a few years, we use the documentation primarily as a remainder to ourselves. And in this setup, the above approach works quite well.
我喜欢数据流程图。 很多。
I like Data Flow Diagrams. A lot.
我使用任何沟通所需的东西。 通常这根本就没什么。 有时它是白板。
我有时会使用 Sparx Enterprise Architect，它是一个 UML 建模工具，尽管它在使用时会生成不错的图表。 我将它用于需求、用例、活动、序列、域，甚至类建模，有时还用于一些逆向工程的 ER 图。 不惜一切代价来表达要点。
I use whatever is needed for communicatation. Usually that's nothing at all. Sometimes it's a whiteboard.
From time to time, I use Sparx Enterprise Architect, which is a UML modeling tool, though it produces decent diagams while it's at it. I've used it for requirements, use case, activity, sequence, domain, and even class modeling, and sometimes some reverse-engineered ER diagrams. Whatever it takes to get the point across.