chelsea
- 浏览: 117848 次
- 来自: ...
-
最新评论
文章列表
跨团队的持续集成: 几个基本矛盾
- 博客分类：
- 道
单个团队内部的持续集成已经是成熟的实践. 跨团队的集成则碰到了很多问题, 包括全部测试运行时间过长,
合并成本高等问题. 针对这些问题有一些对应的解决方案, 如合理的分支策略, 分层的集成等.
这里想讨论一下几个基 ...
敏捷质疑: 迭代开发
- 博客分类：
- 道
迭代在于我们明确的承认信息和知识的不完备性, 不可完备性. 而项目的成功, 需要某种程度的完备性.
这种认知的局限与成功的条件之间的矛盾, 促成了人们解决这类问题的通用方法: 渐进的试错法
试错法参考一: http://en.wikipedia.org/wiki/Trial_and_error.
试错法参考二: http://zh.wikipedia.org/wiki/%E8%AF%95%E9%94%99%E6%B3%95: 是解决问题、获得知识常用的方法，即根据已有经验，采取系统或随机的方式，去尝试各种可能的答案。当问题相对来说比较简单或范围比较有限时，试错的方法有一定效果。 ...
http://www.infoq.com/articles/scaling-lean-agile-feature-teams
Feature Team
long-lived—the
team stays together so they can ‘jell’ for higher performance; they take on
new features over time
cross-functional
and cross-component
co-located
w ...
- 2009-06-28 22:30
- 浏览 581
- 评论(0)
敏捷质疑: 持续集成
- 博客分类：
- 道
Q: 我的产品是电信级的设备, 几百人分成几十个项目组在开发, 各个项目组进度不统一, 如何集成?
A: 你要做的其实跟技术无关, 更多的是管理工作, 就是制定你的产品级别的集成策略.
这涉及到需求分析和发布计划(依赖管理, 价值和风险识别), 开发方法(自顶向下还是自底向上, 横向分层还是垂直特性),
集成粒度划分(完整特性的集成还是API的集成), 集成间隔计划, 版本控制策略, 还有尤为重要的集成测试/验证策略, 甚至你的决心.
任何集成策略在执行过程中都会遇到困难, 如迟迟得不到能够成功集成的版本. 这时你要找出原因, 并有权力或相应措施要求整个几百人的团队停下来,
做为第 ...
第
1
部分
让领域模型发挥作用
第1
章 汲取知识
第2
章 沟通和语言的使用:
通用语言,
大声读出模型,
一个团队,
一种语言
第3
章 将模型和实现相绑定
第
2
部分
模型驱动设计的构造块
第4
章 分离出领域:
分层架构,
领域层中存放着模型
第5
章 模型在软件中的表现形式:
关联,
实体（也称为引用对象）,
值对象,
服务,
模块（也称为包）,
建模范型
第6
章 领域对象的生命周期:
聚合,
工厂,
资源库,
为关系型数据库设计对象
第7
章 使 ...
- 2009-06-25 22:18
- 浏览 799
- 评论(0)
HTML clipboard
做了半年的东西又被否定了, 这里有两个可以改进的地方, 一个是半年, 一个是否定; 那以后干脆两星期让他们看一次, 顶多浪费两星期的工作; 想不被否定,
干脆拉他们一起来干活, 现场让他们说要啥, 立马就做啥给他看.
可两个星期就演示一次能演示啥? 架构还没设计好. 那干脆先简单直接一点, 把功能实现, 别的以后再说, 有问题再改, 别两周啥功能也没实现,
显得没工作量.
功能是做出来了, 演示也通过了, 可新的需求来了, 前面的代码要大量改动, 谁也保证不了不会破坏以前的功能. 那看来以后得写测试, 保证改动的正确性.
现在为了准备演示需要花两 ...
- 2009-06-09 23:01
- 浏览 558
- 评论(0)
xUnit测试模式--测试码重构
“脆弱测试”问题15a15
c
15a
c
151515
c
151515a15a15
4017
使用商业“记录与回放”或“机器人用户”工具的测试自动化在这些工具的早期用户中名声狼籍.a
使用这种方法的自动化测试通常因为看起来不太重要的原因而失败.a
重要的是要理解这类测试自动化的局限性,16
以免落入与它相关的陷阱——即行为敏感性.c
接口敏感性.c
数据敏感性和上下文敏感性.
- 2009-06-06 11:37
- 浏览 1259
- 评论(0)
敏捷外传之FBI: 世界上最敏捷的团队
事实上, 世界上有一支最著名的敏捷团队, 一直很少有人意识到, 这就是美国的 FBI. 虽然我们不知道它内部实际的情况, 也有不少电影把
FBI 描述的很白痴, 但是至少在<<越狱>>中 ...
需求是表单提交后, 转到另外一个已经存在的页面, 并在页面上方的空白处显示一条醒目的消息, 而且只显示一次 (刷新后这条消息不应该再出现). 对 Web 开发相当不熟, Pair说这需求类似 RoR里的 flash message, 问Java里有没有. 我们用SpringMVC + Velocity, 看了看文档, 问了问人, 短时间没有得到确定方案.那就试一试吧, 明知几乎不可能成功, 还是写下了下面的代码:
model.put("flashMessage","I'mstupid");
returnnewModelAndView(ne ...
持续集成: 实践指南
- 博客分类：
- 术
第一部分. 实现
0. 持续集成工具的作用
降低风险? No
提高质量? No
快速反馈? Yes !
工具本身并不能降低项目风险, 提高代码质量. 工具唯一能做的是给你快速反馈. 你收到反馈之后的行为, 才是降低风险, 提高质量的关键 (好几天不check
in, 工具再牛也白搭; 失败的build不修复, 工具也无能为力)
所以持续集成是一个以人为核心的过程, 工具只是在这个过程中我们要用到的一个产品, 而且绝对不是唯一的一个.
快速反馈: 快速反馈实际上是两个词, 快速 和 反馈, 而持续集成又牵扯到人和工具两个方面, 所以一个好的持续集成过程, 至少需 ...
持续集成: 流程指南
- 博客分类：
- 术
/** * 本没有流程, 公司采用CMMI, 要求有个流程, 就写了一个 */
Continuous Integration Process Guide
持续集成实施指南
像" 版本控制", "配置管理"一样, "每日构建", "持续集成(Continuous Integration, 简称CI)"等 ...
敏捷质疑: 结对编程, 代码集体所有权
- 博客分类：
- 道
Q: 结对编程、责任共享，完全是胡说，代码找不到作者，开发人员哪里会有责任心!
A: 这个疑问基于一个假设: 开发人员的责任心来自于问责制度, 开发人员只有在恐惧的驱使下才会细心去编码.
我不知道你的职位是什么, 你或 ...
Q: 为什么通过单元测试发现的 Bug 很少 ?
A: 单元测试不是用来发现 Bug 的, 而是用来预防 Bug 的. 如果采用 TDD, 测试用例完成之时, 产品代码尚未编写, Bug更无从谈起.
Q: 那是否写单元测试就能提高代码质量了 ?
A: 关于这一点, 似乎有人不这么看, <<TDD Opinion: Quality Is a Function of Thought and Reflection, Not Bug Prevention>>.
不错, 代码质量并不必然关联到单元测试, 诸如净室软件开发之类的方法依然可以在没有单元测试的情况下得到高 ...
预处理的接入点
构建脚本中的宏定义可以控制将文本解释为真正的实现还是假的实现
构建脚本中的头文件搜索路径可被用来控制接入真正的声明还是假的声明
头文件中的防卫宏可被用来接入假的声明以遮挡 ...
设计原则与模式: 案例介绍--CppUnit
- 博客分类：
- 术
设计原则与模式: 案例介绍--CppUnit
CppUnit 是一个单元测试框架, 我们看一看它的设计是如何遵循基础的设计原则和模式的
单一职责原则
TestRunner 和 TestResult 的分离
class
CPPUNIT_API TestRunner {
virtual
void
addTest( Test *test );
virtual
void
run( TestResult &result,
const
std::string &testPath =
& ...