banner
- 浏览: 52601 次
- 性别:
- 来自: 北京
-
最新评论
-
dingding5060：
您好！
我自己写了一个类继承viewpart，实现一个导航树 ...
How to close a viewPart in RCP -
banner：
对于我们，其实都在工作中不断寻找着改进工作、提升效率并且适合自 ...
这种情况下如何应用敏捷提高效率 -
zhanyingle_1981：
敏捷只是手段，最重要的是定位你要解决什么问题。
鉴于楼主说的 ...
这种情况下如何应用敏捷提高效率 -
stevensinclair：
所谓的敏捷 就是一个忽悠世人的概念 大家却还乐此不疲 悲哀
...
这种情况下如何应用敏捷提高效率 -
cow13000：
MS我所在组也是这样，甚至连组员间使用语言都不统一。。
暂考 ...
这种情况下如何应用敏捷提高效率
文章列表
Some comments of RMI
- 博客分类：
- Java基础
1.About Stub:
java.rmi.server.RemoteStub is a class that implements the Serializable interface. The RMI serialization mechanism knows that whenever a remote server is "sent" over the wire, the server object should be replaced by a stub that knows how to communicate with the server (e.g ...
stand up meeting上，几个做同一模块的同事都说到merger代码很头疼，花费了很多effort，有同事重构了sub module依赖的base code， 有多位同事修改了相同的文件。SCM为CC,每个人有自己的sub-stream 和view。
简单看一下，问题很common,每个人闷头做自己的task， code merge的频率小，UT滞后于source code。比较忙，不详细分析了：
1、估story时、拆task时就应看到多个story或task有共同frame的倾向，coding之前或前期就应有简单的沟通，讨论framework，这时当然不宜在framew ...
对于design，当前我们存在这样的问题：test code够不完善，有bug不好发现，发现了不好定位，改完了可能引发其他问题而test code能够跑过。 这个想想以前定义的关于“root cause”和“code coverage improvement”的story应该可以了解。
...
“软件工程”这个词由来已久，今天忽然感觉有些别扭，记得在某本书里好像看到该词来源于建筑工程，而当前的软件行业中很多情况下很难用“工程”一词来形容，或者说，当前的软件开发现在很难用笼统的过程来定义，比如“需求分析、概要设计、详细设计、开发、测试”。
当然，由于敏捷的概念越来越被人知晓，传统的瀑布式模式已经部分的被不少公司抛弃，但行业中一些人们的思维习惯有时仍然摆脱不了“工程”的影子，总摆脱不了过程化、量化。比如很多公司对quality有要求，规定测试覆盖率、单元代码行出现bug的数量不能超过多少多少等等。我们可以想想，开发人员能像流水线上的工人一样吗，我们的项目能像天朝的房地产项目一样 ...
敏捷设计中有一条原则是:简单设计,够用就好. 反观我们所在的公司的管理,其实也有类似之处.
经常有这种情况:一天的工作中时不时的要被与当前工作无关的事情打断,再回来继续自己的工作时,思路已经不在了. 尽管当前已经有不少公司在实施敏捷的实践,但做到公司级的恐怕寥寥无几,我有时把outlook关掉,但有些"事情"又容易被误解. 现在想来,有个愿望不知能否实现: team在一天的某个时间段专注于工作,屏蔽外界的打扰.以前有封闭开发的经历,那种状况下,感觉工作效率提高了不少.
说到流程,这个有些敏感,流程在某种情况下是一种管理/控制工具, 由于自组织的局限性,很多流程 ...
这段时间一直在考虑重构与设计模式。思考了些东西，暂时写下来。
不少人对agile team的code的设计不满，这是真实的现实，我也是。因为前期对于framework之类的设计一般不会投入过多，这没什么问题。但问题是agile team需要重构，而由于种种原因，重构没有有效进行，这会使得设计变得逐渐混乱。
一种做法是找一段时间，大家一起基于framework重构，这有些危险，尤其是在UT与FT不完善的情况下。我倾向于大家在日常做好功课，这几天在改一个bug时对此更有体会，UT不全，代码混乱，改代码困难，时间又紧。如果大家在平时能够写出“好看”一点的code，即使没有规规矩矩的fram ...
什么是Cyclomatic Complexity，以及其计算方法，这里不做讨论。
圈复杂度可以用PMD(http://pmd.sourceforge.net/)分析出，它有相应的eclipse plug-in。
一般我们会用重构来降低圈复杂度，重构办法有：
1、Extract method
2、合并条件分支，合并后可用boolean变量来替换条件分支中的语句。例如：
//合并后的条件分支
// if (((Name)names[i]).getKey() > ((Name)names[j]).getKey() && b>a && c& ...
我接触到一个scrum team， 在拆分story的task时，按照如下规定：
1、一个工作日的理想工作小时为5个；
2、story point总数量乘以3（3是team的经验值），即是这些story总的要花费的小时数。总的小时数除以5即得出要花费的天数。
对规定1，我不反对；对于2，这个team这样做的目的也许是为了计算作完一个项目需要的时间，我认为笼统的乘以一个常量得出“理想”小时数欠妥。story point数量本身就是一个估算值，乘以一个常量无疑是将其误差放大了。记得《敏捷规划与估计》好像提出不要试图确定story与task之间的计算关系，并且这本书提出用story point/sp ...
进入公司后，开始接触clearcase，之前用过VSS、CVS、SVN。我是一个比较懒的人，也是一个不太爱钻研这类工具的人，单纯从一个coder角度说，clearcase用起来太麻烦了。网上对此有不少争论，我也不想说太多。现在进入了一个用敏捷开发的team，clearcase还在使用，每次只能rebase才能看到别人的代码，而提交代码每次都要mkbl、deliver，所谓的team内代码共享没有直接实现，真受不了。也许有人会说，用不好不能怪工具。我一直认为，简单易用是衡量工具的一个很重要的标准。
公司一直讲控制成本，clearcase好像不便宜，每天开发人员在它上面花的时间成本更别提，关 ...
抒发一下对煤炭总医院医生的气愤
- 博客分类：
- 生活
老婆昨天从医院剖腹产出院了，我当父亲了，本来很高兴的一件事。可想想老婆在北京煤炭总医院这段时间的住院经历就不舒服。
妇产科的陈大夫，叫什么不清楚，态度相当的让人不敢恭维，说话尖刻。有一次老婆向另外一个大夫问了问某项检查的事，那位值班的陈大夫竟然跑过来说：不知道你们是不是有当大夫的亲戚或朋友，你要做什么检查，我们都有安排，你们不需要知道的就不要知道。当时我都想抽她，想想还要在医院待着，就没说什么，想想真TMD后悔。
上周某天（大概是5月1日或2日），老婆的刀口一直很疼（后来才发现是刀口上装的拉链掩住了肉），大夫一直没给看，那天我想让大夫看看，护士说值班大夫正在睡觉，叫醒了她她会不高兴的 ...
这段时间在重构代码，这些代码是基于上一版本的，当前版本在功能上去掉了很多，而代码一直没有做大的改动，里面有原因很多基于扩展性而做的设计，现在看起来很多都用不到了，代码也很难看懂，我正在考虑如何简化它们，产生了扩展性到什么程度的疑虑。
一点想法，所谓的扩展性不能依赖于开发者的想象。设计人员在项目开发过程中，需要把技术严格的放到业务后面，加强与客户的沟通，强化自己的业务理解，基于当前业务需要对设计进行适度扩展。用频繁的多方面的交流来降低后续扩展的风险与成本。这个交流是多方面，可以是挖掘需求、澄清需求、确认需求，也可以是通过某种方式拒绝需求，当然更可以是与客户的感情沟通。
昨天在用Maven2.0.9 run mvn site的时候突然遇到了这个error。google了一下，说这是个maven的bug（见http://jira.codehaus.org/browse/MNG-3139和http://jira.codehaus.org/browse/MSITE-228，后面用附件把这两个页面东西粘上了）。
由于用的maven是server上的共用maven，不方便停restart，只好从网上down下了maven-default-skin-1.0.jar和对应的pom，然后install到了local repository上；再run,还是不行。看 ...
1.TDD源于需求
2.TDD促成设计
3.TDD与代码覆盖率没有直接关系
4.TDD讲究小步快跑，有点增量开发的意思，不要把所有Test case都写完了再去写实现。
5.不要在一个test case中写多个或过多的assert
小组目前的组织形式还是部门中的开发小组的构成形式，小组工作目前基本是维护、升级既有系统，每个人负责一个模块，每个人负责的模块都非常独立，模块间没有什么关系，各成员对其他成员做的模块也不熟悉，但每个模块都会依赖位于异地的其他team的输出，比如jar；每个模块应用的开发技术虽然都是java但具体技术都不一样。团队成员日常工作大部分时间是调查、修改各自模块中测出的bug，或增加新功能。配置管理工具应用的是clearcase，每个模块都有自己的project。
从具体上讲应用TDD、daily build、持续集成倒是可行，但每个模块都需要要有自己的daily build project。小组 ...
上午参加了公司内部的一个Agile入门宣讲，会上简单介绍了Agile、XP和Scrum的一些理论。会上有一些讨论，我对其中的一些问题做了简单思考。
1、有人提出：在取任务时，不少团队成员会报出高的时间估计。从一些资料和我的 ...
- 2009-10-30 13:14
- 浏览 884
- 评论(0)