实习月总结

前言

时间似流水般潺潺而过,不经意便从指尖溜走,于笔尖划过。悄然无声,却迹痕般般。投江至今足月有余,恍然恰似昨日,梦醒犹如初见。席地而坐,所思?所获?何为?…

印象

投江近一个月,切身体会这里的人、事、景、物。30多个小伙伴组成了和睦有爱的前端大家庭,他们身怀过硬的技术专长,对工作用心务实,待新人耐心和善,领导没有高架子,与”平民”同乐,他们日出而”作”,日落而归,没有夜夜加班的bat文化,没有尔虞我诈的勾心斗角,在这里自己开心快乐,充实而饱满。

目标

  1. 熟悉和实践移动端相关技术
    移动端在web开发中所占的地位不断加重,前端开发不了解其相关技术势必被浪潮拍在
    沙滩上。
  2. 在工作中锻炼技术,提高解决问题和独立学习的能力

所获

主动思考

实习收获最大的一件事情就是学会主动思考,主动去思考需求本身是否合理,去思考如何做才能使体验更佳…

mmp项目中有一个模块用来专门做渠道管理,使应用可以关联相应的渠道,但是产品给出的原型中应用却有一套自己独立的添加渠道操作,该渠道并不是从前面维护的渠道中选出,于是和产品沟通,如果这样渠道管理就失去了维护的意义,后来产品更改需求,交互原型也变成如下图

图片描述

图片描述

前端无需了解需求本身?

在之前的一段实习过程中,经常有合作的后端同学说前端无需了解需求本身,但是我觉得这样的看法是不对的。

抛开码农的世界,无论身处何处,在做什么,首先知道自己做的是什么是非常重要的事情,如果只是按部就班的把被安排的事情做好,这与行尸走肉无异,于己而言也就没有什么意义了。

回归码农的世界,前端除了了解产品界面原型和ui效果图,还应当了解产品的功能需求和业务规则。很多时候,在没有设计或者交互参与的项目中,产品对界面的把控并没有前端仔细,而且在一些交互细节上也无法做到体验最佳。如果前端不去了解业务需求,而只是按照原型将页面实现,那做出来的东西一定不是”更好的”。

关于编码习惯

好的编码习惯可以提高我们的代码质量,增强团规开发协作效,减少bug出现的几率…
甚至可以提高自己对曾经写过的代码的理解力(时间一长,如果编码习惯不好,哪怕是自己写的程序,恐怕也不能快速理解)

