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

[1919010126-曾博文]

这个作业的要求是：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 来在代码中写注释。

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

问题二

问题提出

我阅读了教材的这内容”敏捷的方法能帮助你更早地知道你是否能如期完成任务“（教材第六章6.5 敏捷的问答 P123）。

有这个问题：敏捷开发过程中，总会有突发性的事务，如客户需求变更、团队成员变化等，这会影响任务的完成时间。作为团队里的一名工程师，如何处理好这些突发性的事件，以保证项目如期完成呢？

相关资料

我查了资料 开发团队如何管理琐碎、突发性任务？

有这些说法：

从人员分工角度思考，建议开发团队人员最好有工作侧重点的划分。一部分人员精力用于开发，另一部分人员侧重于应对突发工作。应对突发工作的人员时刻准备着问题风险的对应（比如开发工作尽量领取简单、松耦合的）。应对开发工作的人员专心完成开发内容。不管工作分工是哪种类型的开发团队，再有新的工作进来时，都需要遵循开发团队制定的规则，也就是管理好工作项的规则。

我们知道了管理好工作项是解决问题的核心，那么在形成工作项之前，我们需要解决谁对工作项负责或者说工作项来源的问题，然后要针对工作项做好工作计划，这样开发团队才能很好的执行。

• 首先，明确产品经理，做到需求来源唯一。其次，梳理产品待办列表，高优先级的工作项先做。
• 然后，重新定计划，确保开发团队容量适合，合理更新迭代目标。
• 再然后，回顾总结，选出改善点，下个迭代做得更好。
• 最后，几个迭代下来，度量分析，不断改善。
• 另外，同步需要进行的是人才的培养，向跨职能型团队努力。

解决方案思路示意图如下：

我的回答

1. 突发性工作来临时，首先需要明确需求责任人，即能很好地理解项目中用户的利益需求及其优先级，一般为产品经理
2. 需求责任人要在Backlog层面改善决策，在突发性事件改变开发的Backlog后，将高优先级的Backlog放入迭代列表优先进行迭代
3. 将Backlog的修改反应在工作项中，细化每个工作项，并做相应的时间估算，根据优先级排列
4. 团队中的开发人员对因突发性事件更改的任务进行反馈。判断是否能够在规定时间内完成任务，可向需求责任人提出修改意见。需求责任人根据成员反馈，适当调整工作安排。
5. 需求责任人进行工作项的等价交换，即保证项目完成度的情况下，用优先级高的突发性工作项，替掉同等工作量的其它工作项
6. 进行小组会议，成员反馈突发性事件处理的进度和感受，并讨论优化点，以求不断优化迭代流程

经验困惑

经验：突发性事务在敏捷开发中无法避免，需要需求责任人，如产品经理，及时响应突发性需求变更，并快速做好Backlog的优化整理，协调整个团队的工作分配。同时，工程师也需要及时做出反馈，判断任务是否能按时保质保量完成，并与需求责任人进行交流。最后，进行团队会议，讨论此次事件处理Sprint的改善点，持续迭代。

困惑：从上述说法来看，突发性事件发生后，需求责任人任务将会较重，会发生“单点故障”问题，即需求责任人出现失误，则整个团队难以继续推进，如何解决“单点故障”？

问题三

问题提出

我阅读了教材的这内容”一个沉溺于技术而忽略商业价值的团队，就像盲人骑烈马，跑起来很拉风，但最终不免人仰马翻“（教材第七章7.2 MSF基本准则 P134）。

有这个问题：软件团队应以产生经济效益，拿到客户的报酬为最终目的，那么对于开源软件，如何实现盈利和商业价值呢？

相关资料

我查了资料 开源软件七大盈利模式

有这些说法：

在开源软件领域中，常见的盈利模式一共有7种。

• 盈利模式之一：多种产品线
  如 MySQL 产品就同时推出面向个人和企业的两种版本，即开源版本和专业版本，分别采用不同的授权方式。开源版本完全免费以便更好的推广，而从专业版的许可销售和支持服务获得收入。
• 盈利模式之二：技术服务型
  JBoss就是这种模式的典型代表。JBoss 应用服务器完全免费，而通过提供技术文档、培训、二次开发支持等技术服务而获得收入。
• 盈利模式之三：应用服务托管（ASP）
  例如，PHP Live！ 就是一种构架于 PHP、MySQL 之上的开源软件，它可为企业用户提供实时交谈服务。目前已经有数十家公开提供 PHP Live！ 托管服务的应用服务提供商。
• 盈利模式之四：软、硬件一体化
  比如 IBM HP 等服务器供应商巨头，通过捆绑免费的 Linux 操作系统销售硬件服务器。SUN 公司近期将其 Solaris 操作系统开放源码，以确保服务器硬件的销售收入，也是这种模式的体现。
• 盈利模式之五：附属品
  O'Reilly集团是销售开源软件附加产品公司的典型案例，他出版了很多优秀的开放源代码软件的参考资料。
• 盈利模式之六：品牌战略、服务至上
  康比尔公司的 Compiere ERP & CRM 软件是这种模式的典型案例。
• 盈利模式之七：市场策略
  比如，微软宣称部分的公开 Office 的源代码，就是执行这种策略。

经验困惑

经验：开源软件虽然本身无法带来盈利，但软件公司可以基于该款开源软件的流行度，在此基础上不断添加新业务，如性能优化、软硬件一体化、附属品等。同时，开源软件的质量也直接影响着软件公司的服务质量，质量好的开源软件可以为公司积累大量的开发者用户。并且，开源软件可以让全世界的开发者成为软件的contributor，软件优化和迭代速度将非常之快，也提供给软件公司更多优秀、创新的解决方案，以用于自身的盈利性业务。

