[软工顶级理解组] Alpha阶段团队贡献分评分

评分总表

下述表格适用于前端、后端、爬虫开发者的评分，基础分数为50分，在此基础上进行增减。

PM由于工作性质较为特殊，所以不参与以上打分。PM若在实际开发阶段中参与了开发，则可适用Bonus相关的规则。PM的分数将由剩下的所有同学，在团队项目验收结束后进行统一打分。打分模板如下。如果该模板不够详细，可进行进一步细化。

准时性评分

对于Alpha阶段开始时所开放的issue，大家都有在Alpha阶段结束时较好的完成。不过，在测试这一周，依然出现了不少需要开发的任务，这些任务先前没有分配，会计入“完成额外的开发任务”的bonus中。

因此，在准时性方面，大家都没有扣分。

质量评分

所有的额外开发任务和Bug都有issue进行记录，对issue进行量化评分。统计4月23日~5月4日之间的issue。

胡彬彬的代码bug数量最少，并且每次上交之前都会进行测试，整体代码质量在测试阶段表现较好。对于上一阶段做的不够完善的错误处理，在测试阶段也进行了修改，目前的错误处理信息已经较为完善，会给到加分。

李嘉铖的代码bug数量不多，且都是可以原谅，不太影响功能的bug。不过，在写代码时还是存在一定程度的粗心和考虑不周，需要注意。

杜博玮作为爬虫开发，bug数量确实非常多。大部分debug时间都在与爬虫交流，或者说一个bug最终总会定位到爬虫身上。不过这不代表其代码本身的质量比其他开发者差，只是这份工作的特殊性导致bug不断。不过这么多的bug应当也有办法去减少。比如：

• 建立更加完善的错误处理机制，覆盖更全面的try-catch，起码保证不要有chrome没杀掉
• 与后端沟通，最好是每一个字段都有为空串或者null的准备，预防特殊情况
• 做好错误局部化处理，不要因为一个错误导致整个爬虫进程瘫痪（例如issue#140，issue#98）

我认为这些都是爬虫可以做到更好的地方。在Beta阶段，在使用python的requests包进行重构的时候，虽然避免了许多内存上的问题，但在网络方面的问题依然无法忽视。希望爬虫能够做到更好。

前端总体来说，bug较少，可能是因为使用了较为成熟的框架和模板，但存在一些疏忽的bug。

相对而言，单彦博出的bug更少，且担任了前端code review的职责，在PM不熟悉前端代码的情况下，充当了一个3人组内的PM角色，所以会把加分给到单彦博。

Bonus评分

下面是额外开发任务的评分参考。完全按照issue数量来定开发加分不太合适，因为每个issue的任务量不同。如果是任务量较少但可归为一类的任务，会统一计算。

最终评分

折算加权时，前端3人共享150分加权，后端3人共享150分加权。

因为要求不能出现重分，且分数必须为整数，所以如果出现重分，会优先根据代码质量、额外开发issue数量来决定谁的分数更高。

最终分数将等PM分数投票出来后，七人共享350分加权。

PM分数投票，加权均分53.33，截图如下：