贵公司的软件开发真的很像（方法论，工具......）？

Question

自从我两年前开始作为专业软件开发人员的第一份工作以来，我读过许多关于普遍接受的方法（例如Scrum，XP），技术（例如EJB，Spring），技术（例如TDD）的文章软件公司的代码评论，工具（bug跟踪，维基）等等。

对于其中许多人，我发现我们公司没有使用它们，我问自己为什么。我们做错了还是仅仅是我读过的这些文章并没有真正说明它在现实世界中是什么样的？这些文章更具学术性吗？

所以，请告诉我你公司的情况。讲述有关软件开发的所有内容。以下是一些建议（按照我的想法顺序）。至少告诉你是否这样做，或者做一个简短的评论：

• 测试驱动开发
• 领域驱动-设计
• 模型驱动的设计/结构
• 你测试吗？
• 单元测试
• 集成测试
• 验收测试
• 代码评论
• 创新技术（Spring，Hibernate，Wicket，JSF，WS，REST，......）
• 敏捷
• 结对编程
• UML
• 特定于域的语言
• 要求规格（如何？）
• 持续整合
• 代码覆盖率工具
• Aenemic Domain Model
• 通讯（维基，邮件，即时通讯，邮件列表，其他文件）
• 努力估算
• 团队规模
• 会议
• 代码指标
• 静态代码分析
• 错误跟踪
• ...

请记住：我想知道你真正做了什么，而不是你想做什么或认为你应该做什么。

Answer 1

Answer 2

我认为着名的 Big Ball of Mud 模式描述了很多工作环境，并为您提供了一些关于如何对抗这种事情的好主意。

---

顺便说一句，我意识到我并没有直接回答你的问题，但是在一个令人沮丧的大部分发展情况中，大球泥流盛行。您可以询问测试驱动的开发和缺陷跟踪以及其他类似的事情，但如果从我所看到的事实中得知真相，我会说泥球的大球几乎是人们工作的事实上的方式 - 他们应该或不应该。

Answer 3

• 测试驱动开发：不。充其量只是非常微小的部分。我们都在讨论，但不要这样做。
• 域驱动设计：不。如果您正在开发技术框架，很难知道“域名”是什么。没有太多的DDD经验知道如何做到这一点。
• 模型驱动设计/架构： Nope。
• 你测试吗？：是的，但还不够。每发布一次（我们试图每8周推出一次小版本），总会有超过2个服务版本。我们正处于产品开发的第一年，所以我觉得这很好。
• 单元测试：是的。约。 30％的覆盖率。大多数开发人员现在都知道他们应该为自己编写单元测试。每次他们必须在他们自己的代码中修复一个关键错误时，他们可以看到好处，如果他们预先编写一个简单的测试来防止该错误。
• 集成测试：是的，使用Selenium和WebDriver。
• 性能测试：是的，从现在开始。目标是存档长期绩效测量并将其与版本进行比较。使用JMeter和专用的性能测试服务器。
• 验收测试：不是真的，但我们的产品也在内部使用，我们在发布之前得到的反馈非常快。我认为这是验收测试。
• 代码评论：不。有时，其他人看了30分钟，但就是这样。
• 创新技术（Spring，Hibernate，Wicket，JSF，WS，REST，......）：从我的POV来看，这些技术不再具有“创新性”。他们现在几乎都是老派。除了几年前去世的JSF。过去几年Spring + Hibernate了吗？现在做Wicket + WS 2年了。用iBatis SqlMaps替换了Hibernate。
• 敏捷：没有。
• 结对编程：没有。
• UML：一点点，主要用于部署图。类图太精细，通常与现实不同步。开发人员做他们认为最好的事情，而不是UML图表告诉他们做的事情。
• 特定于域的语言：是的，我们正在使用home-brewn业务规则技术。它是一个适合最终用户的可视DSL。有点像使用Visio来决定模型。
• 要求规格（如何？）： Nope。
• 持续整合：是的。基于Hudson和Maven。在每个构建上运行单元测试。额外的夜间构建，启用更详细的报告。整个团队都会收到关于失败的构建的通知（是的，他们抱怨有时候如果有什么东西打破链条而且所有30个子模块都会出现构建失败，例如当Maven资源库无法访问时）收到太多邮件。
• 代码覆盖率工具：是。 Maven / Cobertura和Sonar。
• 贫血领域模型：不知道这应该是什么。
• 通讯（维基，邮件，即时通讯，邮件列表，其他文件）：维基，邮件，即时消息，每日站立会议，最终用户和开发人员手册，由专业人士/非开发人员撰写。
• 努力估算：努力做好估计。但如果没有要求，它们只是粗略的估计。足够用于资源规划。
• 团队规模： 12
• 会议：每次轻微发布后每8周一次，每日立式。
• 代码指标：声纳。希望遵守大多数规则。没有时间重新配置规则以满足我们的需求。
• 静态代码分析：声纳。
• 错误跟踪： JIRA

