贵公司的软件开发到底是什么样的（方法、工具……）？
自从大约两年前我开始作为专业软件开发人员的第一份工作以来，我阅读了许多关于普遍接受的方法论（例如 Scrum、XP）、技术（例如 EJB、Spring）、技巧（例如 TDD、代码审查）的文章。 ）、软件公司的工具（bug跟踪、wiki）等等。
对于其中许多，我发现我们公司并没有使用它们，我问自己为什么。 我们是否做错了，或者仅仅是我读过的这些文章并没有真正讲述现实世界的情况？ 这些文章比较学术吗？
那么，请告诉我你们公司的情况如何。 讲述有关软件开发的一切。 这里有一些建议（按照我的想法排列）。 至少告诉你是否这样做，或者给出一个简短的评论：
- 测试驱动开发
- 领域驱动设计
- 模型驱动设计/架构
- 你测试吗？
- 单元测试
- 集成测试
- 验收测试
- 代码审查
- 创新技术（Spring、Hibernate、Wicket、JSF、WS、REST...）
- 敏捷
- 结对编程
- UML
- 领域特定语言
- 需求规范（如何？）
- 持续集成
- 代码覆盖工具
- 通用领域模型
- 沟通（Wiki、邮件、IM、邮件列表、其他文档）
- 工作量估算
- 团队规模
- 会议
- 代码度量
- 静态代码分析
- 错误跟踪
- ...
请记住：我想知道您真正在做什么，而不是您想要做什么或认为自己做什么应该做。
Since I've started my first job as a professional software developer about two years ago, I've read many articles about commonly accepted methodologies (e.g. Scrum, XP), technologies (e.g. EJB, Spring), techniques (e.g. TDD, code reviews), tools (bug tracking, wikis) and so on in software companies.
For many of these I've found that we at our company doesn't use them and I ask myself why. Are we doing it wrong or is it merely that these articles I've read are not really telling what it's like in the real world? Are these articles more academic?
So, please tell me what it's like at your company. Tell about everything regarding software development. Here are some suggestions (in the order as they come from my mind). Tell at least if you do it or not, or give a short comment:
- Test-Driven-Development
- Domain-Driven-Design
- Model-Driven-Design/Architecture
- Do you test?
- Unit Testing
- Integration Testing
- Acceptance Testing
- Code Reviews
- Innovative Technologies (Spring, Hibernate, Wicket, JSF, WS, REST, ...)
- Agile
- Pair Programming
- UML
- Domain-specific languages
- Requirement Specification (How?)
- Continous Integration
- Code-Coverage Tools
- Aenemic Domain Model
- Communication (Wiki, Mail, IM, Mailinglists, other documents)
- Effort estimates
- Team size
- Meetings
- Code metrics
- Static code analysis
- Bug tracking
- ...
And remember: I want to know what you really do, not what you would like to do or think you should do.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（23）
就大型企业开发而言，还有更糟糕的情况。 考虑到我住的地方，以及该地区缺乏高科技工作，我实际上很幸运能有一份工作。 但这并不意味着我必须喜欢事情的现状。 即使试图影响既定的企业文化，也需要大量的时间和持续的压力。
但如果他们厌倦了我改变文化的尝试并解雇了我，那么，我想那天晚上我不会哭着入睡。
As far as big, corporate dev't goes, there's a lot worse out there. Given where I live, and the lack of high-tech jobs in the area, I'm actually pretty lucky to have a gig at all. Doesn't mean I have to like the way things are, though. It just takes a lot of time and constant pressure to even try to influence an established corporate culture.
But if they get sick of my attempts to change the culture and fire me, well, I don't think I'd cry myself to sleep that night.
我认为著名的大泥球模式描述了很多工作环境并为您提供一些关于如何应对此类问题的好主意。
顺便说一句，我意识到我没有直接回答你的问题，但大泥球在令人沮丧的大部分开发情况中盛行。 你可以询问测试驱动开发和缺陷跟踪以及其他类似的事情，但如果从我所看到的来看真相，我会说大泥球几乎是人们事实上的工作方式——他们应该还是不应该。
I think the famous Big Ball of Mud pattern describes a lot of work environments and gives you some good ideas about how to combat this kind of thing.
By the way, I realize I'm not directly answering your question but Big Ball of Mud prevails in a depressingly large percentage of development situations. You can ask about test driven development and defect tracking and other sorts of things of that sort but if the truth is told from what I've seen, I'd say the Big Ball of Mud is pretty much the de facto way that people work--whether they should or should not.
我的部门正在进行中。 在过去的几个月里，我一直在努力实施持续改进。 有些事情已经很难谈论了。 然而，当回头看时，他们已经进步了。
My department is a work in progress. Over the past few months, I've made an effort in enforcing continuous improvement. Some stuff has been down right difficult to talk about. However, when looking back, they have improved.
最重要的是...
但是工资低很多，因为很多人想在这家公司工作。 不可能拥有一切！
And most importantly...
However the salary is alot lower because alot of people want to work for this company. Can't have everything!
注意：
Notes:
我为你感到难过:)这不是一个好的工作环境，因为你需要不断练习良好的实践才能真正理解和使用它们。
我知道有几家公司（包括我的）能够在您的列表中勾选所有“好”框。
然而，细节决定成败，即使在一些拥有良好 SDP 政策的公司中，也不是每个项目都遵循这些政策。
I feel sorry for you :) It's not a good environment to work in, as you need to constantly exercise practise good practices to really understand and use them.
I know several (mine included) companies which would be able to tick all the 'good' boxes in your list.
However the devil is in details and even in some companies with good SDP policies not every project follows them.
* 源代码控制 - 我们现在使用 Subversion。 对于任何功能或错误，我们都会创建一个新分支，这样我们就可以独立工作，并且在我们正在处理某些事情时不会让我们的提交破坏构建。 然而，我们都共享相同的开发数据库，这有时会很有趣。
该团队在近 2 个项目中排名第三。我来这里已经很多年了。
CMS 项目是我们都在致力于的一个大项目，尽管有其他人处理的各种支持请求。
在我们任命 IS 副总裁的这一年里，发生了很多变化。 生产更加锁定，并且需要更多工作来完成发布，因为现在有一个检查列表程序和更多可能有用的箍。
* Source Control - We are using Subversion now. For any feature or bug we create a new branch so we can work independently and not have our commits break the build as we are working on something. However, we all share the same DB for development which can be interesting at times.
The team is on our 3rd team lead in the almost 2 years I've been here.
The CMS project is the big project that we are all working on though there are various support requests that come in that others handle.
There have been a lot of changes in the year that we've had a VP of IS. Production is more locked down and there is more work to get a release done as there is a check list procedure now and more hoops that may be useful.
我是一家小型软件公司的两名程序员之一，该公司的所有者非常不懂技术（“什么是‘浏览器’”——上周有人认真询问过）。
优点是我可以自己选择其中的大部分内容。
测试驱动开发 - 我们的所有者有过糟糕的经历或其他什么。 提到以错误的方式进行测试，我发誓她的行为是出于创伤后应激障碍。
领域驱动设计 - 是的。
模型驱动设计/架构 - 是的。
你测试吗？ - 没有。 测试落在销售和销售上。 支持员工和业主。 因此，一旦离开我的开发机器，就不会再进行太多测试。
单元测试——如果我这样做被发现，我可能会被解雇。 这确实是唯一能让我被解雇的事情。
集成测试 - 请参阅“您进行测试吗？”
验收测试 - 嗯，我们必须在某个时候部署它，对吧？
代码审查 - 没有其他人会理解它。 我见过其他人。 但愿我没有。
创新技术（Spring、Hibernate、Wicket、JSF、WS、REST...）- 是的。 但我因此受到批评。 我是一个“孩子”，对过去十年中未发明的任何东西一无所知（尽管我已经 30 岁了，桌上有《数据库系统读物》）。
敏捷——我不瀑布式。 但我也不太擅长敏捷。
结对编程——您不想尝试与在我们公司工作的其他“程序员”交谈。
UML - 不。 但有时我会在白板上画一些带有标识符的方框。 老板们都喜欢这样。 好在他们不更倾向于技术，否则我可能会看到更多的盒子。
特定领域的语言 - 不。
需求规格（如何？）- 不。
持续集成 - 不。
代码覆盖工具 - 不。
贫血领域模型 - 是的。 试过了。 在我的大多数情况下，我不喜欢它，也不使用它。
沟通（Wiki、邮件、IM、邮件列表、其他文档）- 尝试过，但无法获得同事的认可。 我们的 MediaWiki 安装仍然具有默认的徽标图形。
工作量估计 - 我们必须估计每项工作需要多长时间（以小时为单位）。 这就是客户收到的账单。 这就是我们预计在该项目上花费的资金。 当我们寻找新客户并从头开始开发新应用程序时，以及当我们进行错误修复（是的，我们向客户收取费用）、添加功能等时，我们甚至会这样做。
团队规模 - 1. 让我说这不是一个好的工作方式。 能够实时反馈其他有能力的程序员的想法要好得多。
会议——每周几个小时，有时是两倍，很少少于这个时间。 我与客户举行的会议有一半是完全内部的。
代码指标 - 不。
静态代码分析 - 不。
错误跟踪 - 没有我应该做的那么多。
I am one of two programmers at a small software firm with VERY non-technical owners ("what's a 'browser'" - seriously asked last week).
The advantage is that I can choose for myself on most of these points.
Test-Driven-Development - Our owner had a bad experience or something. Mention testing in the wrong way and I'd swear she's acting out of PTSD.
Domain-Driven-Design - Yep.
Model-Driven-Design/Architecture - Yep.
Do you test? - Nope. Testing falls on the sales & support staff and the owners. So nothing gets tested much once it leaves my dev machine.
Unit Testing - If I got caught doing it I might get fired. And its seriously the only thing that could get me fired.
Integration Testing - See "Do you test?"
Acceptance Testing - Well, we have to deploy it sometime, right?
Code Reviews - No one else would understand it. I've seen everyone elses. Wish I hadn't.
Innovative Technologies (Spring, Hibernate, Wicket, JSF, WS, REST, ...) - Yep. But I get flak for it. I'm the "kid" who doesn't know anything that wasn't invented in the last ten years (despite being 30 and having "Readings in Database Systems" on my desk).
Agile - I don't waterfall. But I don't really Agile, either.
Pair Programming - You don't want to try to talk to the other "programmer" that works at our company.
UML - Nope. But I draw boxes with identifiers in them sometimes on my whiteboard. The bosses like that. Good thing they're not more technically inclined, or I'd probably see more boxes.
Domain-specific languages - Nope.
Requirement Specification (How?) - Nope.
Continous Integration - Nope.
Code-Coverage Tools - Nope.
Aenemic Domain Model - Yep. Tried it. Most of my situations I don't like it for and don't use it.
Communication (Wiki, Mail, IM, Mailinglists, other documents) - Tried, couldn't get coworker buy-in. Our MediaWiki install still has the default logo graphic.
Effort estimates - We have to estimate how long every job will take in hours. That is what the client gets billed. And that is what we are expected to spend on the project. We even do this when we are looking at new clients and developing new apps from scratch, as well as when we do bug fixes (yeah, we charge clients for that), feature additions, etc.
Team size - 1. And let me say this is not a good way to work. It is much better to be able to bounce ideas of other capable programmers in real time.
Meetings - few hours worth a week, sometimes double that and rarely less than that. Half the meetings I do are with clients, have are totally internal.
Code metrics - Nope.
Static code analysis - Nope.
Bug tracking - Not as much as I should.
我在澳大利亚布里斯班的一家 Ruby on Rails 咨询公司工作。
测试驱动开发：我们办公室非常非常努力地推动这一点。 不进行测试被视为“极其愚蠢”。 您编写代码，如何通过 CI 等自动化流程确保它仍然有效？ 测试。
你测试吗？：参见第一点。
单元测试：一直使用 RSpec。 我对 Test::Unit 和 Shoulda 也很“流利”。
集成测试：再次强调，一直以来，Cucumber。
验收测试：通过我们的票据，我们“交付”它们并附有验收标准。 然后，客户必须通过跟随弹跳球来“接受”或“拒绝”它们。 验收标准的好处是，它也是我们编写的 Cucumber 功能的内容。
代码审查 && 结对编程：我们结对。 这是代码审查的即时版本。 这太棒了，因为您可以坐下来观看其他人工作，他们编写测试，然后您编写代码以使测试通过。 如果您生病了，那么其他人就会知道您在做什么，并且可以与其他人配对。
创新技术：因为我们使用 Rails，所以我们非常喜欢 REST。
敏捷：我们使用 Pivotal Tracker 进行 2 周迭代。
需求规范（如何？）：使用 Pivotal Tracker 中的功能，客户可以指定他们的需求，然后我们将其充实（通常通过与他们交谈）为验收标准，并最终实现 Real世界功能。
持续集成：我们使用我开发的 CI 服务器，名为 construct 。 它的构建理念与 Integrity 类似，但具有后台工作和对分支机构更好的支持。 现在 Integrity 已经有了后台构建，仍然有分支支持让我们保持“领先”。
代码覆盖工具：有时是 RCov。 我们并不真正担心代码覆盖率，因为我们在编写代码之前测试了所有内容。 如果存在，就会有一些东西来测试它。
沟通（Wiki、邮件、IM、邮件列表、其他文档）：我们主要使用电子邮件与客户沟通，但我们也使用 Skype 与他们进行“站立”。 我们还为此使用了 Basecamp。 我想在我们的下一个项目中使用 Google Wave，只是作为一个小实验。 我认为这真的很有帮助。
团队规模：我们的团队有 4 人，通常是 2 对，除非有人生病了。
I work for a Ruby on Rails consultancy in Brisbane, Australia.
Test-Driven-Development: This is pushed very, very hard in our office. Not testing is viewed as "incredibly stupid". You write the code, how do you ensure by way of an automated process such as CI, that it still works? Tests.
Do you test?: See point one.
Unit Testing: All the time, using RSpec. I'm "fluent" in Test::Unit and Shoulda also.
Integration Testing: Again, all the time, Cucumber.
Acceptance Testing: With our tickets we "deliver" them with an Acceptance Criteria. Then the client has to either "Accept" or "Reject" them by following the bouncing ball. The Acceptance Criteria has the bonus of also being what our Cucumber features are written in.
Code Reviews && Pair Progamming: We pair. It's the instant version of code review. It's awesome because you can sit back and watch someone else work, they write the test and then you write the code to make that test pass. If you're sick then the other person knows what you were up to and can pair with somebody else.
Innovative Technologies: Because we use Rails, we're really fond of REST.
Agile: We work on 2 week iterations using Pivotal Tracker.
Requirement Specification (How?): Using features in Pivotal Tracker the client can specify what requirements they have and then we flesh them out (usually by talking with them) into acceptance criteria, and eventually Real World features.
Continous Integration: We use a CI server I developed called construct. This was built with the idea of being like Integrity, but with background jobs and better support for branches. Now that Integrity has background building, there's still the branching support keeping us "ahead".
Code-Coverage Tools: RCov sometimes. We're not really fussed with code coverage as we test EVERYTHING before we write it. If it exists, there's something that will test it.
Communication (Wiki, Mail, IM, Mailinglists, other documents): We communicate with our clients using Email primarily, but we also have "standups" with them using Skype. We've also used Basecamp for this. I'm wanting to use Google Wave for our next project, just as a little experiment. I think it'd be really helpful.
Team size: We have 4 people in our team, usually 2 pairs unless someone's sick.
我在南非的 Chillisoft.co.za 工作
测试驱动开发：自第一本 Kent Beck 书籍以来，我们一直在使用测试驱动开发实践。 我们使用 NUnit 和 R# 作为测试运行程序。
你测试吗？：除了 TDD 之外，我们还进行手动测试（可视化），并且在必要时实现自动化。 用于自动化的技术取决于 UI 技术。
单元测试：请参阅 TDD。
集成测试：是的，但我们尚未普遍使用。
验收测试：我们为外部客户进行定制软件开发，在他们接受之前您不会获得报酬，因此是的。
代码审查：每个项目每两个月安排一次。 即使是那些已经结对/对等编程的。
结对编程：我们大部分编码都是结对进行的，但肯定有一些任务和项目的某些阶段效率较低。 我们所做的是在项目启动期间（每个阶段的前几周）我们结对编程。 在最后阶段我们不会。 当我们从事开源项目时，我们也有特定的时间（每个开发人员每周 8 小时），这些都是结对编程的。 我们所有的机器都配备了多个键盘和鼠标，以促进开发人员之间的流畅交互。
创新技术：我们在 Habanero 上做了大量的工作，并使用它框架以及 DI 容器 Unity 和 RhinoMocks。
敏捷：我们使用敏捷理念已经有 8 年了，并且在沿着这条道路前进的过程中，我们将继续尝试工具和理念。
需求规范（如何？）：我们为 MSWord 中的下一次迭代捕获用户故事（用例）。 然后，我们在 Jeera 中捕获这些内容的摘要，并通过工作量估计等来管理绘制图表等。
持续集成：我们目前使用的是在 SVN 之上工作的 Hudson。
代码覆盖工具：作为夜间构建的一部分，我们为每个项目运行代码覆盖率。 我们已将生成的报告集成到 Hudson 报告中，以便我们可以每天跟踪每个项目的这些报告。
沟通（Wiki、邮件、IM、邮件列表、其他文档）：显然，我们以多种不同的方式进行沟通，我们有内部 Wiki 等。
团队规模：我们有 15 名软件开发人员。
会议：我们每天早上都会举行一次“scrum”，持续约 10 分钟。
错误跟踪：我们使用不同的系统进行内部错误跟踪（即在开发和内部测试期间）和外部错误跟踪（即来自客户的错误）。 内部跟踪（即内部测试和开发期间）我们使用redmine。 我们使用 Mantis 进行外部跟踪（即针对我们的客户）。
I Work for Chillisoft.co.za in South Africa
Test-Driven-Development: We have been using Test Driven Development practices since the first Kent Beck Book it is enforced throughout. We use NUnit and R# as the test runner.
Do you test?: In addition to TDD we do manual testing (Visual) and this is automated where necessary. Technologies used for automation depends on UI Technologies.
Unit Testing: See TDD.
Integration Testing: Yes but we not yet used ubiquitously.
Acceptance Testing: We do custom software development for external customers you don't get paid untill they accept hence yes.
Code Reviews: Scheduled bimonthly for every project. Even those that have been pair/peer programmed.
Pair Progamming: We do most of our coding in pairs but there are certainly some tasks and some stages of the project where this is less efficient. What we do is during project startup (first few weeks of each phase) we pair program. In the finishing stages we do not. We also have specific times (8 hours per week per developer) when we work on open source projects these are all pair programmed. All our machines are setup with multiple keyboards and mouse to facilitate the smooth interaction between devs.
Innovative Technologies: We have done a large amount of work on Habanero and use this framework along with a DI container Unity and RhinoMocks.
Agile: We have been using agile philosophies for 8 years and are continuing to experiment with tools and Philosophies as we continue down this path.
Requirement Specification (How?): We capture user stories (Use Cases) for the next iterations in MSWord. We then capture the summary of these in Jeera with effort estimates etc which manages draw down graphs etc.
Continous Integration: We are currently using Hudson which works on top of SVN.
Code-Coverage Tools: We run code coverage for every project as part of our nightly build. We have intergrated the resulting report into the Hudson reports so that we can track these daily for every project.
Communication (Wiki, Mail, IM, Mailinglists, other documents):Obviously we commmunicate in many different manners we have an internal Wiki etc.
Team size: We have 15 software developers.
Meetings: We have a "scrum" every the mornings lasting about 10 minutes.
Bug tracking: We use different systems for internal bug tracking (i.e. during development and internal testing) and for external bug tracking i.e. bugs from customers. Internal tracking (i.e. during internal testing and dev) we use redmine. External tracking (i.e. for our customers) we use Mantis.
•测试驱动开发- 刚刚开始接管，到目前为止非常满意
•您进行测试吗？ - 当然，每个人都这样做，谁希望 QA 嘲笑他们呢？
•单元测试 - 大约 2 年了，它有助于提高稳定性，并且每次构建都会运行测试
•代码审查 - 到处进行，尤其是任何最新的更改
•敏捷 - 喜欢敏捷及其响应能力
•结对编程 - 只是尝试一下一些景点，早期回报有希望
•持续集成-CruiseControl.NET 为赢！ 如此巨大的帮助
•代码覆盖工具 - 在每个单元测试运行期间，CC.NET 都会向全世界发布此信息
•通信（Wiki、邮件、IM、邮件列表、其他文档）- WIKI、IM、Campfire
•团队规模- 规模较小，当产品团队规模扩大时，我们会分解为功能团队
• 会议 - 简短且不频繁，更有可能是走廊聚会
• 代码指标 - 仅圈复杂度
• 静态代码分析 - 真正尝试这个 更多使用 FxCop 和VSTS 自主开发的
•Bug 跟踪 - Windows 版 TFS 和 Mac 版 Traq
•Test-Driven-Development - Just starting to take over, very happy with it so far
•Do you test? - Of course, everyone does, who wants QA laughing at them?
•Unit Testing - For about 2 years now, has helped with stability and tests are run every build
•Code Reviews - Here and There, especially with any late changes
•Agile - Love Agile and its repsonsiveness
•Pair Programming - Just trying it out in a few spots, early returns promising
•Continous Integration - CruiseControl.NET for the Win!!! Such a huge help
•Code-Coverage Tools - Always during every unit test run, CC.NET publishes this info out to the world
•Communication (Wiki, Mail, IM, Mailinglists, other documents) - WIKI, IM, Campfire
•Team size - small, when a product team gets to big we break down into feature teams
•Meetings - short and not often, more likely to get hallway get togethers
•Code metrics - Only cyclomatic complexity
•Static code analysis - Really trying this More use FxCop and VSTS's homegrown
•Bug tracking - TFS for windows and Traq for Mac
测试：我进行了大量的系统测试，以及少量的单元测试。 当测试驱动开发有意义时，我会尝试使用它，但感觉大多数时候它对于我正在做的事情的核心没有意义。
至于其余的，我不确定我是否正确地执行了“特定于域的语言”，但我确实使用了大量自动生成的代码来捕获工作中的重复内容 - 我数了数 9 个 Perl 脚本生成了几乎100,000 行代码。
至于其余的，团队规模始终是一。 我大约每年使用一次 PC-Lint 进行静态代码分析。 我非常频繁地使用 gprof 和 valgrind （你似乎没有提到此类工具）。 多年来我一直渴望有一个合适的错误跟踪系统，但目前仍在使用待办事项列表软件和电子邮件来处理它。
Testing: I do a lot of system testing, and a far smaller amount of unit testing. I try to use test driven development when it makes sense, but it feels like most of the time it doesn't make sense for the core of what I'm doing.
As for the rest, I'm not sure if I properly do "domain-specific languages" or not, but I do use a lot of automatically generated code to capture the repetitive stuff in my work -- I count 9 Perl scripts generating nearly 100,000 lines of code.
As for the rest, team size is always one. I use PC-Lint for static code analysis about once a year. I use gprof and valgrind quite heavily (you don't seem to have mentioned this class of tools). I've been pining for a proper bug tracker system for years now, but am still using to-do list software and e-mail to handle it at the moment.
就是这样。 我觉得我们有一些可以改进的地方。
更新：
在我发布这篇文章几周后（11 月 8 日早些时候），我们因大规模裁员而失去了业务分析师。 此后，我在现有应用程序和最近开发的应用程序中实现了 ELMAH，以协助错误跟踪（我们还登录到数据库），我喜欢它的易用性、功能和功能捕获我们未捕获的异常的能力（这在很大程度上未使用，但仍然具有很好的覆盖范围）。 我仍在自己研究单元测试——我真的需要加快步伐（我也想学习 MVC，但我也主要研究它）。
我们现在正在设计一个新的应用程序，我正在为 6 个模块中的 3 个模块（团队负责人正在处理其他 3 个）制作模拟数据库模式（这将获得一些基本图表）。 我并不期待它，因为这将由我们 3 个人（每人 2 个模块）使用 IronSpeed Designer (6.1) 协同开发。 IronSpeed 可以为我做一些我喜欢的事情，但这并不是快速完成这些事情的唯一方法，而且它可以做一些我不喜欢的事情。
其他一切都没有改变。
That's it. We have areas I feel like we could improve on.
Update:
We lost our business analyst to a large layoff a couple of weeks after I posted this (early November 08). I've since implemented ELMAH in an existing application and a more recently developed one to assist in bug tracking (we also log to a database) and I love it for the ease of use, the features, and the ability to catch exceptions we aren't catching (which is largely unused, but still nice coverage to have). I'm still poking around with Unit Testing on my own - I really need to pick up the pace there (I also want to learn MVC but I mostly poke around with that too).
We're desinging a new application right now, and I'm doing a mock DB schema (which will get some basic diagrams) for 3 of the 6 modules (Team Leader is working on the other 3). I'm not looking forward to it, since this will be developed in tandem by the 3 of us (2 modules each) using IronSpeed Designer (6.1). There are things IronSpeed will do for me that I like, but it's not the only way to do these things quickly, and it does some things I don't care for.
Nothing else has changed.
我的公司已经采用了大多数“流行语”方法。 单元测试、测试驱动开发、Scrum、敏捷、持续集成、代码覆盖率分析等。
我发现随着团队规模随着经济的变化而变化，我们正在从一个产品跳到另一个产品。 经过大量裁员后，我们从 Rally Dev/Scrum 转向 Jira/Agile。
我们正在使用 Selenium 进行自动化测试，但现在正在考虑 Tellenium 和 Google 的 WebDriver。
我们发现了什么？ 通过了为其创建的所有测试（包括负载测试）的站点在真正分析时可能效率低得令人难以置信。 经过代码性能分析后，我们能够将其中一个站点的服务器资源削减 2/3，并且仍然具有更好的性能。 它仍然通过了相同的测试。
前端自动化测试无法捕获人类在几秒钟内就会注意到的定位问题。 当然，我们可以花几个小时编写测试来检查定位。 但测试很脆弱，当页面布局发生变化时，即使只有一点点变化，也必须重写。 测试通常只是表明代码可以工作，而不是表明它有多好。
我曾在使用许多不同技术的大大小小的公司工作过。 包括简单的“牛仔编码”。 当我们不采用规划和测试方法时，会出现更多错误，但我们的行动速度要快得多。 我们在几小时内（而不是几天或一周）推出了更改和修复。
Facebook 每周（周二）都会进行一次“推送”。 最新的代码推送中经常存在错误（测试不够？），但他们通常会在周四或周五之前进行另一次推送以解决任何问题。 我的猜测是 Facebook 更接近“牛仔编码”方法，并且它一直为他们工作。
My company has jumped on most of the "buzzword" methodologies. Unit Testing, Test Driven Development, Scrum, Agile, Continuous Integration, Code-Coverage analysis, etc.
I find we are jumping from product to product as team sizes change with the economy. We shifted from Rally Dev/Scrum to Jira/Agile after plenty of layoffs.
We are using Selenium for automated testing, but now looking at Tellenium and Google's WebDriver.
What are we finding? Sites that have passed every test created for it (including load testing), can be incredible inefficient when truly analyzed. After a code performance analysis we were able to cut server resources by 2/3 for one of our sites, and still had better performance. It still passed the same tests too.
Front-end automated testing does not catch positioning issues that a human would notice in seconds. Sure, we could spend a few hours writing tests to check for positioning. But the tests are brittle and have to be rewritten when page layouts change, even just a little. Testing usually just indicates the code works, not how good it is.
I've worked at big and small companies using many different technologies. Including simple "cowboy coding". There were a lot more bugs when we didn't employ planning and testing methodologies, but we moved a lot quicker. We pushed out changes and fixes in hours, not days and week.
Facebook does a "push" every week (Tuesdays). Often enough there are bugs in the latest code push (not enough testing?), but they often do another push by that Thursday or Friday to fix any issues. My guess is Facebook is closer to the "cowboy coding" methodology and it's been working for them.
以下是我的观察结果：
测试驱动开发：否
领域驱动设计：是
模型驱动设计/架构：是
你测试吗？ : 是的
单元测试：是
集成测试：是
验收测试：是
代码审查：否
创新技术（Spring、
休眠、Wicket、JSF、WS、REST、
...) : 是
敏捷结对编程：否
UML：是
特定领域语言：是
需求规范（如何？）是
持续集成：是
代码覆盖工具：否
通用领域模型：否（这是什么意思？）
通信（维基、邮件、即时通讯、
邮件列表、其他文档）：Wiki、邮件、IM、邮件列表
工作量估计：是
团队规模：2-4 名成员
代码指标：是
静态代码分析：否
错误跟踪：是
Here are my observations:
Test-Driven-Development : No
Domain-Driven-Design : Yes
Model-Driven-Design/Architecture : Yes
Do you test? : Yes
Unit Testing : Yes
Integration Testing : Yes
Acceptance Testing : Yes
Code Reviews : No
Innovative Technologies (Spring,
Hibernate, Wicket, JSF, WS, REST,
...) : Yes
Agile Pair Programming : No
UML : Yes
Domain-specific languages : Yes
Requirement Specification (How?) Yes
Continous Integration : Yes
Code-Coverage Tools : No
Aenemic Domain Model : No (What do we mean by this ?)
Communication (Wiki, Mail, IM,
Mailinglists, other documents) : Wiki, Mail, IM, Mailinglists
Effort estimates : Yes
Team size : 2-4 members
Meetings : Every Monday fix meetings and every other day floating meetings
Code metrics : Yes
Static code analysis : No
Bug tracking : Yes
你看过 NDepend 吗？ 该工具分析 C# 和 .NET 代码，并具有大量很酷的功能来浏览分析结果。 使用 NDepend，您可以在代码上编写规则，您可以比较代码库的 2 个版本您可以利用 80 个代码指标。
此外，该工具还具有几个出色的可视化功能，例如：
依赖关系图：
依赖关系矩阵：
通过树形图进行代码指标可视化：
Did you have a look at NDepend? The tool analyze C# and .NET code and comes with plenty of cool features to browse the analysis results. With NDepend you can write rules on code, you can compare 2 versions of the code base and you can harness more than 80 code metrics.
Also, the tool comes with several great visualization features like:
Dependency Graph:
Dependency Matrix:
Code metric visualization through treemaping:
很高兴听到 MDA、DDD 和结对编程没有在任何地方使用：D Martin Fowler 不是神，只是有一些奇怪想法的人。
its nice to hear that MDA, DDD and Pair Programming is not used anywhere :D Martin Fowler is not god, just guys with some weird ideas.