
开发管理
iteye_18906
这个作者很懒,什么都没留下…
展开
专栏收录文章
- 默认排序
- 最新发布
- 最早发布
- 最多阅读
- 最少阅读
-
关于Detail Design
上周一个小feature的DD花了我一周的时间!还是 Agile 好啊:写出详细准确的user case,结合UML(class diagram and sequense diagram)和适当的文字说明,适当的代码注释不能少。不过,写DD的过程也是个熟悉框架、代码,并予以完善的过程。 产品框架设计的不错,代码里常用的design pattern、multi-thread用的不少。代...原创 2009-03-06 23:41:16 · 148 阅读 · 0 评论 -
软件开发工程化、过程化与量化的思考
“软件工程”这个词由来已久,今天忽然感觉有些别扭,记得在某本书里好像看到该词来源于建筑工程,而当前的软件行业中很多情况下很难用“工程”一词来形容,或者说,当前的软件开发现在很难用笼统的过程来定义,比如“需求分析、概要设计、详细设计、开发、测试”。 当然,由于敏捷的概念越来越被人知晓,传统的瀑布式模式已经部分的被不少公司抛弃,但行业中一些人们的思维习惯有时仍然摆脱不了“工程”的影子,总...原创 2011-03-18 11:24:51 · 295 阅读 · 0 评论 -
简单设计与简化流程、简化管理
敏捷设计中有一条原则是:简单设计,够用就好. 反观我们所在的公司的管理,其实也有类似之处. 经常有这种情况:一天的工作中时不时的要被与当前工作无关的事情打断,再回来继续自己的工作时,思路已经不在了. 尽管当前已经有不少公司在实施敏捷的实践,但做到公司级的恐怕寥寥无几,我有时把outlook关掉,但有些"事情"又容易被误解. 现在想来,有个愿望不知能否实现: team在一天的某个时间段...原创 2011-02-12 16:16:09 · 377 阅读 · 0 评论 -
重构与framework生成的思考
这段时间一直在考虑重构与设计模式。思考了些东西,暂时写下来。 不少人对agile team的code的设计不满,这是真实的现实,我也是。因为前期对于framework之类的设计一般不会投入过多,这没什么问题。但问题是agile team需要重构,而由于种种原因,重构没有有效进行,这会使得设计变得逐渐混乱。 一种做法是找一段时间,大家一起基于framework重构,这有些危险,尤其是...原创 2011-01-27 09:42:08 · 127 阅读 · 0 评论 -
由一个team内的code merge问题引发的思考
stand up meeting上,几个做同一模块的同事都说到merger代码很头疼,花费了很多effort,有同事重构了sub module依赖的base code, 有多位同事修改了相同的文件。SCM为CC,每个人有自己的sub-stream 和view。 简单看一下,问题很common,每个人闷头做自己的task, code merge的频率小,UT滞后于source code。比...原创 2011-09-16 15:59:24 · 379 阅读 · 0 评论 -
敏捷设计的可扩展性考虑
这段时间在重构代码,这些代码是基于上一版本的,当前版本在功能上去掉了很多,而代码一直没有做大的改动,里面有原因很多基于扩展性而做的设计,现在看起来很多都用不到了,代码也很难看懂,我正在考虑如何简化它们,产生了扩展性到什么程度的疑虑。 一点想法,所谓的扩展性不能依赖于开发者的想象。设计人员在项目开发过程中,需要把技术严格的放到业务后面,加强与客户的沟通,强化自己的业务理解,基于当前业务需要...2010-04-16 09:43:54 · 174 阅读 · 0 评论 -
从实际出发
记得前几天看到一个关于是否写UT和一个“过度设计”的帖子,结合自己工作中的事情随便说说。 好多武侠小说中有这样的情节,高人教导某大侠:忘掉所有的武功,于是该大侠便无招无式也可胜敌了。记得一本拳经上说“拳无拳,意无意,无意之中是真意”。UT、测试驱动、设计模式等都是手段,我们要的结果是在规定成本内作出符合客户要求的产品或项目。质量,当然是越高越好,高到什么程度,客户认可是底线。 ...2009-10-15 16:54:10 · 113 阅读 · 0 评论 -
TDD学习笔记
1.TDD源于需求2.TDD促成设计3.TDD与代码覆盖率没有直接关系4.TDD讲究小步快跑,有点增量开发的意思,不要把所有Test case都写完了再去写实现。5.不要在一个test case中写多个或过多的assert...原创 2010-01-06 16:50:26 · 219 阅读 · 0 评论 -
这种情况下如何应用敏捷提高效率
小组目前的组织形式还是部门中的开发小组的构成形式,小组工作目前基本是维护、升级既有系统,每个人负责一个模块,每个人负责的模块都非常独立,模块间没有什么关系,各成员对其他成员做的模块也不熟悉,但每个模块都会依赖位于异地的其他team的输出,比如jar;每个模块应用的开发技术虽然都是java但具体技术都不一样。团队成员日常工作大部分时间是调查、修改各自模块中测出的bug,或增加新功能。配置管理工具...原创 2010-01-04 14:55:09 · 158 阅读 · 0 评论 -
有感于今日的Agile Software Development Introduction
上午参加了公司内部的一个Agile入门宣讲,会上简单介绍了Agile、XP和Scrum的一些理论。会上有一些讨论,我对其中的一些问题做了简单思考。1、有人提出:在取任务时,不少团队成员会报出高的时间估计。从一些资料和我的经验来看,大多数开发人员比较激进,估算的开发时间常常小于其实际的开发时间。当然,这也因人而异,具有丰富的估算技术和经验的人会有较为准确的时间估算,这里也不排除,一些开发...2009-10-30 13:14:36 · 121 阅读 · 0 评论 -
Fitnesse for designer
对于design,当前我们存在这样的问题:test code够不完善,有bug不好发现,发现了不好定位,改完了可能引发其他问题而test code能够跑过。 这个想想以前定义的关于“root cause”和“code coverage improvement”的story应该可以了解。 Fitnesse用于regression testing, daily-build integra...原创 2011-03-23 11:29:50 · 179 阅读 · 0 评论