自己开发

Question

在我的公司里，每个开发人员都有一个独立工作的项目，因此几乎没有任何团队合作。一年以来，我一直在构建这样的软件，没有良好的开发方法学科。结果还可以，但我想改变并开始为我的下一个项目使用更严肃的开发方法。

您认为自行开发软件的最佳做法是什么？我可以使用哪些方法来避免软件开发中常见的陷阱？什么模型的软件开发（瀑布 - 我是开玩笑，极端，敏捷等）最适合我？

如果您向我指出一些我可以学习如何成为更好的开发人员的资源或教程，我会非常高兴。）

感谢。

Answer 1

自己开发软件非常困难，让另一个人反复思考，让事情变得更容易/更令人满意。但是，这是踢球者 - 其他人并不一定非常关注你正在做的事情。简单地向其他人解释事情通常可以让您深入了解自己在做什么。

我曾经和推荐“和泰迪说话”的人一起工作 - 即选择你最喜欢的毛绒玩具（Binky先生），解释你正在为Binky先生制作的新RESTful API的细节。 S as as as as as as - - - - - - - “”“”“”“”“”“”“”“”“”“”“”“”“”“”“

请注意，我不确定同事的理智......

对于一个更合理的方法，你不能与另一个开发人员形成一个松散的联盟，你将项目互相反弹，即使你再回到孤立的工作中去了吗？

Answer 2

不要陷入不记录代码的陷阱！我认为，那是很容易被遗忘的建议之一，因为，嘿，你自己写了这个，所以你应该知道它做了什么，对吧？......错了！只需选择一个过去的项目，并在不使用任何文档的情况下弄清楚事情是如何工作的，就像读别人（坏）代码一样。

我总是鼓励自己使用标准文档样式，例如java的javadoc或代码中.NET的等效文档，但实际上任何类型的文档都没有... < / p>

Answer 3

多年来我一直在做自己的工作。首先作为一组机械工程师的一部分。现在我自己的项目。我同意上面的答案：

与某人（任何人）讨论您正在做的事情。我妻子的眼睛很快就凝视着，但她试图提出澄清问题。通常问题没有意义，但我假装她是我的老板并且无论如何都要回答它们。我找到了各种各样的解决方案。

对于一人团队来说，开发方法主要是矫枉过正。我采用了一些敏捷实践。首先，估计一小部分时间内的所有内容不超过半天。其次，将你的工作分成三到四周的小“冲刺”。我使用FogBugz进行所有估算和调度（有1-2人组的免费托管版本）。

不要忘记代码文档，源代码控制和单元测试的基本要素。我分别使用Doxygen，Subversion / TortoiseSVN和NUnit。

Answer 4

使用版本控制，始终将代码编译作为最低限度，并始终检入。我在一个更大的组织中相对孤立地工作多年，我自然地应用了更常见的敏捷开发实践。无论多么粗糙，重构和重复，都能得到一些有用的东西。

维持一个稳定的状态有很大帮助，这意味着当你可以与某些人进行互动时，你需要展示一些东西，而不是一堆想法和抽象概念。

我同意“实用程序员”是一本很好的读物。

Answer 5

大多数方法的很大一部分实际上是定义如何作为一个团队一起工作。敏捷/极端编程等很大一部分是关于沟通，建立你的团队环境以及更多的东西。如果你独自工作，一些事情会变得更容易，而某些事情（例如结对编程）则更难。

尝试阅读几种方法并选择您认为需要的实践。如果你是一个单人团队，你就会非常灵活。所以尽量不要只是为了遵循一种方法，让大型团队协同工作。所以只能选择你真正需要的做法。像TDD这样的东西和迭代工作都是低调的结果。只要继续评估你的工作并不断改进。

Answer 6

结帐The Joel Test。作为独立开发人员实施这些实践是一项有益的挑战。

Answer 7

似乎你已经控制了代码部分，但仅仅因为你是唯一的开发人员，你需要管理你如何与用户，管理人员，网络管理员等合作。我是我们公司唯一的程序员，但在给定项目上不断与他人互动。他们可能对文档，需求收集，测试和解决方案更感兴趣。调试。

