2008-07-02
全文显示

你做不做？做什么啊——软件工程（旧作留念）

曾泛泛地看过本叫《代码大全》的书，其他都没记住，只记得讲到一个类比的问题，即“软件的研发”和哪种人们比较熟知的事务有可比性，以便不熟悉软件研发的人（各级管理层，客户等）能够得到个大致合适概念。很多人都把“软件研发”类比成“房屋的建筑”，我也很同意这个类比。 在上海有很多在建的高楼大厦，路过那些工地，我常常会想：即便是100万行规模的软件研发，难道就比造一幢10来层的楼难度更大吗？ 虽然也有劣质的楼房，但我武断地认为，豆腐渣的软件系统要比豆腐渣的楼多得多。我常自问这是为什么。 我不知道，是否有刚入行2年的建筑工去主持厂房的设计建造。 但我知道常有 刚入行2年1年甚至几个月的人在担当软 ...
2008-05-06
全文显示

从金融学的角度看“重构”

前些日子在InfoQ看到篇文章 "抛砖引玉——重构是必要的浪费" http://www.infoq.com/cn/news/2007/12/refactoring-is-waste. 文中认为 “重构并不能为客户创造可衡量的价值。所以将重构归为必要的浪费。 个人觉得这样的解读很牵强，也有悖于精益的基本精神。 我觉得问题核心在于重构对于客户创造了什么价值。 近日从金融学的角度来进行分析，略有所悟。 重构其实提供了“需求变化”的“看多期权”（call）--事实上还提供了其他多种变化的看多期权。需求变化的可能性越大，这份期权就价值越高。而在金融市场上充满了明码 ...
2008-01-15
全文显示

书摘1--难道这就是传说中的pair programming

摘自 《质量.软件.管理--协调行动》 第19章 成长的团队 中文版P254 下面是Jensen的研究： 研究1. 当前有5个任务需要执行,这些任务的目的是建立一个30000行的军队标准的实时 执行系统。系统有一个领导者率领10个程序员创建。在这个项目之前,这些人的 平均效率是大约75行每人月。项目领导把他们分成5组，每组2个人并象征性地 发了一支铅笔。意思是让这些团队开发每一行代码并且和他的伙伴做文档记录。 结果是以每人175行每人月的速度完成了这个系统，并且错误数不到从前每人产 生的错误数量的1%。 注：根据书中提及，这项研究应该不晚于1980年。
2007-12-08
全文显示

毫不含糊地反对结构性忽悠 (与钱有关2 )

关键字: 理财
总有人忽悠我们说现在是结构性的物价上涨,言下之意这都没什么大不了的. 宣传部门的造词能力和对汉语丰富的所做出的贡献,令人叹为观止. 转载一篇"毫不含糊地反对通货膨胀" http://www.zhouqiren.com/eco_56.html
2007-03-14
全文显示

New Feature Review Question List (Draft)

听取一个客户的功能后,可以参考以下问题对功能进行审核. 审核重点在于该功能的来源,而非具体实现方式. ------------------------------------------------- 明确功能点所针对的问题来源 ------------------------------------------------- Q1. 谁是这个功能点的原始提出者? Q2. 这个功能点期望解决一个什么问题? Q3. 这个问题是谁(role)所面临的问题? Q4. 目前的工作流程是如何处理这个问题的? --------------------------------------- ...
tuti
搜索本博客
存档
最新评论