2021 已经过去两个月多了.年后非常忙.对年终总结也是有心无力. 节后时间富裕.回想去年也是感慨颇多. 生活上去年是糟心的一年. 技术上依然还是收获慢慢. 下面是我个人的 技术工作总结
收获不仅在框架使用、cocos的学习、内存泄露的排查、webview/js cocos/js的通信、npm包的开发等等并且累积了交付质量的把握、需求评审排期、工作角色正确沟通等等实际的经验
| 2021清单 | 详情 |
|---|---|
| cocos | 在已经既定的框架下在HB的需求的Push下学习了cocos. 它是什么?底层的实现等等这些有一定认识. 做动画确实会比较烧脑一些... 顺便吐槽下cocos的技术文档大而乱...对小白超级不友好 |
| 移动端开发 | 刚工作那会甚至都不知道webview是啥...当时调用端的一些方法都是一脸茫然. 经历了半年多风吹日晒之后 移动端的开发变得熟练 |
| npm包的开发 | 没接触之前觉得npm开发老复杂老牛了. 第一次开发的时候大佬就告诉了我一个命令npm publish... 嗯就这样. 当然这离不开公司基建的完善. 深入之后确实也是大有天地. 关于npm 可以延伸到Node相关的很多生态知识. 这些也在我写的一篇文章《我们身边的node_modules》中体现. |
| 交付质量 | 交付质量说白了就是提交测试之后的Bug数量.它的影响因素会包括时间(排期)/技术实现难易/需求本身复杂与否/等等 而作为技术要做的是 写码前要清楚 写码中要细心 写码后要检查. 写码前清楚意味着需要深度参与技术评审、详细推敲需求的细节.试试以使用者的视角感受需求的可行性和漏洞. 这可以避免后期出现新加\更改功能.写码中要细节 那么就需要技术开发在编写逻辑或者视图中考虑各种可能和不可能. 保证严谨. 写码后要检查. 温故而知新(今天写的代码明天自己再看说不定就能看出新的漏洞) |
| 需求评审排期 | 评审排期对应了上面的写码前要清楚. 熟悉需求本身之后技术都会有自己的一个预估排期. 不出意外的话这就是需求的工作时间. 但是!意外就是常常发生. 这个需求很紧急\大老板亲自在盯 产品的声音回荡在耳边... 那么这就需要技术打开全局视野. UI/前端/后端/测试都需要有排期. 可以了解其他角色的预估排期.在基于产品的预估交付给出各方都稳妥的排期当然这其中少不了拉扯. |
| 工作沟通 | 沟通向来都是一门高深的学问. 无论是日常还是在工作. |
| 线上问题 | 这个模块拉到成长里说实话有点牵强. 遇到过很多同事在定位问题的时候都会茫然、慌不择路导致问题迟迟得不到解决. 因此想分享一些心得 1. 线上问题不能慌.心态最重要 2. 问题一般都不会是空穴来风. 先检查问题模块最新的变动 3. 对于难定位的问题可以先尝试使用线上数据线下复现 4. 埋点 这依赖在开发中埋点的完整性. 基于充分的埋点对用户进行行为分析能帮助我们掌握问题 |
| 文章产出 | 今年产出的文章更多偏向是实际开发写码 |
2022展望
技术
- 框架原理
- 工程化探索
- 做出一款实用的开源作品
- 产出具备探索性的文章 6篇+
- 包括但不限于以上