2019上半年总结
Opened this issue · 6 comments
上半年接了陆续5个大需求，涉及到的工程有:
- 司机app
- station
- manage
- mes
接触了销售经理重构、标签的设置和打印，pda和手机的扫码，gm-printer的重构和司机承运商重构等。
销售经理重构
这个需求本身比较简单，是销售经理的相关数据的可视化和提供多种筛选条件。但问题就出在这些数据的聚合和计算处理后端没法做，原因似乎是服务器压力大(数据量比较多)，所以把这些交给前端做了。所以也引发了一些难点：
- 前端处理，如果数据量大页面是直接卡死的，而后端处理页面只是没有数据而已
- 处理数据的逻辑比较复杂且多，该怎么管理这些代码，如何写的优雅
第一点，只能通过限制用户操作来尽量不让他卡死，比如只能选一个月，当然某些用户数据量大的，1天的数据量就足以让页面卡死，首先是没办法在算法层面优化，因为算法太简易了。后来发现无法解决，只能等以后改为后端处理😹
第二点，做之前是觉得简单的，但看了需求文档后并询问产品后，发现这些大量的逻辑处理竟然无法复用的，因为都不一样。选择"按每日" "按商品"和"按商户" "按每日"的数据是完全不一样的，聚合的方式、展现的字段不一样，并且功能很不"清晰"，需要一定时间理解，最终的出来的代码非常"硬"。这些逻辑放在后端也是同样的，因为产品的功能的复杂性，可预见后端的代码应该并不"整洁"😸。
扫码
这个需求印象中花的时间最长，涉及到的地方比较多，对这些工程也比较陌生，慢慢熟悉后发现还是很容易理解的。有意思的地方比如司机app的一个滑动手势。引用了一个手势库，给组件套上之后发现会有一些奇怪的现象，后来发现忘记给组件卸载事件。在扫码方面，同个订单下商品标签，有些能扫有些不能，经过排查是宽度问题，宽度过窄扫码设别率会降低不少。
对gm-printer做了一些改进
主要改进有：
- shadowDOM
- 启用了iframe
- 业务代码和库分离
打印方面印象中比较大的坑有两个。
-
重构后的gm-printer客户反馈字体模糊了，是点状打印。我就在想是不是iframe的问题，在控制台上仔细对比前后的css，并没有什么不同。然后各种谷歌也没有下文，当时也挺着急的，最后索性比对整个css文件，一个个排查，发现凶手竟然是字体颜色，如果打印时字体颜色如果不是#000，古老的针式打印机就会使用“点状”来模拟“灰色”，很是神奇。*
-
历史遗留bug。station打印配送单在打开打印页面后会弹出一个打印的面板，这时如果返回到station的tab，会发现整个页面卡死。在以前，我一直认为浏览器的每个页面都是独立的，与其他页面互不干扰。但这个bug推翻了我的观点。查阅资料后发现，原来是chrome下，如果window.open打开一个页面，这个新页面会查看referer比较hostname，如果一致，chrome并不会开新的进程（chrome一个页面一个进程）给你。因此，打印页面阻塞了，源页面也会阻塞。解决方案，基于HTML标准，可以在a标签使用rel="noreferer"。前面提到，新页面查看referer来决定开不开进程，那么只要切断referer这个点，问题就迎刃而解了。
新增多个自定义模板
增加了：
- 自定义入库单模板
- 自定义结款单模板
- 自定义对账单模板
因为这些需求大体上相似，为了开发效率和可维护性，需要将相同的代码抽象成组件。
这些需求的难点主要是：每个模板都有不同的特殊要求，如何在满足这些特殊要求的情况下还能把代码写漂亮？因为gm-printer的编辑部分已经做了很好的组件抽象，所以可以把编辑部分特殊要求写在对应的组件里，但打印部分只有一个类组件，特殊的代码只能写到这个组件。
对于这类问题，我的处理是：
跟产品讨论这些特殊的要求能否用已有的功能替换，是否真的必要？如果否，使用已有的功能，实现简单。如果是，那就思考这个功能其他模板是否会用到，会用到就需要尽可能让新增的代码做到可扩展，可维护，不能硬编码。
做这些需求的感悟就深的是，编程非常需要前人栽树后人乘凉（你是"前人"）的**，如果搭项目架构或者增加功能或模块的人具备这种**，那么往上面做增删改操作都会变得异常简单，开发体验好，效率高。整个代码也是充满活力的。
2019 上半年年总结
👨🔧Think
- gm-printer 拓展和抽象。以前gm-printer专注于配送单的自定义打印。随着业务的拓展,原来的某些架构已经无法适应变化。所以做了一波小重构和优化,经过抽象和封装，后面迭代舒服多了。总结就是，把变与不变认真思考，再设计代码，是最基本原则。例如这次优化，把数据层抽离出库外，这应该是最开始就要应该设计如此，因为数据层永远是处于不断变化当中。（也有历史原因，一开始业务并不复杂，不抽离是最省时间的做法。但是途一时省事，后面还是要还的。）
- iconfont 迁移到 svg. 鉴于使用 SVG 图标系统能更好地遵循图形的访问性标准，并渲染出更高质量的图像。加之现代浏览器基本支持SVG,这对于推行SVG是一个很好契机。关于SVG也做了一些总结
- 配送单上线好一段时间了，一直平稳运行当中。但是某一段时间之后，成功中心不断反馈BUG，追查问题。经过追查，发现并不是BUG,我就想为什么最近经常反馈bug呢？ 后来了解发现，原来是成功中心来了很多新同学，对配送单的使用不了解。 于是，再把配送单原理和使用总结了一次，做好ppt，线下开分享。分享之后，BUG反馈大大减少，最近甚至没有。真真切切体会'授之以鱼不如授之于渔'，减轻自己的包袱同时帮到别人。
- 自律而后自由。
🤝About Share
生活中会有这样的案例:
一个朋友问我一个看似很简单的问题, '基本类型不可变,怎么理解?' 顿时好像可以解释,但是有不能用语言表达出来。为什么答不上来，答案很简单，自己还没理解。后来，查阅大量知识，最终完美解释给别人听。发现在这个过程中，自己无形把知识理解加深到另一个层次。
对于知识分享的一些看法:
1 锻炼自己口头表达能力
2 写分享稿的过程,会深入理解知识.形成自己的理解
3 解释知识点,使别人明白,才是真正掌握知识点. 解释不通,其实是自己没想明白。这个也叫费曼技巧，十分推荐的一个学习方法！
4 增加自己的影响力
5 知识点罗列，有时候分享的时候无需解释太多原理性问题，分享了就能拓展视野
6 沟通. 沟通能增长自己的认知，产生**火花
🚀Todolist
- 上年说好的 typescript 呢?
- [Head First 设计模式] 这书不错,有必要一探究竟
- 形成一个好习惯
2019 上半年总结
上半年总体上在 Android 原生的支持和维护以及一些项目的重构花的时间较多，持续的时间也比较长，不过也接了几个 station 相关的几个小需求，比如 station 的报价单打印、复制订单和采购到货，虽然是小需求，不过还是比较认真对待的，上线之后相关需求也没出现过 bug，小问题都能在测试阶段解决，暂时没发现埋下什么坑。
项目总结
Android pda
主要做了扫描头 SDK 适配的工作，按理说 pda 可以直接用来扫描然后填充扫描结果，不过我们产品业务还需要利用 pda 能够自动做更多事情，利用厂商提供的 SDK 进行二次开发确实是最好的选择了，使我们的应用能够跟扫描枪底层进行通讯。考虑到可能需要适配不止一种厂商型号的 pda，所以开始的时候就有意识的做很多额外的封装，做到尽可能解耦，目前陆续经过四个型号的适配，已经封装出了一个还算满意的二次开发 SDK，接入使用很简单，就算再增加适配型号，也能在原来的框架上，轻松的快速接入。目前 「扫码 PDA」软件和「司机 APP」都有接入这个库使用。
分拣软件
把分拣软件的 web 版本移植到 pad 端，主要工作是在 pad 端增加硬件交互能力，因为分拣软件需要获取电子秤数据，以及使用打印机的能力。两者都是通过蓝牙来实现通讯的，为此改进了原来使用的蓝牙原生库，优化点包括连接速度加快以及增加多设备连接能力。不过打印机依靠蓝牙指令打印出来的样式比较粗糙，最近改用蓝牙发送图片数据来打印，速度却又较慢，算是无线打印的一点局限性吧，对客户作业效率影响不好，还不到能够正式推出的程度，希望后面有更好的方式解决这个问题吧。
采购 APP 重构
不久前刚完成了采购 APP 的重构，把原先使用的 rn 技术完全改成原生 webview 的方式了，对于公司的业务形态来说还是挺适合这种方式，一是很多项目迭代频繁，二是体验和性能要求也都还允许这种方式，暂时没太大瓶颈。不过做这个项目的时候主要是 web 方面的重写了，简单的套 webview 有之前项目的积累已经不需要花费太多精力了，几乎是整个项目的模块我都参与了重写，所以对这个项目还是挺熟悉的。由于当时留给开发的时间还是比较短的，加上后面产品不断的修改业务逻辑，导致整体延期了一周左右，测试期间也发现很多问题，也幸亏有测试的负责，上线之后到现在还没有出现代码逻辑的 bug，后来套入到小程序在 iOS 倒是有两个兼容小问题。期间也感觉到，开发前作为开发人员也应该尽量去理解整个需求的细节应该会更好一点，因为有时候产品也是不一定能够对业务逻辑有精确的把握的，这样能减少在开发过程中变更业务和代码逻辑的情况，对代码质量的提高也有好处。
下半年展望
公司方面，还是有挺多产品在依赖着原生技术这边的支持，虽然都是比较基础的技术，但是目前公司中有相关技术积累的同事不多，所以一些细致需要注意的点还是应该多落实到文字记录上，让别的同事也有所了解，也方便后面的维护，比如之前司机 app 扫码的需求，产品和开发开始都没不知道需要原生方面的支持，找我帮忙的时候本身还在做着别的需求，所以可能会出现意外的需求延期。另外，现在主要维护的项目和需求都比较固定了，在分拣软件以及采购这边的比较多，所以相关业务也越来越熟悉，做需求的时候，更加还要注重代码质量和整理一下一些不可以优化的代码逻辑。
个人方面，最近主动学习有所懈怠，业余时间没有太多系统知识的吸收，反思一下。
2019上半年总结
项目工作
- 供应商报价报量
- MES-PAD重构
- 优先设置供应商
- 采购分析
-分拣序号排序
-采购app重构
-其他一些零碎的项目
总结
总的来说上半年工作的很充实，紧凑的需求排期，可以更加快速的把精力投入工作中，提高效率。同时上半年主要偏向于采购这一块需求，而工作中并没有太多的难点，需求进行的比较顺利。嗯..所以感觉没什么好说！
意识到问题
- 需求的归纳总结
- 最重要的一点，落实笔记，落实笔记，落实笔记.....
2019上半年总结
工作
重构
上半年花了较长的一段时间在bshop重构上。因为代码不是自己写的，开始重构前需要理解之前的代码逻辑，梳理清楚其中的业务，然后才敢开始写代码。重构的周期比较长，为了保持与主线分支的同步，我们选择一个一个模块的进行，依次进入测试灰度全量，最终也基本完成整个项目的改造。
重构给自己带来的好处：
- 代码组织能力。有的时候看之前的代码会很疑惑，可能就是代码结构逻辑等不合理，自己重写就能写出更加合理的代码，保证代码质量。
- 业务理解。首先要懂业务才能开始写代码，之后的自测也需要对相关业务有所了解，走一遍业务流程才能确保代码是可靠的。
需求迭代
陆续接了些 station bshop 的需求。这一块还好，就是走正常的需求节奏，碰到问题也能快速的响应去解决。
其他
有时间的时候，也研究了下 lock, babel7, webpack 这些，输出了一两篇文章。
遇到过一个比较大的问题是关于 lock 的，很多人拉代码下来，npm i 后发现 package-lock.json 会变化。在 so 和 npm issue 上看了一些资料，发现这个问题是这样。
- 基本来说，
package-lock.json会决定node_modules的结构 - 但是如果已经存在
node_modules，已经安装好的包也会影响到package-lock.json，更改其中的某些字段(相互影响) - 还有其他的因素 比如 npm 版本，使用的 registry 等等
针对这个问题，其实没有太好的解决办法(感觉像是设计问题?)，我们现在是这样做的。
- 尽量的统一
npm版本，registry这些(解决部分问题) - 如果
package.json没变化(没更新包)，可以忽略掉package-lock.json文件的变化(不提交到 git) - 如果希望
npm i之后 lock 文件不变化，可以尝试清掉npm cache，然后跑npm ci重新安装node_modules试下
总结
上半年没有做太多的事情，基本都是专注在一两件事上(bshop/其他)，总体感觉比较平稳。个人来说，似乎很长时间没有系统的去学习、深入了解一些东西了，需要反思。
我的上半年 -- 2019
新的环境
四月份来到的观麦大家庭，两个多月的学习与工作，时间过得很快，让人有点措手不及。在这两个多月的时间里，我学到了相关的技术知识，懂得应该如何更好地推动一件事情的完成。同时对个人的不足有了更深一层的了解，后续要做的就是把这些慢慢消化，更好的进步。
理解三个原则
- 闭环。不管做什么事情，及时沟通反馈，完成后周知他人，有始有终。
- 谁难受谁推进。由最难受的那个人来推动进度，完成任务（当然，那个人我觉得最好是对应事情的主负责人）
- think bigger。不要着眼于眼前的一个小点，拓展看全局，可能会发现很多有意思的事情。
这是团队中贯穿始终的最重要的三条原则，在不断的学习和工作中有了进一步的理解，对于我们完成任何事情有很大的帮助。
我做了什么？
- 汇付提现
这是接手的第一个小需求，总体来说并不难，主要是帮助自己理解和熟悉整个团队的开发流程以及一些规范性的东西。 - 补录订单迭代
个人觉得这个需求的主要难点不在于技术，而是针对运营时间、运营周期以及收货时间这两个比较复杂的业务逻辑上的理解，并且还向后台的兄弟要了一份这部分的开发文档去深入理解。首先，需要注意的是运营时间是否跨天的情况。其次，我们必须保证补录订单的收货时间遵守一定的规则：在不同的运营时间选择下，确保收货时间需要在一个运营周期时间内，并且下单时间不能超过当前时刻。在理解了正确的逻辑之后再开始动手做需求，这个需求我学到的很重要的一点就是：不懂一定要问！不懂一定要问！不懂一定要问！及时的求助和沟通可以帮助我们更快地完成所做的事情，同时不同的思维可以碰撞出更多不一样的火花。当然，在后期一定要去进行整理归纳知识点，消化保存成自己的东西。 - storage cdn版本优化
这是一个自认为比较难的需求了（对于目前的自己来说），也是让自己印象最深刻的一个需求，主要内容涉及到了跟cdn有关的前端项目中的静态资源部署更新问题。在这个需求上所耗费的时间超过了自己的预期，也给自己敲了一个大大的警钟：在遇到自己无法解决的事情时，请求别人的帮助也是必须的，待问题解决之后自己再花时间研究。另外一方面，这个需求也拓展了自己的技术层面，了解前端项目中应该如何去部署静态资源以及应用版本号来达到精确控制资源更新的问题。当然，这个需求也从侧面提醒自己对于async await的掌握还不够熟练，需要多加巩固。在这个过程中还了解到了关于webpack、gulp等生成文件hash的方法以及应用，尽管最后没有派上用场，算是额外的收获了。 - 参与react-gm库完善
这个是目前还在继续做的一件事。看代码可以锻炼自己的逻辑思维能力，同时在修改的过程中学到很多其它的东西。代码的规范性，代码的逻辑结构是一个很值得思考的问题，在这个过程中也可以提升自己的思考能力。 - 其它一些比较简单的小需求
虽然做的需求不算很多，但是每一个需求中蕴含的东西都能够学到不一样的东西，一定要用心去完成，开动自己的脑筋。
除了工作之外的其它呢？
毕业季算是比较繁忙的阶段了，在上半年中，自己有点荒废了，不管是学习上兴趣上还是运动上。好在，工作上算是已经在慢慢进入正轨，慢慢地也开始恢复以前看书的习惯。不管是技术上的还是文学上的，书籍是最能提升一个人的**境界的宝贵资源。偶尔也会想要画画了，尽管画的不好看，但是是能够让自己静心的方式呀。
下半年呢？
- 该巩固的基础知识还是要巩固，打好根基才能建好一座大厦。
- 多学习新的知识，主要是typescript以及node.js
- 多看看一些好代码，拓展自己的思维思考能力。
- 代码不仅要看，也需要写。同时平时的笔记也很重要，说不定哪一天派上用场了呢。
- 希望能多看几本好书（技术上的 or 文学上的）。
- 运动起来呀，身体是革命的本钱。