制作应用程序的开发生命周期？
我有一个想法想要制作成一个应用程序（我有 C/C++、C# 和 Java 编程背景，因此我将在 QT Creator 中进行开发以进行交叉编译）。那么现在我请教各位资深开发人员，接下来我该怎么办？我知道所有好的程序都源于一个想法。那我该怎么办呢？设计 UI 原型？然后开发代码？有没有类似应用程序开发的循环？
我并不是说这个问题是主观的或有争议的
I have an idea that I want to make into an application (I have a C/C++, C#, and Java programming background so I will be developing in QT Creator for cross-compilation's sake). So now I am asking you senior developers, what should I do next? I know that all good programs come from an idea. Then what should I do? Prototype the UI? Then develop the code? Is there like a circle of the development of an application?
I DO NOT MEAN FOR THIS QUESTION TO BE SUBJECTIVE OR ARGUMENTATIVE
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
好吧，从经验丰富的开发人员的角度来看，我工作过的大多数公司至少都遵循某种流程驱动的方法。我见过的开源项目差异很大，从临时的到极端流程驱动的。但总的来说，至少在企业界，即使是小型项目，类似以下方法对我和我合作过的团队都很有效。当然，使用不同的范式有很多变体，但总的来说，这些是我在大多数范式中看到的步骤类型（并且我确信我已经遗漏了一些具体步骤）：
有些方法是迭代的，例如增量开发或敏捷/Scrum。在敏捷/Scrum 中，你的迭代会非常快，就像每隔几周就会经历一个完整的周期。在增量开发中，周期通常更长：数月甚至数年。在 Scrum 和增量开发中，要记住的主要事情是，在每次迭代结束时，您都希望拥有一个可用的软件（即使它没有做太多事情）。这有助于保持真实或潜在客户，甚至开发人员的兴趣。
无论您采用哪种方法，您都可以通过查看 UI 原型或通过 可用性测试，越好。
Ok, from a seasoned developer's perspective, most companies I've worked for follow at least a somewhat process-driven approach. Open source projects I've seen can vary widely, from ad-hoc to extremely process-driven. In general though, at least in the corporate world, even on smallish projects, something like the following approaches has worked well for me and the teams I've worked with. Of course, there are many variations, using different paradigms, but in general, these are the types of steps I see across most paradigms (and I'm sure I've left some nitty-gritty steps out):
Some approaches are iterative, such as Incremental Development or Agile/Scrum. In Agile/Scrum, your iterations will be very quick, like every few weeks go through a complete cycle. In Incremental Development, the cycle is typically longer: months or even years. In both Scrum and in Incremental Development, the main thing to keep in mind is that at the end of each iteration, you want to have a usable piece of software (even if it doesn't do much). This helps keep real or potential customers, and even developers, interested.
Whatever your approach, the earlier and more often you can involve your users (or prospective users), either via looking at UI prototypes, or via Usability Testing, the better.
我想说这取决于应用程序的主要部分是什么。大部分工作是否来自设计用户界面（即“令人惊叹的因素”来自何处？），或者主要是数据操作或其他一些“繁重的工作”（即这些是我的结果）简单的用户界面）？
如果应用程序的目的是让人们“惊叹”，那么对用户界面进行原型设计并获取意见会大有帮助。这可以在开始编写代码之前完成，然后在收到反馈时可以应用增量更新。当您寻求反馈时，您可以开始对应用程序的其余部分进行编码，因此每个部分都可以顺利进行，而无需等待其中一个或另一个。
好处是，如果做得正确，这两件事应该完全（或几乎完全）解耦并且彼此独立。
最后一点：通过对用户界面进行原型设计，可能有助于巩固您头脑中的想法，这将简化用户界面背后的代码设计。不同的方法适用于不同的人，但根据我的经验，对界面进行原型设计非常有用。
I would say that it depends on what the main portion of the application will be. Will the majority of the work come from designing the user interface (i.e. is that where the "wow factor" comes from?) or is it going to be mostly data manipulation or some other "heavy lifting" (i.e. these are my results in a simple user interface)?
If the application is meant to "wow" people, prototyping the user interface and getting opinions on it goes a long way. This can be done before starting on the code, then incremental updates can be applied as you receive feedback. While you are asking for feedback, you can start working on coding the rest of the application, so each piece is moving along without waiting for one or the other.
The nice thing is that if done correctly, these two things should be entirely (or almost entirely) decoupled and independent of each other.
One last note: by prototyping your user interface, it might help solidify your idea in your head, which will ease designing the code behind the user interface. Different methods work for different people, but in my experience, prototyping the interface is very useful.
继续吧。坚持下去。
尝试将事物设计得灵活，这样当您意识到自己走错了路时，就可以轻松地重构事物。将 UI、业务逻辑和数据层分开，以便稍后当您确切了解 UI 的作用时，可以轻松地重新设计 UI 等。
总是很难知道从哪里开始，所以我能给出的最好建议就是彻底思考，选择一点，然后开始工作。预计您将不得不重构甚至重写一些位 - 不要害怕这一点，这是正常的。但你可能会永远坐在那里，循环地尝试决定先做什么，甚至永远不会开始。只要您心中有一个总体计划，以便您实现的各个部分最终都能连贯地组合在一起，那么您首先执行哪一步并不重要。
（我并不是建议您在没有先设计或原型化任何东西的情况下就开始搞砸。只是开发新应用程序最困难的部分之一就是决定从哪里开始。在某些时候，您只需要采取跳水并开始游泳）
Crack on with it. Just get stuck in.
Try to design things to be flexible so you can easily refactor things when you realise you've taken the wrong path. Keep your UI, business logic and data tiers separated so you can easily rework the UI etc later when you understand exactly what it has to do.
It's always hard to know where to start, so the best advice I can give is to just think it all through, pick a bit, and get to work. Expect that you will have to refactor or even rewrite some bits - don't be afraid of this, it's normal. But you could sit there forever looping trying to decide which bit to do first and never even get started. It doesn't really matter which bit you do first, as long as you have an overall plan in mind so that the bits you implement all fit together coherently at the end.
(I'm not suggesting you go off and make a big mess without desiging or prototyping anything first. It's just that one of the most difficult parts of developing a new application is deciding where to start. At some point, you just have to take the plunge and start swimming)