工作经验

混合开发移动APP：

1. 对于混合开发(webview+H5)，第一次发布前一定要有checkAPI来测试是否存在webview和js相互调用的桥
2. 必须借助webview向后端传数据时尽量让webview透传，方便维护

JS开发：

• 函数传参

// 禁止传多个参数
function fun1(param1，param2，param3，param4){}
// 鼓励传对象
function fun1(param = {}){
    const {param1，param2，param3，param4} = param；
}

• 对于既能使用数字又能使用字符串的场合一定使用字符串，比如移动APP中年龄范围的选择，如果使用了number进行枚举，则需求变动加入“不限”时就尴尬了
• 使用开元框架时，能封装的函数尽量封装下，但一定注意命名且不能封装逻辑太复杂，保证既能很容易看懂又能使团队集中尽力在业务上而不是学习开源框架
• 代码是给人读的，一定要考虑好后期维护，一行垃圾代码根据破窗理论以后肯定会变得很恶心
• 代码表达的意思一定要和业务是全等的，禁止优化逻辑导致业务和代码逻辑不全等

  // 加入这种是标准的业务逻辑
  function fun(str){
      switch (str) {
          case 'page1':
              console.log('page1'); break;
          case 'page2':
              console.log('page1'); break;
          case 'page3':
              console.log('pageX'); break;
          case 'page4':
              console.log('pageX'); break;
          default:
                  break;
      }
  }
  
  // 禁止优化成这种逻辑，因为其没有真实描述业务，后期维护就傻逼了
  function fun1(str){
      switch (str) {
          case 'page1':
              console.log('page1'); break;
          case 'page2':
              console.log('page1'); break;
          default:
              console.log('pageX'); break;
      }
  }
  

   

开发规范：

1. 对于团队没有使用过的API能不用的尽量不要用，加大了大家的学习成本且容易出bug
2. 代码逻辑必须和业务逻辑全等，这样二次开发才能减少bug
3. 大家必须遵守开发规范，有了第一行烂代码就有第二行烂代码
4. 逻辑能描述清楚的逻辑就不要用注释去搞定，注释既不能保证别人能完全理解，也容易在二次开发时别人改了逻辑但忘了改注释，最终导致注释和代码真实逻辑的差距越来越大
5. 新功能上线一定要考虑其有下线的一天，所以代码的影响范围一定一定要尽量小
6. 尽量避免使用全局变量
7. 前端跳页或路由携带参数时一定附加个标志位，对于这个标志位通过switch语句减小携带的参数的影响范围，业务也更加明晰

开源框架：

1. 使用开源框架时对于某个问题一定要选择对应的API，不能生搬硬凑
2. 定期升级开源库（建议频率：每4-6个月一次），原因：

               1）保证性能最优；2）时间久了可能该版本文档都找不到了，代码变的不可维护，版本号差的太多也不易升级；3）github会发邮件提示某个开源框架的某些依赖可能存在安全问题，但收到邮件时该框架可能还没解决这个问题，定期更新可以在该框架解决了这个问题之后也及时解决（鲁莽强行更新开源依赖可能出bug）

1. 对开源库的方法进行合理封装，避免因为框架升级了API导致业务代码大范围改动，但一定不能封装的很复杂，增大团队学习成本
2. 同事之间养成相互走查代码的习惯，而不是每次都是leader来看，避免到最后只有leader水平最好且对业务最熟悉，同时实时地保证团队开发风格一致，及时共享经验