会点儿linux命令
这个项目是在linux下才能运行的。很多后端服务基于linux环境。诸如文件操作(gedit或vim)，拷贝操作，这些基本的命令都应该掌握。毕竟以后如果是和linux环境下的后端打交道，基本的操作就不用麻烦人家了。
对任何项目都应该认真
因为我从半路接手，也并不了解项目，都是听负责人再说。包括技术总监也说是个小项目，简单做就好了。一开始我认为这是个小项目，也没特别认真对待，没有主动去想产品，等主体内容做完之后，就忙着做其他项目，抽空写写这个项目。
真没想到自己一做就是三周。我以为顶多两周就完成了。当然这其中也有很多问题。比如项目负责人并没有在一开始的时候就把全局的情况和细节都讲清楚，没有一开始的一个规划，只是知道主体的内容，然后就是做一点想一点了。
写页面的经验
-
随时准备应对需求变更。要注意凡是有
<ul><li>标签相互组合的地方，就要考虑增加新li标签的情况。所以固定高度以及位置写死这种做法就不可取。尤其像这种需求并不明确，设计稿仅是参考稿的情况下，一会让你增加一个li标签，本来可以只修改html结构就好了，非得去修改css，降低了多少效率！所以，一定要事先考虑清楚：能否利用达到高度自动撑开，利用top:100%这个属性来自动定位以达到目的。 - 对于设计图的精准还原，我还是没有做的很好。比如色彩，距离，比例，字体大小。以及选用图片还是选用css去写，如何拆分图片的问题上我都还欠缺经验。这次项目经理对于页面效果和设计图比照的非常细致。连浅粉色和白色的差别都要改。所以一开始就请认真对待设计图，一点细节都不能马虎！
-
前端工程师的基本素养。连密码输入框要用
<input type="password"/>都不知道！
css能力有待加强
很多时候感觉自己写css还是慢了，而且对布局的理解，对于需求变更的处理，都做得不是很好。
- 居中问题。水平居中，垂直居中。
- 布局问题。左右布局，左中右布局。
重视产品需求
不明白产品需求，只做技术实现就会陷进去，或者做的不是产品经理想要的。一定要沟通。如果遇到产品需求阐述并不明确的经理。应该主动去提问，对未知的去了解。主动了解需求很重要。
给用户的提示信息，语言上要进行斟酌
比如提示信息，"还没有部署产品"就没有"尚未部署产品"更严肃。在目前没有产品经理，部分图纸没有ui设计的情况，语言要有意识去积累。平时在使用app的时候，在看别人写的提示信息的时候要有意识积累。
越是精小的UI组件越是考察你的细心
项目当中需要做一个ip输入框组件。我主要是参照windows下的ip输入框进行制作的。
核心实现四个input,组成一个大的输入框，然后监听input的keypress事件，onblur事件来处理一些问题。
其实代码逻辑较为复杂,各种细节因素没有照顾周全。比如什么时候按·跳行，跳行之后是否选中下一行，focus子网掩码的时候如果IP有值自动生出子网掩码，退格应该能清空上一格，每个输入框最多输入3个数字，最大不超过255。
好我就随便写几个写IP组件过程中遇到的问题：
- keypress和keydown有什么区别：keypress中e.preventDefault()可以真正屏蔽按键输入。但是keydown不行。
- 如何focus下一个input的时候选中其中的值
- 如何判断当前input中时候有选中的值。火狐浏览器下用window.getSelection()获取input中的选中值无效。
有机会再把ip组件写一遍，你的代码逻辑会更加清楚。我发现这个是锻炼前端逻辑的非常好的一个练习：仿照windows系统ip输入框做输入组件。
把各种情况都要考虑到！
代码分离问题
我不知道其他公司前后端是怎么交接的，我这里是一部分的和后端交互的js代码，后端同学也有权维护，所以和后端的代码要抽离到单独的js中，这样方便后端同学查看。
并且还有就是不要过度封装。我觉得我function(xxx,callback){}这样的接口都不是很好，因为你根本不知道callback是什么，很多后端同学去看代码都傻了，找callback太费劲了，干脆就把callback显式地写在方法体里面就好了。
数据刷新设计到的页面变化
当涉及到一个列表数据（ul,li的这种结构）刷新的时候，由于数据更新之后涉及到样式变更，后端希望我重新渲染整个ul标签就完了。但我觉得那样浪费性能，点击的时候那个变动了刷新那个，这样更有针对性。弊端就是控制上要用css控制的更加精准。没有刷新整个那么无脑。我认为我做的是对的。
涉及后端长时间io操作的时候，需要等待的时候，要给出loading信息，并且屏蔽部分操作按钮
低级问题不要犯
刚开始我并不会很主动去沟通，项目经理又一次随口提了一句，有不懂的就要问，不要搁置不解决。其实我一直在解决，会有一些冤枉的情绪在里面。受批评，有冤枉，被人不理解，很正常。不要觉得不好意思。一定要对自己有信心。
我现在才去的策略是除非这个工作影响到我根本进行不下去了，比如后端没有开启某个服务，本地没有数据。没法实际走一遍。就会请相应的人帮忙。正常情况下，只要我还能继续往下走，我就不会轻易寻求别人帮忙。因为我一直认为沟通是有沟通成本的问题的。反正我手头还有很多部分可以继续深入做，现在去找他，时间都浪费在沟通上了。所以在这种情况下我时常处于等待的情况。我先忙我的，有事你找我。但其实这种做法会有小问题，就是有些困难会减缓你前进速度，不如直接去找后端帮忙。
但是之后有一次，我犯了一个低级错误，后端显得非常不耐烦，“你关了重新开！”原来，这个项目集成到一定程度的时候，不能随意点击重启键，否则电脑的信息会被刚才安装部署的部分重置。而且这个问题发生了两三次，每次都要麻烦后端人员，重新安装，自己也不懂linux.
所以你要分清，有些关键点不懂了，马上问。但是低级的错误你犯了，你麻烦别人，无形增加对方工作量，就是你的不对了！所以对方生气了，也是可以理解的。
