TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: Software Design and documentation – what do you use?

2 点作者 eddyparkinson将近 11 年前
When you create software, what do you use to design, document and visualize. What do you use to help with designing software.<p>e.g. Use cases, Pseudo code, Gantt chats, PERT charts, DFD, decision trees, decision tables (Your answers maybe used to help teach students)<p>Also, why? When have they proved valuable?

2 条评论

dennybritz将近 11 年前
I barely use anything sophisticated. When designing a complex system I usually start with a simple document that lists the use cases (this is the most important), system components, and some implementation details. There are a couple of architectural models I&#x27;ve tried using (such as <a href="http://en.wikipedia.org/wiki/4%2B1_architectural_view_model" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;4%2B1_architectural_view_model</a>), but I haven&#x27;t found them very useful in practice.<p>Instead of over-designing and engineering from the very beginning, I prefer a more iterative approach. Admit to yourself that the first time you design&#x2F;implement a system you will most likely get a lot of things wrong. Get a proof of concept out there, and try to learn from it. The second time you design that system you will probably try to incorporate everything you know and are prone to overengineering and feature bloat (<a href="http://en.wikipedia.org/wiki/Second-system_effect" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Second-system_effect</a>). So, be careful.<p>Check out &quot;The Mythical Man-Month&quot;. It&#x27;s a timeliness book on software engineering.
评论 #8175519 未加载
kromodor将近 11 年前
Design: paper; mockup app; .psd; html; whiteboard Docs: github wiki; word docs (for smaller pieces)<p>There are too many tools. One can drown in tools and still not do anything.<p>We try to keep as simple as possible, until it is not enough. Then we escalate the tool, but only IF experience proves we work less efficient without it.