个人作业-提问回顾与个人总结

  • “阅读和调研”文章链接
  • 问题回顾 & 解答
  • 所学知识点
      • 需求
      • 设计
      • 实现
      • 测试
      • 发布
      • 维护
  • 理解和心得

“阅读和调研”文章链接

[BUAA软工第一次]个人阅读作业-阅读和调研

问题回顾 & 解答

  1. 在“软件工程概论”章节中有一句话：

    一个好的软件，即使功能和同类软件区别不大，但是会让人感觉到非常好用。这就是软件的“用户体验” (User Experience) 特别好。用户体验和数据结构，算法没什么关系，但是很多非常成功的软件就赢在这个方面。

    我的问题是，是否程序员也需要掌握用户体验设计的几大设计原理？我看许多互联网巨头公司都会有专门的用户体验设计师岗位，而且国外的很多名牌大学也在认知科学或者信息学系专门设置了这个专业方向。但是既然成功软件的很大一部分仰仗于其良好的用户体验，这也在无形中要求软件工程师需要掌握用户体验的设计原则。所以，为何长久以来用户体验设计师或者用户体验专业没有被软件工程师或者计算机系所代替？或者说程序员在哪些地方是必须依赖一个额外的用户体验设计师的？

    答： 从我们的开发实际情况来看，程序员了解一些用户体验设计的原则是非常必要的，尤其是对于在规模不大的公司中就职的程序员群体。当然，术业有专攻，我们不能完全指望程序员能够设计出一个使用感十分舒适的图形界面。老话说得好，隔行如隔山。就算我们作为软件工程师的设计出了自己认为不错的用户界面以及交互方式，实际做出来的其实往往远远达不到我们的预期。而这个现实和预期的差值往往需要一位经验丰富的用户体验设计师（UX Designer）弥补。我在这个学期中与一位用户体验设计师朋友谈论时他说到，UX Designer主要会在意以下几点：

    1. 设计思路：是否展示了完整的设计过程和思路？设计过程中是否充分运用了各种设计方式？是否有针对每个项目应用最合理的流程和工具？
    2. 以用户为中心的设计理念：是否有尽自己所能去了解目标用户？在设计过程中是否考虑到了不同用户的需求？设计的核心是不是为了解决实际问题？是否会操作用户测试、以及合理地根据用户反馈修改设计？
    3. 视觉功底：是否能熟练运用色彩、排版、字体？是否能正确应用各平台的设计规范？
    4. 创新能力：是否能突破框架尝试与众不同的方案？是否能在新奇的交互模式与可用性之间权衡？

    我们不难发现，这些知识往往是软件工程师不具备的。所以，在一个团队中，我们不能完全指望前端工程师可以提供出一个很好的界面以及交互设计方案，因为程序员群体普遍缺乏相关方面的训练。一个软件的成功，良好的用户体验是不可缺少的，故此UX Designer和软件工程师的良好合作也是不可缺少的。

  2. 在“技能的反面——魔方与模仿”章节中，作者以这样的话做结语：

    那怎么才能考察出一个人“精通”魔方呢? 我想了这样一个办法:

    a) 给面试者一个各面打乱颜色的魔方

    b) 要求他把六面还原

    c) 如果还原了, 要求他把魔方恢复成我最初给他那个混乱的局面, 必须一模一样。

    我没有完全理解作者以这段话做结的意图。作者是想告诉我们必须有逆向思维吗？但是程序的逆向思维是什么呢？是编写完一个项目之后可以给别人讲出从最后一句到第一句是什么意思吗？但是这样做的意义似乎是不明确的。我不了解魔方，我认为将还原的魔方返回到最初的混乱状态是一个比较不可回溯的过程，然而程序的每一行都是清晰且可以回看的。这样的结语似乎第一无法说明任何问题，第二和前文重笔墨探讨的项目抄袭几乎没有关系，在我看来比较莫名其妙。不知道作者的真正意图是？

    答： 我在这次的开发过程中我体会到作者说魔方这个例子的用意其实没有那么晦涩深奥，其实是一个所有软件工程师都应该具备的一种复盘能力。我们在两次阶段开发项目展示时，都会遇到老师或者同学对我们进行提问，而为了回答好这种问题，我们往往需要回到程序开发的最起点，从架构设计开始说起一直到成品实现，这样才能让提问者对我们的产品有一个更加完整的认知。而这个在开发结束后回过头去说架构设计的行为其实就是“魔方”例子中说的还原成六个面之后再恢复到最初的混乱局面。

  3. 在“两人合作要会做汉堡包”章节中有一句话：

    有一个说法, 创业家在创业初期必须要说服三个F: Family, Friend, and a Fool. 如果Family 和 Friend 都没人支持你的想法, 第三个F 估计也帮不了带大的忙。

    前两个F好理解，但是我们为什么要给一个Fool解释我们的计划并且要期待来自Fool的任何评论呢？既然我们已经知道对方是Fool，那么他的意见的建设性是不大的。我认为第三个F应该是Folks。Folks可以指普通人，即软件的普通用户。这部分人往往占据了一个软件大部分的适用群体，所以他们对于一款未发布产品期待与否才应该是软件团队关心的重点，因为这直接影响销量。
    答： 我们在此次敏捷开发的用户调研阶段发现，其实许多使用者甚至软件的投资者都是第三类人，即Fool群体。他们不具备或者不需要具备相关软件开发知识，也不需要关心软件团队具体的开发过程。一个软件工程团队获得的投资往往来自Fools，所以向他们解释清楚自己软件的杀手级功能是很关键的。然而，在这之前，正如书中所说，我们需要先获得Family和Friend的绝对支持，不然想要获得Fool的支持是很不稳妥的。

  4. 在“用户调研”章节中提到了两个方法：

    深入面谈 和 用户调查问卷

    史蒂夫·乔布斯曾在苹果公司开发的iTunes饱受诟病时公开表示苹果公司永远不做市场调研，因为用户不知道自己想要什么。他们只会在你把新东西放在他们面前的时候他们才会说，哇，这才是我想要的！(“People don’t know what they want until you show it to them. That’s why I never rely on market research.”)

    我认为乔布斯的观点是正确的。用户除了一些基本需求（比如微信的云同步消息记录）希望软件公司做出改进，其实是根本无法作出太具有建设性和突破性的意见的。然后，软件的开发者也一定是使用者，我们知道一个好的软件需要做到什么，甚至比用户更加清楚和专业。我不否认需要在产品开发前细致入微地设计项目，但是我认为和用户深入面谈或者回收其调查问卷是几乎无意义的。
    答： 在经历了两个阶段的用户调查和开发之后我依然认为，对于普通软件的开发（不考虑专业软件，比如军工类软件和专业设计类软件），用户调查效率非常低下，因为用户其实自己对“好”也没有非常明确的定义，只有我们把产品放出来，用户才会有“这个好”或者“这个不好”的想法。我们这次做的这个计划软件就是典型的普通软件。但是，对于专业软件，用户沟通是必要的，因为软件工程师不具备相关专业知识，几乎一切设计都要根据专业用户来确定。

  5. 在“开发阶段的日常管理”章节中有这样一段话：

    如果你是写一个商业项目，请不要让连开发语言都没有接触过的队员进行开发工作。并不是非得 “写” 程序才是对项目有贡献，有时不写也有很好的贡献。如果他们有热情，就从测试开始学习吧。

    作者说一个从来没有接触过某们编程语言的人在项目组中从测试人员开始做起，但是我认为测试人员反而更加需要专业的语言能力。因为测试在我的心目中是稳定软件市场口碑的镇山石，如果测试人员对开发人员所用的语言完全不懂的话，我认为测试人员是无法对开发人员提出高效修改意见的。学习一门新语言很容易，但是能够一眼看出新语言的bug是会难很多的。所以在我的心目中，测试人员，至少在语言理解度上，需要比开发人员更强悍。
    答： 在我们这次的敏捷开发中我体会到其实测试人员并不需要太深刻的编程功底，但是这并不意味着测试团队不需要对软件本身有一个良好的理解。我们的测试团队由一个计算机学院同学和一个非计算机学院同学构成，我们发现这样的一个搭配是非常合理的。专业能力较强的同学可以专注于收集报错信息，找到问题所在，反馈给开发团队进行代码调试；专业能力较弱的同学可以专注于单元测试的管理，只需要发现问题。经过这次开发，我发现我在最初认为的测试人员角色其实是不准确的。

  6. 在“源代码管理”章节中作者提到利用好诸如GitHub这样的管理平台来检查提交代码的规范性，但是我不知道能否通过GitHub来检查提交的代码是否符合团队代码风格规范？我试图在StackOverflow上寻找答案，但是似乎没有人能够真正通过这种方法来检验比对代码风格。如果像GitHub这样的平台无法做到的话，是否只能先手动添加到自己的IDE中逐文件查看才能检查代码规范？
    答： 在本次开发中我们采取的代码规范管理方法是：1. 下发代码规范手册 .xml 文件；2. 在本机IDE中设置自动校对代码规范功能（如JetBrains WebStorm -> Preferences -> On Save）；3. 代码编写及检查完成后发起Merge Request，PM检查若无误则采纳，否则打回此次Request。我们发现，利用好相关IDE的开发功能，比如保存时自动检查格式，是非常高效率的，可以给PM或者代码管理人员带来不小的便利，同时也会规避由于代码风格而造成的大规模代码冲突。

