软工大作业之“微学堂”

2016年就要走入尾声了,今年最后一个提交的作业是软件工程课最后交付的产品——清华大学微信网络学堂助手“微学堂”。虽说是“产品”,但其实11月底才公布和确定选题,只花了一个月开发,中间还经历了1个编译大作业,1个嵌入式大作业,1个传感器网络大作业,还有一场haskell考试和杂七杂八的小作业和不太麻烦的大作业……还好有我们的组长群主,每周勤勤恳恳地为我们订周一和周二的研讨间,每周两次的集体开发大家的效率都非常高,当然赶迭代n的ddl时也会有“加班”的情况,不过总体而言工作都在有条不紊地进行中(大概组长还是经历了很多承担压力内心崩溃的时刻……),最后我们的完成度也相当高。

简单来说,我们这次仍然做了一个基于微信的移动端web应用,从网络学堂爬取课程作业、公告等等信息,然后通过微信公众号能推送新消息或者提供给用户可以便捷查看作业、公告、讲座等信息的界面。后来爬虫的工作由另一个组接手专门开发api,我们也从最初的查看新鲜事、推送ddl等基本功能,拓展到了可以通过日历界面查看新鲜事,还可以在平台上发布组队信息等等,当然这个过程中我们也放弃了很多特性,比如一开始在讨论目标用户的时候,我们就选择放弃了助教和老师,专心做好针对学生的应用,还有后来在很多组都在做讨论区的时候,我们一直在犹豫,最后放弃了做通用的论坛,而只是做一个发布“求组队”信息的平台,更具针对性的特性,能最大化地解决用户的问题,最后能发展到大家一想到“我要组队”就会想到“微学堂”,还能起到一定的宣传效果,而要是这个平台上什么东西都有反而就弱化了这个应用的印象。

img

我想,这是我从这个大作业学到的第一点,第一次做自己给自己提需求的作业,当然会面临“啊我们就写简单一点吧”的惰性,但其实要决定是否加一个特性的时候,真正让我们犹豫的是这个功能是不是有意义的,当然也有对自己能否如期完成并交付这个特性的考量。这个思考的过程很有意思,也如华榕大帝迭代一检查的时候所说,要学会做“小而精”的东西。一个高完成度的产品,不仅需要前期的脑洞、后期的技术,也需要逻辑,这个逻辑包含了常识和合情推理,能判断用户到底想要什么的能力,这一点我意外地从跟群主的言谈中得到很多体会。

关于收获,第二点当然是对前端有了新的认识,虽说很多地方自己仍然非常naive,不过相对于之前的naive还是要好多了……学习了vue.js,略微了解了一点点现在流行的前端框架,顺带复习了js的各种语法(尤其是js的Date对象……坑很多啊),还有再次感叹前端果然需要设计力,大概自己在这一点上还是越来越有自信了吧,能用有限的工具、有限的能力,做出让大家眼前一亮的东西。

第三点就是学习到了团队开发中维护文档的重要性,多人协作的时候,尤其是不能集体开发的时候,文档对效率的提高尤其重要、能使很多问题引刃而解,对写前端的同学来说,甚至都不用花太多时间来阅读后端的代码。对文档的信任,也体现了团队成员之间的相互信任吧。而如何设计接口也很有学问,参数应该尽量简洁的同时足够灵活和强大,不过一般来说我们就根据需要的功能来设计这些接口的参数和返回字段,有其它需要的时候再进行添加。另外,这个文档也不仅是我们在wiki里维护的前后端api文档,需求建模的作业里我们写文档的过程也帮助我们梳理了很多思路,也为后面写代码的过程提供了很多约定好的支撑。

总之这个大作业写完还是很有成就感的,全靠组长和其它队友的carry!感谢感谢!

老师说大家在个人总结里可以写一写关于课程的建议,我想就是能不能给后一个大作业再多一些的时间?用心做真的收获很多呢,或许再多几个星期,能做得更好OwO 也感谢老师和助教一直以来的关照,再次感谢!