读微博小感
2011-03-09 by 嘉瑜, Category: 码农日记, Tags: 求思 No Comments 0次浏览
我觉得我还根本没能知道TDD究竟是个什么玩意的时候，我只体会到那种由上至下、由大到小所带来的好处，一天的开始，如果能够给自己10分钟左右时计划今天需要做什么，那比一上班就抓着头天留下的工作，感觉上，要强上很多。去年老大偶尔会提到“写design document”，我觉得写design doc真的是挺耽误时间而且蛮马后炮的事，因为我还没有学会如何在开发之前就写清楚design doc，而我总是将它做成了软件文档，所以我觉得那些文档化有时性价比实在不算高，特别是我这人有完美主义的弊病，所以容易浪费大把时间，很心疼。我在这次quote时，尝试着自己“偷偷”用了一种test-fist的概念，我在想，虽然BA将需求将SPEC已经细节到了牙齿上，可如果能自己按照这个流程，写出简单却尽可能全面的test-case，那这个quote就真的不是在“走过场”，纵观全局，这感觉就象站在了小上坡了，就象看书要先看TOC，就象画画要先描轮廓，这样我写代码的时候，就能做到胸有成竹了，而且事先的impact analysis，即使好像是在double work，不过从后期来看，用老大的话说“未必真的比你不做这些分析文档用掉的时间多”。
工作中，有很多东西都需要自己时刻用一种重新审视的态度，偶尔学会批判自己，这样可以从不同角度来审视，就象几个思维在内部brainstorm一样，很崩溃很分裂很浪费时间很高压，不过收益是有的。近来在新浪微博、博客园和InfoQ上，真的有看上很多让我惊喜的内容，体会到忙碌一天后，微博快速阅读与分享所带来的便利。摘抄今天刚看到的，如下：
@李开复：网友问如何提问才是好领导：1）愿意承认“我不知道”，2）鼓励提问，3）解答的过程才是重要的，不是寻找“正确的答案”。4）正面提问、鼓励性提问，5）专心听，不要打断，正面回馈， 6）避免质询，问“这是谁的错”，7）记得常问：“我可以如何帮助你？”，8）用开放式问题，引导员工自己解答疑难。
@王晓明同学：不但领导，每个团队成员都要做到。增加四条交流时候的注意事项：1) 避免过早定论，“这样设计肯定不对”；2) 通过5Why来寻找问题本源(root cause)，最终帮助团队找到针对本源的解决方案；3) 淡定； 4) 遇到跑题的情况要及时打断，“我们来focus眼前这个问题，您的观点很有价值，我们稍后讨论”
我自己有些很严重的问题，我在过去这大半年，我在很有意识的争取去避免，争取最后能够开成习惯，
- 我是属于一说话就停不下来的人，而且说话会非常快，似乎是急着将自己的想法全盘脱出，我将这种思想筛选重组的过程给略去了丢给了listener，而且经常就喜欢用brainstorm的方式说话，想到就说，好坏不论。我一点都不害怕说出自己的不足，甚至不害怕表露自己的缺点和成长中的那些扭曲和蹒跚，有时我也会想，这是不是一种正确的说话方式。
- 我有个非常大的毛病，就是不喜欢one time one thing，比如对方在说A的时候，我很容易把注意点又分散到B，当然A和B是有关联的，不过在当时的context下，B是可以“暂缓再议”的，我这一点，就好像把议题给跑了，遇到这种情况，如果是和WY开会，她会非常果断的将我拉回来，她会说“one time one thing, let’s focus on this now"。
- 老大曾不止一次的说过“you’re not a good listener“，我开始其实蛮不懂的，因为我比较喜欢打断别人，去年年中以前，我这问题非常明显。我当时总固执的认为我记性很不好，你在说话的时候，我灵光一闪就必须扔出来告诉你、打断你，你得过会再接上去，这会我一定要表达我的见解。后来我思考过很多次，觉得打断别人不止是不尊重了，更有可能是失去了听取别人的意见的好机会。我将签名改成了“想要打断人家说话时，就咬住自己的舌头”，不过舌头后来的确是没有咬了，可好处是后来我都会很有意识的避免随机去打断任何正在表达自己见解的人。
不过这三点，我都还在不断的修正中。至于5 why，这东东我有09年底研究过的，觉得非常有趣，指的是问为什么要刨根，一直问到第5个，随便来举个例子：
场景一：这个为什么(1)会出错? 因为我改了。你为什么(2)要改? 因为我觉得它不好我想重构。那么为什么(2)BA没有测到? 因为我没有做完整的impact analysis而且没有告诉BA。你为什么(4)没有告诉BA? 因为觉得这个改动很小，我顺手可以做了，而且我以为它会没有问题的。
这样一步一步刨根问底，就可以发现一个表面简单的问题背后更深层的原因，这样就能更早发现问题，更早收集缺陷。以能得到及时改进 – 不管是从认知、流程、沟通、工作方式等方面。当然我举的这个例子实在太小了点，如果真要有人有个BUG我要这么的刨下去，问题没怎么发现，倒把人给刨走了。其实在自我管理、anti-pattern, anti-management的团队中，这种过程倒更多的是应该用来省视自己。所以可以将它改成这样 –
场景一（改）：这个为什么(1)会出错? 因为我改了。我为什么(2)要改? 因为我觉得它不好我想重构。那么为什么(2)BA没有测到? 因为我没有做完整的impact analysis而且没有告诉BA。我为什么(4)没有告诉BA? 因为我当时觉得这个改动很小，我顺手可以做了，而且我以为它会没有问题的。
这样的话，效果是不是会完全不同呢?
@王晓明同学：分析一下我们的开发慢的原因：1. 产品经理想一步到位，在concept没有得到用户验证的情况下过度开发；2. 缺少必要的需求分析，很多需求没有想清楚；3. Dev没有强烈的质量保证观念；4. Dev不关注细节；5. 没有遵循敏捷原则Simplicity–the art of maximizing the amount of work not done–is essential.
这个“过度开发”的说法太有意思了，我非常的感同身受。就是我在第一段中说到的另一个问题，我经常喜欢看到有点挑战性的工作，就当即磨刀霍霍的开干起来，通常有时那个resolution客户都没有正经确认，如果这个阶段还在anaylsis，还在确定这次iteration的backlog时，我就动手开始做了，甚至有次有觉得legacy code太丑看上去看难看，所以直接把它大刀阔斧的给重构了下，我根本没有获得BA的反馈和确认，其实这就是一种“过度开发”，过度开发，在我身上表现出来的结果，就是BA很无奈，你告诉她你已经做了，她会需要为了catch deadline重新调整自己的需求来适合你，打乱很多事，我记得WY曾经和我说过“your intention is good, but as a BA, I can see farer than you”，还提到，"you’re develop a long-standing project, there maybe has a lot of legacy code which are bad, but please stop it first“这话说得太棒了，后来我又看到一篇文章，里面讲到这种coder恰恰是最可恶的，因为他好心的随手重构了下，可是未来可能带来很难troubleshoot的BUG，这问题，我经常犯，比如我觉得以前的一个popup小公共方法没有把窗口居中，我觉得很难看，就随手给居中了，结果后来另一个页面就看上去完全不是那么回事。所以我后来一直在克制自己，尽量从客户角度思考，而不是凭自己喜好局限在自己的思维里。这又得提到design doc和test-first的优点了，如果先有全局思考，则会比较少的限在这些局部问题中，而是从大局出发，考虑全局。（关于这个，我依然还在学习和思考中）
@王晓明同学：技术人员通常会犯两种错误:1. 学而不思，比如网上看到一种新颖的设计就建议在自己的产品上应用，没有考虑使用场景，用户需求及所面对的问题。2. 思而不学，比如遇到一个问题即刻冥思苦想，尝试各种方法来解决，其实最简单的办法是看这个问题是不是有人解决过，直接利用现有方案即可。即学且思才是王道。
@王晓明同学：有两种“聪明”的领导。一种是“Smart”，智商超长，任何事情喜欢亲历亲为，喜欢团队按照他的方法做事，追求完美，关注细节，关注过程；另外一种是“Wise”，喜欢聆听，提供辅导，帮助团队建立流程，利用工具，使团队可以自组织的完善流程，做好事情，更关注结果。你喜欢哪一种？
@王晓明同学：沟通能力(或者说影响能力分4种):Persuasion, Assertion, Bridging 和Attraction。演讲使用Persuasion和Assertion的能力，是让听众可以接受你的观点，并且信服。日常的交流主要使用Bridging和Attraction的能力，为了可以更好的理解大家的观点，并且使团队达成一致。交流能力是资深开发人员的必备技能。
容易成功的10种能力：1.解决问题时的逆向思维能力 2.考虑问题时的换位思考能力 3.强于他人的总结能力 4.简洁的文书编写能力 5.信息资料收集能力 6.解决问题的方案制定能力 7.超强的自我安慰能力 8.岗位变化的承受能力 9.勇于接受份外之事 10.积极寻求培训和实践的机会
再谈敏捷和ThoughtWorks中国咨询师
TDD的学习资料
书：
- Kent Beck的“测试驱动开发”
- Martin Fowler的“重构”
- Bob大叔的“敏捷软件开发原则、模式、实践”和“代码整洁之道”
- Michael Feathers的“修改代码的艺术”
- Gerard Meszaros的“XUnit模式”
- Roy Osherove的“The Art of Test Driven Development”
- Steve Freeman的“Growing Object Oriented Software Guided by Tests”
- Eric Evans的“领域驱动设计”等。
视频
- 到Google去查Kata
- James Shore的“Let’s Play TDD”系列
Tags: 求思
