自从我两年前开始作为专业软件开发人员开始我的第一份工作以来,我读过很多关于普遍接受的方法(例如Scrum,XP),技术(例如EJB,Spring),技术(例如TDD,代码评论)的文章.软件公司的工具(bug跟踪,维基)等等.
对于其中许多人,我发现我们公司没有使用它们,我问自己为什么.我们做错了还是仅仅是我读过的这些文章并没有真正说明它在现实世界中是什么样的？这些文章更具学术性吗？
那么,请告诉我你公司的情况.讲述有关软件开发的所有内容.以下是一些建议(按照我的想法顺序).至少告诉你是否这样做,或者做一个简短的评论:
测试驱动开发
领域驱动,设计
模型驱动设计/建筑
你考试吗？
单元测试
集成测试
验收测试
代码评论
创新技术(Spring,Hibernate,Wicket,JSF,WS,REST,...)
敏捷
配对编程
UML
特定于域的语言
要求规格(如何？)
持续整合
代码覆盖工具
贫血领域模型
沟通(维基,邮件,即时通讯,邮件列表,其他文件)
努力估计
团队规模
会议
代码指标
静态代码分析
错误跟踪
...
请记住:我想知道你真正做了什么,而不是你想做什么或认为你应该做什么.
测试驱动开发 - 没办法.
领域驱动设计 - 什么设计？
模型驱动设计/架构 - 什么设计？我们有一个架构团队.除了一个例外(最初级的建筑师),他们无法用纸袋编码.不过,他们肯定擅长用线条绘制盒子!并建立蹩脚,毫无价值,过于通用和完全无用的标准.(旧的OPC的东西还可以,但是过去4年左右,UA标准已经"完成了下个月".)
你考试吗？ - 是的,我们确实有一个专门的测试团队.每10-12个开发者大约有1个测试者.他们完全被淹没了.问我是否测试得好.
单元测试 - 完全非正式/由开发人员决定.当我给出的时间表允许时,我这样做.
集成测试 - 是的.鉴于我们开发和支持的产品套件,这是必要的.
验收测试 - 是的,仅适用于合同工作.
代码评论 - 始终支付口头服务,从来没有做过.
创新技术(Spring,Hibernate,Wicket,JSF,WS,REST,......) - 强烈反对采用新的依赖关系.Boost永远不会被采用,例如,我们通常很幸运能够获得更新版本的.Net,如果通常在曲线后2年左右.
敏捷 - 号管理层声称要"敏捷",尽管他们没有表现出对它的本质的最深刻理解.我们最近刚修改了我们的流程,以便更高优先级的任务被指定并实现...(等待它)更高的优先级!管理层告诉我,这是我们新的"敏捷"流程.它仍然像瀑布一样闻起来,散步和嘎嘎叫.
结对编程 - 没办法!支付两个人做一个人的工作？接下来你会建议开发人员浪费时间在设计和代码审查等废话上.狗,猫,住在一起!
UML - 不.我们有一次UML工具可以帮助我们理解已经发展的遗留代码库.负责评估该工具的人非常喜欢它,它在不到30秒的时间内对整个百万+行C++代码库进行了逆向设计!在他们谈到购买它并且实际的开发人员试图使用它之后,我们发现它真的花了30秒才解析95 +%的代码库.错误报告非常糟糕,评估人员甚至没有发现它失败了.(我正在看着你,孩子!)我们只花了一年半的时间才开始放弃我们的执照.看到？敏捷!
特定领域的语言 - 它们可能在某个地方使用,但不是我自己.
需求规范(如何？) - 产品经理执行一些伏都教并发明它们.有时他们甚至可能会与客户谈论他们!如果你真的很幸运,他们甚至会理解用例和需求之间的区别.不过,不要指望它.我们实际上并没有用例.
持续整合 - 没办法.一切都破裂的时候更令人兴奋.
代码覆盖工具 - 曾经有人在寒冷的服务器机房中的源存储库服务器上放了一个空白.这算数了吗？
贫血领域模型 - 严肃地说,我以前从未听说过这个.
通讯(维基,邮件,即时通讯,邮件列表,其他文件) - 备忘录.Lotus Notes不执行 "电子邮件".一堆新奇的垃圾.
努力估计 - 不是真的.在我的组织中,Estimates是目标代码..在项目的瀑布开发的5个"敏捷"阶段的第一阶段,项目的截止日期被锁定.这些截止日期被称为"球场估计",但实际上意味着"发货日期".
团队规模 - 根据产品运行色域.如果你包括经理,我们的团队只有四个,大到十五个.
会议 - 如果你是相对初级的并且没有超过一两种产品的工作,那就不错了.我每周只需要参加2-3次1小时的会议.
代码指标 - 没有.
静态代码分析 - 理论上用于.Net b/c FxCop是内置的,它的使用是我们的标准强制要求的,但实际上,没有.没有人检查它b/c从来没有任何代码审查.只是偶尔进行质量审核(又称纸质跟踪/非责任审核),以确保我们不会失去今年的认证.
错误跟踪 - 是的,但仅限于客户报告的问题.不允许开发人员提交已发现的错误,这些错误是针对他们正在使用的不是"团队合作者"的b/c产品.(当我犯了这个错误时,我老板的老板非常详细地向我解释了这一点.我现在对一位愿意"发现"我在其他支持相关沟通过程中"偶然"提到的错误的客户表示友好. .)
至于大企业,不管怎样,那里的情况要糟糕得多.鉴于我居住的地方,以及该地区缺乏高科技工作,我实际上很幸运能够举办一场演出.但这并不意味着我必须喜欢事物的方式.即使试图影响既定的企业文化,也需要花费大量时间和持续的压力.
但如果他们厌倦了我改变文化和解雇我的努力,那么,我认为那天晚上我不会哭泣.
我认为着名的Big Ball of Mud模式描述了很多工作环境,并为你提供了一些关于如何对抗这种事情的好主意.
顺便说一句,我意识到我并没有直接回答你的问题,但是在一个令人沮丧的大部分开发情况中,大球泥流动.您可以询问测试驱动的开发和缺陷跟踪以及其他类似的事情,但如果从我所看到的事实中得知真相,我会说泥球的大球几乎是人们工作的事实上的方式 - 他们应该或不应该.
京公网安备 11010802040832号 | 京ICP备19059560号-6 