[2019BUAA软工助教]答黄衫同学

[2019BUAA软工助教]答黄衫同学

一、答黄杉同学

1. 011-黄衫博客

   我当然不否认软件工程的各种博客是有一定作用的，但是相信大多数人对诸如例会博客并没有什么热情（不过似乎也没有什么其他方法保证团队内都在为了进度努力）。而更加鼓励技术博客对课程并没有什么害处，技术博客正是在开发中完全可能产出的部分，发布出来对其他人也会有很大帮助。这一点相信课程组也比较认同，只是没有明确说明出来而已。而且我希望鼓励的方式包括且限于：给个人加分，并给出明确的说明。

   这是一个很好的建议，另一位黄衫得主也提到这个问题：

   进入团队阶段后对个人的关注度不够。

   这部分现在的考虑是：可以给个人/小组增加一个得分项叫做：“技术博客的积累”，个人在团队开发中，学习了相应技术、解决了相应技术问题后，可以通过发布技术博客、示例代码的形式给个人加分，例如：使用highcharts绘制美观的燃尽图。

   具体如何操作，需要等待老师助教们的讨论决定:) 好在我们这学期有三个迭代，课程本身也能在之后的两个迭代做改进:)

2. 167-结对编程感想

   软件工程确实一个可以很好的锻炼我们能力的课程，但是目前正在进行的团队作业每日例会可以稍微放松一下，比如每两日一次，现在我们处于大三下学期，每个同学也都有着除了课程 以外的规划，比如企业实习，实验室实习，或者备战考研。每日例会会占用一些额外的时间，两天开一次的话，项目的进度也会在群里大家互相监督推进，文档也是大家沟通的一个很好的桥梁，并不会导致项目进度的滞后。

   [捂脸]实际上，进入每个迭代的 Sprint 阶段之后，就要开始紧张刺激的编码工作了，这个时候应该是不能放松的，毕竟这个阶段叫做冲刺，我在跟提不起劲想赶紧完工队PM交流的时候，也提到这个问题，最后我的建议是：

   Sprint的两周时间里，并不是只有工作日才可以发布例会博客，周末的四天也是可以的，只要当日有工作，有进展，就可以开会，另外大家都住在一起，可以等晚上大家都回到宿舍了开会，会议的时间不长，也不会占用过多时间。另外，如果实在聚不齐，不能到场的同学可以打电话旁听，也可以考虑进行线上会议。

   不过迭代之间的两周还是可以放松的:)

3. 170-结对编程感想

   结对编程题目的改善

   本次结对编程的题目是解决最短单词链问题，分为有单词环和无单词环两种情况。根据课程组给出的作业要求，笔者认为完成本题目的重点应当在与对算法的优化方面。在无单词环的情况，由于英文字母数量的限制，搜索的复杂度并不大，不同搜索算法的差距不易体现。笔者在这一步分尝试采取了深度搜索和动态规划两种方法来解决问题。最终两种方法取得了相近的效果（肉眼不可见的差距）。

   在有单词环的情况，该问题相当于NP问题，而最终评测是要求程序给出确定解。于是无法采用启发式算法解决问题，仅能通过优化确定算法来提高性能。而这种方法带来的效益是相当有限的。当然也有个别小组采取了相当有效的优化操作，但绝大部分组的优化效果甚微（包括笔者的小组）。笔者认为该部分若改成“在最短时间内给出最长的单词链”这样的评判标准的话，大家就会在这一部分有更多的操作空间。

   除此之外，笔者认为本次结对编程的题目缺少一定的开放性。这主要体现在开发过程中在用户体验等其他方面缺少设计的开放性，大家除了算法的方面几乎没有操作的余地。而最后的程序评测也主要参考程序通过的测试点和性能，少了些程序其他的方面的评价。

   这个建议很具体很好，我们助教团队会尽快商量如何对这个作业改进，包括你的这个建议:)

4. 152-黄衫感想

   比如第一次阅读作业给的时间比较少，很难详细读完整本《构建之法》，很多时候只能草草读完撰写博客。

   另外，根据我了解的敏捷开发，基本条件就是大家都有足够的积极性，足够的时间去一起完成工作，有什么问题当即解决探讨。敏捷开发本身就是对程序员由很高的要求。但是大家都大三下了有自己的方向，并不一定有很多的时间可以投入课程，而且未必能抽出时间选择自己更喜欢的课。强制所有人参加可能对于贯穿敏捷开发理念的工作不会太有利。可以看出课程组本身在实验，至于效果还是拭目以待。

   快速读完教材并提出疑问这个作业的目的就是让大家在短时间内阅读大量材料，并不是要求大家在一周内十分细致地把书读完，对每个部分都了如指掌。大家可以粗读，记录下陌生/感兴趣的点，然后挑选其中的一部分，细致地读读，做一些展开。

   关于这部分建议，可以考虑给作业增加对应的说明，但我们还是认为，大学生应当有一定的快速阅读的能力。

   强制所有人参加这部分一开始我以为指的应该是小组的每日例（立）会，询问了这位同学我才知道她说的是软件工程课变成必修这件事。关于这个，直接上聊天记录吧：

   助教：强制所有人参加是说每日例会吗？
   同学：不[捂脸] 我说的是这门课我不否认它的必要性 就是效果是否能达到预期
   
   助教：噢 你说的是 软工变必修这件事是嘛
   助教：[捂脸]是这样的，计算机学院的人，了解一些软工方法论还是很有必要的
   
   同学：我说的是 我确实不否认它的重要性，只是对效果提出疑问
   助教：效果这个事吧[捂脸]怎么说呢，你如果不上的话，（这门课）就一点效果都没有了[捂脸]
   同学：或者我觉得可以把这种需要团队合作的课程放在更靠前的学期
   
   助教：给你看个东西，你体会一下：https://shimo.im/doc/ob4cWwVmKgEP3QQT
   
   助教：你们上一届的时候，软工是和编译数据库放一起的，再往前放就是OO，但实际上，OO之后，大家才具备一定的开发工程的能力。
   助教：每门课程都有他的先导课程
   
   同学：我也不能很好统筹计算机的课程设计并且给出实际的解决方案 所以这种探索的过程我觉得也很必要
   助教：对，我们一直在探索这个

   中途分享的链接 8.14 北航软件工程课改研讨会会议纪要 是我当助教之后旁听的第一个会。大家可以简单看软件工程课程的地位、制约。

   整个学院的课程设计也是在一届一届改进的，这个改进周期比较长，以届为单位，但并不是说我们就停滞在了某个所谓“成熟”的模式中:)