所学知识点

需求

NABCD是由Need、Approach、Benfit、Competitors、Delivery五个单词的首字母组成，分别指需求、做法、好处、竞争、推广五部分。通过这五部分，可以清楚简明的把项目的特点概括出来，更好地确定软件开发目标。

设计

架构设计七大原则：1. 开闭原则：对扩展开放，对修改关闭，降低维护带来的新风险；2. 依赖倒置原则：高层不应依赖低层，更利于代码结构的升级拓展；3. 单一职责原则：一个类只干一件事，便于理解，提高代码可读性；4. 接口隔离原则：一个接口只干一件事，功能解耦，高聚合，低耦合；5. 迪米特原则：不该知道的不要知道，只和朋友交流，不和陌生人说话，减少代码臃肿；6. 里氏替换原则：子类重写方法功能发生改变，不应影响父类方法的含义，防止继承泛滥；7. 合成复用原则：尽量使用组合来实现代码复用，而不使用继承，降低代码耦合。

实现

代码管理原则：PM需要下发给特定人员不重复的、符合相关人员能力水平的任务，这对PM的管理能力是有一定的要求的。另外，在具体的代码实现中，代码规范的规定是需要严格遵守的，不然，在后期处理代码冲突会非常的没有意义。最后，在代码签入时，团队成员需要严格遵守团队规定的代码签入规则，这样才能避免代码管理紊乱。

