我应该如何计划和启动一个项目？

每次启动项目时，我都会在关键时刻决定完全更改核心类并陷入晦涩的错误中。我尝试进行高级规划，通常会从一个好的脚步开始，但是后来我又去了，并决定我想“另辟way径”。

启动项目时（例如映射类和从单元测试开始），是否有某种标准？在计划和启动中型项目时，有什么好的约定。

最后一个开始的项目是射弹运动模拟器-我知道，可以预见。

在计划时，不要提前计划所有可能的应用程序。计划婴儿的步骤。开始使用该应用程序所需的最低功能是什么？从那里开始。

当您开始项目时，仅编码出绝对的最小功能。在编写代码时，请确保使用智能封装编写了良好，干净的代码。这样可以最大程度地减少以后进行更改带来的错误。

迭代该最小功能，直到您对此感到满意为止。然后开始一次添加新功能和增强功能。再次专注于通过智能封装编写良好，简洁的代码。

如果您计划一些小步骤并编写清晰的代码，它将最大程度地减少您实际需要进行的更改。在完成第一个功能的编写时，您应该已经采用了应用程序基础所基于的模式。如果该基础存在问题，则您的下一个功能应该可以迅速发现问题。可以更容易地看到部件如何集成在一起。此时，您所做的更改应将干扰降到最低。

看来您的计划无济于事。这不足为奇，因为您没有足够的经验来制定可行的计划。解决方案很简单。别再计划了。只要接受您将要编写和重写代码的方式即可。可以，因为代码是免费的，但您的时间除外。如果要编写UI应用程序，则只需从空白窗口开始，然后每次添加一点，直到完成。当您有更多经验时，您的项目将会更快。担心因为您正在更改代码而已，就像音乐专业的学生担心实际中浪费的所有音符一样。

在他们编码了一定数量的代码之前，没有人真正知道最佳设计是什么。因此，良好设计的秘诀是认识到您的初稿不可避免地会欠佳，并计划更早，更频繁地重写较小的部分。一旦发现行或函数或类的缺陷，就可以代替它们来废弃几乎完整的程序。

经验丰富的程序员通常也不会在初稿上做对。经验带来的是能够更快地识别出不良设计的能力，以及更快地重写的能力。

以我的经验，当您有了更多的经验时，这个问题就消失了。此外，良好的封装可以降低更改设计的成本。模块封装得越紧密，以后更改的成本就越便宜。认为这是使您的班级分开的绝佳动机。

http://nathanmarz.com/blog/suffering-oriented-programming.html

这解决了您的问题。他首先只是确保该软件可行，然后进行原型设计和创建。然后，他开始接受代码并将其分解。然后，他对其进行优化。

设计应用程序有两个方面。首先是确定您的应用程序可以做什么。第二个是设计方法。对其所做的更改非常重要，并且取决于应用程序的成熟度（以及应用程序方向的变化），最好以重写而不是重新编写的方式进行。

第二个方面是如何。通过使用单元测试和敏捷开发实践，您可以将通过重构实现特定功能的方式所产生的影响最小化。学习如何利用这些技术的一部分是练习练习。

我会一次又一次地给出建议。选择一个宠物项目。尽力而为。学习新知识，并运用所学知识来改进开发该项目的方式。

例如，从待办事项列表开始。简单点...一开始就不必担心数据库存储。只是使其工作。现在开始在此基础上构建。也许您想学习MVVM和WPF ...您已经知道如何实现内存中的待办事项列表，因此您要解决的问题要少得多。现在，您要使其成为多个用户可以从数据库加载其待办事项列表的地方。您已经解决了内存不足和显示方式分离的问题，因此可以专注于学习数据访问。从那里，您可以扩展应用程序，使其具有更复杂的域模型（例如，从Todo列表更改为项目管理解决方案），Web界面，甚至使其在移动设备上运行。进行这项工作的关键是选择您可以完成的事情，这些事情可以标记进度，并且可以随着时间的推移而增长。

以我的经验，系统设计通常需要比实际编码更长或更长的时间。当您说“预先计划”时，您实际上在计划什么？也许去了老派，并使用了一种久经考验的设计方法。或去老学校，在编写实际代码之前先编写伪代码。

