这一个多月，开发了一个微信公众号的微信H5商城。
地址：
技术栈
前端：jQuery + rem + flex
后台： java
前言
公司一共两个前端，我负责一个后台管理系统项目，一人独立前端开发。另外一个同事A前端开发这个公众号商城。由于公司开发策略有变，公众号商城放在首位，我被迫放在现有项目，加入商城开发。
我是一个接盘侠
所谓接盘侠，就是接别人的烂摊子，继续开发，所以我可以算是二次开发？
接手项目
加入项目，此时页面大概有10多个，已经写得差不多了，但只是静态页面，后台接口还没有。我心里美滋滋的，心想还不错，不用我来写页面，直接等后台接口渲染数据加载，优化下就完事了。
直到我真正看到代码的时候
我所认为的问题
- 文件目录混乱
- class id 等命名不规范样式
- 样式大多使用标签选择器
- 代码混乱
沟通与处理
毕竟我来公司也两个月了，但一直都是独立一人开发项目，和同事A也没有多大的接触，只有时聊天，说说前端流行的东西，也略知其水平一二。
由于这个项目已经开发了一段时间了，目录结构再改要花更多时间，迫于时间不能改了，只能顺着A的路径走了，后来到了现在项目上线了，随着文件的增多，目录结构越来越乱，找文件的时间也花得比较多，也挺懊悔当初没有改回来，导致现在找文件速度有点慢。
此时页面也差不多写完了，命名不规范，样式混乱我能怎么办，我也相当无奈，也不能一个个地找，一个个地改回来吧，现有的就只能随他去吧，我看了代码之后也细心明确告诉A，他写的代码的不足之处，后来到现在好一点了，也许还需要点沉淀与积累吧？
关于标签大量使用了标签选择器和 :nth-child() ，而没有正确使用class出现的问题。一开始我也没觉得是个问题，后台等到需求不断变的时候，功能不断变化，有时候在这个div里加上一个内容，之前使用标签选择器和:nth-child()来控制样式会变得非常致命。这就为什么大牛都推荐使用class来控制样式的原因吧。
共同开发
虽然A水平没有自己好，但是还要一起开发的，我只能自己接手比较难的模块，简单点的模块就交给A。
由于静态页面与渲染数据、事件绑定有紧密联系，所以最好一个模块当中，html、css、js都要自己来写会比较好，自己对页面内容，事件的把控都会比较熟悉。
开发中出现的问题
移动端适配
所谓移动端适配，就是要根据移动设备的屏幕大小来显示适当比例的内容与图像。因为A没有做过移动端，没有考虑到适配问题，这让我相当无奈，因为当时我接手的时候页面已经差不多写完了。没办法，只能一个一个地改，所以说，刚开始真的很重要很重要，直接影响了之后的开发与迭代了。
使用rem.js
我是通过使用rem单位和一个rem.js来解决移动端适配问题。
(function(doc, win) {
var docEl = doc.documentElement,
resizeEvt = 'orientationchange' in window ? 'orientationchange' : 'resize',
recalc = function() {
var clientWidth = docEl.clientWidth;
if (!clientWidth) return;
docEl.style.fontSize = 20 * (clientWidth / 320) + 'px';
};
if (!doc.addEventListener) return;
win.addEventListener(resizeEvt, recalc, false);
doc.addEventListener('DOMContentLoaded', recalc, false);
})(document, window);
通过获得屏幕的宽度大小，来改变html的font-size
用户错误操作提示
很多时候用户都会有一些误操作，比如填写表单的时候手机号码不正确或者漏填信息、后台接口错误提示等等，都应该给予适当的误操作提示，一开始我是使用alert()直接完事，但用户体验相当不好，尤其是移动端，相当难看而又让用户再点一次，感到恶心，后来模仿其他平台做法自己写了一个通用方法弹出层进行错误提示。
//HTML
<div class="tips" style="display: none">
<div></div>
</div>
// CSS
.tips {
position: fixed;
top: 42%;
width: 100%;
left: 50%;
text-align: center;
z-index: 999;
-webkit-transform: translateX(-50%);
transform: translateX(-50%);
}
.tips>div {
display: inline-block;
margin: 0;
padding: 0.2rem 0.3rem;
text-align: center;
color: #fff;
font-size: 0.6rem;
text-shadow: 1px 1px 1px #000;
border-radius: 50px;
/*line-height: 1.5rem;*/
background: rgba(0,0,0,.8);
}
// JS
function showTips(text) {
$('.tips>div').text(text).parent().fadeIn().fadeOut(2000);
}
需求不明确
这个问题相当重要，直接影响你的开发进度和心情。由于需求不明确，往往在开发当中，等你写完了这个页面或者开发完这个功能之后，很有可能需求发生更改，UI很可能会变，所以当你写完一个页面之后，产品和UI告诉你，"之前的那个页面老板说不好看，需要重做，这个是最新的页面" 我想你会相当崩溃的，直到我三番四次地改，我才发现了这个问题的严重性。可笑可笑
意见
- 先做你觉得不会改变的页面和功能
- 一个页面中，很可能只有一块是不确定的或者改来改去的，这块可以先放下，不要做
兼容性处理与多测试
往往在浏览器中调试是不会出现问题的，等到真的放上服务器，用真机测试时，会出现各种各样的问题。
首先，在开发过程中，有条件和时间的话，可以开启一个本地服务器，多在真机中测试。而一些微信支付、微信分享等功能需要放到服务器上测试的，就要多测试，基于微信公众号开发，调用微信JDK，这也没什么办法的。
安卓端、IOS端
IOS微信浏览器是自带一个返回键的，而安卓端有些是用home键来控制返回，有些是没有返回的，例如在下单页面中，需要填写用户收获信息，我会在同一个页面来进行，利用一个弹出层来控制，页面来会有一个关闭按钮，确保安卓端与ios都可以点击关闭，而不是按"返回"，返回到上一个页面，这个流程就是不对的，所以在开发中，要与产品沟通好，了解整个流程，确保安卓端以及IOS端的流程一致，避免一些不必要的开发。由于使用了比较笨重的jquery，其他兼容性问题出现得比较少，如有出现，直接Google，搜一下，相信就有解决方法了。
总结
这个项目中，整个团队都是从零出发，需求不明确，在开发中遇到的问题还是比较多，与同事交流讨论也比较多，大家一步一步讨论、一步一步优化以及提出自己的建议，每个人都尽力做好自己的事情，在开发过程中还是挺开心的，等到真的测试上线了，看到自己做的东西，心情又会很开心。我知道自己代码还是写得不够好，还是不太会利用面向对象方式来编程，相信下次会越来越好。
致自己，加油。
