第一次作业（个人作业）：阅读教材，提五个问题

这个作业的要求是：https://bbs.csdn.net/topics/608340750

问题一

问题提出

我阅读了教材的这内容”软件工程中最基本的复审手段，就是同伴复审“（教材第四章4.4 代码复审 P73）。

有这个问题：当前的软件产品迭代迅速，同伴难以有大量时间进行代码复审，如何让程序员自己的代码能够在快速的迭代过程中，尽可能减少错误呢？

相关资料

我查了资料 持续集成：代码审查篇 [译] 代码审查的艺术：Dropbox 的故事

有这些说法：

一般认为，代码复查、结对编程和静态分析如果能够严格执行，对提高代码的总体品质是有好处的。在快速、成功地执行无尽的、重复的任务时，人的能力是有限的，采用静态分析工具执行审查逐渐成为共识。持续审查可以减少发现问题和修复问题之间的时间，确定系统中需要特别关注的部分。在CI系统中执行持续自动化审查，可以积极地预防缺陷，并确保一种可重复和一致的方式。

来自前Apple公司的IOS工程师对Code Review的见解：Dropbox 的 iOS 应用中的每一行代码，都是开始于被添加到 Maniphest 中的一个 bug 或者功能任务，Maniphest 是我们的任务管理系统。当一位工程师在上面接受一个任务，那么在开始写代码前相应的责任就已经赋予他。Phabricator 这个平台包含了我们的代码审查工具，这个代码审查工具有很多很好的功能，但它在评估对象之间的相互协作上不是做的很好。为了弥补这点，我们的工程师在开始他们的工作之前需要知道审查他们的任务的人是谁。对于被审查代码的工程师来说，这样能确保在他们的团队中有一个橡皮鸭，这个橡皮鸭知道项目中一些改动代码的背景和原因，并且对代码的设计决策上起到协助的作用。对于审查者来说，这有助于他们将一些变化考虑进他们的开发周期评估中，这样有助于开发周期评估的准确。如果不出意外的话，我们的经验会告诉我们提前做好计划可以有效地避免审查代码过程中的重复劳动。针对项目中的变化做计划可以像在白板前做交流一样简单，也可以像写一篇建设性文档一样深入。这都取决于我们自己的选择。

经验困惑

经验：利用工具进行自动化代码审查解决80%的问题，让人来处理另外20%的重要问题，自动化审查可以让人工复查变得更有效，代码底层已经通过扫描检查，人工复查可以关注那些自动化不能处理的方面，如代码是否满足需求，是否从长远来看易于维护等。

提供任务管理系统与代码审查工具，以实现自动化、高效的代码审查。任务管理系统负责接收工程师的代码提交请求，也给予审查者查看代码审查报表的权限，代码审查工具则运行指定的程序算法，对提交的代码进行审查，并将结果输出到平台中。鼓励软件工程师使用//TODO，//HAX，和 //FIXME 来在代码中写注释。

困惑：代码中难以发现的错误，或者说隐性的错误，如死锁、多线程并发问题等，如何能够使用自动化工具进行审查？

问题二

问题提出

我阅读了教材的p63-p69页第四章关于两人合作中论及处理同伴关系和判断同伴性格有如下问题。

问 题：书中强调合作中两人关系以及同伴性格的重要性，并且要采取相对委婉的方式告诉同伴可能存在的问题。我很好奇，如果同伴的对委婉的问题置之不理或者不屑一顾该如何处理，以及如何能够通过代码编写和日常交流判断同伴的性格。

相关资料
https://www.docin.com/p-2029476742.html、http://t.zoukankan.com/yinyunmoyi-p-12578130.html以及https://blog.csdn.net/myf_666/article/details/124306828均与书中的观点相仿，都提倡委婉通知，考虑伙伴的心情与能力，要求和谐处理和伙伴的关系。

经验困惑

**经验：**和谐处理与合作伙伴的关系确实是在合作中很重要的，但是难免会出现另一方消极态度或者不顾及你的感受依旧我行我素的情况。同时，在个别情况下委婉提出问题可能不会引起足够的重视，在未来可能会带来更多的麻烦。我们需要一个和谐的伙伴关系是希望能够顺利的完成工作，而不是满足社交需求。在极端情况下两个能力强的同伴合作其实不会需要很多的交流就能完成工作。所以，我们应该掌握与人相处的哲学而不能一味的以和为贵。

