PhylabWeb——阅读作业
- 问题回顾
- 提问博客地址：http://www.cnblogs.com/kibbon/p/4831104.html
- 尚待解决的问题：
- Alpha/Beta，ZBB/RC阶段的界定，由于只体验了项目开发的alpha/beta阶段，对这两个的定义仍然仅有时间上的概念，alpha阶段须作出一个相对完整的可以运行的版本，那么这个”完整“要如何理解才合适，毕竟beta阶段也会添加一些核心功能，alpha阶段未必总是完成了所有的核心功能的
- 对于代码规范的制定尚不清晰，因为我们的团队项目使用到了很多种不同的语言，网页前端这里主要是php,html,css和js，后端核心功能模块则是用python编写脚本，在这种代码不统一的项目中，需要如何制定代码规范呢？我在使用bootstrap框架进行网页编写的时候，了解到bootstrap是通过分层次的类定义来为dom标签赋予样式的（bootstrap的类名定义非常工整），js则是基于Jquery编写，可以理解为前端的代码规范都是采用这样的模式制定的嘛？
- 已经解决的问题：
- 对于写了再改模式的利弊分析，我认为对于团队协作编程，弊总是大于利的。在结对编程中因为前后端交互较少，都是围绕着接口进行，程序松耦合性比较好，写了再改模式的弊端没有充分体现出来；而在团队项目中，我和后端需要对同一个网页的Php文件进行修改，频繁修改导致的问题就是两个人自己仓库里的文件差异增多，冲突增多，并且由于服务器环境较为复杂，我不便于立即查看自己修改后的代码运行效果，每次修改都需要等待后端部署好后再查看。这样就极大地拖慢了工作效率，因此我在处理论坛页面的时候，借助于后端工程师的引导，在本地部署了一个wecenter服务器用于检查代码执行结果，以尽可能的提高代码质量，减少复写率。
- 关于单元测试，通过scrum meeting我从负责后端计算模块的同学那里了解到，这个还是单独去做的，每次上线前会进行一次测试，不然会影响效率。当然，后端的压力测试就更是如此了
- 对于优化，项目中前端这里的优化主要是指浏览器兼容性优化和响应式布局，这一点我确实意识到有的时候过多的做一些优化可能会起到反效果，网页是内容，而浏览器是框架，浏览器自身会通过优化兼容越来越多的网页（比如支持更多的H5/CSS3特性），编写网页文件时，为低端浏览器所做的一些兼容优化最终都会成为废代码，因浏览器自身的更新而被淘汰，因此只需要考虑对主流浏览器较新版本提供支持即可，兼容其他浏览器反而容易丧失代码的纯粹性，甚至会影响到原本主流浏览器的效果。响应式布局方面，因为不同浏览器对响应式设计支持的程度不同，全部兼容会造成大量的代码冗余，时间资源又有限，所以只考虑chrome/firefox内核。
- 新问题
- 在没有办法在本地部署服务器的前提下，前端工程师有无快速核查自己代码执行效果的手段？
- 在需要修改同一个网页文件来配置路由的前提下，前端和后端搭配工作的最好模式是什么？在同一个分支下协作还是共同完成 ？
- 新体会
- 团队项目中，如果不能解决一个bug，那么至少需要将其掩盖，因为团队项目的文件可能经手不同的人修改，如果bug不解决，很容易就会引发至各处，届时bug的修复成本是难以估计的，也就是所谓的”大泥球“现象，在开发过程中我们遇到了页面图标字体显示异常的状况，经排查知道是由于本地的bootstrap.css和bootstrap.min.css对字体文件路径依赖不一所致，前者是fonts目录下而后者是font目录下，因此在处理的时候牵涉到了路由修改和相关css路径的修改，可以说是饶了很大一圈，由此可见对”大泥球“问题必须时刻保持足够的重视程度
- 收获的知识点
- 需求阶段
- NABCD分析法
- 设计阶段
- 界面原型设计，了解了诸如mockupbuilder的原型设计工具
- 实现阶段
- 了解迭代开发的基本流程，如何运用github进行项目代码管理，学习了bootstrap框架并初步了解了网页前后端对接
- 测试阶段
- 意识到”大泥球“现象的存在，在后端的配合下在本地部署服务器，意识到开发人员自身的测试对于团队项目管理的重要性
- 发布阶段
- 了解了产品发布需要做哪些准备工作，如何通过git合并各个分支的源代码以整合成最终产品
- 维护阶段
- 充分意识到了敏捷开发中运维阶段工作的重要性，由于敏捷开发追求效率，运维阶段每个人都必须在自己负责的模块上针对各种意见反馈给出及时的处理，以免耽误整个队伍的代码修缮进度
- 需求阶段