一、日常问题
1）成员间的信任
信任危机不是发生在自己团队，而是出现在隔壁服务端组。
他们组没有一个正式的组长，只有一个临时的代理组长，这种情况从我进公司到现在一直是这种情况，也是蛮奇怪的。
前几天，这个代理组长和其中的一个组员爆发了点冲突，我从旁观者对他们对话的理解就是，组员觉得他瞎指挥，他觉得组员无担当。
其实从平时他们的协作中，我就有点预感会有冲突。
这个组员平时经常会质疑他的决策，并且他们在讨论方案时我听的最多的就是那我该怎么办？
一个这么多年开发经验的人，总是把这句话挂在嘴边，我是很难理解的。每当此时，他就会给他详细的解决思路，像是在教他写代码，甚至有时候既然你不想做，那直接自己把活揽了。
而这个代理组长，我感觉也有点问题，什么事都往自己身上揽。并且挂在嘴边最多的一句是，这个很简单的，然后巴拉巴拉讲了一堆，从他的组员的表情和反应中，我可以观察出他们并不是这么认为的。
这次的冲突点，就是一个支付的功能，组员突然就做不下去了。然后他们就开始针对之前的方案展开讨论，后面找了个会议室，再然后说话的声音越来越大，整个办公室都听到了，虽然还没到争吵，但气氛已经很紧张了。
我往深层次的看就是他们之间互相不信任，组员并不服他。而他也过于的干涉组员的开发细节。要让组员能信服自己，并不仅仅只在技术方面，管理方面也不能拉下。至少得让他们觉得跟着你这么干，对他们自己也是有帮助的。
那天之后，自己也会思考若碰到这样的成员，自己该怎么应对？现在还没有特别完善的应对策略，之后会通过研读书籍、专栏、分享等各种途径，来替自己解答这个疑惑。
2）JSBridge新功能演示页
最近遇到个小问题，客户端有个版本要发布，其中会涉及到几个JSBridge的接口。
在测试和预发环境已经验过这些JSBridge，都是正常的，现在马上要提审了，在提审之前需要验证这个包是否能调起JSBridge。
而H5活动页面会在提审完后再发布，这样的话如果要验证JSBridge是否正确，那么就得需要个演示页面或者是通过预发的活动页面来验证。
其实这些JSBridge都是需要一张演示页面的，那就定个规范，每次需要联调JSBridge时，要先配置好这个页面，供客户端、前端以及QA验收用。
在验收时，即使活动不上线，也能在此页面中加以验证。
3）协作通知
今天产品经理像我抱怨我一个功能开发的太快，她都来不及没写产品文档，也还没设计原型。
这是一个很小的需求，并且页面功能非常简单，一个文本框和一个按钮，需求几句话就能描述清楚。
我自以为和产品经理已经达成共识，即不需要原型，文档编写与我这边也可以不同步，但是产品经理并不是这么理解的。
因为我没有明确的告知她，这功能不需要单独的文档，这次其实还好，她还没开始，时间上也没有损失。
但从深层次上来说，这次的事情暴露了跨团队的协作仍然存在着障碍，虽然这次没有损失，可是不代表下次也没有损失，所以得防患于未来，我马上去更新了协作规范，加了一句。
其实项目管理经常会涉及到很多细节方面的事情，稍不留神，就会踩坑，然后就会爆发这个那个的问题。
4）知行
这其实并不是什么问题，而是我最近在看的一本书的书名，全称叫《知行 技术人的管理之路》，书中讲了许多管理的方法论和技巧，有两处的讲解让我感触颇深，特在此做摘抄。
第一处是分工模糊导致的问题（142页），在我之前的日常思考中也有提到过，当时我用的标题是“争议区域”，讲的没有书中那么理论化。下面是书中的内容：
“管理者为了能够让大家互相补位、主动承担、增强互助，还会刻意去模糊边界。但是任何不以分工清晰为前提的边界模糊，结果都会事与愿违。
因为只有明确的分工，才能让员工清楚自己的职责，只有清楚职责，才能带来归属感，才愿意主动多付出一些。”
第二处是对下属的沟通（向下沟通，232页），书中的第7章介绍了管理沟通的方方面面，涉及到了很多细节。带团队免不了向下沟通，这其实是最有挑战的管理主题。
在此书中描绘了4种沟通场景，并给出了相应的解决方案。
- 批评员工，真实意图是促其改变，可以先转换下意图看看是否需要批评，如果批评依然是最好的手段，那么指出员工错误的行为以及需要改善的地方，同时帮助制定改进方案，提供出路。
- 沟通不顺，对于内向沉默的员工需引导他打开话匣子，话题不必局限于工作，首要任务是建立起沟通通道。对于聊不到一个频道的员工，从事实、判断和意图三个层面和对方进行频道对齐。对于捉摸不透的员工，可以用封闭式问题做一些回放和复述，例如你是不是这个意思、你看我理解的对不对。
- 牛人下属，对牛人的态度应该是用之，而不是竞之。认清自己的角色，认同高工的价值，支持和帮助，以及必要的约束。
- 应对刺头，刺头就是那些管理成本很高的员工，对需要淘汰的刺头应该尽早淘汰，而另外一些需要促其发生积极的改变，即从他的不满意和愿景出发，制定迈出第一步的行动计划，帮他克服改变的阻力。
5）换位思考
换位思考说起来容易，做起来很难，尤其是要做到持续换位思考，难上加难。此处换位思考的对象主要是业务方和产品，他们关注的比较多的是营收和体验。
如果保持站在他们的角度看待他们所提出的需求，那么对于自己、团队和公司都会有很多益处。
- 对于自己，每天工作时的心情能比较愉悦，而不是在看到提出新需求时，眉头一皱。
- 对于团队，在互相理解时，就能高效地配合制订出多套符合需求的方案。
- 对于公司，员工的高效产出，自然能有更多的收益，这个收益包括时间、金钱等。
虽然有这么多好处，但是在日常开发的过程中，就会发现自己有时候会有点抗拒，当然，心情好与坏、和自己关系近与远在处理需求时的心理也会不同。
由此足以见得自己专业素养还不够，并且还无法做到对事不对人。有个小例子，之前公司需要在多个官网底部加几句声明，然后提需求的人在快下班的时候发给我消息。
而这个人之前还提过一些比较无厘头的需求，因此对他的印象不是很好，对于他的需求有点抗拒，并且还是临近下班时间，更加抗拒。
但是事情最终还是要完成的，当天就修改好了，中间还有点波折。在中途了解到，这个修改是为了应付某个审核，而这个审核对公司很重要。
若换位思考，那么就能设身处地的理解他们迫切的心情，我在处理这个需求时也能带入更好的感情，而不是负面情绪。
还有个小例子，产品提出很多用户在APP内的一个H5聊天界面中，经常会误操作返回上一页，返回后再回来就无法找到与他之前聊的用户了。
站在她的角度，她当然希望用户误操作返回后，再进入还能维持之前的聊天，提升用户体验，无可厚非。
但我们在评估后发现保持这种状态，会对现有系统做些修改，而现有系统内部逻辑错综复杂，担心改了之后就会出现新BUG，更加影响用户体验。
换位思考理解她的诉求后，提出了一个比较折中的方案，那就是在聊天界面，阻止返回上一页的手势，这样既能杜绝此类误操作，也不影响系统的稳定性。
二、工作优化
1）设计方案
最近看了一篇文章，文章中提到在开发流程中包含一个设计方案的阶段，位于需求评审之后，用于描述自己对于该需求的实现思路、模块划分等相关考虑的点，可供今后自己或他人查阅。
目的就是在编码前理清思路，整体架构，查缺补漏，作为他人或自己的技术参考文档。
自己在项目开发的过程中，也曽有过这样类似的想法，但没有作者那样写的系统，也没有在团队中落地。
基于文章中的设计方案，自己做了点修改。设计方案包括4个部分：需求、调研、实现和复盘。
- 需求：在设计方案的开头，列出相关人员（便于精确找人），需求信息和各类时间。
- 调研：功能的技术选型，对比不同方案的优缺点，适当取舍，形成一套适合当前场景的最优方案。
- 实现：需要考虑业务流程、数据结构、功能逻辑、异常处理、安全性能、组件复用等，可用任意方式表达自己的思路，例如伪代码、流程图或纯文字等。
- 复盘：内容可自由发挥，按照自己的实践，记录与需求相关的一切。
设计方案的难点在我看来有几个方面，第一个是对于我们这样的小公司，难以留出三四天专门做设计方案，我们的时间会被压缩。
第二个就是在实际开发中，会与文档有些出入，那么就得实时维护这份文档，程序员最烦的就是没有文档和让自己写文档了，所以维护文档是对自己的一个挑战。
第三个就是规范的贯彻，制订规范很简单，动动嘴敲敲键盘就行，但是真正的执行却会有很多阻力，其中最大的阻力就是人的惰性以及公司的客观情况。
2）E2E测试
之前一直在思考一个问题，就是页面搭建到很后面或者完成后，突然需要修改些逻辑，那该如何保证功能都正确呢？
靠人工测试，担心会有遗漏，所以得想个自动化的方式。最近正好看到E2E测试，这个就能为我解惑了。
我选取的是比较知名的Cypress框架，功能众多，文档也非常完善，只是都是英文的，不过读起来并不困难。
我并不需要达到多少的测试覆盖率，我只要保证主流程能够不出错，尤其是在后期做修修补补后，有一个可靠的方式告诉我们当前页面是正常的就行。
接下来就是在团队中推广了，得让团队成员切切实实的感受到，有了这个玩意儿能提升项目的质量，而并不是仅增加了工作量而已。
3）BFF
BFF字面意思是服务于前端的后端，我的理解就是数据聚合层。我们组在维护一个后台管理系统，会频繁的与数据库交互。
过去为了增删改查会写大量的对应接口，并且还需要在Model、Service、Router三层写不同的代码逻辑，吃力不讨好。
为了节约开发时间，构思通用接口，并付诸于实际项目中。虽然简化了Router和Service部分，但其实就是将该部分的代码迁移到了前端页面中。
这里有一点小隐患，因为目前我们组的成员是全栈维护，所以知道数据库ORM的语法规则，若前后端分离，那就不可取了，并且工作量其实是从后端转移到了前端。
虽然时间是节约了一些，但是后端的代码却暴露在了前端，维护性方面下降了不少，于是想到了BFF。
首先查看了许多已经在运行的成功案例，有些是基于GraphQL重新封装的系统，有些是定制化的系统。经过三天的仔细权衡对比后，决定自己定制化。
主要考虑了两方面，一方面是改造成本，如果基于GraphQL的一些封装库（例如Type-GraphQL、apollo、Prisma等）来设计系统的话，那势必需要了解这些的库的方方面面，并且还需要将其集成到已经的结构中。
另一方面是使用成本，系统完成后是给人用的，不能太复杂，为了避免让使用人员来适应这套系统，最方便的就是将之前的开发流程修改成配置化。
BFF的实现逻辑由后端定义，并且⽆需重构，也不必后端配合改造与联调。
这套系统完成后，会真真切切地影响之前的开发流程，例如不必单独写接口文档，并且可以随时在系统中调试，而不必借助postman调试。
具体的实现可参考此文。
4）需求遗漏
这两天有个活动要上线，但是在上线前一天，才发现遗漏了一个支付需求。
此时离上线已经没有几个小时了，产品经理当机立断，做了降级处理。
虽然临时方案敲定了，但是这个事件背后，还是有需要我们反思的地方。
当时接到这个活动时，粗略看了下，和之前的活动差不多，于是就直接交给了之前的开发人员。
她在看了这个需求后，表示可以沿用之前的逻辑，没过多久就完成了这个活动，提测交给QA。
大家都大意了，潜意识中都以为这次的需求和之前差不多，于是就漏了一个比较麻烦的功能，才出现了开场时的窘境。
那么经过这次事件后，我再一次的完善了与产品的协作规范，要求至少有两个人确认最终的产品文档，罗列功能。
5）AST
AST就是抽象语法树，这个缩写我在很早之前就听说了，最近听一些视频分享，讲某某技术如何实现的，就提到借助AST实现了一套规则语法。
然后之前在构思通用接口时，找到了一套开源系统，其中也提到根据AST自定义了一套规则。
这说明在设计一套系统时，了解AST的话，可以创造更多的可能。正好在V站上看到个帖子，问如何学习编译原理，按照网友们的推荐，我搜了几个视频。
看了哈工大编译原理的前面几个视频，还能理解，后面越看越闷，涉及到许多的数学原理，虽然每个视频很短小，但是我的理解已经有点跟不上了。
后面突然想到之前用过的一个模板引擎：mustache.js，它的代码只有600多行，但是自定义了语法和解析器，学习它的原理，有助于理解形成AST的词法分析和语法分析。
在拜读了多篇网上的源码分析后，了解到mustache.js会先通过正则将模板字符串分割成各种类型的token，然后再将这些token与传入的数据组合，根据规定的语法渲染HTML。
其中token包含type（类型，例如#、^等），text（匹配值），start（起始索引）和end（结束索引）。我这边讲的比较简短，其实内部包括context.js、scanner.js、writer.js等模块。
posted on
