构建之法（第三版）

问题一：

在第一章概论中提到，软件工程的目标— 创造“足够好”的软件，并对其做了定义：

什么是好的软件？一些同学认为，所谓好软件，就是软件没有缺陷（Bug），所谓软件工程，就是把软件中的Bug都消灭掉的过程。这的确是抓住了软件工程的一个要素。和软件打交道的专业人士都知道软件有“Bug”（缺陷），软件团队的很多人都整天和Bug打交道，Bug的多少可以直接衡量一个软件的开发效率、用户满意度、可靠性和可维护性。 ——P15

很多人认为有Bug就是质量不合格，没有Bug就是质量完美，其实这也未必。我们在大街上看到很多小汽车，这些汽车出厂时都通过了各自的质量检测，符合行业的质量标准。但是你问路人哪些车的“质量好”，很多人会告诉你有些车的质量大大好于另外一些车，那为什么还有人买那些质量“不够好”的汽车呢？对于某些顾客来说，某一类的汽车满足了他们的需求，他们就会买。如果销售人员不经市场调研胡乱推销自己公司的汽车，最后销量未必理想。

市面上有这么多不完美的产品，软件团队为什么还要把这些不完美的软件发布出来呢？为什么不能等到它们完美之后再发布？**软件工程的一个重要任务，就是要决定一个软件在什么时候能“足够好”，可以发布。** ——P16

从书本中大概能了解到一个好软件，就是Bug尽可能的少。而书中定义的Bug即软件的行为和用户的期望值不一样。那么如果一个功能对于一部分用户来讲是十分好用的，而有一部分的用户认为这是不合乎自己的期望值的功能，那么此时这算不算是Bug,工程师需不需要解决优化这个Bug。在一个被认定为“足够好”的软件发布后，得到的用户反馈中，哪些是有用的？什么时候才能将这个软件优化到相对稳定的版本？

不同的人对不同的事物有不同的看法，那么倘若这个软件已经被80%的用户认为已经很完美了，那剩下20%所提的建议还是否需要采纳，按照反馈来修复这20%所认为的Bug呢？我个人认为，Bug是相对的，只有软件的行为和大多数用户的期望值不一样才叫做Bug。

倘若一个软件能让80%的用户喜爱上那便是成功的好软件。但是如果那20%的用户提出的一些更加细致化功能化的模块时，程序员是否应该当做Bug来完善，这样会不会导致整个程序为了小部分的精致要求变得越来越复杂，到最后由小认知阻力的软件成长为一个大认知阻力的软件呢？

问题二：

在第四章两人合作中结对编程一小节中提到极限编程这一思想：

既然代码复审能发现这么多问题，有这么好的效果，如果我们每时每刻都在代码复审的状态，那不是很好么？事实上，极限编程（Extreme Programming）正是这一思想的体现——为什么不把一些卓有成效的开发方法用到极致（Extreme），让我们无时无刻地使用它们？ ——p84页 极限编程对工程师提出了更高的要求。这种要求不关乎技术水平，也不关乎学历水平或工作经验。这种要求是对一个人的心智、道德修养的更高要求。结队编程中，编码不再是私人的工作，而是一种公开的“表演”。程序员的代码、工作方式、技术水平都变得公开和透明，这也许是一些人不喜欢这一方式的原因。 ——P87

那么，极限编程和结对编程，这两者的关系到底是怎样的？书中也只是提到这个名词，并没有详细的对这两者进行解释，根据百度我查到：

• 极限编程包括了十几种实践（就是一些具体做法），结对编程是极限编程的一种实践。
• 极限编程是一种轻量级的、灵巧的、简单的软件工程方法。与传统的开发过程不同，极限编程的核心活动体现在需求→测试→编码→设计过程中。因此适用于规模小、进度紧、需求变化大、质量要求严的项目。它希望以最高的效率和质量来解决用户目前的问题，以最大的灵活性和最小的代价来满足用户未来的需求。
• 结对编程，也就是两个人写一个程序，其中，一个人叫Driver，另一个人叫Observer，Driver在编程代码，而Observer在旁边实时查看Driver的代码，并帮助Driver编程。并且，Driver和Observer在一起时可以相互讨论，有效地避免了闭门造车，并可以减少后期的code review时间，以及代码的学习成本。

随着现代软件产业的发展，一个软件的开发不再是一个人就可以完成的任务了，都是在相互合作中完成的。合作的最小单位便是两个人，那么两个人的合作如何才能真正的实现“1+1>2”的效果？传统编程上是双方提前做好约定，分别完成不同模板再进行后期拼接，共同完成同一个项目。而结对编程则是两人一同一致的一起完成项目的每一个步骤，其基本合约是双方平等合作，不存在领导与被领导的关系。这两种方式各自有各自的好处，但是在什么情况下选择何种方式，这并没有在书中详细告知。

