什么是你按照设计你要写软件的工作流程？ [英] What is the workflow you follow to design the software you're about to write?
问题描述
我已经开始在一个相当复杂的软件的工作。这是一个个人项目，但尽管如此，我付出了很多的努力进去。
现在，我已经习惯了别人的解决方案/设计，或在一个非常可控的方式增加项目。
这时候，我开始两次code的基本知识，我很快发现自己被卡住。所以，我花了休息，决定编写一个单行之前写下的完整解决方案。我做了什么（按顺序）是：
- 在CLI命令的形式写用例（这是一个命令行应用程序）
- 写一些帮助
- 设计的类中，数据文件的结构和各部分的功能性的工作流程。
现在，我要在这整个部分很慢。我已经成立了一个个人的wiki，我用它来写这些规范，但我清楚地感觉到我缺乏经验和清晰的方法论。
我知道，软件的设计是一个非常复杂的课题和的书籍pletora描写过它，但我很想你分享你的经验/建议/方法。
个人，中型项目的工作时，你是什么开始code之前指定？怎么样？
在此先感谢
个人，中型项目的工作时，你是什么开始code之前指定？
我指定的功能说明：
- 我担心它可能是太容易了，如果我刚开始编码（这是如何），忘了为什么和什么我想code（对于相当复杂软件，在几个月或几年，这可能需要开发）。
- 我也想明白了，或多或少的的范围什么，我会制定：为了评估左右（到一个数量级）：
- 将设多大
- 不管我能完成它
- 不管是值得入手
- 可以先开发怎样的子集，它
对于风险管理的缘故我要补充的是一些什么，我想使用一些软件，我不熟悉与开拓暗示;尽量减少与此有关的风险，我也做了一个小扔掉的原型设计。
如何？
我勾勒出的功能规范，使用笔纸。有些什么，我写的是高层次（业务级别远见的文件），而一些较低级别的，更像设计（一些UI细节）。有时候，我停了下来，困惑如何组织它，但接着又上推理每一页是更多或更少的关于每个主题有凝聚力，而且我可以在以后如何组织页面拼图（很像你的wiki，也许）。
我都做了，并没有指定软件架构提前：
- 我开始在考虑一个基本的架构（一些小部件）的发展，然后添加code;并且，我添加code，如果任何组件获取太大而复杂的话，我再细分为几个小部件......这是一个渐进的过程......因为它在说的 Systemantics 的< STRONG>的复杂系统的工作原理是不约而同地发现，已演变从一个简单的系统，该系统的工作。
- 我不记录体系结构;或者说，该体系结构的唯一文件是code本身。例如，以何种方式源$ C $ C被安排成源目录，命名空间和DLL文件
我有对架构的理论依据，因为它是现在，但我还没有记载这些原因：
- 我是唯一的开发
- 实际的架构是由code记录
- 为架构的原因是在我的脑海，并通过类似的事情在源$ C $ C的命名约定[重新]发现，和各种组件的依赖
如果（仅当）我不是唯一的开发者，那么我可能会认为值得记录的结构和它的理由。
我上面所说的关于该软件的架构也是在数据该软件过程。
真至于测试，我code了一下，然后对其进行测试;或者写一个测试，然后code，将通过这个测试的功能。我没有做大爆炸整合，即写作个月没有任何测试。
在其中一个最大的弱点（或失踪的事情）我的过程中的估算的努力提前，以及对估计......这之间的这种个人的差异之一，然后跟踪执行项目的过程与付费项目，我愿意为别人做其他商业。我怀疑这是否是好的，但：如果估计是最佳的做法商业化，那么也许我应该太做一个个人项目
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:
- writing the use cases in the form of CLI commands (this is a command line application)
- write some help
- design the classes, the structure of the data files and the functional workflow for the various parts.
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?
Thanks in advance
解决方案When working on personal, middle-sized projects, what do you specify before starting to code?
I specify the functional specification:
- 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?
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).
I both did and didn't specify the software architecture in advance:
- I start development with a basic architecture (a few small components) in mind, and then add code; and, as I add code, if any component gets too big and complicated then I subdivide it into several smaller components ... it's an evolutionary process ... as it says in Systemantics, A COMPLEX SYSTEM THAT WORKS IS INVARIABLY FOUND TO HAVE EVOLVED FROM A SIMPLE SYSTEM THAT WORKED.
- I'm not documenting the architecture; or, rather, the only documentation of the architecture is the code itself: for example, the way in which source code is arranged into source directories, namespaces, and DLLs.
I do have a theoretical justification for the architecture as it is now, but I haven't documented these reasons:
- I'm the sole developer
- The actual architecture is documented by the code
- The reasons for the architecture are in my head, and are [re]discoverable by things like the naming conventions in the source code, and the various components' dependencies
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.
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屋！
