构建之法——总结

一、开头

这个作业属于哪个课程	链接
这个作业要求在哪里	链接
团队名称	Running Man
这个作业的目标	总结
Github地址	链接

二、队员列表

李星晨	201731091410	组长
刘伊凡	201731062603	组员
陈嘉莹	201731104215	组员
唐财伟	201731062416	组员
谭伟	201731062415	组员

三、正文

谭伟个人总结

姓名	学号	以前的博客链接
谭伟	201731062415	博客链接

一、对问题的解答

问题（1）:什么样的软件才叫“足够好”呢？在实际运用中存不存在一个边界或者说是概念来定义本书所谓的“足够好”呢？

通过实际的开发，我解决了这个问题，我认为“足够好”的软件应该是这样的：
1、界面友好，无须帮助可以轻松操作。
2、运行效率不能太低，尽量减少报错现象。
3、作为单个软件尽量全功能，不要整天修补，作为需要经常更新的软件必须保证更新服务器流畅。
4、尽量占用系统资源少。
5、支持后台运行。
这样的软件就是我心目中“足够好”的软件了，在我们实际的项目操作中，我们最开始不知道到底软件怎么样才算完成了，可是想到了“足够好”的软件时，我们慢慢的往这方面去靠，最终完成了软件的开发，也得到了这样的结论。

问题（2）：怎么样才能从低等级转变为高等级呢？比如说，我想将一份临时的寄托转换为工作或其他的，具体应该怎么样来施舍呢？

解答：通过我与室友的讨论，我们认为，如果你对一份寄托十分强烈，并且你渴望融入这份寄托中，那么你可以加强对这份寄托的使用，将它转换为你可以利用的技能，再将这个技能勤加练习，这样取提升自己，让自己尽可能的找到一份可以实施自己寄托的工作；但是如果你的寄托并不强烈或者是你的寄托并不能在实际生活中找到一份工作，那么，就不用非要去转换自己的寄托了。

问题（3）：在结对编程中，遇到两个人的能力有差距，或者说两人的能力与想象中的有一定的差异怎么办？

解答：在我们进行结对编程时，我的能力就与队友差距较大，但是在实际操作中，我们在分配好任务后，我觉得并没有怎么拖累队友，或者说对队友产生了折磨，可能是我们制定的任务很合理，并且在分配任务后，我对于不懂的地方也认真的去网上寻找问题的答案。因此，拓宽到实际项目中，在任务分配合理，并且你懂的自己去找到解决问题的方法，对于两个能力差距较大的人来说并不是很难完成项目的。

问题（4）：在实际开发中到底以什么样的标准去判断一个对一个项目来说，什么对于它来说是最好的编程语言，什么样的工具对于它又是最好的工具？

解答：在我们实际开发项目时，我们也经常考虑换一个工具来开发这个项目会不会更好，可是我们最终发现，工具只是工具，工具是死的，而人是活的，所以并不能以工具对项目这样去判断，而且在最开始写项目时你可以用你熟悉的工具，但在开发一段时间后你应该试试其它的工具，看一下效果，比较一下，什么才是最适合你的，适合的才重要。

问题（5）：书中的针对用户体验的调查方法都能在实际的项目中应用吗？

​ 解答：我认为，方法和工具一样，都有过时的时候，我们不能尽信书，也不能无书，因此，在实际项目中，针对不同的项目，最适合该项目的调查方法才重要，而书中针对用户的调查方法也不可能都能在实际中使用的。

二、掌握的技能

在本学期的学习中，我们完整的学习了系统分析与设计，并且利用所学的进行了完整的项目开发，在这个过程中，我学到了以下：
业务分析，主要处理的是业务领域的建模。解决的问题是业务上如何实现。然后是技术与架构方面的设计，主要针对的是技术实现，解决的问题是技术上如何实现。这两个方面是会互相影响的，设计的时候往往需要来来回回的考虑这两个方面。甚至系统开发时也时常会需要调整模型或者架构，当然相应的也需要更新文档。
建立实体模型：实体模型是确定系统包含的实体以及它们之间的关联的过程：

• 理清业务概念，统一业务词汇。

• 抽象业务实体，包括事件、人/角色、地点和事物等。

• 识别实体关系：继承、聚合、关联等。

  架构设计，常见的是4+1视图，即逻辑视图、开发视图、过程视图、物理视图，再加上场景。另外一种我更喜欢的是视点和视角的方法，如果再加上场景的话，可能会更全面。

  设计功能模块，确定系统内部的功能模块及其职责：

• 确定系统的模块划分。