注意：

• Sonar是一款代码质量服务器。它结合了PMD，Findbugs，Checkstyle等工具。

Answer 4

• 测试驱动开发：是
• Domain-Driven-Design：是的
• 模型驱动设计/架构：是
• 你测试吗？是
• 单元测试 - 是
• 集成测试 - 是
• 验收测试 - 是
• 代码评论 - 是
• 创新技术 - 是的
• 敏捷 - 完全敏捷
• 结对编程 - 是
• UML - 有时用于ddd白板战斗
• 特定于域的语言 - 是
• 要求规范（如何？） - 以示例和验收测试的形式
• 持续整合 - 是 - TeamCity
• 代码覆盖率工具 - 是 - NCover
• Aenemic Domain Model - 不确定
• 通讯（维基，邮件，即时通讯，邮件列表，其他文件） - wiki，mail，msn
• 团队规模 - 6+依赖项目
• 会议 - 每天早上9:30 - SCRUM
• 代码指标 - dunno
• 静态代码分析 - dunno
• 错误跟踪 - Mantis

最重要的是......

• 每个人都在5:30回家：是

然而，由于很多人想为这家公司工作，薪水很低。不能拥有一切！

Answer 5

• 测试驱动开发 - 几乎就在那里。
• 域驱动设计 - 否
• 模型驱动设计/架构 - 否
• 你测试吗？ - 是的
• 单元测试 - 是
• 集成测试 - 是
• 验收测试 - 否
• 代码评论 - 否
• 创新/新技术（Spring，Hibernate，Wicket，JSF，WS，REST，...） - ASP.NET MVC？ NHibernate的？是
• 敏捷 - 刚刚开始
• 结对编程 - 否
• UML - 没有正式的
• 特定于域的语言 - 否
• 要求规格（如何？） - 是的。捕捉故事要求。
• 持续整合 - 是的。 TeamCity的
• 代码覆盖率工具 - 是的。 NCover
• Aenemic Domain Model - No
• 通讯（维基，邮件，即时通讯，邮件列表，其他文件） - 即时通讯，电子邮件
• 努力估计 - 1,2,4,8
• 团队规模 - 4
• 会议 - 每日站立
• 代码指标 - 否
• 静态代码分析 - 否
• 错误跟踪 - 现有的自定义作业

我的部门正在进行中。在过去的几个月里，我努力实施持续改进。有些东西很难被谈论。然而，当回顾过去时，它们已经有所改善。

Answer 6

我为你感到难过:)这不是一个好的工作环境，因为你需要不断练习练习好的练习来真正理解和使用它们。

我知道有几家公司（包括我的公司）能够勾选列表中的所有“好”框。

然而，恶魔是详细的，甚至在一些具有良好SDP政策的公司中并非每个项目都遵循它们。

Answer 7

我为南非的Chillisoft.co.za工作

测试驱动开发：自从第一本强制执行的Kent Beck Book以来，我们一直在使用测试驱动开发实践。我们使用NUnit和R＃作为测试运行者。

你测试吗？：除TDD外，我们还进行手动测试（Visual），并在必要时自动进行测试。用于自动化的技术取决于UI Technologies。

单元测试：参见TDD。

集成测试：是的，但我们还没有普遍使用。

验收测试：我们为您未获得付款的外部客户进行定制软件开发，直到他们接受为止。

代码评论：每个项目预定双月刊。甚至那些已经成对/对等编程的。

配对编程：我们成对编写了大部分编码，但肯定有一些任务和项目的某些阶段效率较低。我们所做的是在项目启动期间（每个阶段的前几周）我们配对程序。在完成阶段，我们没有。当我们处理开源项目时，我们也有特定的时间（每个开发人员每周8小时），这些项目都是成对编程的。我们所有的机器都配有多个键盘和鼠标，以方便开发人员之间的顺畅互动。

创新技术：我们在Habanero上做了大量工作，并使用此框架以及DI容器Unity和RhinoMocks。

