单人应用程序开发？ [关闭]答案

【问题标题】：Single Person Application Development? [closed]单人应用程序开发？ [关闭]
【发布时间】：2009-10-06 03:17:00
【问题描述】：

大家好。我想对我一直试图找到一些信息的问题有所了解。 如果您是从头开始构建项目的独立开发人员，您如何管理该项目？ 过去，我曾参与过一些已发展为相当大的项目的个人项目。在几乎所有这些项目中，我都尝试担任正常软件开发项目中所有正常的角色（即产品负责人、开发人员）、建筑师、测试员等）。似乎当我离开项目一段时间然后回来时，很难重新回到我正在做的事情的节奏中。因此，我有一些问题：

如果我知道要求（在此当前时间），我要记录它们吗无论如何？如果是这样，我该怎么做这样做，以及如何管理这些要求？ 产品积压，功能列表等？
如果是这种情况，完整的产品积压或用例是否有点矫枉过正？
如何有效地适应他/她在每个角色上的时间？
什么是正常的事件流那一个会跟随吗？ 开始编码立即，写下用户故事/用例，然后进入 OOA/D?
什么样的图表/建模对于这个级别是足够的？ 领域模型、类图等？

基本上，我很好奇 SO 社区中的每个人都将如何开发一个项目，从开始到部署，当你是一个孤独的开发者时。需要哪些步骤、文档和其他与项目相关的活动来帮助将这个项目从一个不切实际的爱好项目转变为更专业的项目？任何帮助、参考或建议将不胜感激。提前致谢。

【问题讨论】：

你可以看到：stackoverflow.com/questions/987081/…和stackoverflow.com/questions/59561/…
哇。我之前搜索过与标题类似的内容，但它没有返回我正在寻找的任何结果。我会检查这些。谢谢。
我记得他们是从过去看到他们的。祝你好运。

标签： project-management

【解决方案1】：

我发现，单人发展最困难的部分是很难让自己保持前进。即使您这样做是为了谋生（AKA，经营自己的软件业务），除非您有紧迫的需求（AKA，如果您不赚钱就会挨饿），也很难坐下来并且只是代码。

从您的角度来看，我建议您在有意义的情况下遵循良好的软件实践。例如，如果我是一个单独的软件开发人员，我就没有理由创建一个协作开发环境。我真正需要的是一个 SVN 服务器、我的 IDE 和一个记录文档的地方（可能设置一个 wiki 或网站或其他东西）。我会亲自制定一个现实的时间表来遵循并努力坚持下去。

至于文档的工作量，这实际上取决于您和您正在开发的产品。例如，我肯定会建议记录您的要求。除非你的产品是微不足道的，否则你不可能全部记住它们，以及为什么你想要某些产品而不是其他产品。然而，管理完整的积压工作本身就是一项工作。在单独程序员的情况下，这可能没有意义。

基本上，我试图表达的观点（每个项目都应该遵循——不仅仅是在这种情况下）是足够管理是有意义的。其余的应该专注于产品的工作和开发。

您可能想查看的其他内容是阅读此内容 - Agile Programming Works for the Solo Developer。还有其他类似的文章。可能会给你一些好的想法。

【讨论】：

【解决方案2】：

如果我知道要求（此时当前时间），我要记录它们吗无论如何？如果是这样，我该怎么做这样做，以及如何管理这些要求？产品积压，功能列表等？

我有两个功能列表：

说明成品范围的高级视图
我在本次迭代中实现的功能列表

因为我不需要与其他人交流（但）我倾向于写下我不知道的关于该项目的事情（如果我已经知道就没有必要写下来）：它是当它变得太复杂时，或者当我没有定义但需要定义的细节时，我开始以书面形式定义它们。

不过，在开始编码之前，我确实尝试过调查/制作business-case for the project。

如何有效地适应他/她每个角色的时间？

当我不得不离开计算机时，我会考虑非程序员、产品所有者。

除此之外，我的周期是：

实现更多功能
集成测试它
[如上重复]

每 3 到 6 个月，我都会将完成的新功能与我的估计时间表进行比较，然后重新校准：即，制作一个新列表，列出未来几个月内要实施的最高优先级功能。

什么是正常的事件流程那一个会跟随吗？开始编码立即，写下用户故事/用例，然后进入OOA/D？

我从兼职或业余时间开始工作，以确保我有：

了解所需的功能
做出重要的架构决策
根据需要编写任何一次性原型以学习新技术

在那之后，我准备开始全职开发。

什么样的图表/建模对于这个级别是足够的？领域模型、类图等？

我根本不使用图表（UI 草图除外）。通过构建代码和重构，我能够知道/记住/重新发现/决定哪些软件组件实现了哪些功能。

【讨论】：

【解决方案3】：

似乎当我离开项目时一段时间后回来，它是很难回到我正在做的事情的节奏。

您需要更多地注释您的代码。如果你留下代码，两周后回来，不记得代码是如何工作的，你需要更多的 cmets。

如果我知道要求（此时当前时间），我要记录它们吗还是？

是的，原因与上述相同。

如何管理这些要求？

功能列表是可以的，只要您对每个功能都有足够的详细信息来记忆。

如何有效地适应他/她每个角色的时间？

将每个功能分解成越来越小的任务，直到您觉得自己可以在半天或更短的时间内完成每个任务。

什么是正常的事件流程那个会跟随？

这取决于你的开发风格。一般来说，我会遵循一个清晰而简单的架构，在可行的情况下利用软件模式，并为你的代码提供足够的单元测试。

什么是图表/建模这个级别够吗？

