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