敏捷：我们已经使用敏捷哲学8年了，并且在我们继续沿着这条道路继续尝试工具和哲学时。

需求规范（如何？）：我们为MSWord中的下一次迭代捕获用户故事（用例）。然后，我们通过努力估计等来捕捉Jeera中的这些摘要，这些估算管理绘制图等。

持续集成：我们目前正在使用在SVN之上运行的Hudson。

代码覆盖率工具：我们为每个项目运行代码覆盖，作为每晚构建的一部分。我们将生成的报告整合到Hudson报告中，以便我们可以每天跟踪每个项目。

沟通（维基，邮件，即时通讯，邮件列表，其他文件）：很明显，我们以多种不同的方式进行交流，我们有内部维基等。

团队规模：我们有15位软件开发人员。

会议：我们每天早上都有一个“scrum”，大约持续10分钟。

错误跟踪：我们使用不同的系统进行内部错误跟踪（即在开发和内部测试期间）以及外部错误跟踪，即来自客户的错误。内部跟踪（即在内部测试和开发期间）我们使用redmine。外部跟踪（即我们的客户）我们使用Mantis。

Answer 8

我在澳大利亚布里斯班的一家Ruby on Rails咨询公司工作。

• 测试驱动开发：我们的办公室非常非常努力。不测试被视为“令人难以置信的愚蠢”。您编写代码，如何通过CI等自动化流程确保它仍然有效？测试

• 你测试吗？：见第一点。

• 单元测试：始终使用RSpec。我在“测试::单位”中也“流利”，而且也是“。”

• 集成测试：同样，Cucumber。

• 验收测试：使用我们的门票，我们会使用验收标准“交付”它们。然后客户必须通过跟随弹跳球“接受”或“拒绝”它们。验收标准还有我们的黄瓜功能所写的奖励。

• 代码评论＆amp;＆amp; Pair Progamming ：我们配对。这是代码审查的即时版本。它真棒，因为你可以坐下来看别人工作，他们编写测试然后你编写代码来让测试通过。如果你生病了，那么另一个人就知道你在做什么，并且可以与其他人配对。

• 创新技术：因为我们使用Rails，所以我们非常喜欢REST。

• 敏捷：我们使用Pivotal Tracker进行为期2周的迭代。

• 需求规范（如何？）：使用Pivotal Tracker中的功能，客户可以指定他们的要求，然后我们将它们（通常通过与他们交谈）充实到验收标准中，最终是真实世界的特色。

• 持续集成：我们使用的是我开发的名为construct的CI服务器。这是建立在像Integrity这样的想法的基础上，但是有后台工作和对分支机构的更好支持。既然Integrity已经建立了背景，那么仍有分支支持使我们“领先”。

• 代码覆盖率工具：有时候是RCov。我们并没有真正对代码覆盖感到困惑，因为我们在编写它之前测试了所有内容。如果它存在，那就会测试它。

• 通讯（维基，邮件，即时通讯，邮件列表，其他文件）：我们主要使用电子邮件与客户沟通，但我们也使用Skype与他们“站起来”。我们也使用了Basecamp。我想将谷歌Wave用于我们的下一个项目，就像一个小实验。我认为这真的很有帮助。

• 团队规模：我们团队中有4人，除非有人生病，否则通常会有2人。

• 会议：我们在早上大约15分钟就有一个“scrum”/“站立”。这样做的想法是你回顾你前一天所做的事情，你遇到的任何问题，你今天要做的事情以及你找到的“新的和有光泽的”。这不应该变成项目会议。如果需要，这些是在站立之后。
• 错误跟踪：我们再次使用Pivotal Tracker。客户端可以在此处提交错误，然后（理想情况下）编写如何复制它。然后我们编写一个测试来确保它不会再次发生（也就是：回归测试），它会经历与我们的功能相同的工作流程，我们提供并且客户接受。

Answer 9

我是一家小型软件公司的两名程序员之一，他们非常非技术所有者（“什么是'浏览器'” - 上周认真询问过。）

优点是我可以在大多数这些方面为自己选择。

测试驱动 - 开发 - 我们的主人经历了不好的经历。以错误的方式提到测试，我发誓她是在创伤后应激障碍中行事。

Domain-Driven-Design - 是的。

模型驱动设计/架构 - 是的。

你测试了吗？ - 不。测试属于销售和销售范围。支持员工和业主。因此，一旦它离开我的开发机器，就没有任何测试。

