1、对于每一名程序猿,在刚踏入C语言的世界,蹩手蹩脚得输出Hello world时,便已经开始接触到了编码规范。缩进、命名原则、花括号位置等等,这些规范肯定都曾让每个程序猿头疼好久。在自己大一刚接触C语言的时候,并没有考虑过编码规范的问题,但是随着代码写得越来越多,才逐渐深感一份规范得体的代码的重要性。每当别人叫我去帮忙看哪些排版乱七八糟的代码时,无疑是一种地狱般的体验,于是从那时开始,自己便逐渐注意到编码规范的问题,并在自己日常编程中,尽量提升自己的代码规范性和可读性。 2、自己之前也做过几个Android项目,或多或少对项目开发的编程开发有一定的接触和了解。虽说我们团队所负责的是PHP端的项目,但是编程世界万变不离其宗,大致的编码规范都是相同的。而我们小组也有几名组员接触过PHP和前端的编码,因此在开会讨论编码规范时,整体的过程还是比较顺畅的。不过介于我们所制定的编码规范内容太多,便把编码规范文档上传到github上,以免博客内容太长。
031402342 许玲玲
由于一直都没注意过编码规范这个问题,都是自己看得懂就好的原则,通过这次作业了解了编码规范,发现自己以前都是乱来,这样在团队里面根本是不行的,只有代码规范了之后才能使得整个团队更好的进行编码。开始学习规范编程,从现在开始做起。
031402337 胡心颖
以前写代码都不管编码规范的,什么大写小写驼峰下划线,开心叫什么就叫什么,只要不error不wrong就都可以接受。代码注释更是从来不写,毕竟一个人做,虽然时间久了自己也有点看不懂。这次要规定编码规范,百度了一下,第一反应是:这文档好长。毕竟这次是一群人写一个项目,各种规范还是要做好,万一编程的时候沟通出了差错,轻则几个BUG,重则GG。
031402203 陈齐民
1、每个程序猿都有自己敲代码的风格,而且彼此之前的风格大相径庭,如果多人合作完成一个项目的话,彼此之间做好编码规范和代码风格的确定是非常重要的,因为如果不做规范统一,绝大多数的时间会花在理解代码结构上,而不是代码的逻辑功能;在编写PHP编码规范的时候,我发现自己的编码风格不是特别的规范,在每个接口前我会注释该接口所需参数是什么,何种数据类型,调用方式是什么,返回数据的类型是什么,但是在方法中我很少或者基本不会添加代码注视,这样队友在看我的接口代码的时候,就可能需要花时间去理解逻辑,而且一些细节方面我也会不注意,比如{ 和 }另起一行与否,函数方法变量命名要清晰易懂等等,所以我觉得编写编码规范是很重要的,而且对这门语言也会有更加深入的了解。 2、尤其是PHP,不仅仅是语言本身的编码规范,还包括了给其他开发者阅读的接口说明规范,采用标准的接口说明是很重要的,因为接口是提供给其他开发者使用的,如果不清晰不准确,很容易造成数据的错误,这样就失去了接口本身应该提供便利的特性了。 3、所以,代码的编码规范和风格是我们共同讨论出来的,因此我们每个人对这个编码规范是比较熟悉的,在编程的过程中我也希望自己和队友都能够遵循编码规范,提高开发效率。
031402209 黄伟炜
当你是一个孤胆极客时,不遵守编程规范似乎不是一件大事。因为所有的代码只要你能看懂,可以编译通过,能在机器跑起来就行。但是,如果是一个团队。这样的方式,就不可行了。在一个团队,同一份代码,经手的人可能就有好几个。每个人如果都按照自己喜好来编写,将会有不同的缩进、不同注释、不同命名方法。对接手的人来说这是很棘手的,他需要去适应不同人的不同风格。光是看懂代码,都需要不少的时间。但是,有了编程规范,大家只要共同遵守一份规约,就能很愉快的合作写代码了。而不用去适应不同人的不同风格,节省时间成本。
031402233 郑扬涛
对于编码规范,其实早有耳闻,但是平常自己写代码的时候却不是很在意。而且自己在写acm题目的时候,一般会喜欢“压行”,比如说同类型变量全部定义在一行,大括号不换行,使用逗号表达式等等。但是现在我们是作为一个团队,写出来的代码不仅仅只有自己一个人看,代码也不是为了AC而生,遵守编码规范将给团队交流带来极大的便利。网上有各式各样的编码规范,该如何编写属于自己团队的编码规范呢?于是我们团队就开了会讨论此问题,最后整理了一份大纲。我相信如果每个人都能够遵守编码规范的话,那么后期的开发效率将大大提高。
031402341 王婷婷
以前做php项目时都是一个人完成所有编码,所以对于编码、命名基本都是我行我素,想怎么来怎么来,现在由于多人合作,编码规范自然是要考虑的。不做不知道,一做吓一跳,自己之前的代码规范性简直为0啊,估计除了自己也没谁看得懂了。组员们一起讨论了许久,最终编码规范总算是确立出来了。通过这次的编码规范作业,相信以后我的代码应该越来越规范!

三、数据库设计

用PowerDesigner进行数据库的设计
ER图

四、体系结构与界面设计