**困 惑：**关于上述的特例情况书中也没有详细说明，我想知道在极端情况下我们应该如何处理关系？如何通过自己的观察判断同伴的性格来采取相应的措施？一味的委婉是否会让同伴不能真正意识到自己的错误？

问题三

问题提出

我阅读了教材上第11章的“我从来不喜欢uml类型的工具，如果你不能通过计算机语言表达（uml要表达的东西），那就是这种语言的弱点。……有经验的开发者和适当的技能组合。

有了为什么大师不喜欢uml，uml为什么没有改变软件项目成功的关键？

相关资料

https://www.zhihu.com/question/29423180

https://coffee.pmcaff.com/article/3090640756361344/pmcaff?utm_source=forum&newwindow=1

http://t.zoukankan.com/nokiaguy-p-1307139.html

UML混合用少，一来不方便分层思考，也就是把问题归类设计；二来产品经理这样做必要性降低，且使用难度加大，更加抽象与宏观。
常见的用例使用误区有：① 就画图而忽略其分析方法，如其先外后内，化繁为简（把大系统先抽象成一些用例）的分析方法；② 用例的包含扩展关系（这是UML自身问题）。
UML普及问题：① UML发明人没有给出应用和其注意事项，也就是没有实战，从而导致误用；② UML的确有很多问题，其用例、类图都有些问题，从而导致用不好和用不上；③ 而中国的UML书常把软件架构和产
UML建模被反对有很多原因，其中一个原因就是被很多人用成了一种僵化的、极其强调文档的做法，然而同时却又非常不考虑真正文档的受众的感受，重视流程而不重视实效，使得它成为了一种没有效果却又造成极大痛苦的做法， 这是人们抨击的关键。

经验困惑

经验：
已僵化不适合开放的灵活的编程环境
不方便，标准难以实现，学习投入精力多。
不方便分层思考
有些项目适合，有些不适合。应项目而异。
因为部分人的惯性思维，过于看中之前的成功经验(一些是借势)，从而导致用的少。

困惑：
项目开发过程中不需要清晰的架构吗？
程序员的个人习惯是不是也导致了uml的减少使用。
不使用uml是否是不好的习惯。
能有比uml更方便的工具出现吗？

问题四

问题提出

我阅读了教材上P146-148关于msf的部分，msf运用的主要场合和在项目中运用的情况如何？

相关资料

https://blog.csdn.net/xuwedo2003/article/details/4390139?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522166476357416782395350817%2522%252C%2522scm%2522%253A%252220140713.130102334…%2522%257D&request_id=166476357416782395350817&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2_allsobaiduend~default-2-4390139-null-null.142^v51control,201^v3control_2&utm_term=%E5%BE%AE%E8%BD%AF%E8%A7%A3%E5%86%B3%E6%96%B9%E6%A1%88msf&spm=1018.2226.3001.4187

经验困惑

经验：
MSF负责指导计划阶段的中期和后期、软件构造阶段、部署阶段前期和中期的任务。而软件项目生命周期的其余阶段，即部署阶段的后期、运营期、计划期的前期均是在微软运营框架负责。

困惑：
msf概括了项目所有可能出现的问题方面吗？msf是否将每个问题的责任归属划分清楚了？

问题五

问题提出

我阅读了教材的这内容：这些事真的要让与项目无关的专业人士来做么？（P315）

有这个问题：
软件开发过程中如果遇到某些板块，交给团队成员做的话能完成但是质量、效果一般，交给与项目无关的专业人士完成的话可能会得到更好的结果，且更加省力，但需要先让对方了解项目，这会造成额外的开销，也会带来新的风险。这该如何抉择？

相关资料

https://www.zhihu.com/question/59063608/answer/2413680584
有这些说法:
要具体情况具体分析，例如：资金紧张时肯定暂时选择前者，资金充裕且该部分内容较为重要时，选后者可能更好。

经验困惑

经验:
看项目进度而言，如果进度紧张，团队成员手头的工作安排都很紧凑，那可以选择外包出去，反之可以先尝试内部解决，若结果实在太差则考虑外包。

困惑：
如何更好的应对交给专业人士去做的任务最终完成结果与预期成果差距较大的情况？