关于方法论：自行开发

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

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

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

谢谢。

---

靠自己开发软件非常困难，要有另一个人来激发思想，这会使事情变得更加轻松/更加令人满意。但是，这里有一个关键点-另一个人实际上不必完全了解您的工作。简单地向他人解释事物通常可以使您洞悉自己在做什么。

我曾经和推荐"与泰迪说话"的人一起工作-即选择您最喜欢的毛绒玩具(宾基先生)，向宾基先生解释您正在使用的新RESTful API的来龙去脉。拍打着你的脑袋，灵感一闪而过。"嘎，我知道我需要在那里的另一种资源，谢谢宾克斯特！"

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

对于更合理的方法，您是否不能与另一个开发人员结成松散的联盟，使您的项目彼此退缩，即使您随后又回到孤立的状态下工作呢？

---

不要陷入不编写代码的陷阱！我认为，这是很容易忘记的建议之一，因为，嘿，您自己写了can，所以您应该知道它的作用，对吗...错！只需拿起您过去的一个项目并弄清楚它们是如何工作的，而无需使用任何文档，这就像在阅读其他(错误的)代码一样。

我总是鼓励自己使用标准的文档样式，例如Javadoc的javadoc或等效的.NET代码，但是实际上任何一种文档都比没有文档更好。

---

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

与某人(任何人)讨论您的工作。我妻子的眼睛很快就呆呆了，但她想问清楚一些问题。通常，这些问题毫无意义，但我假装她是我的老板，无论如何都会回答。我以这种方式找到了各种解决方案。

对于一个1人的团队来说，开发方法大部分是过大的。不过，我采用了一些敏捷实践。首先，在不超过半天的时间内，估计所有事情。其次，将您的工作分成三到四周的小"冲刺"。我使用FogBugz进行所有估算和安排(有一个针对1-2人的免费托管版本)。

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

---

使用版本控制，总是把代码的编译工作放在最低限度，并总是签到。我在一个较大的组织中相对隔离地工作了很多年，我自然地采用了通常称为敏捷开发实践的方法。无论工作多么艰巨，重构并重复，都可以使工作正常。

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

我同意"实用程序员"是一本好书。

---

查看Joel测试。以独立开发人员的身份实施这些实践一直是一项艰巨的挑战。

---

大多数方法中的很大一部分实际上是在定义您如何团队协作。敏捷/极端编程等的很大一部分是关于沟通，建立团队环境以及更多的东西。如果您独自工作，某些事情会更容易一些，而某些事情(例如，配对编程)会更困难。

尝试阅读一些方法，并选择您认为需要的实践。如果您是一个单人团队，那么您将拥有非常灵活的优势。因此，请不要仅仅为了遵循一种使大型团队协同工作的方法而放弃它。因此，仅选择您真正需要的实践。像TDD这样的可扩展性和可重复使用的特性是低下的果实。只是不断评估您的工作并不断改进。

---

当您是唯一从事项目/问题工作的人时，沟通应该很好，因此并不需要正式的手续。但是，正如其他帖子中所提到的那样，诸如版本控制之类的良好做法仍然适用。跳出别人的想法对我来说也很关键。

虽然单独工作时沟通不是问题，但我发现在某些情况下使用便利贴和制作个人Scrum板很有帮助。最近，我刚从一家以团队为中心的公司转移到距离这很远的公司，这是一个艰难的过渡。

只是关于如何解决问题的另一种思路……《概念性重击》一书对如何更好地解决问题有一些很好的观察。

---

凯尔

旧的通过文件唤醒中的注释向自己解释吗？令我震惊的是，前几天我在一些旧代码的顶部看到了这个注释：

---

似乎您已控制了代码部分，但仅由于您是唯一的开发人员，您需要管理与用户，管理层，网络管理员等的合作方式。我是公司唯一的程序员，但始终如一在给定的项目上与他人互动。他们可能对文档，需求收集，测试和调试更感兴趣。

---

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

当您将事情从清单上划掉时，它还会给您带来温暖的模糊感。我将其视为TODO列表的扩展。

---

如果您认为这种做法不太理想，并且还有其他人也有同样的想法，为什么不开始合作呢？如果您的公司特别怪异并且不想让开发人员互相学习，那么我认为您应该认真考虑其他工作：在这种环境下，您可能不会达到最佳状态。

现在，我已经建议您问错了一个问题；)C2 Wiki上的开发人员敏捷敏捷性是一个很好的起点

---

当我担任贷款开发人员时，我会使用XP，再加上Joel将事情做完的时候，如果您只是个粗俗的文章，那我就会陷入困境。

我将其视为一项学习练习，如果可以证明应用"最佳实践"具有良好的投资回报率，我可以将其融入团队。尽管这是给优秀开发人员的，但仍然需要加以证明；至少根据我的经验

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

---

我认为大多数"成熟"的开发方法(例如xp等)都集中在引导和简化团队成员之间的沟通上。

如果在"单人"团队中进行开发，那么与自己进行日常的Scrum会议是没有好处的；-)因此，如果坚持"使用版本控制"这样的最佳做法就足够了。"等书籍。"实用程序员"和"送货！"无论您是团队合作还是单独工作，都可能使您对一些值得遵循的实践有一个很好的了解。至少是为我做的。

需要明确的是，在开始编码之前，您需要为项目准备某种结构或计划，但是诸如简单的待办事项清单和计划的软件设计的原始草图之类的东西就可以了。

---

@reefnet_alex

您是绝对正确的-清晰的表达过程，即使是您自己还是毛绒玩具，对于思考问题也非常棒。就个人而言，在尝试解决问题时，我会在文件中键入类似博客的独白。这具有我需要时可以引用它的额外好处。

至于其他策略，我发现最好的方法是维护TODO列表。如果我被一件事卡住了，我就移到待办事项列表上的另一件事上。

---

非常感谢您的提示：

• 我尝试使用通用标准尽可能地记录我的代码。我试着想到那个可怜的家伙，也许有一天他会来并必须维护我的代码(谁知道，也许那个家伙可能是我！)。

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

• 单元测试(这不是第三个支柱吗？)...嗯...我根本不做任何单元测试:(，这是我想为将来的项目更改的一件事。

• 当我设计时，我会尝试记录所有内部想法(这或多或少就像和您的泰迪熊说话，不是吗？)。

• 我也有一个待办事项清单。我想知道是否有一些应用程序(或Web应用程序)可以更好地监视所有这些任务。

我将研究一些现代方法论，并尝试将一些技术结合到我自己的方法论中。这似乎真的很有趣。

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

---

个人软件流程

---