单元测试 - 如果我被抓住了，我可能会被解雇。而且它是唯一能让我解雇的东西。

集成测试 - 请参阅“您测试吗？”

验收测试 - 好吧，我们必须在某个时候部署它，对吗？

代码评论 - 没有人会理解它。我见过所有人。希望我没有。

创新技术（Spring，Hibernate，Wicket，JSF，WS，REST，......） - 是的。但是我得到了好消息。我是“孩子”，他不知道过去十年没有发明的任何东西（尽管我30岁并在我的桌面上有“数据库系统读物”）。

敏捷 - 我不是瀑布。但我也不是敏捷的。

结对编程 - 您不想尝试与在我们公司工作的其他“程序员”交谈。

UML - 不。但我有时会在我的白板上绘制带有标识符的方框。这样的老板。好东西，他们不是更倾向于技术，或者我可能会看到更多的盒子。

特定于域的语言 - 不。

要求规格（如何？） - 没有。

持续整合 - 不。

代码覆盖率工具 - 没有。

Aenemic Domain Model - 是的。试了一下。我的大部分情况都不喜欢它，也不使用它。

通讯（维基，邮件，即时通讯，邮件列表，其他文件） - 试过，无法让同事买进。我们的MediaWiki安装仍然具有默认徽标图形。

努力估计 - 我们必须估计每个工作需要多长时间才能完成。这就是客户收费的原因。这就是我们期望在项目上花费的。当我们从头开始查看新客户和开发新应用程序时，以及当我们进行错误修复（是的，我们向客户收费），功能添加等时，我们甚至会这样做。

团队规模 - 1.让我说这不是一个好的工作方式。能够实时反映其他有能力的程序员的想法要好得多。

会议 - 每周几个小时的价值，有时是两倍，而且很少少于此。我做的一半与客户会面，完全是内部的。

代码指标 - 不。

静态代码分析 - 没有。

错误跟踪 - 没有我应该的那么多。

Answer 10

• 测试驱动开发 - 如果你这意味着在代码之前编写测试，并不总是
• 域驱动设计 - 不是纯DDD
• 模型驱动 - 设计/架构 - 永远，但绝不是，再次
• 你测试吗？ - 是的，总是
• 单元测试 - 是的，总是
• 集成测试 - 这取决于我们试图避免它们，因为它们通常很慢
• 验收测试 - 是的，理想的自动化
• 代码评论 - 是的，这包含在已完成
的定义中
• 创新技术（Spring，Hibernate，Wicket，JSF，WS，REST，......） - 不确定所提到的技术是否具有创新性，但对Spring，Hibernate，WS来说是肯定的
• 敏捷 - 是的，这是我的DNA
• 结对编程 - 并非总是如此（对于新主题，新成员，如果明确要求）
• UML - 一点点（即不时在白板上的类或序列图），只有在有用的情况下
• 特定于域的语言 - 直到现在才真正使用
• 要求规格（如何？） - 轻量级规范（例如用户故事）
• 持续集成 - 当然（根据我们对已完成的定义，代码必须“集成”）
• 代码覆盖率工具 - 是（cobertura），这是在完成
的定义中
• Aenemic Domain Model - 不，我们尽力避免
• 通讯（维基，邮件，即时消息，邮件列表，其他文件） - 面对面，维基，即时通讯，邮件，邮件列表（但我们尽量避免使用word文档）
• 努力估计 - 是的，在积压级别的故事点，在迭代级别的小时数
• 团队规模 - 7 +/- 2
• 会议 - 是的，但只是有用的，总是时间盒装（迭代计划，每日会议，演示和回顾）
• 代码指标 - 是（圈复杂度，代码覆盖率，声纳中收集的编码标准）
• 静态代码分析 - 是（findbugs，checkstyle）
• 错误跟踪 - 是的，当然（但我们会在发现错误后立即修复错误）

Answer 11