• 确定每个模块的职责以及模块间的关联。

  设计数据库模型，等等。

三、心得体会

在上系统分析与设计这门课前，说实话，我并不知道设计一个项目需要这么多的步骤，我只是想当然的认为，一个项目嘛，做出软件就好了，哪管那么多的东西，可是在学习这门课后，我发现我太天真了，并不是说你能把一个软件设计出来就行了，你仅仅是设计软件出来并不能说明你已经完成了这个项目，因为你这样设计出来的软件仅仅是你认为的软件，在实际中可能它并不适合实际，因此进行系统分析与设计就很重要了，在进行这个过程后，你才能实际的知道你想要设计的软件和你设计的软件有没有差异，不会因为这个导致全盘项目的失败，并且在你进行系统分析后你才能设计出更好的软件，有了分析，你才有头绪。
总之，在这门课上，我学到了很多。

李星晨个人总结

姓名	学号	以前的博客链接
李星晨	201731091410	博客链接

一、尝试对自己提出的问题进行解答

Q：《构建之法》中3.2章中有一个过早优化问题，我想知道为什么过早优化是不对的？

A：我在这个课程一开始的时候，认为早点优化，未雨绸缪似乎没有错。而且对 “一个工程师在写程序的时候，经常容易在某一个局部问题陷进去，花大量时间对其进行优化，无视这个模块对全局的重要性，甚至还不知道这个“全局”是怎么样的”书上的这句话，并不报以认同的态度。

但是在这次项目中，我切实的感受到了过早优化的缺点。在项目伊始，我们需要考虑的不是细节的描绘，而是全局。这次的项目分为α1、α2版本以及β版本，α则是完成项目核心内容，β则是对项目进行改进优化。如果过早优化，即在α版本就进行β版本的工作，无疑会拖慢整个团队的进度，使得工作无法完成。

Q：《构建之法》中4.5.2为什么要结对编程？

A：在这个课程开始之前，我想知道一个项目，我们怎么区分它是更适合个人编程、结对编程或是团队编程呢？是否有什么判断的原则或是标准呢？

现在我的答案是：尝试。尝试出真理。在这次课程中我们有结对编程这个作业，详情可以参考之前博客中写到的部分。一开始肯定是不习惯，不过一周下来，也明显感觉到了结对编程的有点以及带给我的帮助。

二、新的问题

在这次项目中采用了敏捷开发，但是对敏捷开发中很多人员真正在实际中职责还有有点模糊。

在项目开发过程中经常会有成员疲惫的状态出现，不知道如何调动积极性。

三、掌握到了哪些以前没有的技能

这一点，我认为有很多很多可以说的部分。在技能上，我认为不一定要学会一门新的语言或者掌握什么很高超的技术才能算学会什么技能。(｡•ᴗ-)_

在这次的课程中真的有学到很多的东西，如果要总结的话，每一次博客的内容就是一次新的技能学习的过程。

• 认识自我

  找到自我的方向，认识自己也是一门之前没有掌握的技能hhh。当然通过第一次作业还学会了博客园这个工具的使用。

• 熟悉工具的使用

• 原型设计

  这个工具是真的一个很好用，很有趣而且是之前没有接触过的工具。在项目还没开始的时候打一个样本，可以很好使团队的成员了解项目的需求，明确需求，加快进度。

• 项目管理过程

  在这个过程中我觉得掌握最好的部分其实就是进度管理叭，在以前的项目中是没有尝试过α1，α2，β版本的这种进度方式的，α版本完成任务，β版本进行优化，按照程序一步一步走，没有进度滞后的情况出现，是很优越的方式。学会了！୧(⁎˃ ◡˂⁎)୨。

其实还有很多其他的更小的方面的技能，不过在我看来都是一份收获。

四、一学期的总结

其实第一个感觉是终于结束了，累是真的很累的，在我们的课程学习中几乎没有这么累的课程，没完没了的博客，没完没了的个人作业和团队作业。

但是结束之后回顾这个课程，收获确实很大。普通的课程更偏向于老师讲学生听，学习知识的途径比较单一。在这个课程中，感觉学生占主体性很强。还有一定很重要的就是，在这次课程中，所有的一切都是公开的，不论是你的博客，还是团队的项目，都是同学之间可以互相查看。这样既起到了监督的作用，同时又可以从别人的博客中汲取经验教训。看到别人优秀的项目也可以学习。我觉得这种方式能起到很好的监督作用。

总而言之，这一学期，很棒！(๑•̀ㅂ•́)√

陈嘉莹个人总结

姓名	学号	以前的博客链接
陈嘉莹	201731104215	博客链接

