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

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

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

谢谢。

解决方案

回答

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

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

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

使用更合理的方法，我们是否可以与其他开发人员组成松散的联盟，使项目彼此退缩，即使我们随后又回到孤立的状态下工作呢？

回答

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

如果我们是由"单人"团队开发的，那么与自己进行日常的Scrum会议是没有好处的；-)因此，如果坚持"使用版本控制"这样的最佳做法就足够了。 "等书籍。"实用程序员"和"运送它！"无论我们是团队合作还是单独工作，都可以为我们提供一些值得遵守的实践的良好概述。至少是为我做的。

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

回答

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

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

回答

当我担任贷款开发人员时，我会使用XP，再加上Joel将事情做完的时候，如果我们只是个粗俗的文章，我会变得直截了当。

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

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

回答

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

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

回答

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

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

回答

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

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

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

回答

@reefnet_alex

我们说得对，这是绝对正确的，即使是我们自己还是毛绒玩具，也可以很好地考虑问题。就个人而言，当尝试解决某些问题时，我会在文件中键入类似博客的独白。这具有我需要时可以引用它的额外好处。

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

回答

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

与某人(任何人)讨论我们正在从事的工作。我妻子的眼睛很快就呆呆了，但她想问清楚一些问题。通常，这些问题没有道理，但我假装她是我的老板，无论如何都要回答。我以这种方式找到了各种各样的解决方案。

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

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

回答

凯尔

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

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

回答

当我们是唯一从事项目/问题工作的人时，沟通应该很好，因此并不需要手续。但是，如其他文章所述，良好的做法(例如版本控制)仍然适用。跳出别人的想法对我来说也很关键。

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

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

回答

非常感谢提示：

• 我尝试使用通用标准尽可能多地记录我的代码。我试图想到这个可怜的家伙，也许有一天他会来并必须维护我的代码(谁知道，也许那个家伙可能是我！)。
• 我使用源代码控制。对我来说这是必须的，没有它我就无法工作。
• 单元测试(这不是第三个支柱吗？)...嗯...我根本不做任何单元测试:(，这是我要为将来的项目更改的一件事。
• 当我设计时，我会记下我所有的内部想法(有点像和泰迪熊说话，不是吗？)。
• 我也有一个待办事项清单。我想知道是否有一些应用程序(或者Web应用程序)可以更好地监视所有这些任务。

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

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

回答

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

回答

我之前曾问过类似的问题，我们可能会在这里找到一些好的答案。

回答

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

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

回答

个人软件流程

回答

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