• 测试驱动开发 - 虽然它应该被尝试引入，但我认为它没有起飞，所以这仍然是一个没有，但现在有更多的细节。
• 域驱动设计 - 否
• 模型驱动设计/架构 - 否
• 你测试吗？ - 是的，但不是全面的。我们确实有一些单元测试，一些集成测试和一些WatiN测试。
• 单元测试 - 我们有一些用于我们的新开发，但遗留的开发没有。
• 集成测试 - 通常，适用时。我的团队作为网络团队似乎并不经常这样做。
• 验收测试 - 我们有几个级别。第一个是在开发新功能时，必须获得另一个团队中的某个人的初步批准，该团队将在其与代码集成之前输入内容。第二个是在Sprint结束时演示功能，以获得更多关于看起来不正确或运行良好的反馈。然后在它作为决赛投入生产之前还有第三个级别，“是的，这不会搞砸我们已经拥有的东西”，有点像。
• 代码评论 - 这些不再做了，但可能是一件好事。
• 创新技术（Spring，Hibernate，Wicket，JSF，WS，REST，...） - 在我们的项目中应用了一些RESTful思想，我们正在使用.Net框架的一些功能，如lambda表达式。
• 敏捷 - 我们使用Scrum并有站立，故事板，迭代计划会议（这实际上是针对sprint而不是迭代，因为在每对冲刺之后，工作会向高管和其他部门展示，然后是2个冲刺。另一个演示是建筑师和内容进入团队的负责人。）
• 结对编程 - 我们确实在大多数新开发项目上进行配对，这些开发项目并不被认为是笨拙的工作。因此，对于想要在网站的培训部分工作的人来说，一对会做而不是只有一个开发人员。
• UML - 不，我们的新机器中删除了UML工具
• 特定于域的语言 - 不，但有一些术语是公司自己对事物的解释，因为内部产品的某些名称会违反其他人可能用于各种事物的术语。
• 要求规范（如何？） - 这可以从一个大字文件拼写出需要做什么，然后尝试做什么，然后尝试一下，然后尝试。
• 持续集成 - 我们在运行代码更改时使用的CI运行Cruise Control.Net。
• 代码覆盖率工具 - 没有。
• Aenemic Domain Model - 有点在这里没有真正的大型域名模型。
• 通讯（维基，邮件，即时通讯，邮件列表，其他文件） - 按重要性排序：电子邮件，即时消息，电话，然后访问小隔间。每周都会与大型项目的应用程序经理和每日站立人员会面。
• 努力估计 - 现在这在每个sprint中都很常见，但有时这是通过发送一张电子表格让每个人都把他们的估计结果放在他们的估计中，Scrum Master结合了我们最终看到的所有结果。
• 团队规模 - 拥有团队领导的5名开发人员，Scrum Master的业务分析师，监督我们所拥有的以及团队外部其他人员的测试人员，包括内容作者实际使用系统。
• 会议 - 对企业而言，简短，有效，通常适合当前事物的沟通。
• 代码指标 - 我不知道。
• 静态代码分析 - 没有。
• 错误跟踪 - 质量中心用于跟踪缺陷。 *源代码管理 - 我们现在正在使用Subversion。对于任何功能或错误，我们创建一个新分支，以便我们可以独立工作，而不是让我们的提交打破构建，因为我们正在处理某些事情。但是，我们都共享相同的DB进行开发，有时可能很有趣。
• IDE - 使用.Net 3.5和Sitecore 6.1
的XP上的Visual Studio 2008
• ...

在我来这里的近2年里，这支球队已经在我们的第3队领先。

CMS项目是我们正在努力的大项目，尽管有其他人提供的支持请求。

我们有一个IS副总裁，这一年有很多变化。由于现在有一个检查清单程序和更多可能有用的环节，生产更加锁定，并且还有更多的工作要完成发布。

Answer 12

• 测试驱动开发 - 否
• 域驱动设计 - 否
• 模型驱动设计/架构 - 否
• 你测试吗？ - 几乎没有
• 单元测试 - 几乎从不
• 集成测试 - 否
• 验收测试 - 否
• 代码评论 - 否
• 创新技术（Spring，Hibernate，Wicket，JSF，WS，REST，...） - Spring，Hibernate，Wicket
• 敏捷 - 没有
• 结对编程 - 否
• UML - 只是草图
• 特定于域的语言 - 否
• 需求规范（如何？） - 我们获得了巨大的客户需求规范，我们使用思维导图来提取当时估计的实际功能
• 持续整合 - 否
• 代码覆盖率工具 - 否
• Aenemic Domain Model - 是
• 通讯（维基，邮件，即时通讯，邮件列表，其他文件） - 思维导图，邮件
• 努力估计 - FITA（手指在空中，see here）
• 团队规模 - 2-6
• 会议 - 每周2-3次
• 代码指标 - 否
• 静态代码分析 - 否（尝试过FindBugs和Checkstyle）
• 错误跟踪 - 是的，Bugzilla

Answer 13