Answer 8

我建议除了使用SCM之外，还要使用问题跟踪器。即使您可能花费更多时间添加需要完成的事情，但它提供了一个具体的进度记录，其格式比修订控件中的更改日志更容易理解。

当你从列表中删除东西时，它也会给你温暖的模糊。我将其视为TODO列表的扩展。

Answer 9

我问a similar question before，你可能会在那里找到一些好的答案。

Answer 10

当你是唯一一个从事项目/问题工作的人时，沟通应该是好的，所以手续并不是必需的。但是，正如其他帖子中所提到的，版本控制等良好实践仍然适用。事实证明，某些人的想法对我来说也很重要。

虽然单独工作时沟通不是问题，但我发现在某些情况下使用post-it和制作个人搜索板会很有帮助。我刚刚从一个以团队为导向的公司转变为一个远离它的公司，这是一个艰难的过渡。

另外一个关于如何解决方案的想法......本书Conceptual Blockbusting对如何更好地解决问题有一些很好的观察。

Answer 11

@Kyle

老人通过文件中的笔记向自己解释呃？令我恐惧的是，我前几天在一些旧代码的顶部看到了这条评论：

/*
    bloody hell - where to start...
*/

Answer 12

@reefnet_alex

你是绝对正确的 - 即使对自己或者填充玩具来说，表达的过程也很好。就个人而言，我在尝试解决问题时在文件中键入类似博客的独白。这有额外的好处，我可以在需要时再参考它。

就其他策略而言，我发现最好的办法是维护一个TODO列表。如果我被困在一件事上，我只是转移到todo列表上的其他内容。

Answer 13

如果你认为这种做法不是最佳的，并且还有其他人有同样的感觉，为什么不开始合作呢？如果你的公司特别奇怪并且不想让开发人员相互学习，那么我认为你应该认真考虑其他就业：你可能不会成为这样一个环境中最好的。

现在我已经建议你提出错误的问题了;）C2 Wiki

上的独立开发人员敏捷性有一个很好的起点

Answer 14

当我作为贷款开发人员工作时，我使用XP，加上Joel的工作已经完成，当你只是一篇笨拙的文章让我保持直线和狭窄。

如果我能证明应用“最佳实践”具有良好的投资回报率，那么我将其视为一种学习练习，我可以融入团队。虽然给予优秀的开发人员，但仍然需要证明;至少根据我的经验。

后来我使用了一个定制的敏捷流程，更适合我所工作的公司的政治。

Answer 15

我认为大多数“全面发展”的开发方法如xp等都专注于引导和简化团队成员之间的沟通。

如果你是在一个“单人”团队中发展，那么每天进行scrum会议并没有任何好处;-)因此，如果你坚持一些最佳实践，那就足够了使用版本控制“等书籍”实用程序员“和”发货！“可能会让您对一些值得遵守的实践有一个很好的概述，无论您是在团队中工作还是单独工作。至少它是为我做的。

为了清楚起见，在开始编码之前，你需要某种结构或计划，但是像一个简单的待办事项列表和计划软件设计的原始草图就可以了。

Answer 16

非常感谢你的提示：

• 我尝试使用通用标准尽可能多地记录我的代码。我试着想想那些可能有一天会来维持我的代码的穷人（谁知道，也许那个人可能是我！）。

• 我使用源代码管理。这对我来说是必须的，没有它我就无法工作。

• 单元测试（这不是第三个皮拉尔？）......好吧......我根本不做任何单元测试:(，这是我想改变的事情之一对于未来的项目。

• 当我设计时，我试着记下我所有的内心想法（它或多或少就像和你的泰迪对话，不是吗？）。

• 我还有一个TODO列表。我想知道是否有一些应用程序（或Web应用程序）可以更好地监控所有这些任务。

我将介绍一些现代方法，并尝试将一些技术融入到我自己的方法中。 This似乎非常有趣。

现在我也在考虑在我的机器上安装Cruise Control，但这对我来说真的值得吗？

Answer 17

Personal Software Process