我经常做的技术思考话题

背景

低头走路，抬头看天，经常思考总结已经成为习惯，分享下我做技术思考的话题

自驱

• webpack 转化成 vue 周末搞，自动工具转化 wp2vuecli
• 脚手架，团队用上自己的脚手架
• cicd 配置 多次部署尝试输出文档，只为自动化部署
• Sentry 搞到深夜配置环境
• gulp gulp 自动化构建，乐此不疲升级
• mock mock 改造 ts 改造
• 问卷调查
• 按钮权限
• react 改造
• 直播间工具 Helper
• CommonData 分析, 改造
• 关键日志分析流程
• CommonUI 常驻暂驻
• CommonData 可靠性分析
• Lottie 懒加载

自己设计的技术方案

• 大斑马的小屋： 分享录入、链接展示、分类筛选、分页、筛选
• 热力图自动生成：excel 的坐标，写入到 html 声称热力图、上传 excel, 自动生成各种类型的热力图，生成过一次的进行保存
• bms 需求展示
• gulp 打包：gulp 将支持 ES6，压缩 js less html、本地服务器启动、文件修改后，自动保存生成 dist 落入文件夹、html 引用dist 文件运行、本地启动服务器打开 html 入口
• 换肤：image、background、lottie、sprite
• 融合：类型判断地方整理、不同直播间需要配置项、组合而成
• 批量奖状下载：canvas 绘制耗时，样式灵活多变、Html2canvas 左右两边拉长、图片过长给提示批量奖状批量渲染批量下载，生产到本地
• 问卷后台
• 题型汇总、组件工厂、入参定义、引用所需组件工厂，声成对应 json 文件；通过 json 配置文件，渲染具体值权限 & 按钮级权限
• 角色 & 权限
• 单元测试 & 覆盖率
• 通过用例更快查看，公共方法是否支撑新业务使用
• jest mock
• 工具&公共组件
• 公共组件抽离，组内维护
• 组件抽离，每个模块复用
• 直播间 Helper 工具

创新

• 架构：Electron 之 bv 多容器架构
• 技术方案更改：置顶置底变小变大
• 性能优化：commonData proxy 代理
• 打包构建：虚拟模块引入加载
• 视频：清晰度模糊

数据意识

• 优化的东西，有无数据指标
• 关注 cpu 内存增值
• 重要功能有埋点

调用而非记忆

• JS 常用工具: 自己(注意自己)顺手的工具进行整理和存储、以便需要时，快速调用。然后日积跬步

思维

• 注释：代码注释关注解释 Why do this，而非解释 How to do this
• 轮子：只满足业务，仅仅满足业务需求，而没有任何技术沉淀，轮子更是一个都拿不出手，职业路走的越来越凶险；负责业务线，对业务目标一问三不知，天天想着搞轮子；轮子跟大公司小公司也无必然关系，背后是认知高度和研发资源的考量，造轮子本身没错，怕的是为了轮子而轮子，不会抬头看天
• 兜底：如果你来兜底问题解决了，没有这个问题，后面就无法推动别人去做，从而后面出现的所有问题都有你来负责
• 偏见：干过外包不是问题，但一直拿外包的能力来要求自己是个问题, 参加培训班不是问题，但忽略基础想走捷径不持续提升自己会是个问题
• 千万别上瘾只想去解决那些困难的问题。如果那些问题本身就是错的，你会浪费时间；如果你解决不了，也会浪费时间。
• 休息：有一个诀窍，让我成为一个更好的程序员，那就是我常常休息，大量的休息，我的新想法都是在休息时产生的。休息的时候，我阅读，大量阅读任何我有兴趣的内容，这样我才可能产生新想法
• 影响力就是利他输出
• 井蛙不可以语于海者，拘于虚也；夏虫不可以语于冰者，笃于时也；曲士不可以语于道者，束于教也，白兔繁殖，劣币驱逐良币

反思

在保证业务节奏稳步迭代状况下，你有什么收获？在技术上有什么成长？在软素质上有什么成长 除了正常需求的迭代，有没有做一些保障稳定性或者优化的技术动作，是否在每个 Q 都有结果产出？ 另外你的技术优化和保障性的技术动作是否有完善的方案，主要解决的问题是什么？预期的投入产出有多高？根据你在课中的经验看，你觉得可以通过什么样的技术手段来提升课中的稳定性和研发效率？ 或者课中业务项目现在的痛点你觉得是什么？能否提一些可靠的建议 如果是跨部门的话，出发点一定是先考虑各个部门的收益如何，否则基本上难推动 横向：先去了解开发逻辑和运行逻辑，在一些技术方案商反推端去实施落地。甚至你自己可以现行论证