一、日常问题
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 分钟以上。
经过一个月左右的时间，陆续将测试、预发和生产的三个发布流水线部署完成。
当然，在改造的过程中，也会遇到些问题，例如菜单的显示。
路由分离后，需要根据当前环境在展示相应的菜单，而不是像以前那样展示所有。