2007年09月07日
外科手术队是这样一种模式：一个或者两个主刀医师，main-programer或者framework-designer，负责定义整个系统的概念、约束和控制流，并将他们的工作成果交给programer去实现。就好比建筑师统一设计好了蓝图，然后由建筑队负责施工。试想如果建筑队里面的每一个家伙都兴趣盎然的给建筑的某一部分进行自己独有的设计和实现，并为了组合而相互妥协，那最终建成的东西将会是何物？想必多数人对外科手术队模式的反映是：“所有的乐趣都被main-programer和framework-designer剥夺了”，“programer岂不是沦为coder，毫无前途可言”。但其实不是，外科手术队并没有外包那么夸张，主刀医师只是定义了整个系统的概念、约束和控制流，但是并不出设计文档之类有关实现的东西，并且任务仍旧以子系统（已经被定义和约束）的形式分配，因此programer能在指定的约束下进行创造和实现。阅读全文>
发表于 @ 2007年09月07日 09:44:00|评论(loading...)|编辑
2007年09月05日
上周面试了一个开发人员，这个人所有的面试题都答出来了。各方面我们需要的知识也掌握了，但是在初试中，这个人就被我们三个面试官一并否决了。 原因很简单，这个面试者提供的答案都是能解决问题，但几乎都是效率最差的方案；另外，从一些面试题中，可以看出这人很多时候，把开发工作当成一个应付差事的工作来做，而不是作为自己的兴趣来做。缺乏激情，工作只是应付差事，仅仅是由于有几年工作经验，才能答出我们的面试题。这样的人不要也罢。最近在看《人月神话》，其中的很多知识点感触很深，很浅显的一个道理，如果让自己一个人去慢慢悟的话，就不知何时才能出来。回到本文讨论的主题，如何让自己保持激情？如何让团队保持激情？这是每一个程序员，每一个项目经理都要考虑的事情，只有有激情的团队才能产生伟大的作品。才能跟上时代的步伐。阅读全文>
发表于 @ 2007年09月05日 17:45:00|评论(loading...)|编辑
项目计划的重要性相信每个人都了然于胸。Brooks在“祸起萧墙（Hatching a Catastrophe）”一文中提及了项目计划/跟踪。另外，在其他的许多章节中，阐述了计划文档化的重要性。这里，项目计划不仅仅指的是项目进度，采用Microsoft Project所画出的仅仅是项目的进度。在具体的实践中，项目计划可以从以下若干方面考虑：阅读全文>
发表于 @ 2007年09月05日 17:22:00|评论(loading...)|编辑
2007年08月31日
迭代开发可以用“外科手术队伍”、OO及设计模式的实现来实践。面向对象框架的分析设计思想，并不一定非要用面向对象的语言实现。它的一个重要特点，是固化用户要求或者是待开发系统中相对稳定的部分，以牺牲模型某个维度的代价来得到较稳定的模型。然后，在该框架的基础上不断地迭代。“外科手术队伍”则由具有丰富经验的“外科医生”操刀，来主持需求分析和建立迭代框架。少数的人能确保框架不带有过多不必要的非结构性的功能特色，从而保证框架的简捷和良好的扩充性。 阅读全文>
发表于 @ 2007年08月31日 14:22:00|评论(loading...)|编辑
软件开发本身就是一个具有无序趋势的活动。当人们四处游走，寻找一个类似于计算机硬件那样流水线化的方式方法时，可能应该静静思考一下，这本身就是与开发内在发展规律相悖。并且，软件开发是人类的思维创造活动，同诗歌、乐曲一样，好像人类历史上还没有什么为上述创造进行流水线化的尝试。阅读全文>
发表于 @ 2007年08月31日 14:19:00|评论(loading...)|编辑
《人月神话》（32周年中文纪念版）免费试读：第1章 焦油坑 编程系统产品 职业的乐趣 职业的苦恼 第3章 外科手术队伍 问题 Mills的建议 如何运作 团队的扩建 第7章 为什么巴比伦塔会失败 巴比伦塔的管理教训 大型编程项目中的交流 项目工作手册 大型编程项目的组织架构 第16章 没有银弹 摘要[1] 介绍 是否一定那么困难？ 根本困难 以往解决次要困难的一些突破 银弹的希望 针对概念上根本问题的颇具前途的方法 第17章 再论“没有银弹” 人狼和其他恐怖传说 存在着银弹—— 就在这里！ 含糊的表达将会导致误解 Harel的分析 Jones的观点—— 质量带来生产率 那么，生产率的情形如何 面向对象编程—— 这颗铜质子弹可以吗 重用的情况怎样 学习大量的词汇—— 对软件重用的一个可预... 子弹的本质—— 形势没有发生改变 结束语 令人向往、激动人心和充满乐趣的50年
阅读全文>
发表于 @ 2007年08月31日 14:08:00|评论(loading...)|编辑
2007年08月29日
在较早的项目中，有的一般编程人员不安于编码实现，过早接触于一些PM性质工作，以及项目压力等其他因素，造成了代码质量不高，使得框架的重用程度降低。而在另外公司的一个项目中，由于企业的文化，同事们严格按照分工进行开发，提高了质量。后者看似少了机会，但从长远的角度看，大家对设计的了解更加透彻，对流程的理解更加深刻，为以后的发展打下了基础。阅读全文>
发表于 @ 2007年08月29日 10:04:00|评论(loading...)|编辑
在一个小型的C++项目操作中，对上述方法的实践中
- 由PM和结构师一用一备来分析需求、进行框架设计，确保整个项目的概念完整性。分析设计的产出物达到框架示意代码的级别，这部分框架代码主要是帮助团队对项目开发的理解，不存在于正式的代码中；阅读全文>
发表于 @ 2007年08月29日 09:57:00|评论(loading...)|编辑
2007年08月09日
三年时间，微软亚洲工程院的Exchange团队完成了别人看来原本不可能完成的任务。从刚开始只有2人发展到现在的70人，而且其中有近60名是来自高校的毕业生——在大部分人都没有任何大型软件开发经验的情况下，这个团队何以完成微软的软件工作中是最为艰巨的一系列开发事件?何以在短时间内产生如此巨变?阅读全文>
发表于 @ 2007年08月09日 11:41:00|评论(loading...)|编辑
“表面上看起来好像没有任何一个单独的问题会导致困难，每个问题都能获得解决，但是当他们相互纠缠和积累在一起的时候，团队的行动就会变得越来越慢。”对于问题的我们很难看到本质，不过，如果我们想解决问题，就必须试图先去了解问题。那么，这个问题在接下来的对 “编程系统产品” 的介绍，体现出来的，是人们对这个问题认识的不足和误解，并且，对此作了工作量的的确定，程序到编程产品，程序到成为编程系统的一个构件，其工作量都需要乘3。而要达到大多数系统开发的目标及编程系统产品，工作量需要乘9。阅读全文>
发表于 @ 2007年08月09日 11:25:00|评论(loading...)|编辑
2007年08月06日
但當我看完這篇外科手術團隊後，我發現其實還有個成功的關鍵在其中，就是同學們各有專長，所以，分工很容易，又因為有選出leader作為掌控者，所以，不會亂。大家不會做重複的事情。每個人按照時程交差，就可以順利完成。作者認為一個外科手術中，有操刀的大夫，有護士、有麻醉師等等，各司其職。而不是像屠夫團隊，每個人都得拿刀。一個團隊中只有一個人操刀，其他人扮演支援的角色。這樣整件事情就會出自一個腦袋不會亂，也不需要不斷的溝通協調。阅读全文>
发表于 @ 2007年08月06日 10:43:00|评论(loading...)|编辑
首先作者提出了一件常常發生的事情，這也是一個朋友身上發生的故事：『程式設計師都是樂觀的傢伙。』而且我發現越年輕越樂觀，但是無可避免的這是個年輕的產業，很少會遇到很有經驗的程式設計人員，這些年輕人，即使告訴他這樣是會有問題的，他也不改其樂觀。所以『他們所做的第一個錯誤假設是一切都會進行的很順利』可是沒有想到一個bug，就可以花上一天時間也無法解決。然後，就延遲了後面本來假設可以順利進行的部分。阅读全文>
发表于 @ 2007年08月06日 10:40:00|评论(loading...)|编辑
人月，是我們預估和排定時程用的，但是作者提出一個前提：『使用人月必須要在人力與工時可以互換的狀況下。而且要當工作可以切割、投入工作的人不用溝通，人力與工時才能互換。』就是說要可以互換，才能使一個人做30天，與30個人做一天的結果一樣，不然單純用人月去估算時程，一定會有誤差。為什麼呢？首先軟體專案有其連續性，作者舉了個例子，蠻傳神的，他說，生小孩就是要九個月，你叫多少個媽來生都是一樣。第二點是因為即使工作可切割，但是需要溝通，越多人投入就需要多的溝通與教育的時間，所以一個人做30天的工作不可能用30個人做一天就完成。阅读全文>
发表于 @ 2007年08月06日 10:38:00|评论(loading...)|编辑
软件的开发的过程是一个反复的过程，对自己的界面时时刻刻的面对，一种很简单而豪无意思的说法是：换一个角度来看的产品，也许有一些人可以做到，但是他们真的做到吗，这和一个人美术细胞有关，一个修养有关，我认为要做到：吹毛求疵，在《人月神话》里，作者这样说到，程序员是一个天生就有追求完美的天性，这也是在锻炼过程中生成的！（大意），我认为 对自己的产品吹毛求疵是可以做到的，现在你打开一个你自己软件，观看自己的界面阅读全文>
发表于 @ 2007年08月06日 10:29:00|评论(loading...)|编辑