有哪些针对小型项目的独立开发人员编程方法？
问问题
4506 次
9 回答
24
除了那些明确需要团队的开发方法（例如并行编程）之外，几乎任何开发方法都可以在单独的环境中工作。但即便如此，你也可以通过创造一些想象中的朋友/队友或发展多重人格障碍来解决这个问题。
于 2009-06-12T14:59:44.580 回答
12
即使作为单独的开发人员，您也可以使用适用于大型开发团队的方法。
- 编写规范。
- 布局 UML。
- 进行纸笔用户界面设计。
- 走廊测试：如果您预计会有大量人群，请询问妈妈是否易于使用。
- 同行评审：您可以与其他独立开发人员建立临时评审团队。
- 保持最新的时间表。
- 等等...
我一直在独自发展，这些实践使我与自己的工作保持一致，并为我的老板提供了一个很好的资源，让他们知道我做了什么以及我走了多远。他们让我走上正轨，开机！
于 2009-06-12T14:59:22.367 回答
12
于 2009-06-12T14:59:51.133 回答
9
许多敏捷技术在单独使用时效果很好：
- 用户访谈和故事：如果您不知道用户想要什么，为什么您的软件会有用？
- 一个简单的规格：或者甚至只是一个使命宣言。“让人们向他们的订阅者列表广播短消息。” “使用入度对互联网搜索结果进行排序。” “让人们协作回答编程问题。” 任何。
- 严格排序的待办事项列表：有助于防止您沉迷于思绪。
- 切线日志：一个好的待办事项清单有一个“不做”的部分，所以你不会沉迷于你（还）不打算做的事情。
- YAGNI：保持目标。这在您自己工作时非常重要，因为没有人会告诉您“不！不要在 Java 中重新发明动态类型！回到项目中。” To-don't 列出对此的帮助。
- 测试驱动开发：编写测试迫使您考虑最终结果，而不是陷入实现细节。无论如何，您都会陷入困境；没有必要让它变得更糟。
- 频繁发布：让自己遵守最后期限。“我们将在周五发布一个功能完整的版本，其中包括用户故事 1-4。它不会连接到网络或将数据保存到磁盘，但是 XYZ...”
- 用户测试：让你的朋友定期查看你正在做的事情——可能每月一次，也可能每周一次，这取决于你有多少朋友以及你想喂他们多少啤酒/比萨饼。在使用该软件时，请密切注意他们所说的、所做的和所想的。
其他似乎只在大型项目中才有意义的事情会大有帮助：
- 源代码控制：安装git。这很简单。用它。不要沉迷于它。
- 异地备份：你知道。如果发生房屋火灾或洪水。
- 一个博客：但是只有当发布发布时你才被允许在那里写作。;) 还可以帮助您在产品发布之前为您的产品建立受众群体。
希望这可以帮助！大型项目的单独编程可能非常艰巨。
于 2009-06-12T15:31:13.147 回答
7
于 2009-06-12T14:59:28.340 回答
2
于 2009-06-12T15:01:07.027 回答
1
问题更多是关于您对什么感到满意以及您希望解决什么问题的问题。大多数方法都是由独立开发人员在某些时候使用的（结对编程是一个明显的例外）。问题是你真的是一个人，还是一个人工作？我发现让我可以从中汲取灵感的人是非常宝贵的。此外，让其他人查看您的代码（同行评审）是找到您无法“看到”的问题的好方法。所以同意 Aiden Bell的观点“在你的 oen 上编程很不酷”。 我会尝试连接到一个社区（比如 SO），在那里你可以从其他人那里获得想法。然后，您需要以这样一种方式构建您的方法论，以便在您发送想法时允许中断。
那有意义吗？为什么你一个人编程？
帕特奥
于 2009-06-12T15:20:55.560 回答
1
不是真正的官方方法，但我已经做了很多单独的开发（独立顾问和 ISV），以下是我发现重要的事情：
- 寻找在线组织（如 oisv.com）来分享想法和想法
- 确保您花时间与现实世界中的真实人物互动
- 设定项目目标、截止日期和里程碑
- 花时间进行适当的前期设计和项目规划
- 留出工作时间是坚持他们
- 不要工作太多，让自己筋疲力尽
- 没有什么是完美的，所以努力工作的好代码，而不是完美
- 获得一些非编程爱好
于 2009-06-12T15:29:46.863 回答
1
这更像是一种技巧而不是一种方法。当你在调试时，大声地向自己解释错误，就像你试图向同事解释一样。这感觉很愚蠢，但强迫自己大声说出问题通常会揭示问题所在。
于 2009-06-12T15:58:06.140 回答