一.对问题的解答

Q1：

第5章提到了软件团队的各种模式，那在一个企业的成长的过程中，是在团队模式中进行不断的转换，（比如从瀑布模型转换到原型模型，再转换到渐进交付模型）从而摸索到最适合自己企业的模式，还是说在企业的不同项目组中使用不同的团队模式？对于一个初步创业的小企业是否有经验可取？

A：现在团队的主流模式就是敏捷开发模式，敏捷开发可以算是瀑布模式、原型模式等的延伸。这个学期我们就是体验了敏捷模式来进行项目的开发，所以可以说绝大部分的企业的部门都使用敏捷模式来推进项目，对于有特殊需求的项目，或根据企业自身对产品的定位和性质，小部分企业会继续使用原型模式、增量模式等等。

Q2：

书P116，提到对敏捷的团队要求之一是”每个人能全面负责，自己搞定规格说明书，和别人沟通，同时自己搞定测试“。如果大家都自己搞定测试，那对于敏捷的团队来说难道就不需要测试人员了？我觉得这对团队人才的要求过高，而且如果项目庞大，个人花大量时间搞测试难免会拖慢整个项目进度。

A：现在看回自己一开始提出的问题，还是觉得自己当时理解的太肤浅了。事实上每个人学会对自己的代码部分进行测试是很重要的，前期的个人测试可以为项目后期的整体测试减轻很多负担。而且个人测试一般也是比较简单好操作，只要考虑自己的那部分代码不会引起严重的错误就好了。而敏捷团队的测试人员，除了要进行项目的整体测试，还有性能测试、系统测试、集成测试等等，涉及的技术知识和技术难度会多得多。

Q3：

第6章敏捷流程中提到了Scrum Master，和第9章的Project Manager，百度后我发现是两个不一样的概念，Project Manager侧重于管理整个项目和团队，负责达成项目商业目标；而Scrum Master侧重于引导，协助产品负责人，辅导团队，跟进项目流程。那两者之间到底如何才能进行良好的角色转换呢？经查阅资料我还发现，现实中存在一些公司会让同一个人承担这两种角色，他们认为没有必要明确划分这两个角色，这种说法又是否合理呢？

A：我觉得一般大厂都会将Scrum Master和Project Manager很好的区分开，小公司才更可能让一个人承担两种角色，从坏的角度想说明这个角色要承担很大的责任和压力，对这个角色的能力要求较高。

Q4无解。

Q5：

根据第13章提出的软件测试的内容和方法，对于开发周期不同的项目是否应该选择不同的测试方法？如果只是一个小型项目，比如我们要在第8周完成的项目，是否需要每个阶段都进行单元测试，还是在开发的最后才进行测试；对于大型项目，使用TDD（书P117提到）是否能更高效的完成开发（据查阅很少企业使用TDD开发）？

A：一般来说，无论大型项目还是小型项目，都需要进行单元测试，因为这样无疑都会减轻后续的工作量。特别是在本次课程的项目开发中，我更能体会到单元测试的重要性。少部分企业将开发模式玩的很6，就会使用TDD来完成开发。

二.掌握的技能

这个课程下来，从一开始对分布式版本工具使用的不熟悉，到现在能熟练的使用GitHub与团队进行项目的交互，这是一个提升。在跟团队成员合作的过程中，成员也给予了我很多帮助，跟团队成员的交流也让我在技术上有很大的提升。以前可能自己写一个小的项目会形成自己的代码习惯，当看到其他成员写的代码更规范时，我会学习熟悉他们使用的语法来规范项目的开发。以前对前端只有很表层的学习，这段时间在成员的带动下我学会了layui的基本语法操作，与js进行很好的交互。再者就是学会了对项目进行单元测试、用例测试、整体测试。

三.心得体会

这个课程跟以往的专业课很不一样，以前可能更注重的是对某一个技能的学习（比如C、C#、Java），这个课程的理论性更高，我们学到了软件需求分析方法、软件开发的流程、软件团队的合作、软件的测试等等，让我们对“软件工程”这个专业的知识体系结构、走向有了更深刻的理解，而且高强度的课程需要我们花更多的心思在团队项目和部分作业上。上完这门课后，我感觉这门课对以后步入职场进入企业还是很有帮助的，在较短时间内我们还是得到了一定的成长，而不再是一个掌握了某个技术或技术能力很强，但不懂软件开发流程，不懂团队协作，不懂软件结构分析和设计的职场小白。

唐才伟个人总结

姓名	学号	以前博客链接
唐才伟	201731062416	博客链接

一、回望第一次作业