• 测试驱动 - 开发：没有。
• Domain-Driven-Design：否
• 模型驱动设计/架构：我们从应用程序的模型开始
• 你测试吗？是。有时我是唯一一个测试我的东西的人。我讨厌这个。
• 单元测试 - 没有。这是我技能方面的一个缺乏领域，我认为应该高度重视。
• 集成测试 - 否
• 验收测试 - 有时候。即使受到On High的威胁，也很难让用户使用它。
• 代码评论 - 没有。我们已经讨论过这样做但最终从未做过。我对此感到沮丧。
• 创新技术 - 没有
• 敏捷 - 我们有点敏捷，虽然不是通过预先努力的努力
• 结对编程 - 没有
• UML - 尽可能少，但我们做模型（我们在这里更刻意敏捷）。
• 特定于域的语言 - 否
• 要求规格（如何？） - 我们这样做。我的小组有时主要负责收集需求。我们现在通常由Biz Analyst协助，但并非总是如此。 Veep有时会把我们的要求交给我，我不知道在哪里。有时它们是旧的东西，从来没有完成，但很久以前就有计划。通常收集的需求被放入由主要用户以及我的团队，Biz Analyst和Veep审核的Word文档中。
• 持续整合 - 不是
• 代码覆盖率工具 - 否
• Aenemic Domain Model - 我不熟悉他，但没有。
• 通讯（维基，邮件，即时通讯，邮件列表，其他文件） - 只需发送电子邮件即可面对面。我最近提出了这个问题，因为我们需要做更多的事情，更喜欢wiki。它放在后面燃烧器上。
• 努力估计 - 是的，但我们不会尝试真正跟踪它们。这是我缺乏的另一个领域。
• 团队规模 - 3，包括我自己（导演＆lt; - 团队负责人＆lt; - 我）。
• 会议 - 我们每周见面一次，但并非总是如此。老板通常每周至少检查几次。更多的小组会议偶尔会举行。当然，我们会安排会议以根据需要制定项目要求。
• 代码指标 - 不是
• 静态代码分析 - nope
• 错误跟踪 - 我们记录错误。这几乎就是我们的错误跟踪。

就是这样。我们认为我们可以改进这些领域。

更新

在我发布此消息后的几周内（08年11月初），我们失去了业务分析师。我已经在现有的应用程序中实现了ELMAH 和最近开发的应用程序来帮助进行错误跟踪（我们还登录到数据库），我喜欢它的易用性，功能和能够捕获我们没有捕获的异常（这在很大程度上是未使用的，但仍有很好的覆盖范围）。我仍然在自己的单元测试中徘徊 - 我真的需要在那里加快步伐（我也想学习MVC，但我也大部分时间都在考虑）。

我们现在正在设计一个新的应用程序，我正在为6个模块中的3个做一个模拟数据库模式（将获得一些基本的图表）（团队负责人正在研究另外3个模块）。我并不期待它，因为这将由我们3人（每个2个模块）使用IronSpeed Designer（6.1）串联开发。 IronSpeed会为我做一些我喜欢的事情，但这不是快速完成这些事情的唯一方法，它会做一些我不关心的事情。

没有其他任何改变。

Answer 14

测试：我做了很多系统测试，并且进行了少量的单元测试。我尝试在有意义的时候使用测试驱动开发，但感觉就像大多数时候它对我正在做的事情的核心没有意义。

至于其余部分，我不确定我是否正确地使用“特定于域的语言”，但我确实使用了大量自动生成的代码来捕获我工作中的重复内容 - 我算了9 Perl脚本生成近100,000行代码。

至于其他人，团队规模总是一个。我每年一次使用PC-Lint进行静态代码分析。我非常重视gprof和valgrind（你似乎没有提到过这类工具）。多年来我一直在寻找一个适当的bug跟踪系统，但我现在仍在使用待办事项列表软件和电子邮件处理它。

Answer 15

我的公司已经采用了大多数“流行语”方法。单元测试，测试驱动开发，Scrum，敏捷，持续集成，代码覆盖率分析等 我发现随着团队规模随经济发展而变化，我们正在从产品跳到产品。经过大量裁员，我们从Rally Dev / Scrum转移到Jira / Agile。 我们正在使用Selenium进行自动化测试，但现在正在查看Tellenium和Google的WebDriver。

我们发现了什么？已经通过为其创建的每个测试（包括负载测试）的站点在真正分析时可能会非常低效。在进行代码性能分析后，我们能够为我们的一个站点减少2/3的服务器资源，并且仍然具有更好的性能。它仍然通过了相同的测试。

