总结：改官网首页遇到的问题（一个端整页滚动，一个端正常滚怎么搞）

上周接到了一个任务，改官网，说起来很简单，但过程还是有些波折。做个小结提醒自己。

1. 和给需求的人，以及给设计的人沟通好提供给我的材料是什么，我做好的成品是什么，以及deadline。如果有变动，双方都要知晓。如果是对方的原因有大的变动增加额外工作，作必要的解释，尽量避免赶活儿。

   一开始，这个事情就是图文迭代，无脑的活儿。后来，发现运营想简单了，图文不配套，于是沟通。然后改了一版图文，这版把格式调好了，结果又不满意要整个改掉，于是设计重新做了图。到这里以为仍然是原来的< img>插图格式，但拿到图的时候，发现是电脑版的页面都整个用图片代替了，于是把PC的从html起到CSS统统改了，等手机图。接着发现手机的图也跟说好的不一样。。。干脆晚上带回家重新写了一遍。

   中间经历了几次“诶，这跟说好的不一样”的过程，但接了设计稿后没有及时跟运营表明任务变了，需要更多的时间，而是靠加班来希望追平时间。这不是合适的做法。有变动一定要及时沟通，让双方都有底。也要和设计提前确认他提供的原始材料是什么，以避免无谓的工作。

   不到不得已 不去赶活儿。赶也心不要急（这个暂时做不到，表达下美好的希望）。

2. 手机端的要在手机上试，用192.的网址来查看，ios/安卓都要看，ios要换几个不同代的手机测试。。。不但要在自带的浏览器上试，也要在微信浏览器试。最好在qq的内置浏览器上也试。

   一开始不知道手机的怎么去试（以后就知道了，这个应该提前想到问带我的人），就用的浏览器模仿手机端。结果造成了很大的失误。至于兼容性问题，虽然条件所限搞不全，但样本容量仍然越大越好。

3. 不要信任第三方插件，对readme中标榜的功能听听就好，一定要试！！！如果还要引用库，选择demo中的版本。先用非压缩版的，如果报错去源代码中找原因。好改的可以直接改（多半不太好改），不好改的釜底抽薪，直接改dom结构，重新init 该插件。

   开始因为fullpage.js在原网页上一resize就不停报错，滚动也出现问题，所以打算换个插件。选择了onepage-scroll.js，在电脑上表现很好，放到手机上就开始放飞了。。。。飞了。。。了。只好回过头来又用fullpage。引用的jquery一开始是3.x的slim.min.js， 发现有BUG怎么搞都不知道问题出在哪里，也不报错，换成了DEMO中的1.x低版本就好了。。。所以说插件是配合库出来的，老老实实用demo里的版本最好。

   看看源码可不可以改一下。发现还有点麻烦。因为手机端是一滚滚一页，scrollTop始终在顶端，但PC是自由滚动的，所以PC端变到手机版，可以根据高度算出归属在哪一页，定位到该页的顶端。同时也很怕乱动改错了，于是干脆釜底抽薪，加入如下代码：

     // destroy to avoid conflict 
     if($('html').hasClass('fp-enabled')){
            $.fn.fullpage.destroy('all');
      }

      //initializing 
       $('#fullpage').fullpage();

       // call function
        $('.app').fullpage({
        scrollingSpeed:1000,
        scrollOverflow:true,
      });

    }

有点类似jquery.noConflict()，虽然可能浪费了一点性能，但非常稳妥，避免了报错和潜在的Bug。

同时，对不同终端有不用结构的页面，保险起见，让手机和PC都呈现不同的dom结构，手机端时body下只挂它对应的内容，PC同理。以避免插件误伤。（它直接改了body的css）

4.正确的流程：电脑端编程–>手机端和pc 测试（不要分开检测）–>改动–>手机端和PC测试 –>确认无误 –>压缩文件 –> 手机端和PC测试 –>（ 叫给我需求的人确认 ）–> 上传，改PHP格式，确认所有的静态（图片，音频，js , css） 接口地址无误 –> 更新到一个预发布版本（这里之后就可以交给超哥了） –>上线 –> 找周围能找到的OS和浏览器统统测试一遍

既不要信任自己，也不要信任别人，检查是永远必要的。

5.如果是迭代式的任务，检查每一个链接和二维码是否是最新的和正确的，也许给需求的人只交代了ABC，但过手即担责，想不到DEF出了问题锅是要自己背的