测试

单元测试是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

发布

持续集成(CI – Continuous Integration)是指多名开发者在开发不同功能代码的过程当中，可以频繁的将代码行合并到一起并切相互不影响工作。持续部署(CD – Continuous Deployment)是基于某种工具或平台实现代码自动化的构建、测试和部署到线上环境以实现交付高质量的产品，持续部署在某种程度上代表了一个开发团队的更新迭代速率。持续交付(Continuous Delivery)是在持续部署的基础之上，将产品交付到线上环境，因此持续交付是产品价值的一种交付，是产品价值的一种盈利的实现。

维护

  1. 更正性维护(纠错性维护)：诊断和修正系统中遗留的错误，就是纠错性维护。 纠错性维护是在系统运行中发生异常或故障时进行的。核心：出现错误后纠正，叫做更正性维护；2. 适应性维护：适应性维护时为了使系统适应环境的变化而进行的维护工作。核心：环境发生变化。若环境没发生改变，而对系统做出的改进不是适应性维护；3. 完善性维护：在系统的使用过程中， 用户往往要求扩充原有系统的功能 ，增加一些在软件需求规范书中没有规定的功能与性能特征，以及对处理效率和编写程序的改进。核心：基于用户对软件完善。例如：用户觉得某处不行，我们去改，这就是完善性维护。4. 预防性维护：系统维护工作不应总是被动地等待用户提出要求后才进行，应进行主动的预防性维护， 即选择那些还有较长使用寿命， 目前尚能正常运行， 但可能将要发生变化或调整的系统进行维护， 目的是通过预防性维护为未来的修改与调整奠定更好的基础 。核心：预防。也就是说，目前尚可工作，为了预防而做出改变。

理解和心得

我想通过几点心得体会来描述我对软件工程理论的理解：

  • 专业性
    显然，开发团队应该具备出色的编程技能。此外，优秀的开发团队除了传统的开发，也会重视创新对重要性。并且，团队成员善于跟上技术趋势，知道如何以务实的方式使用它来提高绩效。

  • 定期和清晰的沟通
    沟通是让任何团队运作良好的关键，团队需要确保沟通有规律（频率取决于需要）和清晰（没有秘密，意见可以自由分享）。有两种类型的沟通至关重要：团队内部的沟通和与第三方（利益相关者）的沟通。在团队中，领导者应该鼓励团队以健康的沟通来产生有效的流程、工具和解决方案。在与第三方沟通时，在沟通的帮助下，团队可以清晰地设定目标、审查流程、讨论新机会、选择正确的工具等等。

  • 对目标的承诺
    设定明确和可实现的目标对任何团队都至关重要。在制定长期和短期计划并将任务交给团队之前，确保每个人都知道他们在项目结束时的目标是什么。

  • 明确的角色和职责
    为了正常运作，团队需要了解流程的所有方面，以及他们的职责和责任。团队成员还应该了解他们的角色和职责与项目目标的关系。

  • 理解数字产品的业务逻辑
    优秀的开发团队了解他们真正的客户。通过与产品所有者和利益相关者的沟通，他们真正了解最终用户的需求，因此能够做出正确的技术）决策。这是创建成功的定制软件的唯一方法。

  • 自由与灵活性
    每个团队成员都应该可以自由地自行寻找新出现的困难的解决方案。在一个优秀的团队中，团队成员可以灵活地选择工具和与之合作的技术堆栈。当他们以目标为导向并受到启发时，他们会尝试找到最佳解决方案。有些时候，PM对他们的规范不太严格也许可以提供更好的代码，并让开发人员在工作时更快乐。一定的试验自由度有助于开发人员建立具有内部流程和文化的团队模型。
    优秀的开发团队也可以灵活地规划他们的工作日程，因为人类不可能整天保持生产力。他们需要时间放松，在咖啡机旁聊天，或者去健身。所有人都需要一些放松来创新和创造。通过这样做，他们确保了高动力，从而在特别需要时最大限度地提高生产力。