哪个社区（语言/框架）最接受敏捷实践？ [关闭]答案

【问题标题】：Which community (language/framework) embraces agile practices the most? [closed]哪个社区（语言/框架）最接受敏捷实践？ [关闭]
【发布时间】：2009-06-02 17:38:05
【问题描述】：

我已经练习 TDD 和（一些）XP 几年了，发现它解决了我在采用它之前在我的职业生涯中遇到的许多问题。通过消除如此多的头痛，我对编码的热爱重新焕发了活力。问题是我也发现很难找到利用这些实践的 .NET（我当前的堆栈）项目。

我对 SO 社区的问题是：您认为哪些社区（语言和/或框架）最接受敏捷实践，例如 tdd、（所有的 xDD 真的）xp、ci 等？

要问这个问题，必须定义一种测量方法。我将为给定的社区/堆栈将其定义为：

（当前采用敏捷方法的项目数量）/（当前项目数量）

显然没有可能不存在的数据，这是不可能确定的……我只是在寻找人们的看法

【问题讨论】：

标签： tdd agile extreme-programming

【解决方案1】：

我在 Rails 和 Django 训练营都有所涉足。从我所见，Rails 的人真的得到了测试。他们在博客中谈论测试，在会议中谈论测试，并衍生出一些有趣的测试工具（例如，ScrewUnit）来测试他们应用程序的非 Rails 部分。成为 Rails 社区的一员而不进行测试真的很难。

Django 社区在测试方面落后。 Django 附带了对测试的基本支持，但您必须寻找它。当前的 Django 书籍中没有任何比测试脚注更多的东西，而且我很少看到来自 Django 社区成员的任何实质性的“如何测试”博客。第一届 DjangoCon 上没有关于测试的讨论。

另一方面，Rails 人员更容易因为猴子补丁和 gem 版本冲突（或 gem 或插件进行冲突的猴子补丁）而陷入混乱，因此自动化测试是必不可少的。我见过的 Django 项目之所以能够滑过，是因为让自己更难陷入同样的困境。

至于其他敏捷实践，如果不能在日常基础上窥探大量项目的内部情况，就很难说。

【讨论】：

我同意这个观察，但是，我不认为仅仅避免monkey patching 就足以成为不进行全面测试的借口。元编程与否，TDD（或一般的测试）是代码持续进化的重要必要条件。我认为我们应该承认 Django 社区通常对编写高质量代码并不真正感兴趣。
那是 2009 年的答案。变化很大。现在可用于 Django 的测试功能非常好。人们是否使用它们是一个单独的问题，并且可以在许多社区中推广，而 Django 不是必须的。

【解决方案2】：

如果说社区是关于人的，那么真正的社区是什么，这里有几个群体：

Agile Project Leadership Network 的名字暗示它采用敏捷方法。

Alt.Net 让我印象深刻，因为你可以带来各种敏捷实践并获得各种结果，因为有些人可能喜欢它们，有些人可能会遇到问题。

不过，敏捷更多地是关于流程，而不是通常的特定技术。如果您的问题更多的是关于使用敏捷的公司采用哪些技术和框架，那么在我看来，这完全是另一回事，价值值得怀疑。在我附近的阿尔伯塔省卡尔加里，拥抱敏捷的公司可能与其他公司大不相同，例如。印度班加罗尔或英国伦敦或硅谷或纽约市或华盛顿西雅图的哪些公司提供一些有开发人员工作的地点，通常除非你指的是像 Thoughtworks 这样的公司，如果你靠近他们有办公室的大城市。

另一种思路是考虑某些技术可能具有各种子社区或规模，这些子社区或规模可能会使事情变得混乱。例如，可能有许多 Java 和 .Net 开发人员拥护敏捷，但也有许多人厌恶它。如果一些公司有适合他们的瀑布方法，他们为什么要转向敏捷？同时，某些技术可能拥有非常小的社区，因此可能会以截然不同的方式看待它们。如果您认为这是一个因素，那么使用这些新兴技术的人的组织程度也很重要。

希望有人发现这个大脑转储很有趣... ;)

【讨论】：

感谢您对这个 JB 的看法。我想你可能错过了我的问题的重点。作为一名开发人员，我个人认为这些做法非常有用且富有成效。我的问题不是关于辩论敏捷实践，而是从人们的经验中得出简单的结论，以确定哪个堆栈最有可能为您提供与使用这些方法（特别是上述方法）的团队合作的最佳机会。
您的部分问题忽略了我认为的一些事情，例如地理以及您如何了解工作，假设这是您想要使用实践的地方，而不是作为业余爱好。有人可以在业余时间使用敏捷实践来改进开源软件吗？可能，但你的意思是这种情况吗？如果你把就业作为一个维度，那么就会出现一些新的问题，比如你的网络有多好，那里的招聘人员理解你所说的敏捷和寻找职位空缺的能力有多好，等等。我把它看作是一个广泛的问题感觉。 :)

【解决方案3】：

我认为这些工作流程中的任何一个都与特定语言无关，我也不认为任何语言都必然适合这些工作流程。任何与此的偏差主要是文化上的。

例如，规范的 rails 项目框架对于编写测试或使用 TDD 的障碍非常低，但没有什么能阻止您使用 NUnit 并编写 TDD .NET 项目。

以下是一些您可能有兴趣研究的 .NET 工具：

单元测试：

NUnit

持续集成：

【讨论】：

我完全同意，但这就是我问文化的原因。
@Lee：如果它与文化有关，那么你应该问：停下来衡量你所在的“社区”是否是最敏捷的，会有多敏捷。任何需要时间来衡量的社区会有多敏捷？哪个单元测试失败并让他们停下来测量？
我认为一般来说，如果一个社区更倾向于接受最近流行的实践/方法，他们也更有可能接受最近流行的语言/框架。所以，用 Ruby 做 TDD 的人比 Fortran 多。
@Anthony：这是比较 Ruby 和 Fortran 的一个非常好的观点。

【解决方案4】：

根据我有限的经验，我发现 Ruby/rail 社区一直在推动测试的前沿。引入新技术，并将 TDD 和 BDD 的概念普遍集成到大多数事物中。另一方面，PHP 有点随意。一些团体虔诚地使用它，而另一些团体似乎根本没有。 PHP 中的工具集似乎不如 Ruby 和 Rails 社区中的强大和深入。

YMMV.

【讨论】：