Shall We Talk?
如果会议中有人可以不发言, 那他就没有参加会议的必要
项目经理最占便宜
传统团队项目经理最占便宜, 所有人都向他单线汇报, 出了事都找他, 他知道所有的问题和解决方案, 随着项目的进行, 他的知识会被动的越来越丰富. Truck Number的一个实例
公交 vs. 地铁
说的是客户合作和开发节奏. 传统开发就像挤公交, 影响路况的因素太多, 这趟上不去下趟不知啥时候, 所以每次发布都拼命塞feature. 好的开发节奏应该像地铁, 稳定的持续的带走一批批乘客, 交付一批批feature
南辕北辙
说的是提高开发效率为啥非得用敏捷, 选择高效的平台,工具,库不也可以提高效率吗? 在效率上确实有很多方式. 而敏捷更关注有效性的问题. 你的平台工具和库都极端高效, 就像你有最好的马最好的车最好的装备, 可以一天完成十个feature或跑个一千里, 可它们保证不了这是正确的feature, 正确的方向. 敏捷也保证不了, 但它利用一切手段让方向有所偏离的时候能尽快发现.
项目经理是个不好的暗示, Team Manager over Project...阅读全文

The Trouble With Physics: The Rise of String Theory, the Fall of a Science
中译本<<物理学的困惑>>.
阿兰・康尼斯彭罗斯并不是唯一为自己创造量子引力方法的一流数学家。 也许最伟大的一一当然也是最有趣的一健在的数学家是阿兰・康尼斯. 我喜欢和阿兰谈话。有时我不明白他说什么，但他深刻的思想和绝妙的笑话令我快乐无限。（那些笑话经常是少儿不宜 的，尽管有时说的是黑洞或讨厌的卡丘流形。〉不过，虽然我不能总是理解阿兰， 他却总能理解我。他厲于那种思维敏捷的人，知道你想什么，当然也能更好地说出你想说的话。尽管他和他的思想都那么自在轻松，却一点儿也不爱争斗，对别人的思想总是怀着真诚的好奇。阿兰的量子引力方法要回到基础，发明一种能完美统一几何的数学结构与量子引力的新数学。这种数学我在第十四章 提起过，叫非对易几何. 它在根本上统一了代数和几何。只有像他那样，既探索数学又创造性、战略性地思考数学知识结构及其未来的人，才可能 创造那样的思想。
费耶阿本徳费耶阿本徳相信科学足一种人类活动，是投机者的事业，他 们不遵从一般的逻辑...阅读全文

2012-07-18
Bad Smell: Dispensable Test (新的坏味道: 可有可无的测试)<<重构>>里介绍的坏味道, 都是直接去嗅代码. 不过既然我们采用TDD, 那么代码的一切坏味道, 都会反应在测试上, 比如一个函数的测试用例组合太多, 可能意味着函数职责过多. 这在物理上称为对偶性, 即不同的表达方式, 反应的是同一件事. 两个非常不同的理论精确的描述了同样的现象. 分别让一对夫妻给你讲他们的故事，他们的说法会不同，但每个重要事件都能相互得到印证。和他们谈话多了，你就能指出两人说的故事有什么不同和联系。例如，丈夫觉得妻子过于自信，这正好印证了妻子抱怨丈夫太懦弱。我们可以说，两个人的话是互为对偶的。换句话讲, 我们可以通过观察测试而不是直接去看代码, 来发现代码的坏味道.
以上是题外话, 现在进入正题
今天在面向对象训练营的培训中, 发现了一种新的坏味道. 事情是这样的: 学员在完成按空位绝对数量多少停车的时候, 使用了继承, SmartBoy继承自Boy. 停车是不同的, override; 而取车是一样的, 代码都在基类里. 而在写测试的时候...阅读全文

简单 != 可以有Bug
“这种错误情况先不用处理了吧, 简单设计嘛!”
简单不是偷懒的借口. 简单设计是一种宏观的设计策略, 并不意味着微观上的偷工减料:
你可以没有这个功能, 但有的话必须是不能出错的.是对无法预知的需求推迟设计决定, 而不是对已知的需求视而不见这种错误情况可能确实不需要现在处理, 但理由不应该是简单设计, 而是价值和优先级分析简单 != 功能不完整
“这个功能先不用做了, 简单设计嘛!”
当听到这种说法的时候, 请确保团队的理解是一致的:
在产品设计上可能也会有”简单设计”之类的原则, 尽可能的简化功能, 突出主要卖点但我们提到简单设计的时候, 更多的是指软件架构不要过度设计, 而不是功能.最终这个功能可能确实不需要现在做, 但理由不应该是用于指导架构设计的”简单设计”, 而是价值和优先级分析.简单设计 != 不预先设计
简单设计最大的争议在于: 现在还没有这个需求, 但我很清楚这是这个domain固有的问题, 我要不要为此做设计?
其实简单设计原则有一个隐含的前提: 架构是由需求决定的. 这可以是对的. 但它忽视了另外一个事实, 就是不只有一个架...阅读全文

模式名称
SoS, Story over Solution意图
当改变相对复杂时, 通过一个故事或场景引导团队参与方案的推导过程, 而不是枯燥的说应该这么做, 以使团队对复杂的改变更加支持.动机
当一种改变看起来与直觉不符, 通常会遇到一些抵制, 典型的反对意见比如”没必要”, “自找麻烦”, “现在这样已经足够了”. 而这些反对意见有时是源于对新改变背后的原理不够了解. 此时如果强制推行, 在实际操作中也会遭到阴奉阳违的抵制, 使效果不够理想. 我们需要一种使团队更加自愿的接受改变的技巧.
方案
温伯格在<<咨询的奥秘>>中提到一条规则, 当不是直接使用从超市中购买的配好的蛋糕料包而是除了料包还要再加入自己的鸡蛋时, 味道会更好, 因为这个过程有自己的参与. 我们可以借鉴一下. 如果最后的方案制定, 有团队的参与, 那团队是不会反对自己的意见的. 我们只需要创造一个机会, 让团队参与到改变的规划和方案的推导中. 拿这次改变所针对的问题讲一个故事, 一起来推导最后的方案是一种可行的方法.
比如, 当我们需要引入”提交构建”实践的时候, 由于要比不构建直接提交多做很多工作, ...阅读全文