关键词：
《构建之法》一书已完成了第一遍的阅读，接下来，我将随机抽取其中的一段进行精读。
移山公司的项目进行了一段时间，TFS上也积累了不少数据。大栓做了“数据挖掘”，整理出来一些统计信息，向各位领导汇报。
大牛：哇！前端组的这位开发人员是冠军呀，他导致的Bug总量约等于所有其他成员的总和。
二柱：那是有客观原因的，你可能不知道他的工作量是最大的。
大牛：那也不能因此产生这么多Bug，而让整个团队的进度停下来吧。
二柱：别人工作得这么辛苦，我倒是不太忍心再批评他。阿超，其实我觉得我们应该鼓励成员多做贡献，错误总是难免的，但是你知道他上星期完成了两个功能，明显比别人快多了。别的同事和他一比，就慢多了。
大牛：我不太同意，从TFS的数据来看，他的Bug数量远比别人多，而且不少Bug都有一段时间了，你说的“慢”的人，好像没有多少Bug，也是差不多按期完成的。问题是你希望团队成员是“萝卜快了不洗泥”型的，还是“慢工出细活”型的？
阿超：我有一个故事，假设团队里来了两位年轻人，嗯，就叫“萝卜”和“白菜”。萝卜做事很快，是“萝卜快了不洗泥”类型；白菜是“慢工出细活”类型。分配了任务后，萝卜很快就说做好了！白菜还在吭哧吭哧地跟项目经理和测试人员讨论。领导很高兴，让萝卜去做更多的事。开发阶段结束了，萝卜比白菜多做了不少功能。稳定阶段开始了。大家发现萝卜负责的功能出了很多问题，白菜的模块倒是比较稳定。然而萝卜在团队中的曝光率很高，很多问题都在等着他解决，从统计数据上看，他也修复了不少小强。白菜搞定了自己负责的模块，开始帮助其他人，由于不熟悉其他人的模块，白菜修复的缺陷不多。由于萝卜的设计有缺陷，导致模块非常复杂，萝卜也成了唯一了解其模块的开发人员。项目最后阶段，几乎都是萝卜工作得最晚，把最后几个缺陷给修复了。领导们说：有问题，找萝卜！项目结束了，开始了绩效考核，领导A认为白菜绩效不错，模块按时完成，没有大多问题，然后还能帮助其他成员；领导B认为萝卜是超级明星：第一个完成模块，修复的缺陷最多，而且掌握了最复杂的模块，离开他不行，工作得也很晚，有突出贡献。至于白菜，领导B没感觉他做了啥，仅仅是按要求完成任务了。萝卜白菜，各有所爱。那萝卜和白菜谁该得到奖励，谁该得到批评呢？假如领导B的评价方式占了上风，萝卜得到奖励，白菜离开了团队，你觉得下一个版本会出现什么情况？
大牛：我估计萝卜会成为“构建大师”，每天忙得不可开交。然而项目进展不一定会像以前那样顺利……
二柱：有人会怀念白菜。
大牛：你的意思是团队的领导者文化决定了团队的风格。但是当前该怎么办呢？阿超：所以我们要让“萝卜快了不洗泥”的人慢下来，这样能减少他们的危害。大牛：授予他们“萝卜大师”的称号？
阿超：恐怕不行，我们要胡萝卜和大棒并用。我们的大棒就是“小强地狱”（Bug Hell）。
这么一个故事，充分体现了软件开发过程中的“质”与“量”不易兼顾的问题，过于追求“量”，会导致BUG偏多，模块可读性不高，影响整体团队进度等问题；同样地，过于追求“质”，则会在修复BUG上花费较多时间，一样会影响整体的团队进度。但是相比而言，过于追求“量”的情况更多，危害也更大，因此，对这一情况加以限制也显得非常重要。而《构建之法》书中给出的方法便是“小强地狱”，即让导致BUG数量超标者进入小强地狱，期间只允许修复BUG，不允许参与其他开发工作，直到其导致的BUG数量低于阈值为止。这样的方法，只要阈值设置得合理，就可以很有效地使团队成员自觉把控“质”与“量”之间的平衡，从而提升整体团队的工作效率。
《构建之法》第四次随笔
《构建之法》第四次随笔这半个月我阅读了《构建之法》第六章，第七章，第八章。 第六章主要讲的是敏捷流程。敏捷流程是一系列价值观和方法论的集合。敏捷对团队的要求很简单：自主管理，自我组织，多功能型。但是... 查看详情
构建之法阅读随笔二
谁不喜欢创新呢？然而细细想来，创新就是做和以前不一样的事，并不是所有的人都喜欢“不一样”。当你提出一个创新的想法时，你会得到什么回答呢？为什么我辛辛苦苦想出来的点子得不到领导或同事的赞赏？这里面有好几... 查看详情
《构建之法》第1216章阅读随笔
第一章：概论有一个朋友问我：“你们软件工程和计算机的课表差不多，你们有c有Java，他们也有，你们要学计算机组成原理，他们也要学，有什么区别吗？”大一我还真的无法回答，我只知道我们学费是他们三倍，但是学的课... 查看详情
构建之法第六次随笔
我这个礼拜阅读了构建之法第12,13章。其中，第十二章讲的是用户体验，我们要考虑用户体验的不同角度，用户的第一印象就很重要，用户第一次使用软件，就很大程度上决定了用户对软件的评价。软件服务始终都要记住用户的... 查看详情
《构建之法》第三次随笔
从《构建之法》前两章的阅读学习中，我了解到了软件工程的概论，知道了“软件=程序+软件工程”，明白了个人技术和流程。阅读了第三章之后，我体会到了软件工程师的成长。 软件工程包括了开发、运营、维护软件... 查看详情
随笔之读《构建之法》（作业一）
自从拜读了邹欣老师的力作《构建之法》后，感触颇深。从书中不难看出邹老师是一个才华横溢、卓尔不群的人。《构建之法》言辞精辟，引人入胜。虽然只是浅读了《构建之法》的部分章节，但是对其中的一些内容我也有... 查看详情
《构建之法》随笔一
...巧和方法还是比较陌生。所以，在这个周末，我学习了《构建之法》的第一章。一开始我以为是很枯燥的教科书类的题材，只有系统的代码教学之类的内容，但是翻了几页后，竟然出乎我的意料，编者的语言相当幽默有趣，引人... 查看详情
《构建之法》第二次随笔
阅读了《构建之法》第一章中软件工程的概论，我学习到了“软件=程序+软件工程”这个黄金公式，并且对软件工程充满了兴趣和信心。但是，一个好的软件工程开发团队需要首先确保团队里的每个成员是合格的工程师... 查看详情
《构建之法》第一次随笔
...间的学习，逐步对软件工程有了新的理解与认识。读了《构建之法-现代软件工程》（邹欣 著 第二版）这本书，感觉学习到了很多有用的知识和以前不理解的方面。书中一开始给出了一个定式“软件=程序+软件工程”，几... 查看详情
读《构建之法》的第一次随笔
在收到纸质书籍到手之前，我简单的看了一些多看阅读上的试读章节。第一章开始便以程序猿们编程遇到的各种问题引出了软件工程的重要性。在一个工程的进展过程中，各种的不确定性因素会以多种不同的方式阻碍项目的... 查看详情
构建之法随笔
软件需求分析在软件开发过程中十分重要，过去人们一直认为需求分析是整个软件工程中的一个简单的步骤，“软件危机”爆发之后，人们才逐渐认识到需求分析是软件开发过程中最关键的一个工程。由此可见需求分析的重... 查看详情
《构建之法》阅读笔记一
1.程序=数据结构+算法2.构建管理，源代码管理，软件设计，软件测试，项目管理是软件工程的核心部分。3.软件=程序+软件工程4.软件企业=软件+商业模式5.软件开发的不同阶段：玩具阶段，业余爱好阶段，探索阶段，成熟的产业... 查看详情
《构建之法》阅读笔记01
...两节课下来，果然如此。 老师引用了《构建之法》书中的理念，认为软件不是靠着理论堆积而成，而是一个个实发的项目组成的，在课上，老师引用了书中的例子来形容学生和老师的关系。1、餐馆服务员/食客2... 查看详情
构建之法阅读笔记03
最近又跟随老师的进度阅读了《构建之法》的“软件团队和开发流程”部分。自从学习软件工程以来，每次的作业和程序都是我自己一个人做的，从未尝试过和别人一起来写程序。想到自己如果以后和别人... 查看详情
构建之法阅读笔记
构建之法阅读笔记（1）这周我开始了我的阅读之路，阅读了构建之法的第一二章。构建之法的第一章讲的是软件和软件工程是什么:软件=程序+软件工程。我一开始对软件工程的理解就是敲代码，写程序，其实，事实不是这样，... 查看详情
构建之法阅读笔记01
经过一周大致的浏览《构建之法》这本书，我看到了这本书的很多优点，不同于其他书，这本书注重的是启发，里边的很多小例子，以及里边的很多模型都给我们提供了解决一种问题的办法或者说是方向，... 查看详情
《构建之法》第七次随笔
典型的软件团队里除了能写代码、测试代码和画图做设计的成员，还有一类角色也很重要，我们叫他们项目经理——PM。 PM的M就是Manger，但是P就有这几种：ProductManager、ProjectManager/ProgramManager,在不同的行业和公司，... 查看详情
《构建之法》第七次随笔
这周，我学习了《构建之法》第十四十五章。第十四章主要讲的是软件的质量。软件质量等于程序质量加软件工程质量。程序的质量体现在软件外在功能的质量。衡量软件的功能，基本的判断可以用是、否来判定。软件的开发过... 查看详情