我们知道，一个大型项目的完成肯定需要分工合作，需要将任务分解成不同模块，让队员分开编写代码，同步进行项目的制作。所以合作时，工作效率是一个必须考虑的问题。我们在期末的课程设计时，大多数组都会出现一个致命的问题，代码拼接时所浪费测试的时间不如同一个人完成来的效率更高。而两个人采用结对编程的方法一同完成时确实会比较高效快速完成，同时两个人也会对于代码的认知度达到一个相对持平的水平。

我个人对于结对编程的方式是十分推崇的，前提条件是双方要尽可能的水平一致。但是好像学校的课程设计组队中又很难真正的运用到结对编程这一思想观点，就像书中所说结对编程产生的代码是“公共”代码，不属于任何一个人，故而在课程设计组队中很难评判结对编程两人的贡献值，这对老师的评分评判有很大的难度，但是倘若仅仅为了严格区分每个人的代码分配而采用传统的编程方式导致项目在拼接时消耗大量时间的话，这就成了仅仅为考试而做的工作，违背了课程设计的初衷。我想请问倘若在结对编程更加受益于整个团队时，老师是否可以接受部分队员之间存在部分的“公共”代码？倘若需要对这部分“公共”代码进行划分，要如何划分这部分代码的归属。

参考文献：https://blog.csdn.net/lanjianhun/article/details/8963374

参考文献：https://blog.csdn.net/haoel/article/details/3868090

问题三：

这本书对计算机科学这一学术领域划分了两个不同方面，其一是偏理论领域，其二是偏实践领域，人工智能划分在实践领域，同时本书对于“智能”的阐述也让我对人工智能的发展有了不同的认知。

计算机人工智能研究的一个重大挑战，就是计算机程序是否在国际象棋这个游戏中打败人类。从20世纪60年代开始，就有很多研究人员从理论和“智能”的角度去着手，取得了一定进栈，但是里最终胜利还是遥遥无期。1985年，还是一个研究生的徐峰雄这样想： “我们从一个不同的方向去逼近这个问题。我们，至少是我自己，把这个问题看成是一个纯粹的工程问题。” 历史证明，这个从工程的角度出发，用“蛮力”提高计算机速度的工程方法远远甩开了同时代的各种“智能”方案。1997年，徐峰雄带队设计的“深蓝”战胜了国际象棋大师加里·卡斯帕洛夫。 ——P13

提到人工智能的发展，大家往往都持有不同的观点。有的人认为人工智能可以将人类从低级繁琐劳动中解放出来，而有的人担心高智能之后脱离人类的控制导致不可预估的后果。霍金曾在接受英国广播公司(BBC)采访时明确表示：

“制造能够思考的机器无疑是对人类自身存在的巨大威胁。”、

“它（人工智能）能够自行发展，并且以从未有过的速度重塑自我，而人类受限于缓慢地生物进化，无法与之抗衡而终将被替代。”

这些对于人工智能观点如果从工程角度来判断的话，仿佛并不可信。1997年，徐峰雄所带领小组研发的深蓝战胜国家象棋世界冠军卡斯帕罗夫。这是人类进化史上的一个里程碑，人类制造工具来打败自己。而人工智能在弈棋机实现上主要由三个主要部分组成：

• [1] 走法生成器；
• [2] 评价函数；
• [3] 搜索控制。

这与人类的记忆选择是非常相似的。我之前在一场讲座中听到周昌乐教授讲人工智能的时候，他讲述智能在棋盘的体现便是，程序员设计程序将所有的可能性指出，并给出每一种可能的对应策略，对于每一种可以选择的方案进行评估，最后选出最合适最受益的棋路。同时他还提到了人工智能的发展的瓶颈不是算法的局限性，是计算机计算速度的局限性。如果这么理解的话，那么人工智能的实现便是人类赋予的各种可能性的综合，倘若计算的速度允许，那么人工智能将迎来再次的快速发展，这和书中指出用“蛮力”提高计算机速度的工程方法远远甩开了同时代的各种“智能”方案是吻合的。那么我想问的是，如果人工智能的发展现阶段仍旧是工程问题，局限性还是计算速度的问题的话，那人工智能的发展对于人类文化的破坏，以及人类受限于缓慢地生物进化，无法与之抗衡而终将被替代的观点是否在此基础上无法成立？

参考文献：http://www.360doc.com/content/17/1010/21/41653239_693879542.shtml

参考文献：https://book.douban.com/annotation/17174085/

问题四：

在第十二章的用户体验中，作者用了大量的文笔来介绍用户体验的要素，如：用户的第一印象、用户的角度考虑问题、软件服务始终都要记住用户的选择、短期刺激和长期影响、不让用户反简单错误、用户体验和质量、情感设计。 这几点给出的故事都是在讲述如何从细节部分让用户喜欢上甚至爱上设计的程序。在了解了影响用户体验的要素后，设计就显得至关重要，如何设计、怎样设计才能满足大部分的用户团体？这是每个工程师都需要考虑的部分。书中讲到：

