18下半年总结
liyatang opened this issue · 9 comments
对比上半年的仓促，下半年是相对从容，没有特别令自己难受的事情，一切走的还算顺利。
碎碎念
技术团队的核心价值是按时完成工作，确保公司能生产好的产品，服务好客户，最终目标是服务号客户
管理者的本职工作就是确保团队按时完成工作
三原则（闭环、谁难受谁推进、Think Bigger）很重要，很重要，很重要，尤其闭环原则
纯粹的沟通，以解决问题为准，不要太在意沟通过程中的情感因素，都是程序员，都不太会沟通
多沟通，增长自己的认知，也一定能增长自己的认知。多和自己厉害的人沟通，也许讨论A，他可以帮你get到26个字母。
身边的人都是资源，充分利用资源，站在巨人的肩膀达成目的
把事情简单化，一定是可以做的。不要怪业务复杂，简单化是一种能力，做不到要么是业务不熟，要么是认知还没到火候，要么...
遇到奇怪问题，静下心。1 认真观察，不要丢掉任何细节；2 从原理入手。往往能解决问题。
需求不在于多，而是有序和无序，要让他们学习自我管理，时间管理，资源管理，冲突管理
一个靠谱的人往往非常注重细节
接到需求做好背景了解，做的时候做好推演把各个环节串联起来
强调独立思考能力，独立跟进事情的能力，不要也不能被动的做事情。如果被动就不要做事情，停下来，改变下认知或者找其他人支持。
最好的管理是去管理，让他们自己管理自己，管理是项服务，规则约定制度等都是服务，Leader是服务。
员工最想要得到的就是成功，得到满足感。其他不是很重要。
招到一批靠谱的人很重要，然后提供好的环境。然后用心观察团队中出现的问题，然后解决掉即可。然后用心观察他们能力，有些人还有很大的上升空间。
好苗子不断地倾斜资源，不断的制造环境，给机会锻炼，在自由的环境中充分施展才能。
自由和纪律，有纪律才有更多自由
不用太在意犯错，而更在意这个过程中你是否学到了什么。也经常让他们放开手，大胆干，从错误中学习。这肯定是非常快的成长方式。
目标是什么
记得18年上半年总结，自己给自己列举了以下5个目标：
-
激发小团队的活力
-
补基础（啃书）
-
station和ma重构、专注于web端框架层和性能优化
-
小程序
-
个人多输出，成文，分享
半年时间制定了太多的目标，现在一细看，勉强只让1、3、4起步了。半年时间其实很短，大可不必列举太多想要做到的东西，把一件事情做好更有价值。半年时间也很长，时间磨掉了人的激情，让人慢慢就忘了还有多少事情没起步，还有很多事情还没完成。
做到了多少
18年下半年其实完成了挺多需求的，例如：
- 营销活动： 优惠券、限购活动
- 商品： 智能定价、税率
- 进销存： 扫码入库
- 新增产品线： 云管家小程序
- 性能优化： mes虚拟列表实践
- 代码质量把控： fundebug预研、log记录、bug上报钉钉
迭代快
这半年已经习惯了A在转测，B需求就准备开评审会，C需求已经挂在你周报下了。刚开始还会插空做一下重构或优化，但慢慢的发现需求（不特指产品需求）切换成本过高，一周如果有超过3个需求要处理，最终各个需求完成的结果不但差强人意，耗费的时间也更多。这就需要去评估优先级，合理把控需求进度。但无论如何安排，都需要做好闭环。
刚开始会想着尽快完成手头上的需求，去做自以为更重要的事情。殊不知，任何需要重构和优化的代码都是因为你没有认真对待每一个现有的需求。
以限购活动需求为例，就想着尽快完成转测上线，只顾着在原有代码基础上加逻辑判断，导致原本已经不可读的代码更加杂乱冗余。每一个需要改动到老代码的需求都是一个很好的锻炼机会，因为需求你有机会更了解代码逻辑，推断每一行代码的作用，锻炼你的归纳总结能力和抽象思维，重点是你要get到能提高个人能力的路径。
代码质量把控
前端的bug其实挺稳定的，pc端基本一周2~3个bug，且大多数是新需求上的bug。为了更好地提升用户体验，我们把监听到的bug都上报到钉钉，配合fundebug，基本能定位到具体哪行代码的问题。
为了查一些偶现的、疑难杂症的bug，我们把用户的每个请求都记录到log上，用户的系统环境等也记录下来。
log的作用远不止定位bug，它能更好地记录用户行为，定位我们的产品方向。这条路很长也很有价值，慢慢探索吧。
思考
多沟通交流，学习别人的思考模式
这半年记忆很深刻的是mes虚拟列表实践的小需求，虚拟列表针对定高与不定高实现方法不一样，定高更容易。我一直认为那个需求就是不定高的，不可能定高。等到我把代码写完、通过测试后，小组内一review，他们提出了完全不一样的结论——这是定高的。
结果当然是定高实现了。但我一直在思考，为什么我看到的是A面，别人可以看到B面和C面，为什么我却想不到事物的另一面。
雅堂老说，要多与别人沟通，即使有了想法，聊A可能拓展到B和C。
自由与责任
前端一直是很自由的团队，我也很喜欢这样宽松的管理模式，我们没有太多的条条框框，给到每个人的权限都是很大的，一个实习生与一个老员工拥有的权限是一样的。犯错不可怕，试错的成本我们是允许的，但相信如果我们团队的原则传递到位的话，是不会出现严重的错误的。
制度管人，人管人都太累了，最好的是自己管自己。对自己的时间负责，对自己的项目代码负责，否则就不适合我们团队了。
帮助别人成长
这半年帮助了贵松、伟强、泳仰融入我们的团队，自我感觉不算成功，以下几个点是小小的心得：
-
前期要重点传递我们团队的原则和规范他们的代码，打好根基后，他们会在短时间里快速适应团队
-
引导他们去搜索答案、与其他团队沟通合作，不干预太多
-
评估好他们的能力点，发现他们的潜力点，放心大胆地让他们接手需求，很多时候他们完成得比我还漂亮
-
做好code review，我喜欢直接拉他们的分支到本地上运行，在webstorm上对比改动。
19年上半年
- 快速响应需求，主动了解业务，推动产品决策
- 代码质量把控
- 沉淀+分享
- 提高自己推演能力（全局把控）
年终总结
来公司也两个月有余，需求接了不少，自我感觉成长的还挺多的，知识点都做了记录，当然还是有些许遗漏的，但问题不大，我只把在工作，或者对前端思考上的难点做一些总结，如下。
GIT
进来先是熟悉git，之前用git只是简单几个基本命令和理解远程仓库概念：
- git add
- git commit
- git push, git pull
只懂这些确实无法应对工作。对于git我也是用到多少学多少的心态去恶补了。git的本质是工具，目的是解决多人协作和版本控制的问题。跟传统的版本管理工具最主要的不同的是，他有本地仓库和远程仓库之分，本地仓库中又有工作区、暂存区、版本库等概念。对我而言，难点是两个。
冲突
多人开发冲突是经常，分支开这么多，合并难免会有冲突。
冲突是什么？
当你的分支合并到另一个分支时，两个分支都改了同一个或多个文件。
怎么解决？
我的办法是用vscode自带的解决冲突的调试工具，选择保留“传入的文件”或“当前文件”
rebase（变基）
一开始很不理解为什么要用rebase，不用merge。他们的目的都是合并，不一样吗？事实上，结果一样，但用图形化界面看git代码库后，会发现，rebase是线性的，干净利落。如果使用merge，项目大了，需求也多，分支合并到master越来越多，越来越乱，对于管理维护项目是很糟糕的体验。rebase的原理是把一个分支上的多个commit修改成一个commit。具体见何为何为rebase
组件设计
前些日子接到一个需求是做一个地图组件。功能简单，但BUG却无穷。其实最开始设计就出了一些的问题。思考发现JS动态类型原来是深渊巨坑，深刻意识到原来像typescript这样的类型检查真的很重要。举个例子，组件有一个props，center={ lat: xx, lng:xx }，可以看到，center是一个object类型，由于设计组件设计到多个项目，有些人想传center=null，有些人想传 center={ lat:null, lng:null }，作为设计者，第一感觉难度不大好实现的需求都是会满足的。事实证明，还是欠考虑。
为了处理这两种类型，我多写了一些特殊逻辑，当时觉得应该没什么问题，就多了几行代码而已。
后来BUG无穷，解决完这个，那个又冒出来了。这简直是终极噩梦，在我焦头烂额的时候，我慢慢意识到，一定有个本质上的错误，他导致了后续的错误，我必须找到这个罪魁祸首。问了Google和同事后，才知道是自己设计组件时，对props的约束太少了。
对于一个组件，我们最该关心的是设计者无法操控的东西。
我们都清楚，自己写的可控的程序是可以做到不出错的。经常出错的往往是那些不可控的东西，例如异步和调用方使用组件所传来的props。后者展开来说，可以是数据类型，是基本类型还是引用类型，基本类型的话，是否是静态的？如果是引用类型，那他的结构是如何的？引用类型需要注意点就更多了，复杂度也更高。所以如果给变量的类型做检查，使变量成为静态类型，那么是否可以免去那些为了处理动态类型而写的繁琐代码？
设计一个组件一个重要原则就是要让调用方去习惯你，而不是调用方要什么你就给什么
组件是很难做一些定制化，因为组件非常注重稳定性，自由度和稳定性很可能是互斥的。
react Fiber
因为项目开启了严格模式，该模式会双调用以下方法：
- constructor
- setState
- render
- static getDerivedStateFromProps
这么做是让你不要在这些方法里写一些有副作用的代码。因为react fiber很可能会多次调用这些方法。什么是react fiber
总结：代码报错比较诡异，就关掉严格模式看看，如果真是严格模式的问题，那么说明你在“第一阶段（render前的阶段）”有副作用，你需要找到那个副作用，并分析为什么会将这个副作用写在“第一阶段”，是否可以写在别的地方？
最后
关于学习方法
前几天，看到一篇新闻，“**氢弹之父于敏去世”，报道中的一句话令人印象深刻。“用宏观的视角去解释微观问题”。这大大的启发了我，作为一名coder，这种看问题的方法是我最应该学习的。
关于新技术
比如HOC，render props，react hooks，mobx等等，就不一一说了。当然，自己也常犯一些基础错误，比如变量命名、错误处理。总之，在公司的两个月真的成长了许多，频繁刷新对前端的认知，每天都有新发现。
关于对抗焦虑
专注是对抗焦虑最好的方式。当你全神贯注的做事时，会进入一种心理学上被称为「心流」（Flow）的状态，在这种状态下，人会产生高度的兴奋感与充实感。在工作中如何获得心流？
回首
日子在弹指一挥间就毫无声息的流逝，就在此时需要回头总结之际才猛然间意识到日子的匆匆。18年6月份毕业，5月中旬加入到观麦工作，多个月的工作下来。认知与见识充实了不少；个人的不足也需提高。
工作上
项目
- 优惠券
- 云商品库
- 云管家
- pda
- fe ...
需求层面上说，2018年下半年做的需求算是挺多的，参与云管家，pda两条新的产品，station订单的重构，代码整理。及需求的迭代。
技术方面涉及nodejs，桌面，移动端。
业务
实地参观企业作业，了解实际仓内投框，分拣，称重等业务场景。更大程度的理解需求设计于解决真实场景的问题。
思考与沟通
千人千面，不同人的想法思维方式皆是不尽相同。思维的碰撞才能带来更多的火花；多点沟通，就会有更多的想法。
个人上
18年小目标
- 多读几本书
- 思维上深度与广度的扩展
- 对前端多端的深入
- 服务器端深入
- 总结
饼很大，货很干，事实很残酷。
对于读书这个事，一直不敢懈怠。每年的年初都会买上些书。偶尔翻上一翻，算是对这一年有所交代了。实际上也只是粗略的看了看。并没有细读。
对于安卓/ios端/pc客户端也还是简单的了解，多看了几遍文档。属于算是demo 的阶段, 自勉之。
18年下半年放在服务器端的时间算是挺多，但这块的技术积累与资源有限，自己摸索，效果也不是很好, 自勉之。
时间很可怕总是不经意间就把好与不好的事都慢慢的消磨光了，只留下了脑海中零星痕迹。
技术提升
多看看好代码，我觉得是一种技术学习上的一种自我修养。平时闲暇之余我常去看看文章，理解别人的解决方案，读源码看看别人的代码设计，好的代码设计是很优美的。
展望2019
承接上年，希望能做的更好
- 多读几本好书。
- 技术上对前端多端/服务器端有深入了解。
- 对新技术的持续探索。
- 常写点什么。
感觉上半年总结刚写完没多久,又到了写下半年总结了. 时间过得飞快.
业务
2018年主要关注点在前端基础库和业务开发上面。司机业务冲出海外，上半年我们组主要精力放在了国际化需求。开发多语言迁移工具，旧项目快速切入多语言。调研多种多语言库，根据当前多个项目特点选择最适合进行选型，落地。
业务开发方面，我们组主要负责station配送单，司机，采购，ma报表，商户等业务。这一年，开发了各种大大小小的需求，对负责的业务更加熟悉。对业务的熟悉，令我们组内在整体把控需求，对系统稳定产生极大的帮助。
staion:
- 库存记录明细
- 新版配送单自定义
- 采购询价记录
- 成品入库迭代
- 订单操作日志
- 司机调度中心地图
- 配送单支持多模板
- 马来定制配送单
- 商品库批量修改
- 采购任务供应商优化
- 司机智能规划优化
- 订单备注功能
ma:
- 商户授信额度
- 商品分析搜索优化
- 到账凭证/商户结算/商户列表/商户对账单优化
基础库,项目底层设施等:
- 多语言国际化
- 前端组件库react-gm持续迭代
- 图标库管理gm-xfont
- 自定义打印库gm-printer
思考
-
工作中让我们受益最大的价值观是闭环原则。闭环原则也是工作中最常用也最有效的原则，但是一直坚持却是难能可贵，以至于需要不断提醒自己和队友们。如果能够在完成自己工作任务过程中，及时的把自己的工作成果反馈给Leader和相关协作人，总会带来各种惊喜。因为反馈或许可以提升团队效率，也可能该表产品决策，同时你会因为持续的反馈获得更为重要的任务和职责。这就是靠谱，有始有终.闭环原则总是值得反复强调，执行和坚持。
-
这一年解决了大大小小的各种问题,采坑挖坑不断.感触比较深的是,一次打印机打印的问题,属于疑难杂症,我自己思考和调试了半年只有一点点眉目.后来,拿出来团队讨论,队友提供了很多自己没想过的思路,经过多次研究以后问题很快就水落石出,这个案例让我明白,每个人的思维都有自己局限性,一个问题有多种解答,合理利用身边一切资源,是解决问题的最快方法.而且讨论中产生的**火花对于拓展自己的认知十分有帮助.
-
做自己擅长的事情,形成自己的影响力,不断得到正反馈,自我驱动
目标
快速稳定迭代需求———是团队的最终目标. 围绕这这个目标，需要做的事情还有很多。
- 更加熟悉业务流程，把控自己的责任领域，同时帮助团队解决问题。
- 构建更加健壮的基础库，助能需求快速迭代。
- 业务设计思考，增加用户体验，提高需求质量。
展望未来
上半年自己画的饼没有全部完成,十分残酷.所以2019,flag就不立了.
但是今年希望做的事有以下,希望能自律,尽力完成.成长永远是第一要务.
- 多读好代码,特别是review代码的时候吸收精华,发现糟粕.
- 学会typescript
- 把几本好书读完
写上半年总结的时候，就有给自己定过几个下半年的目标，现在看来，下半年其实并没有完全按照自己定的目标去走，不过收获是超出了自己目标的预期的，每次回头看看以前的自己，能感觉到自己的进步，这很让人充实，以及更有信心继续保持学习的热情。
目标完成情况
上半年定的第一个目标就是尽快熟悉各个项目的业务逻辑和代码，熟悉公司项目业务是保证效率和准确的前提。
这半年的时间中，接过的需求虽然不算很多，但是无论是主动还是被动，对公司的业务流程也算是有个整体的了解，至于具体项目中的业务逻辑，确实比较多和复杂，只能是响应需求过程中去挖掘和梳理，加上在重构 bshop app 过程中主动了解和梳理了很多细小的业务逻辑，比如收货时间的设定以及支付流程等。
至于技术方面的学习，小程序开发这个并没有过多去接触，这个目标算是失败了，暂时搁置吧；前端的构建工具学习方面，看了些 webpack 的教程和实践，处于能使用的阶段，并没有看得太细，感觉可以遇到问题需要的时候再去深入了解。
笔记方面，在学习一些新东西的时候，会有意的写成总结沉淀下来，用到的时候也会时不时翻阅之前的笔记，这点还算不错。
下半年还做了什么
工作上
除了偶尔一些小需求，主要时间都在净菜二期，bshop app 重构以及 pda 这几件事情上，涉及得其实也挺多，web、react native 和 iOS 以及 Android 原生开发都有，也是因为这个原因加上喜欢折腾的好奇个性，一直都保持学习这些相关技术的热情，也让我觉得，什么技术都好，一段时间不使用，总会生疏的，重要的是了解更多点基础的东西，以前做过的东西虽然会生疏，只要基础还在，捡回来也不会太难，而且还会有新的收获，比如在做与移动原生开发相关的时候。
学习上
很庆幸一直以来都有敦促自己不要停止学习，所以一直涉猎的内容都还算广，下半年在工作之余，也重新学习了下数据结构，不过还没完成，有时候还是会觉得有点吃力，要反复看反复思考，知识点也比较容易忘，可能是自己太死磕了，过程比较艰难，争取今年上半年完成。另外，还学习了 Python 和 nodejs 等，移动 APP 性能优化和逆向也有看了些文章学习。
期望
无论是工作上还是自己主动接触的东西，涉猎虽然多，但是担心啥都是只懂一二半桶水，有时候也会想深入某个方面多钻研下，不过目前还没有找到方向，迷茫中，希望自己还是能够保持主动学习，掌握好自己学习的节奏。
2019 上半年，工作上还是继续全力以赴吧，多总结多思考，收获不会少的。另外，希望，数据结构这块还要继续下去，慢慢把计算机科学的底层的东西补起来。
回顾2018
一晃半年，2018过去了...其实早就到了该总结的时候，是有必要写点东西了。
做了什么
接了一些需求，有完全新的业务(短信、周转物)，也有基于现有业务做的迭代(采购、商品)，用技术做了体验(or 性能)上的优化(webworker、动作记忆)，国际化的推进(多语言/多币种)，以及其他一些大大小小的事情(gmfe document fe...)
回过头来，再看下刚来观麦时给自己的下半年规划
- 熟悉业务和库
- 知识深度(React/node)
- 多思考，多写点东西
由于深知理想和现实的差异，贵在脚踏实地，只给自己定了三个小目标，现在看下完成的怎么样。
业务和库
因为不是生鲜行业的亲身从业者，很多业务场景自己都不是很熟。更好的理解业务、场景，才能帮助产品变得优秀。
我的业务了解主要是需求驱动的。做一个需求，就要知道它具体的业务背景，它的目的是啥，解决了什么样的问题，与现有业务是如何交互的，未来可能会有怎样的变化...从技术上来说，了解这些东西也是很有意义的，它能帮助我们写出更具弹性的代码。
这半年以需求为驱动，业务上也确实懂了不少，但是还有一种感觉，就是这些都是零零散散的、碎片似的东西，好像并不能串在一起，更加系统的去理解。可能是认知不够，还需要再深入。
库方面，在平常开发中都会使用，基本的都有了一定了解，也有参与几个库的pr和cr。
知识深度(react/node)
React这一块，由于原来没有过React的使用经验，从零开始，更多的是边开发边学习，多看别人写的代码和官方文档，抽时间读几篇文章，积累了自己的理解。跟刚开始比，深度已经提升不少。
这个过程也带给了我很多不一样的体验，尤其是，React自身的发展方向让人感到惊喜，越来越倾向于提升用户体验(和开发体验)，期待未来的 Concurrent React。
另一个感受就是，由于 React 官方并没有提供太多开箱即用的东西，更多的是交给社区去弄，造出了很多轮子(单状态管理就不知道有多少了...)，随之也带来了技术选型上的多样化，这让初学者完全不知道从何入手。
当然自己去做技术选型也是有好处的，需要我们自己去独立思考，根据场景做取舍。软件工程没有银弹，如何让技术更好的贴合业务，解决现实问题才是最重要的。
至于node，并没有深入太多原生的东西(:因为平常也不怎么用到)。稍微了解了下 Egg，脚本相关的api和库的使用。
多思考，多写点东西
我喜欢如下的总结方式。
- 可能平常开发遇到的一个场景，跟别人沟通交流得到的一个结论，看文章得到的一些要点难点等等一些东西，会让你有新的感受，这时候可以当作笔记、草稿记下来。
- 不断重复上述，积累，实践，探索，形成个人理解。
- 差不多了，沉淀下来，写篇文章总结下。
这个过程让我学到了很多，但是自己有时候(经常)会卡在最后一步，希望能有所突破。
展望2019
- bshop重构(业务，移动端)
- keep learning (多方面的)
- 养成好的todo list习惯，给事情排优先级(时间管理)
2018下半年总结
工作
- mes 功能迭代(数据同步,打印多标签,按线路批量打印,供应商分拣)
- 司机app重构
- 采购app（货币国际化，大数据优化分页）
- bshop app重构
业务
关于业务，之前一直都是按照需求的节奏走，没有过多思考业务场景，以及背景；虽然有时候，会对业务需求有疑问，但是多数情况下未对其提出质疑。然而18年下半年的大部分时间都在重构以前的项目，这给我很好的机会去了解业务，同时理清楚业务逻辑。再有就是实地参观客户使用我们的系统作业，当自己亲自操作时，就是会明白为什么客户会提的这样的需求，也促使自己在做需求时，会想的更多。
个人收获
- 深刻体会到三原则的重要
- 沟通交流，看文章，取其精华
- 知识体系提升
2019
- 多归纳，多思考，多总结，多做笔记
- 了解业务逻辑，深入业务背景
- 快速需求迭代
2018下半年总结
业务
2018下半年主要都是按产品需求驱动，实现输出。负责bshop，净菜等业务。
- 重构bshop，bhsop相关需求开发
- 净菜二期
- ma异步任务管理开发
- 按线路打印配送单
- 分拣进度任务
- pda预分拣。
思考
2018年接触的项目比较多，在里面学习了并沉淀了很多新的东西。
- 新知识沉淀：bshop移动端的开发以及移动端bug和灵异问题知识沉淀（重新登录openid，微信支付问题）。移动端性能问题引入了虚拟列表。大量数据性能的解决，引入了异步任务处理。大量数据导出也引入了前端的导入导出。同时对硬件pda也有了认识了解。
- 软技能：团队沟通、协作越来越流畅。定位问题手段能力提升很大（抓包，查日志，快速调用内部资源协调解决问题）。开发流程规范话，项目需求迭代的速度也越来越快。
团队的工程项目越来越多来，库也越来越多，越来越完善，功能越来越强大。为团队日后的需求迭代越来越快，系统越来越稳定也奠定了基础。
目标
快速响应完成需求的迭代。完全hold住自己责任领域的业务流程，快速响应解决问题。
不足
- 对系统业务不是很熟悉，不能完全hold住。随着我们系统功能越来越多，客户越来越多，我们对负责的模块的业务很有必须要全面深入了解，这样才能积极快速解决问题。
- review团队成员的代码不足，以后需要多review其他成员代码。
2019年展望
- bshop重构
- bshop业务整体逻辑梳理完成
- 读完三本书