MVC角度看体系结构
MVC结构由Model(模型)、View(视图)、Controller(控制器)组成。
MVC将人机交互从核心功能分离出来,模型对于用户来说是透明的,用户只需要观察视图,用户和模型的交互通过控制其提供的安全方法。模型(Model)包含核心功能和数据和后台的业务逻辑,在模型这一层封装了访问数据的函数,例如查询导师、学生信息,负责人导入新的学生和导师等。这一层对于用户来说是透明的,用户看不到后台对数据库的操作。视图(View)负责向用户显示信息,不同的角色可以看见的视图不同。用户在视图上与系统进行交互,一些用户的行为(例如填报志愿、选择学生、调整结果等)会触发模型的功能,从而向模型传递数据或者得到模型更新后的数据。控制器(Controller)与视图一一对应,每个视图都有一个相关的控制器,控制器组件接受事件,并将事件翻译成堆模型或者视图的请求。如果控制器的行为依赖于模型的状态,那么控制器也需要向模型登记请求变更通知。
例如,导师在视图中点击显示学生信息按钮,控制器接到此事件后,调用模型的查询方法,获得数据库对应的信息,再显示到视图中去。导师查看完学生信息后,点击接受某个学生,控制器从视图中读取到此事件,将相关数据传入模型中,模型进行对应的增加操作。
用户角度看体系结构
从用户角度出发,可将体系结构分为 学生、普通导师、系负责人、院负责人四大模块。
以下是四大模块详细描述:

模块描述
学生填报志愿 修改个人信息 查看导师信息 查看志愿结果
普通导师修改个人信息 设置学生数 选择学生 查看学生信息
系负责人批量导入学生、导师 手动添加学生、导师 修改学生、导师信息 设置默认志愿数 设置流程期限 选择分配方式 导出分配结果
院负责人修改分配结果 导出分配结果 设置系负责人

体系结构运行流程
院负责人首先添加、修改系负责人相关系负责人设置该系导师填报选题起止时间、志愿填报起止时间该系导师在系负责人所设置的报选题时间内填报选题该系学生在系负责人所设置的填报志愿时间内填报志愿导师该系导师在志愿互选时间内选择合适的学生志愿互选时间截止后,该系负责人有权修改、导出分配结果院负责人可再次对系负责人所提交的结果再次修改院负责人课导出并公布分配结果
导师互选系统采用ThinkPHP5框架
ThinkPHP5框架目录
主要应用目录
database.php 数据库配置文件
用于配置数据库相关信息,例如:数据库类型、服务器地址、数据库名、用户名等。Config.php 公共应用配置目录
包含应用设置、模块设置、URL设置、模块设置、异常以及错误设置、日志设置、缓存设置等common.php 应用公共函数文件
放置一些较为常用的公共函数,比如弹窗报错等。index/controller 控制器目录
包含导师互选系统index模块所需所有控制器index/model 模型目录
包含导师互选系统index模块所需所有模型index/view 视图目录
包含导师互选系统index模块所需所有视图
界面设计
原型(修改版)_链接

五、任务分工及比例

姓名任务分工比例
陈燊项目管理;把控任务进度;博客撰写14.2
许玲玲界面设计;原型完善14.3
胡心颖体系结构设计14.0
王婷婷体系结构设计14.2
陈齐民数据库设计;ER图的制作;验证验收标准的改进14.5
黄伟炜编码规范的整理以及撰写14.0
郑扬涛改进完善《需求规格说明书》14.8

六、燃尽图

七、总结

031402304 陈燊
1、在之前访谈学长时,学长们一直告诫我,作为项目管理者,最重要的责任是把控全局,协调分工,尽量不参与编程。而在本次作业中,我也尝试着去改变自己以往在团队里的角色,尽可能得把任务平均分配给每个组员,并让每个组员负责自己较为擅长的部分,以求取得1+1>>2的效果。此外,为了让项目管理更为清晰便捷,我把每个组员的分工、任务实时更新在github的issues上面,改变了以往QQ繁杂的文件传送,让任务成果的显示更为直观。而通过close/open的次数统计以及燃尽图的生成,让我对整体任务的完成进度有着一个清晰的了解。尝到了issues给项目管理带来的甜果,我才明白了之前的作业里,栋哥为何一而再再而三得强调对git以及issues的使用了。 2、当然,有甜也必有苦。以前总是以程序猿的角色自居,开着PM的玩笑,而如今角色互换,等到自己真正开始做一些类似PM的工作时,才深感PM的不易。我觉得我们团队是一支战斗力挺强的队伍,队员们各有所长,对待项目都有着自己独特而理智的见解。而如何把这一根根强劲的钢丝凝合成一把无坚不摧的利刃,便是PM的职责所在。硬件设施有了,而整个团体系统的上限,则取决于PM对任务成果的把控力度。在本次作业过程中,对于每个组员所完成的成果,我都尽可能一字不落得去审核把关,并提出自己一些建设性的意见。当然,意见的提出总是避免不了意见的冲突,但是有冲突,才会逼迫大家去思考,这才是一个团队前进的最大动力。 3、在一个团队里面,沟通很是重要,特别作为一个PM,更是要把自己的想法一字不漏、毫无歧义得传达给队员们。在本次作业中,我自认为对于沟通这一块,自己做得并不是很好,对于部分任务的意见,没有清晰了当得传达给队友们,导致了任务进度的拖拉。不过在下次作业中,我会努力去改正自己的不足之处,尽量让团队里彼此之间的思想都透明起来。 4、最后,作为这个团队的组长,我会尽一切努力把这个团队给带好,理解每一名组员的想法,也非常非常希望,组员们能够理解组长,共同造就“产品经理程序猿和谐一家”的美好局面!谢谢!