在我的公司，每个开发人员都被分配了一个单独工作的项目，因此几乎没有任何团队合作。一年来，我一直在构建这样的软件，但没有遵循良好的开发方法。结果还可以，但我想改变并开始为我的下一个项目使用更严肃的开发方法。
您认为自行开发软件的最佳实践是什么？我可以使用哪些方法来避免软件开发中的常见陷阱？哪些软件开发模型（瀑布-我在开玩笑-、极端、敏捷等）最适合我？
如果您向我指出一些资源或教程，我将非常高兴，我可以在其中学习如何成为一名更好的开发人员:)
谢谢。
【问题讨论】：
标签： methodology
似乎您可以控制代码部分，但仅仅因为您是唯一的开发人员，您需要管理您与用户、管理、网络管理员等的合作方式。我是我们公司唯一的程序员，但在给定的项目上不断与他人互动。他们可能对文档、需求收集、测试和调试更感兴趣。
【讨论】：
我建议除了使用 SCM 之外，还可以使用问题跟踪器。即使您最终可能会花费更多时间添加需要完成的事情，但它提供了您进度的具体记录，并且比您的修订控制中的变更日志更易于遵循。
当你从清单上划掉一些东西时，它也会给你带来温暖的模糊感。我将其视为 TODO 列表的扩展。
【讨论】：
查看The Joel Test。作为独立开发者实施这些实践是一项有益的挑战。
【讨论】：
非常感谢您的提示：
我尝试使用通用标准尽可能多地记录我的代码。我试着想想也许有一天会来维护我的代码的可怜人（谁知道呢，也许那个人可能就是我！）。
我使用源代码管理。这对我来说是必须的，没有它我就无法工作。
单元测试（这不是第三个支柱吗？）...嗯...我根本不做任何单元测试:(，这是我想改变的事情之一用于未来的项目。
当我设计时，我会尝试记下我所有的内心想法（这或多或少像是和你的泰迪熊说话，不是吗？）。
我还有一个 TODO 列表。我想知道是否有一些应用程序（或 Web 应用程序）可以更好地监控所有这些任务。
我将研究一些现代方法，并尝试将一些技术融入我自己的方法中。 This 看起来很有趣。
现在我也在考虑在我的机器上安装巡航控制系统，但这对我来说真的值得吗？
【讨论】：
当您是唯一一个处理项目/问题的人时，沟通应该很好，因此不需要手续。但是，正如其他帖子中提到的，版本控制等良好实践仍然适用。事实证明，从别人那里汲取灵感对我来说也很重要。
虽然单独工作时沟通不是问题，但我发现在某些情况下使用便利贴和制作个人 Scrum 板很有帮助。我最近刚从一家以团队为导向的公司跳槽到远离团队的公司，这是一个艰难的过渡。
关于如何解决问题的另一个想法……Conceptual Blockbusting 这本书对如何更好地解决问题有一些很好的观察。
【讨论】：
@凯尔
老人通过文件中的注释向自己解释，是吗？令我惊恐的是，前几天我在一些旧代码的顶部看到了这条评论：
/*
bloody hell - where to start...
*/
【讨论】：
多年来，我一直在自己工作。首先是作为一组机械工程师的一部分。现在在我自己的项目上。我同意上面的答案：
与某人（任何人）谈论您正在从事的工作。我妻子的眼睛很快就呆住了，但她试图问清楚问题。通常这些问题毫无意义，但我假装她是我的老板并回答他们。我可以通过这种方式找到各种解决方案。
开发方法对于 1 人团队来说大多是矫枉过正。不过，我已经采用了一些敏捷实践。首先，在不超过半天的一小段时间内估计所有事情。其次，将你的工作分成三到四个星期的小“冲刺”。我使用 FogBugz 进行所有估算和调度（有一个免费的托管版本供 1-2 人组使用）。
不要忘记代码文档、源代码控制和单元测试的基本要素。我分别使用 Doxygen、Subversion/TortoiseSVN 和 NUnit。
【讨论】：
我认为大多数“成熟”的开发方法（如 xp 等）都侧重于引导和简化团队成员之间的沟通。
如果您在“单人”团队中发展，那么与自己进行日常 Scrum 会议等没有任何好处；-) 因此，如果您坚持一些最佳实践，例如“使用版本控制”等书籍“实用程序员”和“Ship it！”无论您是在团队中还是单独工作，都可能让您对一些值得坚持的做法有一个很好的了解。至少为我做了。
为了清楚起见，在开始编码之前，您需要为您的项目制定某种结构或计划，但类似简单的待办事项列表和计划软件设计的原始草图之类的东西就可以了。
【讨论】：
@reefnet_alex
您说的完全正确 - 即使是对自己或毛绒玩具，清晰表达的过程也非常适合思考问题。就个人而言，我在尝试解决问题时会在文件中键入类似博客的独白。这有一个额外的好处，当我需要时可以参考它。
就其他策略而言，我发现最好的办法是维护一个 TODO 列表。如果我在一件事情上卡住了，我就会转移到待办事项清单上的其他事情上。
【讨论】：
使用版本控制，始终将代码编译的时间留到最少，并始终签到。我在一个较大的组织中相对孤立地工作了多年，我自然而然地应用了更常见的敏捷开发实践。不管多么粗糙，重构，然后重复。
保持稳定状态有很大帮助，这意味着当您可以与某人互动时，您可以展示一些东西，而不是收集一些想法和抽象概念。
我同意“实用程序员”是一本很好的读物。
【讨论】：
大多数方法实际上是在定义如何作为一个团队一起工作。敏捷/极限编程等的很大一部分是关于沟通，建立你的团队环境等等。如果你独自工作，有些事情会更容易，有些事情（例如结对编程）会更难。
尝试阅读一些方法并选择您认为需要的实践。如果您是一个单人团队，那么您将拥有非常灵活的奢侈。因此，尽量不要仅仅为了遵循一种旨在让大型团队一起工作的方法而放弃这一点。所以只选择你真正需要的做法。像 TDD 和迭代工作这样的细枝末节是唾手可得的成果。只需不断评估您的工作并不断改进即可。
【讨论】：
如果您觉得这种做法并不理想，而其他人也有同样的感受，为什么不开始合作一点呢？如果你的公司特别奇怪并且不想让开发人员互相学习，那么我认为你应该认真考虑替代工作：在这样的环境中你可能不会成为最好的。
现在我已经建议您提出错误的问题了；）C2 Wiki 上的独立开发者敏捷性是一个很好的起点
【讨论】：
当我作为贷款开发人员工作时，我使用 XP，再加上 Joel 的工作，当你只是一篇让我保持直截了当的繁琐文章时。
我将其视为一种学习练习，如果我能证明应用“最佳实践”具有良好的投资回报率，我就可以融入团队。虽然是为优秀的开发人员提供的，但仍然需要证明；至少根据我的经验。
后来我使用了一个定制的敏捷过程，它更符合我工作的公司的政治。
【讨论】：
不要陷入不记录代码的陷阱！我认为，这是很容易被遗忘的建议之一，因为，嘿，你自己写了可能，所以你应该知道它的作用，对吧？......错了！只需拿起您过去的一个项目，并在不使用任何文档的情况下弄清楚事情是如何工作的，这就像阅读其他人的（糟糕的）代码。
我总是鼓励自己在代码中使用标准文档样式，例如用于 java 的 javadoc 或用于 .NET 的等效代码，但实际上任何类型的文档都比没有文档要好...
【讨论】：
自己开发软件非常困难，让另一个人来思考想法会让事情变得更容易/更令人满意。但是，这里的关键是——其他人并不一定要完全适应你正在做的事情。简单地向其他人解释事情通常会让你深入了解自己在做什么。
我曾经与建议“与泰迪说话”的人一起工作 - 即选择您最喜欢的毛绒玩具（宾基先生），向宾基先生解释您正在开发的新 RESTful API 的来龙去脉。突然灵光一闪，拍拍你的脑袋——“哎呀，我知道我需要另一个资源，谢谢宾克斯特！”。
请注意，我不确定同事的理智...
如果采用更合理的方法，您是否不能与另一位开发人员建立松散的联盟，让您的项目相互反弹，即使您随后又回到孤立的工作状态？
【讨论】：