前端自动化测试无法捕捉人类在几秒钟内会注意到的定位问题。当然，我们可以花几个小时写测试来检查定位。但是测试很脆弱，并且在页面布局发生变化时必须重写，即使只是一点点。测试通常只是表明代码有效，而不是有多好。

我曾在使用许多不同技术的大小公司工作过。包括简单的“牛仔编码”。当我们没有采用规划和测试方法时，存在更多错误，但我们移动得更快。我们在几小时内推出了更改和修复，而不是几天和几周。

Facebook每周（周二）都会“推”。通常在最新的代码推送中存在错误（测试不够？），但是他们经常在周四或周五再次推动修复任何问题。我的猜测是Facebook更接近“牛仔编码”方法，而且它一直在为他们工作。

Answer 16

• 测试驱动 - 开发 - 不是故意的。
• Domain-Driven-Design - 不，我们仍在搞清楚域名。
• 模型驱动设计/架构 - Nope
• 你测试吗？ - 我们测试构建版本，并让高级用户进行测试。
• 单元测试 - 没有正式的（没有nUnit等）
• 集成测试 - 否
• 验收测试 - 是
• 代码评论 - 偶尔。
• 创新技术 - 随机SharePoint工具
• 敏捷 - 是的
• 结对编程 - 否
• UML - 从不
• 特定于域的语言 - Nope
• 要求规格（如何？） - 我们对此保持清醒并进行迭代。我们有一个BA进行一些需求分析，但通常我们只是邀请客户参加我们的计划和日常会议。没有正式的文档。
• 持续整合 - 是（cruisecontrol.net）
• 代码覆盖率工具 - 否（但我们确实使用Visual Studio代码分析）
• 通讯 - 展望
• 努力估计 - 球场，加倍，然后再加倍。
• 团队规模 - 2-4
• 会议 - 每天上午9点（scrum！）以及每周计划/审核会议
• 代码指标 - 不是
• 错误跟踪 - Bugzilla
• 来源控制 - SVN

Answer 17

以下是我的观察：

• 测试驱动开发：否

• 域驱动设计：是

• 模型驱动设计/架构：是

• 你测试吗？ ：是的

• 单元测试：是

• 集成测试：是

• 验收测试：是

• 代码评论：否

• 创新技术（春天， Hibernate，Wicket，JSF，WS，REST， ......）：是的

• 敏捷对编程：否

• UML：是

• 特定于域的语言：是

• 要求规格（如何？）是

• 持续整合：是

• 代码覆盖率工具：否

• Aenemic Domain Model：No（这是什么意思？）

• 沟通（Wiki，Mail，IM， 邮件列表，其他文件）：Wiki，Mail，IM，Mailinglists

• 努力估算：是

• 团队规模：2-4名成员

• 会议：每周一举行会议，每隔一天举行一次浮动会议

• 代码指标：是

• 静态代码分析：否

• 错误跟踪：是

Answer 18

•测试驱动开发 - 刚开始接手，到目前为止非常满意

•你测试吗？ - 当然，每个人都这样做，谁想要QA嘲笑他们？

•单元测试 - 大约2年以来，每次构建都有稳定性和测试的帮助

•代码评论 - 此处和那里，尤其是任何后期更改

•敏捷 - 爱敏捷及其代表性

•结对编程 - 只需在几个点上尝试，早期回报有希望

•持续集成 - CruiseControl.NET赢得胜利！如此巨大的帮助

•代码覆盖工具 - 在每次单元测试运行期间，CC.NET都会向全世界发布此信息

•通讯（维基，邮件，即时通讯，邮件列表，其他文件） - WIKI，IM，Campfire

•团队规模 - 小，当产品团队变大时，我们会分解为功能团队

•会议 - 简短但不经常，更有可能走廊走廊

•代码指标 - 仅限于圈复杂度

•静态代码分析 - 真的尝试这个更多使用FxCop和VSTS的本土

•错误跟踪 - Windows的TFS和Mac的Traq

Answer 19

