一、软件工程团队项目感想
两个月的开发一晃而过,我们经历了两轮迭代,完成了我们的产品——“北航Clubs”。这是一个为社团与学生提供服务的网站,这个idea一年前就诞生在我的脑海中,最终经由软件工程课程的开发机会,我完成了自己这么久的执念。同学都戏称完成了夙愿。
一年前,我刚上大二,在宣传部接手凌峰社社团管理事务。从这个身份的角度,我看到了北航学生社团活动的四难:
1.百团大战之后,学生想加入社团难
2.学生如果不及时查看海报,想发现并参与自己感兴趣的活动,难
3.社团想要让学生了解自己、了解自己的活动,难
4.社团想要管理社员、进行招新,种种事物繁琐,难
随着对上述困难的切实感受,我越发感觉到,一个可以连接起学生与社团的平台,会帮助很多希望充实课外生活的学生,方便几乎所有需要组织活动、运营管理的社团。
自然而然的,我们选择“北航Clubs”作为软件工程团队项目。网站的架设与研发历时两个月,时间不短,但是期间很多精力都不得不投入编译、数据库、数学建模以及几科期末考试。这对项目的进展产生了很大的阻碍,也让我们在最后的两周连续刷夜才将项目最终完成。值得庆幸的是,我的六个队友:王开、徐丞、王春阳、杨墨犁、付帅、王若愚都非常非常给力,没有我们的齐心协力,我们不可能完成这样大的一个网站。
春阳做事认真负责,最后答辩前,网站功能还有小bug,团队焦虑的时候会为没有人做的“文档”做准备。春阳是个做事规律,就如他生活习惯规律一样,两轮开发中的scrum都做的很用心。日常开发,很多细节,比如对API实现正确性的质疑与修改等,都体现了责任心与细心。
王开在项目中很主动,短信与邮件服务这块他了解最深也基本由他负责。印象最深的是一轮迭代发布前一晚,王开和我、还有付帅一起把短信、邮件功能开发完成。第二天的一轮收功演示中取得很大的效果。
徐丞学习东西,做开发都很高效,第一轮开发开始,大家都不会rails,徐丞学习并架起来第一轮迭代的服务,和春阳、王开一起完成了后端的建设。两轮开发中,徐丞做出的贡献都相当大。
付帅,前端开发的主力,通过快速地学习,迅速理解了HTML、CSS与JS,并用JS实现了ajax与后端API接入,完成对Ueditor的学习与使用并成功运用入项目,解决开发时的一大难题。
杨墨犁,前端开发的另一主力。她是团队中唯一的女生,有着寻常女生不具备的努力与实力。对她第一印象是执行力,跟她说过的事情往往很快得到响应,交给她的任务,她的完成速度让我意外而惊喜。原本给她规划的任务是做Ui设计,后来却成了前端界面的主要开发者,使用SemanticUI,完成了第一轮界面的建设与第二轮部分界面的设计开发。
王若愚,前端开发的实干家,他在开发中主要负责JS代码的编写,实现页面的逻辑功能。他往往用最朴素的方法实现功能,实现速度很快。有时因为API不正确、JS代码不熟悉等原因而气恼,但交给他的任务他一定会保质保量地完成。
两个月的开发,我觉得最幸运的就是有这么一群靠谱的队友,前端我可以放心地交给付帅若愚,界面交给杨墨犁,后端交给徐丞王开王春阳,所有事情告诉他们就不用重复或催促,任务能完成地很好,也时时有给力队友主动的开拓一些新的好用的功能、特性。在我面对前后端开发的压力时,他们能站住来,让我心安,在我面对文档、软工杂项事务心烦而无力时,一点小的提议,伙伴们给以支持,就有了继续走下去的动力。在面对第二天答辩的DDL,刷夜实现新功能时,我费尽力气完成了短信服务资格(里面有一些波折,差点放弃短信服务),并完成了发短信API的ruby版demo。但已经是凌晨四点,心神俱疲,一切已晚。却没想到,王开付帅都没睡,他俩接过了接力棒,一个完成了API,一个在前端完成页面逻辑,就这样,给力的短信与邮件功能如期上线。一切都来的那么意外,让人满满欣慰与鼓舞。
最后再说一下我自己。第一轮开发,我是团队中唯一有相关技术经验的人,为项目做了整体规划与技术架构设计。在做架构选择时,确实涉及到非常多的问题。我不是经验丰富的老司机,顶多算一个上过路的小司机,却要在众多框架,技术实现路线中寻找适合本项目的结构,这给我很大挑战,我第一次进行了各种技术流派之间的比较,最后选择前后端API交互,后端MVC,前端MV*的技术框架,后端选择rails,前端则决定使用HTML+CSS+JS这样底层语言实现。第一轮对前端没有做太多技术规划,这一方面是相比较而言我在做设计时更担心后端服务,一方面是我对前端开发技术与主流框架不很熟悉。时间检验后,我对前端的不重视让我们走了一些弯路。
到第二轮开发时,在AJAX、后端API开发都不成问题后,UI与前端界面已经成为制约团队开发的技术瓶颈。前端界面的好看与易用程度成为我们最大的关心。我意识到前端的重要性,学习了React和vue.js两个前端框架,看了AngularJS等,真正了解了前端开发思路。我准备采用vue.js,却发现前端彻底重构代价太高,大家时间精力不足的情况下,前端重构的想法无法实现。意外往往出现在你轻视的地方。如果我在一轮开始就使用vue.js,我们的前端开发会更快地走上正轨,而不用受制于重构的困境。
最后,我挑下前端界面重担,二轮开发中负责实现用户相关界面。在这个实现过程中,代码布局、代码结构上都追求与主流代码实现相似,最起码代码看着不要那么“low”,界面也向“微博”的UI看齐,实现了微博UI的各种效果。随着前端工作逐步深入,又加入了jQuery和juicer作为前端逻辑控制工具
二、对《构建之法》阅读问题的回答
1.需求是什么,需求的规范需要明确吗?
需求是对自己目标产品的抽象,它既描述了产品的种种特性,也分条目描述了产品的功能,有为开发提供指导的作用。需求必须明确,否则会导致利刃迷失方向。
最开始,“北航Clubs”立项,这个项目的产品目标是服务社团,为此我们从用户使用角度,规划了许多实用需求,如:信息发布、活动发布、活动报名、社团报名与社员管理、群发短信、群发Email、社团网盘、收缴团费、社团申请借用教室以及社团文化产品电商等。
随后,深入开发后,我们又提出了活动与资讯评论、用户实名验证登陆、查看个人信息与修改个人信息、找回密码、站内信等需求。
一轮开发之后,二轮开发之前,我们又设想了APP端的需求量以及需求实现难度,做一个安卓和iOS的应用也在可以承受范围内。以及web端界面UI的重新设计,好看易用响应快。
我们当时提出的这些都是需求,制定一个需求有两方面的考虑,一是产品定位与用户对该需求的迫切程度,二是需求实现的难易程度以及团队现实情况。可以说,需求既是对产品的规划,也是对技术实现的计划。
比如说,开发安卓、iOS的需求,很切中用户痛点,也符合产品覆盖web、安卓、iOS平台的设想,但需求难度太高,最后也无法实现。
另一种,申请借用教室,这个需求也有一定用户需求,但与我们“社团与学生沟通平台以及服务社团”产品规划偏离稍远一些,于是也没有给予实现。
实际上,提出需求,正式脑洞打开的时候,肯定会有大量合理的不合理的需求被提出来,但对于需求,需要有需求分级,确定下那些需求应该被尽快实现,哪些需求无关紧要。最终项目的实施是按照需求优先级予以完成的。
需求规范,我认为需求更像一个idea,一个需求的规范就是抓住用户痛点,尽可能地细化,并且描述清楚,无歧义。需求需要有用户主体、用户行为、期望功能等几个要点的明确说明。
2. 一个人开发效率非常高,多人开发,个人效率随团队人数上升而直线下降,我们一般需要将大项目拆为小项目,使协作耦合产生的效率负影响减少。但是,谁来做项目拆解工作呢?
这一点我深有体会。拆解工作的人,一定是对项目整体有经验的人,最好是架构师。架构师熟悉各方面开发过程细节,拆解大任务为小任务,最重要的是工作间依赖要少,即使存在依赖要方便沟通,同时为可能存在的依赖进行预估、记录,提前准备解决方案,以防止两个子任务相互干扰。
在项目开发过程中,我实际成为“北航Clubs”的架构师,通过设计前端——API——后端的架构模式,将网站开发任务拆解成前端后端两部分,并准备API文档作为前后端相互依赖的解决方法。
3. PM应该是技术大牛,还是其他哪种人?
首先,PM应该有产品思维,要懂得需求,懂得用户痛点,懂得UI审美,这样产品经理才能将开发团队引领向正确的方向。
其次,PM应该有一定的技术基础,但不应该是技术大牛。技术大牛,能力大,责任也大,开发任务不知不觉就会重,定会顾开发顾不上产品管理。但是PM也不应该是技术小白,不然他提出的需求、产品设想很容易脱离团队实际情况,脱离于技术实现能力,项目因此会受到打击甚至停滞。
我是团队的PM,在一轮迭代中我不写代码,而是负责架构与督促管理,一轮任务进展顺利。二轮迭代,我成为前端开发主力,团队开发效率提高了,产品质量也有改善,而我却无力再负责团队管理,很多后端的事情我都不清楚,只能让前端其他同学直接去找后端同学沟通,团队整体时间安排受到影响。
4. 敏捷开发会导致代码重构次数很多,或者文档不全导致代码可读性差吗?
会的。
在我们的开发中,代码重构时有发生。
一轮开发中,需求是“建设社团活动分享平台”,所以平台上文章全部是活动。
二轮开发,将文章区分为“活动”与“资讯”,资讯没有报名资格,为实现二轮的需求,我们不得不将前后端文章部分的相关代码重构,区分活动与资讯后再重新部署。
另外一个是,一轮开发时,需求只是“短信邮件通知功能”,二轮时变更为“短信邮件与站内信一起作为通知功能并可以查看历史通知”,这使得短信、邮件被取消,新建一个统一的“通知”实体,下分三类子实体(短信、通知、站内信),也导致了大量的代码重构。
而对于UI需求的变更,一轮为开发速度设计的UI在二轮被迫重构,一轮开发的前端学生界面完全弃用。
文档可读性差倒是没有,我们的文档主要是API文档,而且是时时更新。可能有时没及时更新,却不会出现可读性差的问题。代码方面,会有一定影响,因为部分代码是从之前的逻辑中拷贝过来的,但总体影响不大。
5. 团队中,代码风格规范与设计CSS风格规范应该怎样制定?会发生变化吗?
这是个很好的前端问题。
代码风格规范,主要包括:
1.缩进四字符
2.命名遵循驼峰命名法
3.代码封装成块、成类,前端代码将JS代码封装在.js文件,页面JS代码同一卸载HTML的body最后的一个script中。所有页面元素绑定事件函数在一起集中实现,JS全局变量同一写在该script最开头
4.Ajax书写,API报错等代码由API文档规范约束
5.因为项目比较小,CSS样式全局共享,统一放在header2.css文件中,以避免CSS冲突。(如果项目做大,将使用SASS完成CSS功能)
代码风格制定后,会很稳定地存在很长一段时间,除非项目大规模重构,否则代码规范不会被彻底取代。
CSS风格:
当初阅读《构建之法》时,心中对前端开发与UI设计之间的配合有不明晰的地方。比如UI设计出曲线等元素,前端人员可能无法很好的实现,前端容易实现的样式,UI设计由有可能无法注意。这两种职能交叉点就在CSS样式,理想状态是UI出设计图并规定出各个位置CSS样式属性。但这样太难为设计师了,可行性不好。故而我对CSS风格规范的解决方案有疑惑。
经过一定的实践,我了解到前端开发中,设计师只负责出图,具体样式实现全部由前端工程师负责。但是设计师应该出一套CSS风格规范,如网站的配色方案、UI交互方案以及动画实现方案。
CSS风格规范会发生变化。设计师可以更新方案,而前端工程师应做好CSS样式管理工作,可以快速有效地应用新的CSS设计方案。
6. 测试驱动开发的开发方式中,测试用例无法考虑代码中的bug、逻辑不严密的地方,应该怎样修补?
一个程序的状态机应该是可监控的有限的,这种情况应该是将多种逻辑代码杂糅在一个程序体,需要将该程序分解为若干子程序。
7. PM应该要求团队中的每个人都达到“极限编程”的状态吗?
我们团队软工开发过程中时常会有“极限编程”状态,大部分原因是DDL太紧,也有一部分原因是无法阻挡控制的时间分配问题,此时必须充分调动起队员的战斗力,完成任务。“极限编程”状态下,项目进展会非常快。
PM应该为软件工程中可能遇到的各种突发情况做好备案,“极限编程”是备案之一。PM应当尽可能避免“极限编程”,不到十分紧急,最好不要使用。但是如果真的遇到问题,PM应当要求队员“极限编程”完成任务,保证软件工程顺利完成。
三、产生的新问题
团队文档应该交由专人负责吗?
这个问题的产生源自于我们团队博客团队展示效果都比较缺乏。
我们日常开发过程中,不够注重记录,也没有专人强调提醒那些需要被记录,所以到最后博客撰写的时候,常常还需要重新收集素材。除了素材,语言技巧、排版技巧、展示技巧都是我们缺乏的,我们在这方面的短板影响了各位同学。大家无法找一个人专人负责,只好集体负责,这又会导致一定程度的文档不规范与风格不统一。
实际上,文档交给专人负责也会有困难,难点在于很多开发过程中的记录,如果文档负责人不清楚开发过程,也就很难了解哪些东西需要被记录。说到底这也是经验的问题。
我觉得文档应该由一人牵头负责,自己分内负责文字排版与展示,分外需要提醒、督促其他队员记录必要的信息并收集这些信息。这个工作我想不是很轻松的,我在以后的软件工程项目中会加强考虑。
四、软件工程与博客论文再体会
1.瀑布模型与敏捷开发
我们采用的方式是敏捷开发
我感觉敏捷开发很自由,在项目启动的前期大家都有相当高的自由度与活跃度,但随着项目不断发展扩大,敏捷开发带来的文档不足、相互间依赖与不稳定会降低这些自由度与活跃度。最终我们二轮还是书写了大量的文档,包括较一轮复杂全面地多的API文档。
所以我觉得瀑布模型和敏捷开发并不是一个二选一的问题,而是即使你选择一个,在实践中,你也会情不自禁地偏向另一个,最终达到一定的平衡与饱和。
2.大泥球
二轮迭代开发中,深刻地体会到大泥球。
一轮迭代,对前端代码要求比较宽泛,以实现功能为目的。
一块代码完成后,后续的跟进维护没有跟上。
存在大量冗余代码
JS DOM操作随处都有,使用的方法不够简洁
这些问题制约了二轮开发阿德效率。最终,出于重构学生界面前端的想法,我们对学生界面前端进行重构,完全抛弃“大泥团”,实现了新一版前端界面,完成了代码的精简、模块化、规范化等。
大泥球对后续的维护和开发带来的影响是致命性的,绝对不能让“大泥球”进入正式代码,要即使铲除——重构,或者改写精简。
3.银弹
软件工程确实是不存在银弹的
我们找到比较好的架构与工具,在一轮开发中队员也积累了较充分的基础。可软件工程还是在DDL前一天完成开发,这就是软件工程的“银弹”。可以说,尽管有经验,有好工具,软件开发工作中的复杂性、一致性、可变性和不可见性依然是不可变的
五、在实践中学习到的知识点
需求:需求分析、需求分级
设计:API设计、UI设计、技术框架选择
实现:前端技术(HTML、CSS、JS),后端rails技术,短信群发、邮件群发功能
测试:Fiddler前端测试工具
发布:学习软件的部署,从test环境到product环境,需要进行环境的配置。
维护:学到htop等服务器监控、错误处理命令