个人作业week7——前端开发感想总结

个人作业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原生的方式全部过一遍比较好，一方面有助于深入理解前端开发，另一方面在跟后端对接时也会比较有帮助。

开发时参考过的博客：
网页开发中的中文字体：http://www.ruanyifeng.com/blog/2014/07/chinese_fonts.html
JS中的面向对象：http://www.ruanyifeng.com/blog/2010/05/object-oriented_javascript_encapsulation.html