我认为您必须问自己，为什么在关键时刻改变事情，而不是坚持原来的计划。原始计划有缺陷吗？还是您有一个有洞察力的时刻显示了一种更好的做事方法。它实际上是更好还是只是不同？

获得经验后，您将需要重写/抓取并重新开始，而不必那么频繁。写下您要解决的问题。写下您认为需要的模糊类说明，写下将如何交互。了解所有工作原理，然后进行编码。不要花费大量时间写出类的每个属性，方法。在此阶段，您正在尝试获得50K脚步图。开始编码后，如果需要记下更多详细信息，请继续进行编码。如果不是，那就开始编码。

您发现这一点如此困难的原因是您有一个主意，但您实际上并没有一个完整的主意想要做什么。如果您正在做自己的项目，但是没有客户告诉您他们想要什么，那么取决于您是自己的客户。把自己放在顾客的鞋子上，并开始建立一个不可能的愿望清单。

换句话说，当您开始时不要进行任何设计！！！。

一旦列出了您希望系统执行的所有操作，就对所有事情进行优先级排序，并确定运行基本系统所需的最低功能。这可以是单个基本功能，也可以是整个屏幕，但是它必须是您感觉到的（作为客户）对测试有用的东西。

因此，功能清单+基本优先级= 需求。

一旦拥有了所有这些，就进行一个非常高级的设计。只需坐下来，思考一下您的系统需要什么才能启动和运行前几个优先级。如果愿意，可以改变主意，但是您可能希望在此处添加一些代码或系统配置，以了解更多有关可能的信息。进行足够多的步骤以验证您的基本设计思想。

即：现在 您可以放纵设计师的要求。

完成后，即可开始实现功能。为每个功能创建基本的功能规格。这可能像特征语句的集合一样简单。如果您喜欢故事卡。这使您可以在脑海中一点点地发展自己的想法，并创建一组语句，这些语句将成为要测试和建立实现的规范。

哭泣破坏，放任... 代码！

从那里开始，执行符合您的规范的测试，然后为每个测试编写代码。编译，“发布”，然后重复下一个功能，直到您确定项目足够完成。

这确实取决于经验丰富的人，但是我发现这种方法是一个简单的公式，可以帮助您将注意力集中在需要做的事情上，而不是因为试图做太多事情而陷入无休止的拖延周期一旦。

在完成诸如建立项目目标之类的基础知识，获得需求清单以及锁定与外部系统的任何接口之后。

然后，您需要为每个用户交互做一个用例或“故事”。关于如何构成“良好”用例或故事的内容已撰写成卷，并且有许多变体。用例是我遇到的最有效的设计工具。它们在消除不必要的需求的同时，帮助您弥补缺少的功能，并使您的设计精简于其本质。正如我所说，方法各异，但大多数从业者都同意：-

• 简洁明了的英文文本。
• “目标驱动”效果最佳，即“猴子收获葡萄”比“猴子按下红色按钮”要好。
• 禁止使用技术术语。没有“下拉菜单”，“文本框”。一个好的用例应该独立于任何接口技术。您应该能够对基于HTML的系统使用一个用例，并将其用于语音激活系统，而无需对用例本身进行任何更改。（这很难做到，但值得！）。
• 旨在将您的初稿的字数减少50％，摆脱不必要的步骤和琐事。

比您准备指定主要班级要多：

UML-通用建模语言。是设计类的标准工具。您可以指定每个类的公共成员和方法，并将它们链接到清晰简洁的图形模型中。

结合时序图和数据模型，您可以在进行任何编码之前验证和改进设计。

将注意力转移到要获得的结果上，并权衡学习/尝试新实施的潜在收益，否则可能会陷入使您陷入困境的风险。

如果您确实回到了第一方格，那么一切都不会因为您获得经验而流失。

如果您有最后期限（听起来好像您在编程很有趣），那么这确实很棘手。如果您继续采用一种方法，那么随着时间的流逝，您可能会使用过时的方法。如果继续走另一条路，您可能会冒以较低的速度（根据学习冒险的结果而变化的速度）产生产出的后果。

我过去常常忙于工作，一年又一年地快速完成工作，然后有一天，我意识到自己对技能的了解变得不那么流行了。