• 测试驱动开发：偶尔会有人为组件执行此操作。此外，实现一致性测试附带的公共规范提供了TDD的一些优点，而且还有很多其他优点。
• Domain-Driven-Design：否
• 模型驱动设计/架构：否
• 你测试吗？：是的
• 单元测试：有些，虽然不完整。许多组件都是供客户使用的库。 “strlen”实现的单元和功能测试之间存在细微差别。
• 集成测试：不是真的，单元和系统测试之间几乎没有。
• 验收测试：是，并且验收测试的子集用作系统测试
• 代码评论：没有正式的流程，但有些代码会被审核
• 创新技术（Spring，Hibernate，Wicket，JSF，WS，REST，...）：否
• 敏捷：没有
• 配对编程：否
• UML：否
• 特定于域的语言：偶尔
• 要求规格（如何？）：排序
• 持续整合：不，但是每天建立和恢复导致测试团队自行决定的导致失败的变化
• 代码覆盖率工具：没有正式要求，已知测试团队使用'em
• Aenemic Domain Model：我甚至不知道这是什么
• 通信（Wiki，Mail，IM，Mailinglists，其他文档）：所有这些都是临时选择的，除了需求和设计文档必须是源代码控制下的HTML，内部接口文档是从头文件中的Doxygen注释生成的。 / LI>
• 努力估计：有点
• 团队规模：约20名程序员，分为1-4人的组成团队。几乎没有人专门从事他们所属团队的组件。
• 会议：每周一次的全体会议，以交换进度报告，并以其他方式分享正在发生的事情。没有其他定期开发者会议：根据需要安排讨论。
• 代码指标：否
• 静态代码分析：除非你计算-pedantic; - ）
• 错误跟踪：Bugzilla，与源代码控制有些集成

Answer 20

• 测试驱动开发 - 是
• 域驱动设计 - 否
• 模型驱动设计/架构 - 否
• 你测试吗？ - 是的
• 单元测试 - 是
• 集成测试 - 是
• 验收测试 - 已开始
• 代码评论 - 否
• 创新技术（Spring，Hibernate，Wicket，JSF，WS，REST，......） - 不是吗？
• 敏捷 - 是的
• 结对编程 - 几乎所有时间都是如此
• UML - 没有比白板上的线条和方框更正式的了。
• 特定于域的语言 - 一点点
• 要求规范（如何？） - 不，我们尽可能尝试获取用户故事
• 持续整合 - 是
• 代码覆盖率工具 - 否
• Aenemic Domain Model -
• 通讯（维基，邮件，即时通讯，邮件列表，其他文件） - 维基，即时通讯，电邮，Word文档
• 努力估计 - 我们使用T恤尺码（S，M，L，XL等）的组合以及通过冲刺速度冲刺的积分系统。
• 团队规模 - 6-> 8
• 会议 - 每日站立
• 代码指标 - 否
• 静态代码分析 - 否
• 错误跟踪 - Bugzilla / Version One

Answer 21

• 测试驱动开发 - 否
• 域驱动设计 - 否
• 模型驱动设计/架构 - 否
• 你测试吗？ - 有时候
• 单元测试 - 几乎从不
• 集成测试 - 是
• 验收测试 - 有时
• 代码评论 - 仅偶尔
• 创新技术（Spring，Hibernate，Wicket，JSF，WS，REST，......） - 否
• 敏捷 - 没有
• 结对编程 - 否
• UML - 在我的记号板上，是的。
• 特定于域的语言 - C ++是特定于域的，对吧？
• 要求规格（如何？） - 我想我们见面了。
• 持续整合 - 是
• 代码覆盖率工具 - 否
• Aenemic Domain Model - 什么是域模型
• 通讯（维基，邮件，即时消息，邮件列表，其他文件） - 电子邮件＆amp; Skype的。什么是维基？
• 努力估计 - 任何特定任务1-2天
• 团队规模 - 2名软件工程师，10名硬件工程师
• 会议 - 每周2次
• 代码指标 - 否
• 静态代码分析 - 否
• 错误跟踪 - 否

Answer 22

你看过NDepend了吗？该工具分析C＃和.NET代码，并提供了许多很酷的功能来浏览分析结果。使用NDepend，您可以编写代码规则，compare 2 versions of the code base可以使用80 code metrics以上的数据。

此外，该工具还具有几个出色的可视化功能，如：

依赖图：

依赖矩阵：

通过treemaping进行代码度量标准可视化：

Answer 23

很高兴听到MDA，DDD和配对编程没有在任何地方使用：D Martin Fowler不是上帝，只是有些奇怪想法的人。

• 测试驱动开发 - 如果您想
• 单元测试 - 是
• 代码评论 - kindda
• 创新技术（Spring，Hibernate，Wicket，JSF，WS，REST，......） - 是的，Seam
• UML - kindda
• 持续整合 - 是和否
• 代码覆盖率工具 - 是和否