有用和无用的现实生活开发技巧

Question

我在一家中型/大型公司工作，这家公司遵循我认为的一些良好的开发实践，可能不是最好的，但足够好。

我们有一些开发资源可以在“执行，测试，如果它有用的情况下实现，或者扔掉”的基础上实现。我发现大多数所谓的最佳实践有时在理想情况下非常好，但在现实生活中是不可行的甚至是有害的。

例如，我们使用dotproject网站为我们的团队。想法是跟踪任务，更新进度等。我们使用了“do，test，if”，结果是......我们把它扔掉了，只是保留了对我们之间进行沟通极其有用的论坛，并跟踪会议和待办事项列表的结论......另一方面，跟踪每项任务既费时又不现实。

所有人都没有这样做，它没有花费很多时间，但开发人员讨厌它并让他们不高兴，因为他们必须记住更新每项任务，对任务时间的估计被证明是不切实际的当时。

所以我的问题是，您尝试了哪些开发技术并发现有用/无用？

我的意思是，就像现实生活中一样，不是一些理论上的最佳实践，而是一种实践经验。我正在寻找新的技术（或工具或其他），我想知道下一步该做什么。我们目前的状态：

• 内部问题跟踪系统（有用）
• 半自动构建（每个开发人员必须维护一个makefile的等效项，以便系统能够制作它们）。
• 没有自动化测试。测试由测试团队执行。我们有集成测试和广泛的系统测试。
• 两个测试实验室，一个用于测试团队，另一个用于开发人员（如果他们需要执行涉及多台机器的测试或测试开发机器）
• 一般不进行单元测试。有些图书馆有它们，但通常开发人员会根据需要测试它的单位。
• 使用DOOR进行全面规范。
• 测试协议。正式的，用Word写的。
• 源控制（清除案例）。通常一切都在主分支中完成，每当我们发布它被标记的版本时，如果需要，就会修复该版本的分支。

注意：如果可以（如果您不介意：P），您是否可以尝试为您的提案辩护？它是如何以及为何有用？怎么改善你的工作？

Answer 1

我们介绍的最有用的东西之一就是一个项目Wiki，这是一个非常有用的倾倒场，可以解决人们脑海中浮现的所有小信息，但是在完整的文档中记录这些信息太过微不足道了。

Answer 2

参与了各种不同方法的开发团队，我的经验是大多数敏捷原则都很有效。它通常使开发更有趣，因为每个人都更加投入。在较大的开发环境中，协同定位所有团队成员的基本原则带来了巨大的好处，特别是当您在开发人员旁边有独立的信息分析师和测试人员时。让信息分析师，测试人员和开发人员按功能协同工作。这样可以创建最佳的信息流，并尽可能减少开销。您可以进一步采用Lean development process。

总的来说，给我们带来最大好处的是降低沟通障碍的事情。从实际意义上讲，公司wiki也帮助了很多，降低了共享信息的障碍。一个好的错误/功能/ RFC跟踪工具也有助于让利益相关者共同了解项目的方向。而这样的跟踪工具不仅必须是内部的：降低客户的障碍。这也有助于管理期望。

我觉得我刚刚开始在这里。其他人无疑会提出更多建议。

帕斯卡。

Answer 3

关注this link ... 就个人而言，作为开发人员，我更喜欢专注于提高我的表现的事情。我不介意检查一些错误报告网站以检查是否报告了新错误，但我需要能够快速查看它而无需经过几十页或几十次点击。 我不介意在编写代码之前编写技术设计，只要我有正确编写它的工具。必须创建这些工具以提高性能，同时尽量减少任何人无法使用的蓬松功能。例如，在过去，我曾使用Enterprise Architect在编写代码之前创建UML模型。它工作正常，但应用程序有一些我不需要的缺陷和许多功能。当我发现Altoma UModel时，我很快就变成了一个更精简的UML生成工具，它正是我所需要的。没有更多，没有更少。 基本上，你必须让人们专注于最终目标。最终目标是创建一些供用户使用的产品。许多开发团队迷失了，因为他们专注于其他事情。您的用户都不会关心您如何创建他们使用的东西。他们只需要您的项目来实现他们的目标。 因此，最佳做法是让您的团队最舒适，包括任何加入任何项目中途的新团队成员。

Answer 4

就个人而言，我是自动测试（单元测试和集成测试）的忠实粉丝。在我看来，它就像一个安全网 - 开发人员在更改代码时感觉更安全，因为当他们知道有一个测试工具可以抓住它们时会破坏它们。这样可以更快地引入新功能，但也可以消除重构的“恐惧”，例如。

Answer 5

作为我们团队的管理人员：SCRUM