一、日常问题

1）应对简陋需求

　　最近接到隔壁算法组的一个广告配置的需求，就给了两行描述，两张配置截图，给的信息太简陋。

　　给的信息太少，在开发过程中很容易出现目标偏差，例如将预期的圆形最后做成方形。

　　所以前期的准备一定要做好，首先就是理解需求背后的目标，然后再确认也没结构和交互细节。

　　从沟通中了解到需要在现在的广告列表页面增加个流量配置的功能，那就基于列表页做修改。

　　既然有了配置，那就应该有张管理界面，包括列表和上下架。

　　再根据提供的两张配置截图，确认配置需要的字段，并且修改原先的交互流程，改成更利于实现和维护的方式。

　　界面效果完成后，在技术联调时，又出了些问题。之前做的都是需求准备，漏了技术准备。

　　虽然我这边做的技术调整并不复杂，但是调整也是需求花时间的。

　　若遇到复杂情况，调整整个技术方案，那将是巨大的浪费，之前有个需求，就是因为调整了多次方案导致持续一年才上线。

　　所以说，遇到一个简陋需求，要主动去引导提需求的人完善细节，然后做足需求和技术的前期准备，避免不必要的返工和调整。

 2）眼见为实

　　当需求描述比较模糊或比较复杂时，一定要做出个实物让人能看到，而不是靠嘴说。

　　靠嘴说总会出现偏差，导致最后的返工。而实物不一定要可操作的程序，可以是一张图，一张表等等。

　　只要能将问题描述清楚，所有人能达成共识就行了。

　　只有在大家眼睛看到了后，才能感同身受，不然就是盲人摸象，各有各的理解。

3）团队意识

　　在找工作时，招聘条件中经常会有一条叫要有团队意识。

　　我觉得不给别的组增加工作量，就是团队意识的一种体现，即不给别人添麻烦。

　　团队意识这个问题不是发生在我们组，是隔壁组，当时有个需求改动。

　　然后周四下午明确了技术方案，新的需求采用新接口新的数据库表，老的功能全部沿用不变。

　　结果周五下午，测试开始工作时，发现老的功能都受了影响，大大增加了她的工作量，翻了几倍。

　　本来只要测试新的需求即可，但是现在要连同老功能一起测试，当天晚上，她还要加班验收。

　　这对于我们团队也是个警示，确认好方案后，不要随意变动，若会影响其他团队，要及时同步。

4）npm删除stylus

　　周三下午发生了件突发事故。

　　测试环境的一个项目在发布后突然不能启动了，排查发现是 stylus 被 npm 平台删除了。

　　找到 stylus 的 Github 主页，在 issues 的第一条置顶中找到了解决方案。

　　就是切换下载的源地址，从 npm 切换到 Github 中，package.json 参考：

{
  "dependencies": {
    "stylus": "github:stylus/stylus#0.54.4"
  }
}

　　yarn 打包的，也是在 package.json 修改，参考：

{
  "resolutions": {
    "stylus": "github:stylus/stylus#0.54.4"
  }
}

二、工作优化

1）埋点引起的4个问题

　　在本次的年终盛典活动中，有两张页面是直接在后台界面配置生成的。

　　当时就觉得不会有问题，但没想到在运营要埋点数据时，却出现了 4 个问题。

　　第一个问题是，他们不知道看板在哪里，问数据组的人，她居然也不知道，后面只能反查数据库表去搜索。

　　第二个问题是，有个产品知道看板在哪里，但是点进去是空白的，原来从去年 10 月份开始，看板就异常了，但居然没人上报反馈。

　　第三个问题是，有一张页面的埋点没有入库，排查后发现是因为有个值不符合入库规则，那马上就修复了传送规则。

　　由此就引出了第四个问题，由于是后台生成的页面，所以没有引起注意，埋点也就没有让 QA 验收，流程上的漏洞导致没有发现埋点问题。

　　在未来，无论是手写还是生成的，都要验收埋点。

　　其他项目也是的，很多细节还是要打磨推敲，避免遗漏。

2）需求更改流程优化

　　当业务或产品在开发的过程中，提出业务的修改时，一定要引起警惕。

　　很多时候，他只是说了简单的一句话，但是真做起来却要触发很多联动。

　　所以，最科学的方法是让相关人员补齐需求文档，然后任何改动都要同步给测试组。

　　若与服务端或其他端有关，也要一并同步，各组之间要达成共识。

　　在拿到改动的文档后，再各自评估改动的成本，然后计算风险，再决定改不改。

　　上来就干，就会有很多项目风险隐患，还可能会影响其它项目的进度。

　　上个月有个短剧的需求，运营在群里说增加个多语言的功能，没通知产品，服务端就开干了。

　　干到后面才发现搞定不了，需要客户端介入，增加了几天的工作量。

　　最后才通知到产品，产品认为这个功能可以先不做，运营也没有强求。

　　如果按流程来，那么这个需求都不用开始，也不必耗费人力在此处。

3）管理后台分离

　　公司有两个产品，当年两个产品的后台设计在了一个项目中，随着时间的推移，项目变得越来越庞大。

　　每次在代码发布时，构建都会消耗不少时间，于是就想到了优化。

　　那这个时候其实有很多方法可供选择，例如拆分成两个独立的后台，但如此一来，公共代码也要拆分成两份维护。

　　或者采用微前端技术，剥离一个项目出来，不过有一定的开发成本。

　　在观察后发现，构建会根据路由文件来，如果路由文件中没有声明，那么就不会将此文件纳入构建流程中。

　　于是声明了两份路由文件，大家维护各自的路由。

　　公司采用的是 umi3.0 框架，在执行和构建两个命令中增加一个自定义的环境变量来区分。

  "scripts": {
    "start": "umi dev",
    "start2": "THEME=fj umi dev",
    "build": "umi build",
    "build2": "THEME=fj umi build",
  },

　　在 .umirc.js 配置文件中，就能根据此变量来引入合适的路由。

import routes from './src/routes';
import routes2 from './src/routes-fj';
const { THEME } = process.env;
export default {
  define: {
    'process.env': {
      THEME
    }
  },
  routes: (THEME === 'fj' ? routes2 : routes),
}

　　在完成路由构建后，前后的代码发布总时间减少了 3 分钟以上。

　　经过一个月左右的时间，陆续将测试、预发和生产的三个发布流水线部署完成。

　　当然，在改造的过程中，也会遇到些问题，例如菜单的显示。

　　路由分离后，需要根据当前环境在展示相应的菜单，而不是像以前那样展示所有。