您要编写的软件的工作流程是什么？ [英] What is the workflow you follow to design the software you're about to write?
问题描述
我已经开始使用相当复杂的软件。这是一个个人项目，但是我正在付出很多努力。
现在，我习惯于处理其他人的解决方案/设计或以非常可控的方式发展的项目。
I've started working on a fairly complicated software. It is for a personal project, but nonetheless I'm putting a lot of effort into it. Now, I'm used to work on other people's solutions / designs or on projects that grow in a very controllable way.
这一次，我开始了两次编码基础，我迅速发现自己卡住了。所以我休息了，决定在编写一行之前写下完整的解决方案。我所做的（按顺序）是：
This time, I started twice to code the basics and I rapidly found myself stuck. So i took a rest and decided to write down the complete solution before coding a single line. What I've done (in order) is:
- 以CLI命令的形式编写用例（这是一个命令行应用程序）
- 写一些帮助
- 设计各种类的类，数据文件的结构和各个部分的功能工作流程。
现在，我在这一整个部分真的很慢。我已经建立了一个个人维基，我正在使用它来编写这些规范，但我清楚地感觉到我缺乏经验和清晰的方法。
Now, I'm going really slow in this whole part. I've set up a personal wiki and I'm using it to write those specifications, but i clearly feel my lack of experience and a clear methodology.
我是意识到软件设计是一个非常复杂的课题，并且已经写了一小部分书籍，但我希望您能分享您的经验/建议/方法。
I'm aware that software design is a very complex subject and that a pletora of books have been written about it, but I'd love you to share your experience / advices / methodology.
在个人，中型项目工作时，开始编码之前你要指定什么？如何？
When working on personal, middle-sized projects, what do you specify before starting to code? How?
提前感谢
推荐答案
在开发个人，中型项目时，您在开始编码之前指定了什么？
When working on personal, middle-sized projects, what do you specify before starting to code?
我指定功能规范：
- 我担心这可能太容易了，如果我刚开始编码（这是如何 ），忘记为什么和什么我想要编码（对于相当复杂的软件，可能需要开发几个月或几年）。
- 我也想要理解我将要开发的范围：为了评估大约（一个数量级）：
- 如何很大，这将是
- 是否可以完成
- 是否值得开始
- 什么子集可以先开发
- I feared that it might be too easy, if I just started coding (which is the "how"), to forget "why" and "what" I wanted to code (for "fairly complicated" software, over the months or years that it might take to develop).
- I also wanted to understand, more or less, the "scope" of what I would be developing: in order to assess approximately (to an order of magnitude):
- How big it will be
- Whether I could finish it
- Whether it was worth starting
- What subset of it can be developed first
为了风险管理我会补充我想要开发的一些内容意味着使用一些我不熟悉的软件;为了最小化与此相关的风险，我也做了一点点的原型。
For the sake of risk management I'll add that some of what I wanted to develop implied using some software that I wasn't familiar with; to minimize the risk associated with that, I also did a little throw-away prototyping.
如何？
How?
我概述了一个功能规范，使用笔纸。我写的一些是高级（商业级视觉文档），有些是较低级的，更像设计（一些UI细节）。有时候我停止了，如何组织它，但后来继续推理，每一个 每个主题都是或多或少的凝聚力，稍后我可以解决如何组织页面（很像你的wiki，也许）。
I outlined a functional specification, using pen a paper. Some of what I wrote was high-level (a business-level "vision" document), and some was lower-level, more like design (some of the UI details). Sometimes I stopped and puzzled about how to organize it, but then went on, reasoning that each page is more-or-less cohesive about each topic, and that I can puzzle later about how to organize the pages (much like your wiki, perhaps).
我都提前指定了软件架构：
- 我开始开发基础架构（几个小组件），然后添加代码;并且，当我添加代码，如果任何组件变得太大和复杂，那么我将它细分成几个较小的组件...这是一个进化过程...如在系统论， A复杂系统的工作原理是从一个简单的系统中发现的。
- 我没有记录架构;或者，相反，架构的唯一文档是代码本身：例如，将源代码排列到源目录，命名空间和DLL中的方式。
我现在有一个理论上的架构理由，但我没有记录下列原因：
I do have a theoretical justification for the architecture as it is now, but I haven't documented these reasons:
- 我是唯一的开发人员
- 实际架构由代码记录
- 架构的原因在于我的头脑，可以通过源代码中的命名约定以及各种组件的依赖关系来发现它们。
If（only if）我不是唯一的开发人员，那么我可能会认为它值得记录架构及其理由。
If (only if) I weren't the sole developer, then I might think it worth documenting the architecture and its rationale.
上面我对软件架构的说明也是如此数据。
What I said above about the architecture of the software is also true of the data which the software processes.
至于测试，我要代码一点，然后t估计或者写一个测试，然后对通过该测试的功能进行编码。我没有做大爆炸整合，即几个月的写作没有任何测试。
As for testing, I code a bit and then test it; or write a test and then code the functionality which will pass that test. I'm not doing "big bang integration", i.e. months of writing without any testing.
我的过程中（或事情缺少）的最大弱点之一是强>估计努力，然后根据估计跟踪实施...这是这个个人项目过程与我为其他商业人士付费的付费项目之间的区别之一。我怀疑这是否很好：如果估计是商业上的最佳做法，那么也许我应该在个人项目上做。
One of the biggest weaknesses in (or thing missing from) my process is estimating effort in advance, and then tracking implementation against the estimate ... this is one of the differences between this 'personal' project process versus a paid project that I'd do for someone else commercially. I doubt whether this is good though: if estimation is a best practice commercially, then perhaps I 'should' be doing it too on a personal project.
这篇关于您要编写的软件的工作流程是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
