个人作业week7——前端开发感想总结
1. 反思
首先要谈谈在这次团队项目的工作中,我这边出现过的较为严重的一个问题:
我和HoerWing (后端担当)合作时,最初因为我没有使用github(始终连不上,最后才确认是宿舍有线网的问题,没错就我那一个位置这样= =),所以导致我和后端这块对于代码进展的情况严重不同步,因为我们要同时写一个网页,同时又因为是敏捷的工作模式,所以经常会需要做一些小的修饰,而在这个时候就会冲掉对方先前写的一些逻辑。整个项目中前后端对接是比较后期的一件事儿,所以这个问题最后才暴露出来,不过好在后端这边封装得很好,因此没有拖延整个工作流程太久,用无线连上github并和后端使用了一个共同的分支之后这个问题基本已经解决。
2. 网页开发中的‘大泥球’
我最初理解的是对于前端应该不需要过多考虑这方面的问题,但后来整个页面的绘制加前端逻辑写下来也是上千行的东西,结构和功能逻辑都会比较复杂,比如不同的操作时页面元素的改变,用户保存实验数据,发送XML格式化的数据,后端处理完毕后返回正确结果或异常时按钮的响应情况是不同的,相应的也会伴随着一些页面元件的样式变化,因此后端要做代码复审工作就会变成一件非常捉急的事情,这个在前后端对接的初期成为了一个类似于‘Big Ball of Mud’的东西,不过好在我跟后端沟通后结果了这个问题,那就是我来复审后端添加的逻辑代码,并将纯前端的内容分离拷贝出来以便本地查看实际效果,相比较前端的内容,后端添加的逻辑很精简也很易读,毕竟我这边没有配置过后端框架的环境(事实上也不好去在linux系统下做这些设计的事情,至于虚拟机,我可能会在年底考虑换硬盘的事儿,但是现在没有钱),所以没有办法做到所见即所得,只能采取这么个这种的方案,不过好在对于一个小项目,这一点的影响不算很大。
3. 交易频繁的集市
对于集市和大教堂,我觉得整个软件的项目可以从整体上视为一个大教堂,但是同一个部门(比如网页交互,计算核心开发)内部采取的是集市的模式,那么就会不免常常有两个人修改同一部分,结果出现各种代码上的冲突。对于学生时代的我们而言,将这些冲突通过PM合理分配工作来化解实在是太难了,尽管PM很负责,但是我也能看到,更多时候他是通过自己重写有问题的部分来解决这些问题,相比较归咎于经验不足,我觉得这可能是软件工程中的普遍现象?因此我提倡如果要求敏捷,则对于一个独立出来的负责部门而言,或由一人负责,或由有良好交流的两个人结对编程来完成。这样对于敏捷开发过程中的频繁更新情况,在做代码修正时的内部沟通成本也可以有效降低。
4. 代码优化与软件工程
每个软件在开发的过程中,都会不停地去考虑代码优化,或者说代码可扩展性以及兼容性的问题,因此这就增加了每次代码调整的成本(这要求我们必须重新审视之前所有优化过的地方,但是更常见的场景是你有可能不知道别人所做的那一部分优化),比如为了避免冗余我常常会采用jquery绑定的方式来为一组DOM对象绑定事件函数,但对于单一DOM对象的事件则回归JS的写法;对于中文字体的显示,考虑到网速问题,就放弃用下载来的中文字体去渲染而是通过建立合适的font-family顺序,针对不同的用户调用其系统内置的优化字体去显示(将mac的冬青黑列在win的雅黑之前等等);为了更好的兼容各种浏览器而放弃一些H5的新特性之类;于是当我需要改动的时候我自己都常常会忘记有哪些地方需要重构(在没有用户反馈的前提下),所以我发现果然最好的解决办法还是回归PS(笑
5. Agile 敏捷
考虑到敏捷的要求,我们使用了一些框架,并且参考了一些模板(如se7en)中一些css的写法,并提取出来放到网页的样式表中,此外也在codepen社区上摘了一些HTML+CSS的动态样式(LOADING动画),不过由于bootstrap定义了大量的类名使得做这种事儿命名冲突会比较难于处理,所以能自己写的样式部分我就全都自己写了,对于一些批量使用的样式(比如实验数据表格模态框),就集成到自己定义的样式表里,我觉得这也是一个很好的前端初学者工作模式,用框架去保证兼容性和响应式布局的问题(虽然实际上还是自己写了一些响应式的东西去应付较为特殊的情况),然后不去动框架,手写自己的自定义样式,并在它们反复出现的时候去做集成的工作,对于JS这边我想也是如此,即使引入jquery,一些简单的逻辑,或者较为基础的一些(如AJAX)还是自己用JS原生的方式全部过一遍比较好,一方面有助于深入理解前端开发,另一方面在跟后端对接时也会比较有帮助。
开发时参考过的博客:
网页开发中的中文字体:JS中的面向对象: