查询icp备案跟接入的网站,免费建站哪个网站最好,ui的设计网站,株洲知名网站建设这三篇读后感原来发布在我自己申请的域名 yishan.cc 上面#xff0c;后来这个域名被墙了。 (原文写于2008年12月) 几个星期前#xff0c;我给《现代软件工程》课的每一个团队都发了一本 《Dreaming In Code》的中文版 《梦断代码》#xff0c;要求写读后感。这本书讲了这样的… 这三篇读后感原来发布在我自己申请的域名 yishan.cc 上面后来这个域名被墙了。 (原文写于2008年12月) 几个星期前我给《现代软件工程》课的每一个团队都发了一本 《Dreaming In Code》的中文版 《梦断代码》要求写读后感。这本书讲了这样的故事一群很有经验的代码牛人在先进软件开发模式的指导下没有资金压力在更多大牛的带领下原计划用一到两年的时间开发出一个备受期待的个人信息管理软件(PIM)后来花了七年时间才完成这一创举但是已经无人喝彩。我是9月份读的英文版后来又翻阅了中文版也有一些感想如下。 1)驱动 到底是什么驱动程序员和管理人员测试人员长年累月投入到一个软件项目中去 有理论认为传统的软件公司用工资职位绩效考核等让一群经过面试和培训的人在严格定义的流程下一起工作(大教堂/Cathedral模式)。其实用开源社区共享的模式会更好(集市/Bazaar模式)也许更好。正如在第26页所说的 [所有页码都是指英文版] … it maps an alternate universe for programming in which time is simply less important because the work is cooperative rather than corporate, the workers are all volunteers, and the motivation is fun and ego, not financial reward. [p26] 这理论听起来很好但是我想起了两个故事 1) 美国的一个肥皂剧Seinfield里有一集讲了一个混混Kramer 热心地加入了一家公司义务打工起初他的口头幽默和热情感动了团队领导委以重任不料Kramer 根本没法儿把事情做好。最后领导只好找他谈话Kramer 承认自己不行他说- 但是俺是义务给你们打工的 领导说对这就是让我们为难的地方。。。 项目中来了一位“义务打工的”照理说对项目只有帮助而且别人是“义务”你怎么好意思把别人赶走 2) 我以前在西雅图的时候参加过一个非营利组织成员们都是有热情为社区服务而且义务付出。但是后来有些成员就逐渐找不到了一些事情也不了了之。 由于大家都是义务贡献你没法如何要求别人。 在Chandler 项目中Andy Hertzfeld 就是这样一个义务作贡献的大牛。但是他也遇到了同样的志愿者问题 – They don’t know whether to count on you or not. And because you’re not getting paid, there’s lack of control. [p167] 后来这位Hertzfeld 也拍拍屁股走人了大家可以为 fun 和 Ego 一起工作但是如果fun 和 ego 都得不到满足或者那motivation 也会急剧下降。 2)责任 和驱动紧密相关的是责任 – Accountability. 在 Hard Drive 这本书中讲了这样的故事 – 由于Windows 一再拖延BillG 最后跟 SteveB 说 – 如果今年下雪之前Windows 还没出来你就别在这儿干了。 书中没有详细讲 SteveB 回头来又和他的团队讲了什么但是第二天一个员工背着睡袋进驻了办公室。 很多年以后Windows Vista 也经历了很长的拖延在又一次宣布拖延之后人们发现 Windows 团队中一个赫赫有名的 VP 已经卷起铺盖走了。 我们回过头来看在Chandler 项目长达7年的拖延中有没有发生过各位项目管理者引咎辞职的事 好像没有。 [有不少人离开但是没有人直接为项目延期负责] 既然我上一次拖延没有什么惩罚那我为什么一定要拼了老命要避免下一次拖延呢 在传统意义上的软件公司如果项目延期那项目原计划的收入就拿不到拖延的时间再长一些员工就得走人否则整个公司都被拖垮了。在“集市”社区共享的模式下大家都是义务大家都在玩票大家都做贡献但是对最终项目不直接负责任那到底谁负直接责任呢 在《移山之道》 中我讲了下面的例子 阿超我今天在“顶球”网吧看到大牛他爹在下棋围观者支招的不少有的说上马有的说拱卒有的说出车。大牛他爹一会儿招法就乱了眼看局势不灵了围观者一哄而散老崔后来也没法只好认输了。 一个围棋国手在一次重要的对局后听到旁观者对棋局的进程有很多不同的看法他也没有过多争辩只是说“无责任的旁观者和有重大责任的当局者的看法自然是不一样的”。 无责任的旁观者在支招后如果不灵他可以面不改色地继续支招甚至可以给另一位对局者支招不管最后谁输谁赢旁观者随时都能安心地离开回家吃饭。有重大责任的当局者在走了损招或败招之后他很可能就要认输下台丢掉比赛的奖金和头衔。 我在清华大学的这一次《现代软件工程》课我发现有些学生好像不是特别投入后来了解到由于申请学校用的GPA只计算前三年的成绩第四学年课程的分数就和申请学校没有什么关系了所以比较“鸡肋”。有一个同学说如果这门课是在第三学期那许多同学们会非常计较分数排名。现在只要能过就可以了。这也许解释了不少项目中出现了“花最少的努力能过就行”的心态。 一个软件团队可以制定出动人的远景/Vision 但是如果大家没有搞清楚驱动项目的各种因素和每个角色应付的责任那Vision只是一句话而已。 时间和交流时间对每一个人都是公平的对每一个软件项目也是这样。 nearly all software projects require only 1/6 of their time for the writing of code and fully 1/2 of their schedule for testing and fixing bugs. But it was rare project manager who actually planned to allocate developers’ time according to such a breakdown. [p17] 书中援引理论家的话说最高效的软件团队规模应该是一个人因为这样就不用交流了。 随着人数的增加依赖关系的复杂新手老手员工之间的不同步交流的成本会随着几何级数增加。在这里插播一个有奖竟猜 当Windows 研发团队在开发Windows 2000的时候团队内部每天有多少封e-mail 交流 a) 90 b) 900 c) 9,000 d) 90,000 对每一个团队成员来说他/她不仅要完成手头工作还有报告自己的进展(通过email 或其他形式)回答别人的问题了解其他人的进展。每个人的时间都是有限的那怎么能保证我们在应付所有的交流/沟通之后能有时间完成“手头工作” 一个微软的同事前两天跟我说他们最近没写什么代码集中精力做“planning” 去了大家写了很多PowerPoint改了很多PowerPoint。然后给VP, General Manger 做了两轮汇报然后根据VP们的意见再修改再汇报。。。 PowerPoint 的风格变得非常专业和花哨但是他们仍然没有完成Planning进入实质开发阶段。华丽的 PowerPoint 中的每一个条目也需要花PM 很多时间才能写明白让VP 了解同时也要花一线dev/test 很多时间才能实现但是VPPM 和 Dev/Test 面对同一个条目他们心里想的是同一回事么 外部交流 在Chandler 项目中幸运的是他们没有这么多VP 要汇报 (真正的VP – Al Gore 只露了一个小脸)但是我注意到他们用于交流的时间也非常多。例如 Every day the developers shared a chat room via Internet Relay Chat (IRC) [p139] 1 internal and 4 external email list set up. blogs, wiki’s… 这些都是花时间的我看到团队成员还要回复素未谋面的爱好者的各种问题(例如质问他们为何不用某某框架等等)当然这种透明度也满足了很多人的好奇心开源社区的优点么。。。 另一方面项目管理人员发现他们面对着大量的任务没有时间完成。就像第一章 Doomed 的开篇就说到 John is doomed, he has 500 hours of work scheduled between now and the next release… [p11] 团队中其他人也好不到哪里去。那在这种情况下是花时间继续参加各种讨论blog提供透明度 (Transparency)满足大众的好奇心还是集中精力把自己“手头的事” 搞定我从书中没有看到经验丰富的管理人员这时候采取了什么措施。事实上在产品发布之后没有证据表明那些在IRCEmailBBS 上发了很多议论的爱好者未必真正下载并使用你根据他们的意见开发出来的软件。那这么忙于交流是为嘛?! 事实上这么多交流和信息并不能帮助人们回答一个最重要的问题 – What had each programmer accomplished in the past week, and what task was next? [p141] 我的故事 – 在MS Outlook97 发布之后网上对这个V1 版本有很多意见也有很多期待。 其中很多用户在 NewsGroup (新闻组) BBS 上发表了强烈的建议要求Outlook 支持直接阅读 NewsGroup/BBS 的内容当时只有Outlook Express 有这个功能。Outlook 的开发成员一度认为用户的要求太强烈了如果我们没有这个功能可能V2就会很不受欢迎 (几个dev 已经做了一个初始版本)。 但是大家仔细分析后发现在BBS上强烈发言的就是那么几个人因为他们老用BBS因此他们的需求特别强烈并且好像声势浩大但是别的大部分用户根本就不上BBS因此也没机会表达意见。所以Outlook 决定不做 NewsGroup 的功能一直到现在。 内部的交流 除了外部的交流还有内部的交流随着一个人经验的增多会有很多其他人来找你为大大小小的事咨询你的意见。然而你自己也有无数的任务要完成怎么办微软的员工对这种情况也不陌生微软团队允许一些人 “Go Dark”他们可以关起门自己干活敲门不答应不回答一般的email不参加会议等等。 据说很早以前BillG 把开发OS/2 API 的任务交给了一个牛人这位前辈接受任务之后并没有开新闻发布会建立email distribution list, 或者QQ 群而是挂了一个和下面类似的牌子在办公室门外把门一关一个人闷头开发去了。 不要打扰、投喂办公室里的动物 我们知道交流很重要但是软件不是在QQ 群中交流出来的(当然有人在QQ 群中交流别人写好的软件)而是一些人一行行写出来的。 这个过程需要集中注意力避免打扰。在一个 “集市” 风格 “共享” 的开发氛围中如何能保证关起门来开发呢 远虑和近忧 Kapor 的团队看起来非常重视“远景” 他们似乎没有近忧 – 这也许是致命的。 他们对于软件的基本架构/infrastructure 非常关心例如对于存储系统它们提出了下列需求[p103] it has to make life easy for the Python programmersit has to operate efficiently over a networkit needs to be able to handle very large individual date items and very large numbers of itemsit has to be reliable, using database transactions.it has to support searching and indexing[0] User experience //Kapor 后来加上去的似乎不相干的一条远景。 后来对于Data Storage又有如下构想[p109] Provide programmers with as revolutionary a data model as usersdata can live anywhere.Data is safe from corruption.Data is quick to get.Data can be large. 非常令人佩服的远虑。 如果一个项目能同时实现其中3个目标就已经能实用并吸引客户开始赚钱了。 但是Chandler 项目的同志们不满足于只实现两三个他们要实现全部5个梦想。 一群牛人在 “没有近忧只有远虑” 的条件下讨论问题最后只能议而不决。 在一次次延续到深夜的讨论中有人感慨 – How is this night different from all other nights? //[p110] 没有近忧或者说不用为近忧而负责 – “我们这个月的目标没完成不要紧但是我们的远景一定要讨论好”。 导致了项目不能收敛 – 一个项目的一个里程碑中不确定的事情应该越来越少bug 也越来越少直到产品发布。 Making firm technical choices was hard in the absence of a settled design, and settling on a design was hard in the absence of a technical roadmap. [p150 – 151] 正因为大家没有近忧所以大家可以继续等待设计要等技术决定后才好做而技术的选择要等设计决定后才好开始。就这样大家折腾到2005年的时候他们才从高瞻远睹的远虑的云端中下来有了第一个脚踏实地的计划 But for the first time, at least, they could see they had a plan grounded in reality, rooted in estimates that … [p232] Kapor 毕竟是聪明人很多年以后他说到了教训 We’ve consistently overinvested in infrastructure and design… [p342] 收敛的另一个特点是 – 做过了的决定就要执行不要反复。事实上Chandler 团队在很多决定上摇摆不定。 架构师Hertzfeld 度假回来发现他带领其他同事奋战一个夏天得到的 Document Architecture 被扔到一边原来 Kapor 决定 “We’ll have to come back and realign things” [p168]。 如果你是做义务劳动的 Hertzfeld你还能做下去么 回到 “远景” 我相信几乎没有合适的解决方案能满足“远景” 中的所有要求很难找到 “多快好省” 的解决方案(书中提到 fast|cheap|good 不能兼得这也是MSF 中 time | resource | feature 三个元素的矛盾)。但是往往存在若干方案从不同的角度逼近最优但是有各自令人讨厌的缺点。我们能否有智慧来选择这样一个方案把近忧远虑都慢慢解决 我自己在微软正在做一个创新项目前几天一位加入这个项目不久的优秀的开发人员对我说我们去年设计的数据库问题太多了如果我们早就像我这样设计估计会好很多。我不是数据库的专家我只能对他说如果我们当时坚持要做到今天这样才发布这个项目也许就做不到今天了。 换句话说正是因为早期那些不完美但是及时的设计让后来者有挑剔这些不完美的奢侈机会。 我们每个人在使用这些不完美的软件(Windows, Outlook, 甚至Linux)的时候都应该感谢当初设计者做出了正确决定而那些坚持完美设计远景的项目它们都到哪去了