用户体验设计的一个重要目的就是要降低用户的认知阻力（Cog-nitive Friction），即用户对于软件界面的认知（想象某事应该怎么做，想象某操作应该产生什么结果）和实际结果的差异。我们来看一个具体的例子，如果用户（一个生活在中国二线城市，有高中文化水平，有基本计算机基础的成年人）要在一个文稿中写居中的一句话，在下表所列的各种工具中，用户是怎么才能做到的。 倘若认知阻力大，学习曲线就会比较陡；但是经过学习和练习，如果用户适应了新的认知模式，工作效率便会有较大的提高。 ——P271

在用户体验设计这里有一个文字编辑软件的对比表格。由表可见，在Word 2007版本之前需要手动选择选择“居中”功能而Word 2007版之后的软件有添加一个新方法：在文档任意地方双击鼠标，光标将会停在双击的地方。无论是在07版本之前还是之后，这些设计的各种方式也没有办法做到不学就上手，顶多算是学起来图形化界面比较完整，相比起LaTex等论文编辑器更容易上手罢了。而且对于表中提到新添加的双击居中方法在下载后也没有很好的简易教程交给用户，我相信很多人都不知道这个功能，那么如果大多数用户都不了解，不会用到的小功能是否还有必要去开发？

我个人认为，针对这类的软件，应该配备简易的图文流程。就像腾讯每次QQ的更新都会通过五六步的图文引导来简明快捷的介绍最新版本增加的新功能，起到一个推广的作用。

本书中有写到，用户体验设计的一个重要目的就是要降低用户的认知阻力（Cog-nitive Friction），而对于LaTex编辑器来讲，它的认知阻力就相对较大，但是对应的功能就更加强大，对于计算机专业或需要专业论文撰写的用户来说是非常有帮助的。那这类工具所面向的用户团体不就是有专业需求的人士吗？那么这类认知阻力极大的软件岂不是降低了用户体验感吗？针对这种专业性较强的软件来讲，降低认知阻力还是用户体验设计的一个重要目的吗？还是说在一些情况下，总有一些软件是开发给那些需要功能强大，忽略认知阻力的受用团体的。

问题五：

在第十七章 人、绩效和职业道德中：

很多心理学家通过各种试验和分析告诉我们，纯粹强调外界的驱动因素（金钱的报酬或惩罚）仅仅对体力劳动或有明确规则的活动有效（奖金越多，结果越好），但对于需要创造性思维的活动，即使是简单的认知能力的活动，更多奖金反而起到相反的效果。 ——P409

这里讲到对于创造性思维的活动来说，创造力的激发和金钱成反比？奖金为何会没有作用？就算不起作用也不会起到相反的作用吧？但是换个角度来看，倘若一个工程师的一个创造性idea达到一个天价的地步，那么除非他真的看淡名利应该也是会有心理压力和动力的。但是压力和动力不就是激发创造的源泉吗？在有压力和动力的情况下产生创造性突破的概率应该比没有压力和动力的情况下概率更高不是吗？

于是我查了百度，了解到发现创造力的激发和金钱确实成反比！参考的文献中通过一个实验说明了虽然基础良好的待遇的工作环境，是基本的保障，人们在良好的基础保障上在发挥创造力，就是现实的可操作的。但是人脑其实非常孱弱，因此要好好发挥其灵光闪耀，则必须提供和营造良好的分享氛围，强调和激励工作人员去关注创造力本身，而不去纠结奖金激励。

但是个人认为，在员工角度来看，一个员工完成一次创新之后，如果只得到了鼓励没有金钱方面的报酬，会不会影响下一次创造性idea的出现？

参考文献：https://wenku.baidu.com/view/560c086648d7c1c708a1456d

Question 1:软件工程师的能力衡量？

Question 2:绞刑架和职业发展？

Question 3:为什么要充分授权和信任？

Question 4:成功的团队更能创新？

Question 5:不太做广告,主要靠口口相传,容易被技术进步淘汰.？

个人博客园地址：http://www.cnblogs.com/qichang/

欢迎大家评论指教！不胜感激

>本书的培训目标是

1.研发出符合用户需求的软件

通过实际的工作收集、推导、提炼需求......

-- 引用自《构建之法》P11 第一章 概论

成功的软件总是解决了我们生活中的迫切需求，但是不同的人群有不同的需求

"推导"，"提炼需求"的意思是满足大部分用户的需求吗?程序员是否有必要为满足小部分人的需求去做软件,或者为软件添加某些功能？

这一章中，对软件工程师的思维误区这个部分，感受很深。

书中列举了4种误区：

分析麻痹：因为想等到所有分析都完毕之后再动手，结果心理上恐惧，没法起步；

不分主次，想解决所有依赖问题：想解决所有依赖，结果精力被分散，比较好的解决方法应当是找一个当前“足够好”的方案，先解决主要问题；

过早优化：花大量时间优化局部，没有考虑全局

过早扩大化、泛化：过早地将一个工具或算法对其进行扩展

这些问题种，我都或多或少有涉及，其中不分主次最为麻烦。现在工作之后，走了很多弯路之后，才知道问题分优先级、分主次的重要。聚焦核心问题，避免过程中精力分散，问题才好解决。把当时遇到的困难绕过，主要问题解决后，再来解决次要问题。如果一开始在次要问题上折腾，主要问题就没时间解决了，得不偿失。