构建之法（第三版）

问题一：

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

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

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

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

问题二：

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

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

• 极限编程包括了十几种实践（就是一些具体做法），结对编程是极限编程的一种实践。
• 极限编程是一种轻量级的、灵巧的、简单的软件工程方法。与传统的开发过程不同，极限编程的核心活动体现在需求→测试→编码→设计过程中。因此适用于规模小、进度紧、需求变化大、质量要求严的项目。它希望以最高的效率和质量来解决用户目前的问题，以最大的灵活性和最小的代价来满足用户未来的需求。
• 结对编程，也就是两个人写一个程序，其中，一个人叫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

问题三：

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

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

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

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

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

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

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

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

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

问题四：

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

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

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

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

问题五：

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

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

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

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

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

关于图片中提到的得到的多方认可的模型，却不知道下一步该做什么的问题，我没来得及查看链接文献，但也想谈谈我的认识。

在最初使用UML建模时，我也觉得各个阶段模型是割裂的，我如何从用例图到顺序图，我为什么要建立顺序图，用例图面向谁，顺序图面向谁，我如何从顺序图到分析类图，分析类图和设计类图的区别是什么，为什么有了分析类图还要设计类图，我如何确认类图中的方法和属性，以方便我在实现时可以直接定义，体系结构模式如何应用……

在认真的听过四五遍国防科技大学的谭庆平教授的讲课后，我基本理解了上述的问题：

1.从用例图到顺序图，关键是用例描述中的交互动作序列

2.建立顺序图是为了帮助我们区分分析类的对象是如何协作实现业务目标的

3.用例图面向用户，顺序图面向设计和开发人员

4.从顺序图到分析类图，主要关注消息是消息接收者的职责（方法）

5.分析类图帮助确定体系结构模型，设计类图主要为了实现

6.体系结构模式根据关键需求项来确定

通勤的路上，匆忙的记录了一些，也许不太准确……

要在会议结束前达到目标，就要定义好目标具体是什么。组织者应该做到：

明确会议目的，要解决的问题是什么

推动会议进程，促使与会者在每一个阶段做合适的事情

总结会议，记录要点

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

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

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

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

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

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

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