15

有哪些针对小型项目的独立开发人员编程方法?

4

9 回答 9

24

除了那些明确需要团队的开发方法(例如并行编程)之外,几乎任何开发方法都可以在单独的环境中工作。但即便如此,你也可以通过创造一些想象中的朋友/队友或发展多重人格障碍来解决这个问题。

于 2009-06-12T14:59:44.580 回答
12

即使作为单独的开发人员,您也可以使用适用于大型开发团队的方法。

  • 编写规范。
  • 布局 UML。
  • 进行纸笔用户界面设计。
  • 走廊测试:如果您预计会有大量人群,请询问妈妈是否易于使用。
  • 同行评审:您可以与其他独立开发人员建立临时评审团队。
  • 保持最新的时间表。
  • 等等...

我一直在独自发展,这些实践使我与自己的工作保持一致,并为我的老板提供了一个很好的资源,让他们知道我做了什么以及我走了多远。他们让我走上正轨,开机!

于 2009-06-12T14:59:22.367 回答
12

想到橡皮鸭方法:http: //lists.ethernal.org/oldarchives/cantlug-0211/msg00174.html

于 2009-06-12T14:59:51.133 回答
9

许多敏捷技术在单独使用时效果很好:

  • 用户访谈和故事:如果您不知道用户想要什么,为什么您的软件会有用?
  • 一个简单的规格:或者甚至只是一个使命宣言。“让人们向他们的订阅者列表广播短消息。” “使用入度对互联网搜索结果进行排序。” “让人们协作回答编程问题。” 任何。
  • 严格排序的待办事项列表:有助于防止您沉迷于思绪。
  • 切线日志:一个好的待办事项清单有一个“不做”的部分,所以你不会沉迷于你(还)不打算做的事情。
  • YAGNI:保持目标。这在您自己工作时非常重要,因为没有人会告诉您“不!不要在 Java 中重新发明动态类型!回到项目中。” To-don't 列出对此的帮助。
  • 测试驱动开发:编写测试迫使您考虑最终结果,而不是陷入实现细节。无论如何,您都会陷入困境;没有必要让它变得更糟。
  • 频繁发布:让自己遵守最后期限。“我们将在周五发布一个功能完整的版本,其中包括用户故事 1-4。它不会连接到网络或将数据保存到磁盘,但是 XYZ...”
  • 用户测试:让你的朋友定期查看你正在做的事情——可能每月一次,也可能每周一次,这取决于你有多少朋友以及你想喂他们多少啤酒/比萨饼。在使用该软件时,请密切注意他们所说的、所做的和所想的。

其他似乎只在大型项目中才有意义的事情会大有帮助:

  • 源代码控制:安装git。这很简单。用它。不要沉迷于它。
  • 异地备份:你知道。如果发生房屋火灾或洪水。
  • 一个博客:但是只有当发布发布时你才被允许在那里写作。;) 还可以帮助您在产品发布之前为您的产品建立受众群体。

希望这可以帮助!大型项目的单独编程可能非常艰巨。

于 2009-06-12T15:31:13.147 回答
7

请遵循此 Stack Overflow 问题中的说明:

哪些工具/技术可以使独立开发人员受益?

还。使用源代码管理。你不会相信有多少次我在个人项目中被这个问题所困扰。

于 2009-06-12T14:59:28.340 回答
2

有这个:

http://en.wikipedia.org/wiki/Personal_Software_Process

这可能是矫枉过正

于 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 回答