一、日常问题

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-GraphQLapolloPrisma等)来设计系统的话,那势必需要了解这些的库的方方面面,并且还需要将其集成到已经的结构中。

  另一方面是使用成本,系统完成后是给人用的,不能太复杂,为了避免让使用人员来适应这套系统,最方便的就是将之前的开发流程修改成配置化。

  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 2021-10-25 08:15  咖啡机(K.F.J)  阅读(8956)  评论(12编辑  收藏  举报