提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 这个作业属于那个课程 | 班级博客 |
| 这个作业的要求在哪里 | 作业要求 |
| 我在这个课程的目标是 | 学习软件工程相关知识，锻炼软件开发能力。 |
| 这个作业在哪个具体方面帮我实现目标 | 回顾、反思、总结 |
| 作业正文 | 作业正文 |
1.第一次作业链接
2.对以前疑问的解答
问题1
原文出处：单元测试必须由最熟悉代码的人（程序的作者）来写。
作者给出的理由是”代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。“ 但结合我自己目前的编程经历，尤其是OO等课程的锻炼，我认为作者确实对自己的代码了解最为透彻，但是若测试也只由自己来写的话，一些在设计阶段就欠考虑的部分以及一些思维上的盲区就有可能一直被忽略。是否在作者对自己确定思维的部分单元测试写完之后，再由其他人参考作者给出的注释等加以补充更好呢？
解答：经过一学期学习与项目开发，我认识到写单元测试的人必须对整个项目的架构与流程非常熟悉，但我们这学期开发的项目是在学长的基础上继续开发的，要说原本的作者根本找不到，但经过我们前期的代码阅读、认真的分析与交流后，对于项目架构流程的理解有了一定程度之后，也可以进行单元测试的书写，并且，在开发阶段就写好代码注释，在测试阶段一起进行单元测试也并无大的困难。
问题2
结对编程中有两个角色：
（a）驾驶员（Driver）是控制键盘输入的人。
（b）领航员（Navigator）起到领航、提醒的作用。
这两个角色是可以互换的。和现实生活中的例子类似，一个人负责具体的执行（驾驶，用键盘编辑程序等），另一人负责导航、检查、掩护等。
作者提出了结对编程这种提高编程质量的方式，并且给出了结对编程的提供更好的设计质量和代码质量；对工作能带来更多的信心，高质量的产出能带来更高的满足感；心理上促进工作；企业上促进经验交流等优点。
但如何进行恰当的结对以及开始结对编程后的工作我还有所困惑。每个人的代码习惯、思维方式都有所不同，若两个人对于一个项目的理解大相径庭，那么在接手另一个人完成一部分的任务时可能需要花费大量时间来学习，这是否有可能会导致反而降低了效率？也就是说，与什么人结对是否是结对编程的关键与前提？如果两个人的水平差距略大，是否可能就会出现较弱一方接替驾驶员工作时无法理解领航员的指引最终导致单纯的水平较高的人负责编写并且教学水平较差的人，最终结果从总体上或许使得项目完成的基础上另一个人水平提升，但光就项目本身而言，是否不如只由水平高的人独自完成更佳？再者，对于结对对象的选择方面，考虑默契程度，或许选择熟悉的人效果更佳，但若考虑方便对另一个人公正的监督，或许关系不太密切的人更有优势，又或是按照作者所言看心智与修养？那心智与修养又如何衡量呢，按照自己的印象？那是否最终还是会落到熟人然后互相包庇偷懒的消极状况呢？
解答：根据这学期结对项目的实践，我发现基本所有人结对都选的是比较熟悉的人，虽然我与我的伙伴比较按照结对的要求编程，但据我了解到，确实有着一些团队出现了基本都是一个人在工作或者一起拖延的情况。并且由于这次结对编程是在大家都在家中的这种特殊时期，所以大部分团队都是两个人分成两个部分分别编程，最后再整合起来，像书中所写的那样一个人写另一个人看的方式基本没有队伍完全实现。比起书中说的一个看一个写的模式，我觉得单纯的组队开发或许适用范围更广。
问题3
问：我们能不能用goto？
答：函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。
之前上过的课程老师都是不提倡goto的，就个人编程经验来讲，函数若有多个出口，则goto也无法有助于逻辑清晰，若只有单一出口，使用goto看起来也并不会更加清晰，唯一可能有作用的是大量重复的条件嵌套，而这也可以通过重新设计条件来解决。
带着疑问我去查询了相关资料。发现在60年代末和70年代初，关于GOTO语句的用法的争论比较激烈。主张从高级程序语言中去掉GOTO语句的人认为，GOTO语句是对程序结构影响最大的一种有害的语句，他们的主要理由是：GOTO语句使程序的静态结构和动态结构不一致，从而使程序难以理解，难以查错。去掉GOTO语句后，可直接从程序结构上反映程序运行的过程。这样，不仅使程序结构清晰，便于理解，便于查错，而且也有利于程序的正确性证明。持反对意见的人认为，GOTO语句使用起来比较灵活，而且有些情形能提高程序的效率。若完全删去GOTO语句，有些情形反而会使程序过于复杂，增加一些不必要的计算量。但后来，G·加科皮尼和C·波姆从理论上证明了：任何程序都可以用顺序、分支和重复结构表示出来。这个结论表明，从高级程序语言中去掉GOTO语句并不影响高级程序语言的编程能力，而且编写的程序的结构更加清晰。这是否证明了goto语句不能使用呢？而且java等编程语言保留了goto关键字但不允许使用，这是否也否定了goto的意义。
解答：实践中，虽然我们没有用到goto这种方法，但确实体会到了程序逻辑清晰的重要性。我们的项目是继承而来的，其中有一些部分的逻辑十分不清晰，加上haml，js，vue等的混用，以往的代码在很多地方都为我们带来了很多不便。所以在我们开发的时候，十分注重所写代码的逻辑清晰情况，尽量统一结构。
问题4
在企业中, 大家都是拿工资的人, 应该都是全身心投入的 “猪” 了吧? 那倒未必, 各人对一个具体项目的投入和负责程度还是很有区别的。 企业内不同的角色相互合作, 各有想法, 市场变化快, 应该听谁的呢? 是听那些在研发和市场第一线全心投入的 "猪", 还是坐办公室的“鸡”, 还是一些空降而来的 "鹦鹉"? 在软件企业培养新人, 是让他们对公司各项业务作高层次的点评, 写成漂亮的PPT (鹦鹉), 还是让他们坐办公室, 主管流程 (鸡), 还是把他们送到能听到炮声, 可能会流血的第一线 (猪)?
作者将团队中的人分成了第一线的猪，坐办公室的鸡和空降的鹦鹉并且认为猪>>鸡>>鹦鹉，但我认为实际在企业中，真正全身心投入第一线的猪也有可能是只拥有编程能力，缺乏系统知识、缺乏创造性的真·码农，而坐办公室的鸡有可能是有着丰富经验经验的设计师，鹦鹉有可能是创新部门，在企业的发展过程中，或许有些第一线的猪只是自学过编程知识，而产品的核心灵魂却是中层坐办公室的鸡所决定的架构，这个时候，将猪的地位摆的太重，鸡的地位摆的太轻是否会本末倒置呢？就比如建造火箭，难道总设计师不应该比一线的工人更加具有决定重大事务魄力吗？
解答：在这学期的实践中，我深刻的认识到了组织人员和展示人员作用的重要性。开发人员固然重要，但开发人员基本山只能清楚的了解自己的情况，一个团队十分需要一个组织力强的人。这个人需要对项目有一定的了解，并且能够在关键时刻果断做出决策，这样，团队的进度才有保证，不会出现有人累死有人闲死或者大家一起做了很长时间却发现是无用功的情况。这个人不一定只是做办公室的鸡，更像是鸡与猪中间的地位。其次，衡量一个团队的工作并不只是看你做的怎么样，如何呈现，如何展示也是十分重要的一环。是否能够将工作重心投入到给项目评分的人喜欢的地方，对于一个团队的未来也有着很大的作用。比如我们项目，第一阶段投入了大量的精力改善项目，修复了众多的bug，调整了很多结构，付出了很多的努力，但在老师眼里，却认为我们的项目变化不是十分明显，在beta阶段，由于各科的作业以及考试，我认为我们并不能够向a阶段全身心投入，但由于我们beta阶段主要做的是增量的开发，整个项目变化看起来确实很大，感觉老师对我们的评价较a阶段略有上升。展示对于项目来说绝不可以轻视。
问题5
| Project Manager | Program Manager |
|---|---|
| 是团队的行政领导, 带领大家在项目中工作。 | 和大家平等工作, 推动团队完成软件的功能。 |
| 通常是团队和外界打交道的唯一代表 | 一个团队可以有很多PM |
| 对项目的功能有最后的决定权 | 和其他团队成员一起形成决议 |
| 管事也管人 | 管事不管人 |
| 不一定做具体工作 | 一定做具体工作 |
关于PM，作者列出了这个表格，其中Project Manager我理解为项目的老板等人，而关于这个Program Manager的定义我依然有疑问。PM的工作职责，我首先联想到的是团队中的小队长、或者部长之类的人员，在完成自身基本工作的同时关注某一个具体方面的工作，但这样是否并不是平等，也并不是管事不管人。再之，我联想到了体育社团中的社团经理，这些社团经历需要负责关注部员的身体、心理状况，完成一些琐事，比赛时收集情报等等，以社团活动内容之外的活动作为自己社团一员的工作职责，但由于工作重心并不是团队重心，或许地位依旧不是完全平等？再者，如果投入了时间去做这些pm的工作，如果这些工作取得了良好的效果，是否pm在团队中的贡献应该拉高，若pm付出了大量的努力但却最终并没有使整个团队的结果有明显改善，那么这个pm的贡献应该如何衡量呢？
解答：就我所认知的，PM在不同团队中也是完全不同的。有些团队的PM主抓组织，每日组织例会记录，了解成员情况，有些PM也投入开发，站在第一线为团队提出指导性意见，有些PM本身就作为能力较强的人领导整个团队，甚至进行了大部分的开发工作。关于PM的贡献，我认为还是要根据团队的实际情况。
3.产生的新的问题
1.技术学习与代码阅读的问题：由于本课程很多项目都是继承而来，阅读原本的代码以及学习新的很多知识确实会花费很多时间，并且这些成果很难展示到项目中去衡量，或者被老师所认可，关于学习成本或者学习计划应该如何规划制定。
2.合适放弃某些想法：指定的目标很多或者比较困难时，何时应该选择放弃，何时应该咬牙坚持呢？
4. 软件工程中学到的知识点
-
需求
学习了NABCD分析，系统分析用户需求，使用用户矩阵，多去了解实际目标用户，集思广益，多做讨论，但必须有人拍板。
-
设计
设计分为功能设计和技术规格设计。 技术规格要根据成员实际水平，和项目实际的难度来制定。功能设计要在项目进展中不断调整，根据项目实际情况，经常调研用户需求，结合成员状况，由一个主导的人做调整，大家一起讨论确定即可。
-
实现
项目前期分为前端与后端分别开发，但两者的结合上还是有着一些障碍。beta阶段，由于大家对于项目的结构都比较熟悉，所以采取了每个人或每两个人负责一个功能任务，完成后进行下一个任务，遇到困难在当天的会议中寻求帮助，最终进展比较顺利。
-
测试
为了减轻测试的负担，每次commit都要进行代码复审。在测试阶段，要灵活使用自动化测试工具、单元测试等，保证测试覆盖率。同时，人工测试也是必要的。。我们采取的ror框架在单元测试中只会测试能否正常调用，但内部的功能还需要人工详细的测试，我们在后期也安排了专人去测试。同时，测试应该在本地与服务器上都进行，以防发布的时候出现问题。
-
发布
推广对于项目十分重要，由于我们推广主要是为了完成课程组考核，故总会拖到很晚，并且主要也是拜托认识的人等增加用户，但在实际项目中，应当制定完整的推广计划。
-
维护
项目上线后，需要经常收集用户反馈，来不断修复bug或调整功能结构，尤其是要熟悉服务器的知识，防止维护时出现严重问题。
5.个人理解与心得
个人项目：刚开始觉得个人项目就像是数据结构的作业题一样，但跟着博客作业的要求一步步推进，确实能够收获到最基本的软件工程开发流程的相关知识，也为之后的结对和团队做了一些铺垫，略有不足的是与团队项目关联的或许有点少，感觉个人结对与团队好像是不同课程。
结对项目：这种两人合作的方式基本是第一次尝试，收获了比较好的效果。在结对过程中，我认真学习了队友的代码，互相沟通理解，同时也对于封装等有了进一步的理解。略有不足的是，在这个特殊时期，实施起来的效果并不是特别好，并且要保证同时有时间，效率有点低。
团队项目：团队项目我认为是这个课程最成功的，从选题、学习相关知识，到开发、测试，以及最后的发布，展示于维护，我体验到了软件开发的 一个完整的流程。同时，这也是我经历过的最大规模也是最成功的一次团队合作，学习到了很多如何在团队中工作，寻找自己定位的能力。在技术上，学会了新的语言，新的框架，对前端和后端的知识都有了一些了解。在项目的发布展示等阶段，也学会了如何规范的写文档，如何寻找亮点展示出去。在项目的整体推进中，我也与队员们形成了绝佳对的朋友关系，互相积极沟通练习，并且在软工之外的课程中也能够互相帮助。总而言之，团队项目是读大学期间难得的体验，是十分宝贵的经历。