困惑：操作系统、数据库、行业软件等基础软件，此类软件开发难度大，开发周期长，且很难短期实现盈利，存在哪些措施能够保障这些基础软件的发展呢？

问题四

问题提出

我阅读了教材的这内容”本能、行为、反思三个层次的因素相互交织，共同影响了用户体验“（教材第十二章12.1 用户体验的要素 P261）。

有这个问题：软件产品开发过程中，一定是循序渐进的，用户体验亦如。那么在开发的过程中，如何权衡用户体验与业务进度的关系呢？

相关资料

我查了资料 在用户体验与业务目标之间寻求设计的平衡点

有这些说法：

符合公司与产品目标的营销策略确实需要将我们的设计作为与潜在客户进行沟通的触点，这是不争的事实，但并不意味着设计师必须向市面上的那些坏模式进行妥协。互联网世界永远在向前发展，试着在用户目标与业务目标之间寻找平衡点，在一些细微之处尝试创新，使设计既能为用户带来良好的体验，同时又能推动业务目标的实现。

把关闭按钮做的更大一些，让营销内容在样式上与普通内容有着明显的差异，记住用户的关闭操作不要让他们一遍遍的重复执行直到恼羞成怒...把营销内容制作的美观一些，至少让用户不会对这些内容本身的样式产生负面感受。

一切都在于权衡。一方面要理解产品体验对于用户的重要性，另一方面也要理解产品策略对于团队实质性发展的重要性，毕竟，只有在业务层面取得进展，我们才能获得更多的资源确保设计的持续进行。

经验困惑

经验：在软件开发初期，首先需要完成“本能“层次的设计，即UI外形的搭建，此时只需前端工程师和产品经理进行软件原型的构建，暂时不需要后端工程师进行编码。在完成本能层次的设计后，后端工程师有了UI外形的基础，能够更方便地进行编码和测试，这段时期前后端进行接口测试和调试，保证业务功能完整实现，即可生成一个最小可行性产品。将现有的产品雏形与客户或产品经理沟通，此时应该着重考虑”行为“层次的设计，即满足用户的使用乐趣和效率，经过多番沟通，不断迭代产品，以实现行为层次的设计。在这之后，产品已经可以去对接真实用户，并接受用户的反馈和意见，以达到反思的目的，这也是完成”反思“层次设计的必经之路，即从用户的角度考虑问题，满足用户的自我形象和乐趣，而非简单地实现功能的易用，更需要对用户的心理有较好的把握。

困惑：如今软件行业有内卷趋势，可能一次失败就会导致业务线被砍掉。如何能够更快地进行到反思层次的设计，直接抓住用户的心理，从而使软件产品能够短期内成功呢？

问题五

问题提出

我阅读了教材的这内容”迷思之六：技术的创新是关键“（教材第十六章16.1 创新的迷思 P348）。

有这个问题：不可否认，技术在软件创新中起到决定性的作用，如操作系统、数据库等软件，但也有许多软件的成功依靠着商业、营销的创新，如最近火爆的羊了个羊。软件创新的关键因素是否应该视具体情况而定，而非将”技术“作为关键一刀切？

相关资料

我查了资料 技术和商业模式创新　一个也不能少

有这些说法：

对现代企业特别是互联网企业而言，科技创新是发展壮大的基石。企业要以技术创新为先导，打破传统框架，开发满足消费者需求的新产品、新服务。然而，一旦技术创新的成果难以商业化，就会让企业陷入困境。

另一方面，如果企业一味追求商业创新，忽视科技创新，则会导致发展没有后劲。相比需要大量投入的科技创新，商业创新相对容易，但较低的门槛也决定了商业创新容易引来众多模仿者。如果没有不断的技术创新，在同业态的竞争中，曾经的领先者很容易“泯然众人矣”。

只有科技创新与商业创新共振，以新技术打开视野，以新的商业模式、理念、运营方式使技术落地，才能发挥出最大的效能，产生最大的价值。二者可以形成良性循环。科技创新会创造新的产品、带来新的需求，进而刺激企业进行商业创新，以提升竞争力、对接市场需求，为更多消费者提供产品与服务。当市场开拓出来，用户积累到一定数量后，同质化的竞争便会出现，如何立于不败之地？企业就要加大科技创新、技术研发的力度，拿出新产品、创造新需求。

经验困惑

经验：对于软件工程来说，技术和商业的创新缺一不可，甚至可以说，从长远来看，技术决定了商业。如果说技术是软件的经济基础，那么商业就是软件的上层建筑，而经济基础决定了上层建筑。我们可能会拿羊了个羊来举例，因为其仅有商业的创新。不可否认的是，它是一个成功的软件工程所导致的产品，但我不认为从长远来看它能够保持现有的地位，待新鲜感降低，用户会大幅度的减少。因此从一个软件企业发展的角度看，技术一定是需要大量人力物力财力去攻克的，但一定不能忽视商业的作用。一味的技术创新未必能适应当前用户的需求品味，而商业能够带来用户的反馈，防止软件产品误入歧途，保证企业的健康盈利，技术和商业的不断创新构成良性循环。

困惑：在一个决策中，技术和商业往往会发生冲突。比如技术希望提高软件的性能和可用性，保证软件的高并发，而商业希望能够更好地美化UI，提供产品给用户，从而改善企业现金流。在这种冲突的情况下，技术和商业的良性循环会被打破，我们应该如何处理这样的冲突情况呢？