以下是之前的一些问题

1. 所有的测试环节都需要经历一次吗？
   解答：按照软件开发阶段划分，软件测试可分为单元测试、集成测试、系统测试和验收测试。测试往往是衡量每个开发阶段的重要指标。只有针对每个阶段进行了测试，满足需求和设计之后，才可以开始下一个阶段。这样有助于将问题在每个阶段结束之时都解决。因此测试对于企业级是不可省略的。

2. 使用敏捷开发是否只需要简单的做一下需求分析就可以了？
   敏捷开发确实能够很好的适应需求的变更，能够很好的处理需求不明确的情况。当敏捷开发应对需求变更也是有成本的。因此，如果能在设计和编码阶段开始之前就能明确需求，对于降低成本是很有用的。所以如果能在一开始就搞清楚需求，就一定不能拖延，毕竟需求变更越晚，其带来的影响越大。

3. 我们要如何进行需求确认？
   需求确认可以划分为三个步骤：1.非正式需求评审，项目经理先在项目内部组织人员进行非正式的需求评审，消除明确的错误和分歧。2.正式需求评审，项目经理邀请同行专家和用户一起来评审需求文档，尽最大努力是需求文档能够正确无误地反映用户地意愿。3. 获取需求承诺。通过正式评审后，开发方负责人和客户对需求文档做书面承诺，使之具有商业合同效果。

4. 在使用敏捷开发模型时，遇到比较艰难，难以估计时间的任务时如何解决？
   可以对任务进行更细的分解。

5. MFS模型每个成员都需要完成自己的目标，否则将会危及整个项目，那么NFS还适合技术能力较弱的团队吗？
   只要根据每个成员的实际情况合理的指定目标，对于技术能力较弱的团队也适用。

二、掌握了哪些技能

• 认识到了软件的本质，什么是软件工程
• 需求建模的方法
• 了解到了各种软件开发的过程模型
• 结构化分析与设计的方法
• 面向对象分析与设计的方法
• UI设计的方法
• 软件质量保证的方法和重要性

三、体会与总结

通过课堂的学习，对整个软件设计有了初步的了解，对结构化分析与设计和面向对象分析与设计有了充分的认识。学习到了各种开发模型的，并且了解到的它们的特定和适用环境，在后面的课程实践学习中也深刻体会到了。对整个软件开发流程有了比较全面的了解。改变了之前在软件开发中只重视编码的错误理解。对整个软件工程有了比较深入的理解。

刘伊凡个人总结

姓名	学号	以前的博客链接
刘伊凡	201731062603	链接

一、我提出的问题：

1.书中69页有关goto的内容
goto在大一我们学习时被认为时需要尽可能减少使用甚至不使用，因为他会破坏程序的逻辑结构，但在书中认为如果能够体验程序逻辑，什么都可以使用包括goto。
答：第一次阅读时太过狭义了，goto确实能够体验程序逻辑，只是需要合理的慎重的使用。
2.书中291页pair-wise和正交实验设计方法
第一次看到这种测试的方法，不过基础经验得出的众多因素中只有两个因素对某个bug产生关键性影响抱有疑问，可能是代码写少了。
答：很遗憾在本次团队项目中仍然没有使用到这个测试方法，这个问题仍然没有得到解决。

二、新的问题：

1.因为每个人都需要参与项目中来，所以没有体会到经理这一职位的职责任务所在。

三、新技能

有关于git的使用，这次频繁的使用git体会了以前没有的问题，有的在百度下解决了，有的没有但也在组长那边合并了。学会了原型设计，以前没有接触过原型设计，但感觉合理的使用工具进行原型设计确实能够很好的让别人理解我们的想法。在团队项目的开发中也学会了pageinfo等工具的使用。

四、总结体会

在这门课的学习上我们体验了原型设计，结对编程以及一个团队项目的开发。原型设计和结对编程都是一个很新的体验，感受到了原型设计的妙用。在团队项目开发中体会到合理的团队沟通很重要，在我们分配任务时没有进行合理的沟通导致我们的接口变量等等不相同，产生了很大的麻烦。一个项目的完成是一个团队的事，良好的沟通与协作安排能节省大量的时间。除开沟通以外，也感受到了自己在技能学习上的不足，很多时候都给同组的同学拖后腿了，要加强技能学习，跟上同学的步伐。一个项目的开发往往是团队协作的，往后的时间里要多多参与团队项目的开发，逐渐习惯团队项目，也要在今后的项目作业中，吸取本次项目的经验，工作过程中及时与组员进行交流对接，相信我会更有经验的完成今后的任务。