足够的图表/建模让您清楚地了解项目。

有哪些步骤、文档和其他需要与项目相关的活动帮助将这个项目从不切实际的，爱好项目更专业的？

除了我已经提到的以外，请确保您拥有良好的源代码控制系统和每日备份。

祝你好运！

【讨论】：

【解决方案4】：

如果您认为您有可能在该项目上工作一段时间，请先离开，然后稍后再回来...您最好的办法是处理文档就像您与一个大团队一起工作一样。

这意味着记录需求（即使它们来自您自己），编写用例（如果功能会很复杂，否则一些其他形式的文档就足够了），以及某种程度的 UML 图表（或其他特定领域图），其中可能包括活动图/类图/等。

这样，当您离开项目一段时间后，您可以回到一个有据可查的想法并从中断的地方继续。

顺便说一句，我无论如何都会尝试做这些事情中的大部分......这样，如果我发现有人有兴趣和我一起做这个项目，我可以让他们快速上手并得到他们接受我的想法。

【讨论】：

【解决方案5】：

这就是我的工作方式，YMMV：

为所有内容保留一份电子表格 - 列出您的项目以及一些顶级项目/待办事项/提醒
为您拥有或从事的每个产品/项目创建一个“项目”文件夹，并创建一个包含项目文档和代码的结构。
在此文件夹的根目录中为每个项目保留一个顶级“包罗万象”文档。在此文档中保留您的想法、研究、笔记等。

然后，如果您想井井有条，请保留一个 MS 项目文件（或类似文件）并为每个项目中的各个步骤绘制时间表。这有助于跟踪每个项目的进度并确保您不会忘记任何事情。基本上让你对自己诚实。

如果您需要跟踪为客户所做的项目工作的进度，我知道 Basecamp 是一个很好的解决方案。我目前正在为我自己的公司评估它。见 www.basecamphq.com

【讨论】：

【解决方案6】：

即使是独立开发者，您也应该至少记录项目的整体功能，然后是您正在努力完成的特定功能的要求，然后可能会为您正在开发的功能生成一个简短的伪代码目前正在处理中。

这样，如果你最终脱离了那个项目，你可以很容易地回到它，看看你在做什么。出于同样的原因，在细节上过于超前也是没有意义的。

对于独立开发者来说，它也是一个简洁的激励工具 - 完成并打勾是一种显示进度的方式 - 当你咀嚼几千行时，你会开始觉得你没有做到这一点的代码，看起来你离真正完成“模块 x”还有很长的路要走。

最后 - 关于代码 cmets - 我至少尝试在大纲中填写新函数应具有的操作/行为，然后在 cmets 之间编写代码。此外，用简单的英语解释为什么要在 if/else 中分支以支持条件中的逻辑很有用...

【讨论】：

【解决方案7】：

我相信，通过适当的工具支持和任务来弥补其他人的不足并帮助安排工作时间，一个人可以在单独开发中获得更好的结果。任何能够以最小的创建时间成本生成描述您的软件的元数据的工具都会有所帮助。

用于跟踪用户活动/代码更改历史记录的 VCS 和工具 - 添加良好的提交消息非常重要
用于存储项目相关数据的思维导图工具（例如 XMind），blacboard 也很有用:)
时间跟踪工具（例如 Toggl.com）
写很多acceptance test 并使用验收测试框架

当然，这些线索也适合非单独开发:)

【讨论】：

我很惊讶良好的提交消息非常重要。在签到之前，我会检查新旧之间的差异，但除了在一个单独的项目中，我认为我从未阅读过修订历史或提交信息。你什么时候阅读提交信息，为什么？
首先，当您在项目上调用“日志”时，您会看到提交和 cmets 的列表 - 这就是您的积压工作。如果您想了解更改的详细信息，请执行 diff。添加提交消息始终是一个好习惯。

【解决方案8】：

作为一个单独的开发人员，我发现您的时间非常昂贵。这意味着你必须平衡可持续性和动力——即使你只是一个人，你也必须做一些事情，以便从现在起六个月后你可以回去看看旧的东西而不会浪费时间，也不会花费太多时间来维护它会影响您的流程。

您的问题表明您正在考虑相当重量级的工具和流程，但适用 80/20 规则 - 例如，您可以通过 TDD 很好地确定文档，使用您平台的文档工具生成 API 文档，以及一个用于规范、列表等的 Wiki。

因此，我建议您谨慎选择平台。关于建模的问题表明您正在使用一个产生大量代码和工件的平台，但您可能能够以更少的管理开销获得大部分功能。今天我正在开发一个我编写的“正确方式”的 .NET Web 应用程序，但现在我意识到，在这种情况下，通过使用 PHP 和 PHP MVC 框架来保持结构简洁，我可以更有效地提供相同的功能.

我推荐的具体工具：

分布式版本控制系统（开销远低于集中式）
您可以使用的最轻量级的平台，具有良好的工具
一个可轻松捕获和维护大小内容的 Wiki
从项目开始就可以使用任何测试框架
一个轻量级的 TODO 列表系统，您可以从任何地方访问

【讨论】：

【解决方案9】：

我曾经在一个非常小的团队（一名 dba 和一名 C# 开发人员）工作。即便如此，我发现编写需求、正式测试、源代码控制和错误跟踪（我们对我们的功能和错误都使用错误跟踪）非常有用。它帮助我们不要忘记任何事情，一年后，当您进行维护时，您需要研究一些东西来帮助您了解自己所做的事情。另外，当我们两个人离开时（因为大多数人最终会继续前进），那里有下一个人的文件。

【讨论】：