5. 103-黄衫感想博客

   团队作业这部分的引入，我觉得教学方面真的带得不够。正如我上一段所说的，我们大多数人没有任何大项目的开发经验、管理经验。像是团队成立后的第一次课上去做个PPT去讲，然后对于要讲啥的要求都是很概要的几个字/几句话。我知道这是因为各组项目性质/人员类型都不尽相同，不能给出一个定式的模板。但是也正因为如此，我觉得助教的深度介入应该就在此时进行，而不是拖到alpha阶段都快结束了才介入。让一个已经成立的团队改变做法比在一个团队建立时给出意见矫正路线要困难得多。我感觉到课程的意思是让我们先去做，然后再正经地教，这好像是目前更提倡的做法，毕竟自己动手做了才有感受，才能更有针对性地听。但是实际的操作结果是，做的时候一头雾水，瞎搞，然后因为课上讲的都是已经做完上交了的东西，所以都没啥人在意，事后更加没人根据课上讲的东西返工之前做的东西。（在没有出大事故之前，不会有人愿意返工的。）

   我看见黄衫上写着“Learning when doing”，我觉得这句话是没毛病的。所以我的建议是，teaching及时介入doing的过程，引领好doing的方式，让学生能更好地自主地去learning。而不是放任学生自己doing，然后再teaching，指望着学生能自发地返工/自省从而达到learning的效果。

   当然，现在已经alpha阶段快结束了，马上要进入beta阶段了，该定下的团队运作模式基本都定下来了就是了。

   这里还想提一下作业的提交方式。我很喜欢结对编程的那个作业提交方式，两个人有共通的内容，但也有各自独立的部分。不知道为啥团队作业不这么搞了。我觉得哪怕我们以团队形式进行工作了，至少在alpha阶段，也应该在个人级别地督促教学。当然，这不是说要给个人增加单独的博客作业啥的，只是需要有个渠道能真正看见团队里每个人吧。不过因为各组项目的性质、分工都天差地别，这部分可能真的有点棘手吧（笑。

   这位同学的建议比较硬而且比较准，我在发布团队项目选择作业时，仅仅提到了，但没有说明清楚我们以往进行团队项目是靠 github 的 issue 功能进行分工，Scrum Meeting 的作业发布的时间也比较晚，这属于我发布作业的失误。

   第二是这是北航软件工程第一次有这么多助教（8位）参与，我们这学期计划一个助教深度跟踪 1-2 组团队，降低团队车祸概率，但是具体的形式我们商量了一段时间也没有确定下来，在另一位助教提醒之后我觉得可以仅以在 alpha 阶段旁听例会为主，在 alpha 阶段结束后，助教们再集思广益一下，在 beta gamma 阶段改进。当时没有考虑到 alpha 阶段结束后大家的开发模式基本都固定了。没有尽早介入团队开发这是我安排助教工作上的失误。

   另外是部分聊天记录：

   助教：你说的是不是指课程在团队项目前期，教师和助教就需要说明团队开发的注意事项，每个事项应该如何操作，提供初始的方向上的指导，例如任务分配应该xxx，贡献分可以参考xxx，每日例会的内容与形式是怎样的，而不是放任你们自己探索，或者搜索往届学长的博客。
   
   同学：我觉得旁听会议就是个很好的介入方式。课上指导终究是比较浅层的模式，因为一旦提出了“下节课要报告/展示”这样的要求，那么课上团队所表现出的东西就和他们课下做的东西会有些差别了，这是人之常情，没办法的x，而因为这课会议次数要求很多，我想很少有团队会仅因为有助教旁听而去演某次会议x

   第三，关于：

   当然，这不是说要给个人增加单独的博客作业啥的，只是需要有个渠道能真正看见团队里每个人吧。

   我个人现在的考虑是：助教每周/两周与团队的个人进行一次谈话（线上为主）。助教可以以谈话的形式关注团队中每一个人，也相当于对Scrum Meeting博客里展示的团队开发进程做一个验证。然后学生以博客的形式把谈话的内容整理并发布。

   结合第一位同学的建议，可以结合本周内学习/解决的技术问题，一并发出来，相当于一个——周报，这里主要的考虑是：这些东西我们需要留下一个记录，既然需要留下记录，那就需要有人来记录[捂脸]

   同学：说好的不增加单独的博客作业呢[捂脸]
   助教：不，我没说[捂脸]

二、答其他同学

只有获得黄杉的同学才能提建议吗？

当然

不是

中期调查问卷正在路上:)