1.避免走进熟人社交的误区——给新手助教的几个建议

2.[构建之法论坛] 助教之路

https://www.cnblogs.com/SivilTaram/p/8689091.html

关于新人助教，很大可能会遇到时间精力不足，比如点评博客花费大量时间，评论产生审美疲劳，面对同学们的大量问题不能解决/解决效率太低等问题

总结如下:

1.评论不应该大而全，而是小而精，把握博文的重点且能反应个人思维特色的点给予评价，高效率低成本的去完成评价工作。

2.答疑时，制定常见问题极其解决方式的表格放在博客作业的注意事项中来提示同学们。组织统一在线答疑时间，避免一对一答疑。

3.现代实践课程对同学们技术和经验的提高无疑是很明显的，只是需要投入的精力是大量的。

二、自己评价的学生博文链接列表及评价内容

1.https://www.cnblogs.com/3451ymx/p/10541519.html#commentform
引用
而代码作者一定是最熟悉自己代码的，但他自己复审，会有思维的局限性；如果同伴复审，就不存在思维的局限性，那么是选择一个同伴复审，还是两个同伴复，甚至更多呢？

同伴复审的前提是两个人进行结对编程，互相了解任务的需求和各自的任务分配，复审的目的是去理解对方代码逻辑和各功能模块的正确性

2.https://www.cnblogs.com/Jackeyyyy/p/10557874.html
引用
最后一个问题是如何找到那些隐患极大的BUG（来自第十四章质量保障章节

找BUG可以通过运用代码复审，软件测试的方法去发现，优化问题。
我觉得这个不如换一个思路，怎么样去避免BUG，去合理的设计代码规范，项目分工，团队模式的选择等等...

3.https://www.cnblogs.com/IUidol/p/10557988.html
引用
顾客怎么参与到项目中呢？他们只关心所交付的功能是否很好的完成了，并看不懂代码听不懂专业知识。而且在参与过程的顾客并没有在当时就提出新的要求而是之后再提呢？

用户是提供需求的一方，软件工程师们则是解决需求的一方，用户不是在项目中理解代码，而是看代码实现的功能是不是自己想要的；在项目中交流则能够及时提出需求，方便及时改进

4.https://www.cnblogs.com/luopl/p/10573745.html
引用
从刚刚上大学到现在已经两年了，通过这两年的学习对我既有打击也有激励，打击我的是软件开发是一个艰难而比较漫长的事情

正是因为是一个漫长的过程，所以才需要我们去耐心学习，有了那个专劲，做好也就不是问题咯，加油~

5.https://www.cnblogs.com/SW-P-WY/p/10547958.html
引用
纸上得来终觉浅，绝知此事要躬行！一门工程专业，我觉得还是实践最重要。

很有魄力的想法，也很相似的理解，相信你能追逐你的热爱，多敲代码，积累技术

6.https://www.cnblogs.com/wwcy/p/10654363.html
逐渐学会了做软件测试，性能测试和Github提交代码，进步很大。但是在代码规范的制定上没有详细给出，望多多注意

7.https://www.cnblogs.com/SW-P-WY/p/10657136.html
可以看错结对编程对你们提升很大，流程图也清晰的展示了功能的实现过程，很棒~

8.https://www.cnblogs.com/qi-li/p/10656808.html
结对编程就是让大家知道1+1>2这个道理，你们已经能够在结对时合理分工，完成项目咯，很棒。

9.https://www.cnblogs.com/wwcy/p/10745896.html
作业的完成度不是太高噢，在需求分析的分析不是太完整，任务进度的安排上也是需要更加严密，继续加油噢~

10.https://www.cnblogs.com/TakeRabbit/p/10736233.html
原型的展示的非常清楚，表达了具体的软件功能，也可以适当的加入创意，增强软件的吸引力。

三、自己评价后的总结

评价了10份博客后，确实遇到了刘乾助教说的那些问题。

1.刚开始总是兴致勃勃的，到了后面面对相类似的博文时，就会觉得枯燥乏味，不能给出针对性的评价。

2.对于软件开发流程有所生疏了，需要及时复习以前的知识。

3.在比较有技术性的问题上，可能不能及时给出解决方式，技术暂时有些不足。

4.建议博客集中式评价，抽出一段时间去完成很多博客的评价，避免标准不一致。

5.充分利用闲时时间，不会对自己「学习/工作」等需要大段集中注意力的时间形成干扰，也就不会让助教产生劳累感。

后面时间还需要再多看优秀助教的心得经验去学习~