与其说师兄有代码洁癖,强迫症,还不如说他养成了良好的编程习惯,有时候他在看自己写的代码的时候,经常会指出一些编程习惯的问题比如

  1. 保持分号统一,不要一处有,一处没有
  2. 写if while等的时候空一格,这有利于和函数调用区分开
  3. 使用两个空格来缩进,这是保证在各大平台上代码缩进都统一办法
  4. 将调试以及当前使用但未来需要删除的代码做上标记xxx方便以后将其删除
    (经常我们的习惯是用console.log等来进行调试,但是调试完成之后使用//注释掉,很有可能在代码上线之前没有将其删除)
  5. 做好注释,比如在路由那一块,哪一个模板对应什么业务应该有清晰明显的注释,方便自己和后面维护的童鞋一目了然的知晓其作用。
  6. 好习惯的养成不是一朝一夕的事情,而是长时间的积累和坚持,现在自己写程序依然会有各种问题存在,这也说明习惯养成之路漫长且待坚持。

扩展和可配置

代码的扩展性是码农都追求的一个目标,我所理解的代码的扩展性一方面是为了应对或者解决需求的时常变更而给开发者带来比较大的开发代价而做的程序设计。

比如有这么一个常见的导航模块,包含三大板块,每个板块下面会有自己的小模块

图片描述

刚开始做的时候是根据原型完全用写死的方式在html写好,但是后来和产品了解需求的时候发现这个项目并没有最后完全敲锤定音,也就是还存在许多可变因素,导航模块完全有可能增加和删除,为了解决这样的问题,我将原先先死的html结构抽象出来,将大模块标题,小模块,图标用数据配置的方式来生成

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$scope.groups = [
{
title : '应用管理',//标题
icon : 'glyphicon glyphicon-th-list',//图标
isOpen : true,//是否展开
lists : [//子模块
{
title : '应用列表',
ui_sref : 'application_list',
icons : 'glyphicon glyphicon-paperclip'
},
{
title : '渠道管理',
ui_sref : 'channel_management',
icons : 'glyphicon glyphicon-paperclip'
}
]
}
];

再配合这一段模板就可以解决后续模块增加或者删除的问题(只需要在数据模型中增加或者删除对应的字段就可以)

1
2
3
4
5
6
7
8
9
10
11
12
13
<uib-accordion>
<uib-accordion-group is-open="group.isOpen" ng-repeat="group in groups">
<uib-accordion-heading>
{{ group.title }} <i class="{{ group.icon }}"></i><span ng-class="{'triangle': group.isOpen,'triangle_no':!group.isOpen}"></span>
</uib-accordion-heading>
<ul>
<li ng-repeat="item in group.lists" ng-click="tab.setCurrent('application_list')">
<a ui-sref=".{{ item.ui_sref }}">{{ item.title }}</a>
<i class="{{ item.icons }}"></i>
</li>
</ul>
</uib-accordion-group>
</uib-accordion>

技术相关

  1. angular初级开发,可以利用angular提供的特性完成初步的web开发
  2. 移动端入门、了解移动端相关知识熟悉flex布局
  3. gulp知识入门,可以编写常见的gulp代码来处理我们的任务

计划未完成

qDrap组件开发

产生要写这个组件的初始原因是刚来到这里的时候写了一个拖拽排序小组件拖拽排序师兄看了之后提了许多建议

  1. 在进行碰撞检测的时候无需将所有的元素都检测一遍,只需要将即将可能发生碰撞的元素进行检测即可( 当然前提是需要判断哪些元素可能会与当前元素发生碰撞)
  2. 有些行为应该做成可配置,比如拖拽时的动画
  3. 组件开发应该尽量满足和契合其他规范,比如amd、cmd

后来在mmp需求来了之后,把工作重心都放在mmp上,没有完成这一计划….
做事当有始有终,不可以半途而废

mmp项目前端工作未达到预期

mmp项目期望是年前上线,排除一些前端不可控因素( 比如后端数据接口在29号才部分走通,所提供的数据联调机器在28号才给到… )从自己身上找原因

  1. 该项目时间绝对够,快20天的时间前端只完成2/3界面编写与逻辑交互,而且现在还没有经过测试。原因何在?虽说自己设计界面从未有过涉及是一个挑战,但是变化是唯一不变的变化,不可能任何时候都让自己做自己熟悉的事情,所以面对这种情况自己花费了比较多的时间去适应,适应能力差。
  2. 没有把控好时间节点,页面编写花费时间太多近2周,这是不是从侧面说明一个问题,前端基础知识css布局有待加强。

存在的问题

  1. 不能很好地分配时间,安排工作节点实际工作中对需求的评估并给出相应的完成时间节点是非常重要的一件事情,一方面节点的给出有利于其他童鞋知晓你的工作进度,以方便协调合作,一方面也让自己的时间得到有效的利用,但是在实习过程中自己明显表现出计划不合理,工作效率低的问题,说到底还是不懂的合理有效地安排时间

  2. 沟通表达问题团队协作离不开密切地沟通,不同角色之间如何沟通是一个学问。如何用通俗有效的语言与非技术或不懂自己从事的技术与他人沟通,让他人明白我在说什么?这方面自己非常欠缺

  3. 知识面宅前端开发的基础知识上还不够具体和全面, “面”很狭窄。需要多加学习和拓展。

  4. “主动性”做的还不够主动思考,主动与伙伴交流,主动承担更多的责任,觉得项目中或生活中不合理的地方,要学会主动去推动他,不能依靠或等待别人来做( 比如在用后端给的数据接口的时候好些接口对前端是不够友好的,甚至于业务而言真的是错误的,刚开始并没有主动去找后端童鞋说清楚缘由,而是觉得后端童鞋自己应该会发觉问题所在 )

  5. 前端不懂设计
    mmp项目实施过程中没有设计和交互的参与,界面需要自己来进行设计,如何搭配颜色,如何布局展示,怎样交互才更加合理,是一次挑战,实践过程中也发现自己缺乏这方面的知识和能力,之前做的东西大多数也是别人设计好的东西。

结尾

感谢这一段实习经历,遇见一个好的团队,里面每个人都是你的师傅,他们热情耐心,毫无距离感。在这里,自己开心快乐,每天都可以学到新的东西,幸福ing。针对这些不足和问题需要一步步改正加强。兄弟们!!!待来年,从头聚。