入职前三个月,投入了超过 1/3 的时间帮助主管招聘,跟阿里蚂蚁做监控的同学轮番聊、找熟人介绍并在微信群里发广告、沟通或接触了近百人。进入面试流程的有十多个人,进入终面的4个人、最终有2个人顺利入职(一个人在其他部门),当时一共超两千人的基础架构大部门、每双月公开通晒“招人光荣榜”,个人荣获了第五名、并获得了一个小米电纸书的奖品,整个APM团队也只有我榜上有名。
入职不久、上级大前端团队开始组织发行<架构前端双月刊>,我担任了我们APM团队的“接口人”角色,平时跟进各期的稿件“收集对接或review宣传”任务。在期刊的第五期、轮到我们APM团队“制作刊文并做宣发”,刊文要求有最近半年原创的涵盖各个子主题的共计14篇文章。我作为负责人:架构前端双月刊>
开篇提到我入职后负责“前端监控平台” Slardar web,这个产品在我入职之前半年多(约2021年8月)有过一次全新改版、而且当时产品理念也是比较先进的,其中一大亮点是抄了 Datadog 的 Sessions Explorer 功能、改名叫数据探索。但是产品的整体信息结构跟阿里或其他外部的监控平台很不一样,这点对有经验的监控人来说、可能很快会能理解,但当时作为领域新人的我、却有很大的困惑。
比如为什么“JS/性能/API请求/静态资源”等监控类型和这个“数据探索”综合性功能、在信息结构上是平行的?虽然产品上有互相的链接跳转、但也没有文档说明他们之间的关系,其实有不少新用户也有类似的疑惑、不能非常直观地理解这里的逻辑性。又看了一下改版之前的产品,发现这是综合考虑到“B端产品交互风格的渐进延续性、以及用户的教育成本或接受度”等因素后的一个折中的结果。
但时至今日个人仍然觉得,虽然 “抄了个好功能、但没抄出好产品”,当时即便不做大的信息结构变化、也能有更合理的产品设计。但很遗憾的是这种能体现 产品匠心 的时机已经错过,虽然想做优化 但排不上优先级、也很难让别人感受到价值。
除了产品信息结构对新人不友好外、雪上加霜的就是文档写的不太及格(程序员都不太爱写文档~是真的),这个产品因为是前端在负责、只是在大的改版阶段才有专门的产品经理跟进,改版上线后就没有专门的产品经理了。我接手后、就担当起了产品经理职责,优化文档、变身最主要的oncall(客服)负责人、参与几大业务线的bp(需求对接)。
我做了一个产品经理应该做的工作,而且也拿到了 文档易用性、oncall数量减少 等不错的结果数据,并且对工作过程、也做了比较详细的文档记录。从过程到结果都证明了自己的付出和能力,但这个事情的价值、可能更多只是锦上添花。
虽然对 产品各处细节的打磨 看起来应该是专业产品经理的责任,但实际是需要专业前端来做的。 专业的产品经理、因为可能没有前端背景,更多是把控产品整体的设计、在大的产品改版或跨产品统一功能设计上体现价值。
除了兼职产品经理外,我作为业务和产品的owner、还要承担加倍的全面的责任和工作内容,比如:
其实上述的这些工作,回头看相当于一个人、同时承担了 “产品经理 + 一线研发 + 团队半个管理者 + 破局” 的几重责任和任务,整个过程真的是又累又难!但其中最难的就是“破局”责任了。面对这么个复杂的产品,我作为这个领域的新人、一开始难免理解不深,后来发现当时的产品阶段已经是比较成熟的 (这个跟之前负责这块的产品经理也有过交流和印证)、就更加的感到压力巨大。
后来经过更多的了解才知道,在我入职的前两个月、之前负责这个产品的 资深的前后端 同学都离开了、剩下的都是工作4年内的年轻人接手各个子模块。在去年初、负责这块的后端一线同学“离职或转岗”走了两个人,去年九月、我主管的主管(整个监控的总负责人)也转岗到了其他团队、随后两个产品经理也转岗走了。除了 剧烈的人事变动 外、这个产品的体验当时也比较 “糟糕”,因为公司给的服务器资源不太够以及其他代码或设计的原因(后端换人也频繁),经常出现页面查询报错或是误报问题、带来了大量的oncall,后端搞了接近一年的“稳定性建设”、才慢慢有少许好转。
具体到前端和产品建设上,主管希望我做“Issue管理”功能、给产品带来新的亮点或破局,我也充分调研了app监控以及外部竞品、发现这个功能存在很强的“模糊地带”,而且实际效果都不够理想,大家也都 没有很好的或一致的设计方案、甚至没有比较好的量化目标,想做的彻底或有明显效果、要涉及到现有 产品底层逻辑和产品设计上 比较大的变化。先是和团队内以及后端合作等同学密集沟通多轮技术方案,又经过比较“波折”(如下解释)的PRD设计和开发的过程,最终落地了两期功能、并和产品QA等协作同学制定了推广方案。
如上个人承担多重责任、要兼顾投入精力到多个地方,而在这个功能上只能投入1/3左右的时间。
这个功能的 产品PRD 设计稿 研发 都要自己做。综合考虑落地可行性和成本等,功能在最终的页面上没有体现非常明显的变化。产品目标的预期和对齐沟通没有特别到位 (包括主管和他的上级)
作为字节新人,遇到很多比如 “工具平台繁多且上手复杂、有关联的其他功能有许多旧缺陷要修复、其他高优需求插入打乱原本的开发节奏计划、英语沟通效率较低” 等等意想不到问题。
很多时候做成事、尤其是 “破局” 这种很难的事,一定是需要天时地利人和的。至今也 思考了好多次 ,首先自己在监控领域的能力和经验需要更好外、其实还是有巨大的客观困难无法解决,这个功能本身的难度以及协作中各方(小组同学/产品经理/后端)对这个功能看法和目标在内心里比较难一致。对当时甚至是现在来说、这都是一个不可能在短期做出亮眼成果的功能(长期会有结果/但资源不到位),我个人后来对业务理解越来越深后、并且基于客观条件可行性、思考规划一些可能更有价值和ROI也较高的事情:
这些事情在前边几个月里、只能处在脑暴和讨论阶段,也需要拆分成阶段性目标任务、才可能得到资源支持来落地。 后来(去年八月末)调整工作内容、我去支持“后端监控-报警模块”的前端开发。我觉得这样刚好也能深入了解下后端监控是怎么玩的,当时就抱着简单浓厚的学习心态、投身其中。后来发现后端监控业务本身也遇到了破局瓶颈,而且积累了大量的历史缺陷和历史代码债。需要干大量的脏活累活来填坑、同时不断有新的优化类需求,以致几乎无暇有学习时间、难免对后端监控的理解深度不够。后来了解到这块的前端支撑同学近一年换了三个人、后端大主管也转岗走了,原来有个实习生已经给了转正机会、也不来入职了。
网上有人写 “字节一年 人间三年” 的文章,因为字节的组织非常不透明、所以我只了解身边人的工作强度,其实因人而异(工作年限/事情大小/亲疏关系)、也不是每个人都这么累。具体到我个人是处在一个被“全方位严要求”考验的角色定位上、却又遇到了极度困难的客观环境,就出现了那种极度的“身心俱疲”的感受。但我觉得这归根到底是 “管理和信任” 的问题,是涉及和身边所有合作的人、特别是和主管之间的双向问题,而合作中的每个人其实都是管理者、我借助反思这段经历的过程 也特意思考总结了 如何做一个好的管理者。
]]>没有把问题聊透,总是点到为止。(可能是个人风格问题,比如开需求会的后端主管就会深入把问题说透)
没有过程,只制造惊喜的结果。(过程中没有阶段性的对齐、没有明确的标准、不发表自己明确的看法)
对人的信任和考验、平衡的不好,用人也疑。
公司对 leader 的最高要求,可能体现在业务或技术“规划和破局”上,站在公司高层的利益角度、也很可能认为一线同学都是可随时替换的资源。所以在遇到下属和上级的矛盾时、一般都是下属利益受损,而 leader 一般只会因为大的业绩问题、才会承担责任,对人的管理上就算出问题、只要影响不恶劣、就都不是什么大问题。这也导致了很多在“人际方面”的问题,其实没有根本性解法、也没有客观公正的标准。那应该怎么做呢?
自己在工作的前六年、有几年就是跟着两位有“单纯”性格的主管,我很清楚的记得、当时直接顶撞过主管、并有工作细节没做到位的问题,但他们应该是欣赏我的踏实和努力、也就能包容我的不足之处。后来跟过一个后端主管,会跟我们敞开心扉聊事情、也是属于“率真实在”的人。 当然率真开朗的风格、肯定不是口无遮拦,而一般都是真诚不装、表里如一言行一致的,这大概就是人格魅力所在。
公司和下属都对主管有高要求和美好期望,但作为主管有时候也很难办,主管自身也有偏好和缺点,手上的好机会也只能留给少数的人、公平公正也比较难。对熟悉有偏爱的下属用着信任顺手、也是下属工作能力之一的体现,但也不能任人唯亲;有些不太喜欢的下属、可能解决过很大的问题、或者确实有过人的能力,那也应该尊重和善待;而那些不被偏爱、能力和贡献也比较一般的下属,就比较难受了。
下属的“产出多少”、是受主管评价和决定的!而我们的工作产出、不是计件制的标准化商品,如果没有过程的追踪只看结果、就很难准确衡量,也经常会因为业务阶段/问题难易不同、导致也没有和横向其他同学产出的可比性,这也都是主管面临的难题。
但最终处理好上下级关系、解决评价难题,其实不麻烦、沟通 可能就是终极武器:
升华一点说、大家都是管理者,无非是向上下左右管理的方向不同、但方法是可以通用的。越早修炼这个技能,对你的帮助就越及时越有效。
再深入本质,其实很多业务或工作产出问题、都产生自用人和管理的问题,知人善任、排兵布阵很重要。虽然实操起来产生效果确实非常难,但如果是一位真正好的管理者、就能解决这个难题。
]]>本文是内部分享的脱敏版本,由于团队内有国外同事、前十多分钟说英语。 整体内容比较多,前一部分做了手工翻译、后边内容翻译软件自动翻译。
最近在支撑后端监控产品 Argos 的开发,其中在 E2E 的建设上投入了不少精力。基于团队内 Apmplus、Slardar 前端监控产品之前的 E2E 实践经验,结合了 Argos 复杂的业务,并且改变了和 QA 同事的协作方式,进而总结出了一些新的经验。全篇分为两大块做介绍:
Based on the previous E2E practical experience of Apmplus, Slardar. We combined complex Argos business, and changed the way of collaboration with QA colleagues, then summarized some new experiences. The whole article is divided into two big blocks:
Argos 的线上发布流水线里已经配置了 cn/i18n/TTP 等环境的 e2e节点,原来节点跑的是“全量测试用例”、耗时过久而且机器容易出异常、经常会阻碍发布流程,做了一些优化:
Argos’ online release pipeline has been configured with e2e nodes on “cn/i18n/TTP” environments. The original nodes ran “full test cases”, which took too long and the machine was easy to exception and often blocked the release process. So we made some optimizations:
在前端开发中,我们经常复用代码,比如:
QA同学虽然是基于用户界面功能编写用例文档、但其文字描述也应该考虑到如上复用的场景,这样就能和实际运行的代码完全对应起来,也方便统计用例集的覆盖度。
In front-end development, we often reuse code, such as:
Although QA mates write use case docs based on user interface, their text descriptions should also take into account the above reuse scenarios, so that they can completely correspond to the actual running code, and it is also convenient to count the coverage of the use case.
新用例的编写、可以优先使用”用例录制工具”来提高效率,但一般情况下、生成的代码仍然需要经过修改后才能正式使用。录制用例之前需要进行前置环境配置,比如设置登录信息(通过 sso 或其他方式获取登录信息)。 用例录制功能主要 帮助生成 如下示例的“选择元素” 这部分代码:
await page.element({
choices: [
page.findByRole('option', { name: '生效中' }), // highest priority
{ css: '.arco-volc3-select-option:nth-child(1)' },
{ xpath: 'id("arco-volc3-select-popup-2")/div/div/li' }
]
}).click();
pagepass 测试框架是按照 choices
数组里选择器的顺序从高到低排优先级,即如果第一个选择器能命中、就会忽略剩余其他的。实践中需要注意:
data-testid
属性。如上代码示例、第三个选择器 xpath 是不可靠的,其中
arco-volc3-select-popup-2
这个 id 里的 2、很可能会在每次代码构建后被改变。另外有复杂但准确的解法,利用 arco(和antd类似) 组件在各类 popup 触发元素上提供的aria-controls
属性值。
Argos 的几大业务模块、前端页面上的交互功能差别较大:
特别是对于监控和日志业务模块,需要探索和解决 “数据的生成方案、数据覆盖度” 的问题。
深入到“数据细节”,比如很多模块都用到的 metrics 图表数据、一般由两部分构成:
其中 时序数据的“起止时间”需要很明确,这样才能构成一个“稳定可测试”的图形,才能通过 screenshotDiff 等功能、验证 图表渲染 是否正常。
实际演示两个用例文件:
按照“测试金字塔”理论模型建议,测试类型应该是 70% 的单元测试、20% 的集成测试和 10% 的 (UI)E2E 测试。这个模型最早追溯到2009年、那时候前后端代码是融合的开发模式,而且前端代码占比很小。所以它应该是以“前后端”所有代码作为基数、来建议不同类型的测试占比,而不是前端和后端分开的。 从 前后端 代码的功能角度看:
这么看这个模型的话,其实是完全针对后端设计,只有处在塔尖的 E2E 需要涉及到 前端页面 时,才产生一点点关联。
上图来自 testingjavascript 可能是比较适合前端代码的测试理论,它引入了“静态检查”工具、来替代一部分的单测代码,另外不同于后端、前端代码 的构成可能更加多样。
综上,因为“UI组件本身的交互功能、业务数据的处理”都已被单测等测试类型覆盖到。剩下 “UI + 数据” 的 integration 测试、其实就可以由 E2E 测试来完成。
不管是哪种类型的测试金字塔,一般都有个共识:上层是对下层的一个补充,即如果上一层发现了错误、下层没发现,应该写一个低层级测试去覆盖这个错误。
很容易找到怎么写有效的“单测”,比如:
写 E2E case代码时、也应该遵守上述指导原则。另外 E2E 是综合性测试,在开始写代码之前:
不管是单测还是E2E、写出有效的测试,能让投入的时间回报最大化;尽量减少你在测试中投入的精力,并最大化测试提供的好处。
和之前团队内 E2E 实践相比,这次最大的进步之一是合作模式上。我们逐步把“写case”的工作交还给了QA同学,而前端来负责兜底解决环境运行等其他问题。经过一段时间的实践,证明出了更大的收益。
当然因为 QA 同学没掌握专业的前端技术,用例代码的架构和抽象上做的不够好、但影响不大 可以被 CR 修正。
不同的测试类型有不同的责任边界,而E2E测试需要用线上真实的数据进行测试、涉及到前后端数据库各系统,是可以真正验证应用程序可行性的测试、有着更高的置信度。
另外有相关经验的同学会发现,在“写测试用例”的过程中、就能发现被测应用的许多缺陷或优化点,有时候甚至比测试运行过程中发现的问题更多更重要。
我们在编写用例时就发现了比如 “页面元素层级不对、部分数据未在页面上展示出来” 等比较明显的问题。也发现了复杂的问题:比如页面展示的内容是由“多个串行或并行请求“返回的结果决定,但他们到达时间不同、展示出来不同的结果,这不符合预期。
我们现在提倡“测试左移、监控左移”等各种概念,都是为了达到“问题左移”的目的,最终不让问题出现在用户面前。
]]>因为量大且难、导致了不少非技术问题,宝宝心里苦… (缺少能真理解的人)
我个人之前一直认为日志也是“生产力”产品,就像 Mac 电脑、Office 软件等。但在上次跟同事聊到这个产品有没有可能卖出去的时候、想到了另一个词“管理工具”,瞬间就觉得这个词套在“周日报”这个产品上很贴切。周日报如果只是起到“信息同步”作用的话,它就不能算是生产力工具、反而变成是有“负向”作用的解决行政任务的管理工具。
因为这个产品的 PRD 毕竟是产品团队写的,产品的价值对错、我其实不必负主要责任。
本文主要还是介绍下技术方面的一些结果。其中“编辑页面”的截图
另附“查看页面”的截图
如果是重度的周日报用户,写完一篇周报很可能需要花至少一小时、那么过程中“书写”体验就至关重要了。与此类似的就是我们写一篇文档的体验,所以、我认为周日报是“在线文档”的一个比较典型的场景化应用,并且拥有文档的基础必备功能(当然不像 office 或 腾讯文档 这类专业文档有更多丰富功能)。另外我们附带了业务特色,比如与GTS工作台的”人员/钉群/邮箱/消息”、协同域”项目/事项”等做了关联和打通。以下是其总体架构图:
从架构图上乍一看东西好像不多,但其 复杂度 比一般的应用要高很多。除了设计上的复杂性之外,也遇到了很难的各类专项问题。
因为要支持可配置的页面模板和区块,所以数据结构设计上就需要很多的嵌套和关联 这也导致了更多的工作量,数据结构设计具体如下:
tpls -> pages -> nodes -> sections -> tasks -> extInfo
)嵌套的数据结构;tplID_pageID_sectionID
标记为全局 projID
传给其他 sections -> tasks
projId 变动后需再刷新数据;数据结构的设计是起到核心基础架构作用的,在这之上就是各类“专项”问题。
这个大概是“最复杂”的专项问题了,涉及到 保存的“场景、策略、内容、冲突” 各方面。我们的编辑页面 URL 主要有两个参数 templateId 和 id 其值都是唯一数,比如 https://xxx/worklog/editor?id=81e7365bffbd494caa7283cd12ab8e45&templateId=1b1db88bd08245f2b860bb8d802fdd68 而保存过程的可见变化就体现在 URL 参数里,以下做详细介绍。
一、保存的场景:
二、保存的策略:
useEffect
和保存的 Submit
函数里这个值就有新旧区别。需要在旧数据保存成功后再更新数据、监听保存的结果。三、保存的内容:
四、保存的冲突:
同一个编辑页面,在PC或移动端里”多开“时、需要内容过期策略。操作场景比如:
这就需要有一个”锁“的策略,加锁(没有解锁)的核心逻辑是:
因为没有解锁的操作,一个页面“一旦过期”、就无法再把页面内容保存成功,不能自动解除过期(可以刷新页面)。
在实现锁的功能后,我们遇到了个 断网又联网 的情况下出现了页面过期的问题、这个尤其值得说一说。这个问题非常难发现、同时又非常难排查,经过多次梳理才搞清楚了情况!
断网时后端 save 接口返回失败,前端因此没收到 save 后返回的 lockVersion 值,就把下次要传给后端的 lockVersion 参数设为了 undefined 。这时如果还是断网状态、虽然每隔 30s 会再调用一次 save 但也没问题、因为到不了服务端、也不会调用成功。而如果再联网、那么调用 save 就能到达服务端,此时服务端发现参数 lockVersion 是 undefined、就把 save 后的返回值里 lockVersion 设为了 null,这时前端把本地 lockVersion 更新为后端返回的 null,等下次前端再调用时、相应就传了
lockVersion: null
给后端。而后端要求 lockVersion 是必填,但实际收到了 null 就返回了 页面过期 的错误码。
上边描述还原的是当时排查问题的过程、看着还是比较绕的,总结一下就是:
这个事情的影响还是非常大的,因为我们的用户一般用的都是笔记本、还有很多出差或赶飞机的同事,“断网再自动联网”的情况很常见。碰到这情况用户就纳闷:我也没多开新页面、怎么周报写着写着就提示“页面过期”了…?!(页面过期会有补救措施、确保用户的内容不会丢失)。虽然发现问题原因后、很容易就解决了,但这个问题真是太难了!
解决完了这诡异的断网问题后,不禁深感这种“在线文档”的坑之大。看来对于一个更加完善的在线文档产品来说,支持前端的“离线编辑和存储”是必需的功能。但这显然又带来了更多要解决的问题、比如联网后怎么同步后端数据、差异怎么解决…
我们现在不支持离线、导致还有个现存问题:在第一次自动调用保存接口之前写的内容、如果不手动保存直接关掉页面、那就全没了。也许你会说浏览器不是有 beforeunload
事件可以监听吗?但问题来了:一是浏览器每次都会弹出“是否关闭”的模态框、体验很不好,二是即便调用保存接口、也不能阻止用户在保存成功前就关闭了页面、导致很可能没保存成功。
可见这个保存问题,在有时间有精力了、还是需要彻底解决才行!
我们的富文本编辑器使用的是钉钉文档的底层编辑器,首先它的功能是很强大的、但由于我们产品一个页面存在多个编辑器实例,导致了一些额外成本和问题。
至此,我们周日报的主要技术和功能点已介绍完毕,我们回到主题之二、讨论下周日报的“父亲” – 在线文档,应该怎么做?
如一开始就提到,个人认为周日报这个产品是在线文档的一个场景化应用,前边介绍的技术实现和问题里、抛开有业务特色的部分外,其他的在在线文档里都会有体现。但从数据结构和多富文本实例等纬度看周日报,我们最初也把它当成一个 大的复杂的表单 而不是在线文档。所以,真正的在线文档是什么样,最重要的能力有哪些,和表单的区别在哪里?
以上两种顶层数据结构的设计方式,实质有非常大的架构区别、由此也带来很大的技术实现差别。而真正的在线文档、应该采用前一种设计方式,这也是和表单的一个明显区别。前一种设计方式,能带来 充分 的灵活性,比如:
国外的 Notion / coda 文档就支持上述功能,这也能让其瞬间变身简单无代码(低代码)平台。但也正因为有这么强大灵活的特性,导致开发成本、相比 表单型文档 也高了很多。
除了网页上简单输入框不需要编辑器外、其他文档产品必然需要一个编辑器,所以编辑器可能是普通文档产品最重要的功能,但其实它只是在线文档的一个最基础功能。市面上有各种各样的编辑器,理想情况下,在线文档也不应该绑定到某个编辑器上、而是可以把它当做可替换的轮子。
从这个角度看、在线文档最重要的能力应该是 “在线、协同”,落到实际、有在线就会有离线、有协同就会有冲突,所以必然也要解决“离线、冲突” 这些背后的问题。这些能力的实际功能体现就是“自动保存、离线存储、版本记录、协同编辑”等。
这也很容易联想到、我们日常使用的 Git 工具/代码IDE编辑器 等就有这方面的一些功能,我们大多数时间都是在本地做 git commit / save 等操作、离线状态下做了很多事情,只有少数时间做 git push / conflict 的协同。再推导下、在线文档的底层能力、如果不只是单单的离线存储、而能有更完善的“离线操作”支持,那就更好了。另外这些能力能否抽象出来、是否可移植到其他应用呢?我认为很有可能。
近几年国外的 notion/coda 和国内的“腾讯文档/飞书/语雀/钉钉文档”等文档型产品大力发展,导致这本来属于垂直领域的产品却似乎走向了大众、并大有要替代 office 的趋势。另外这些产品都往基于浏览器的 SaaS 方向发展,导致对前端的需求非常强烈、前端在此方向从业人员也越来越多。
过去一年个人作为“独立”参与者、对此也是百感交集,最大的体会仍然是:这是一个大坑、适合有规模的专业团队干,而不适合一般的业务团队来做。一年多前开发的架构图设计工具、也是类似的情况。这么说最大的原因是“投入巨大、收益单一”、投入产出比不足。
当然也许是因为个人目前格局不够、理解狭隘了。
不管怎么样,我相信没有白走的路!感谢这个宝贵的经历。
]]>这些特点都是双刃剑,在天时地利人和时会促成奇迹、但更多情景下造成的是不尽人意。这些都可以总结到 “期望”与“改变” 这两个词上,有了美好的期望、就需要去改变现状。而实际上变坏容易变好很难,另外是对于可塑性逐渐变弱的成年人、改变的难度也大。比如:
期望自己“侃侃而谈/活跃氛围/话题中心”提升软能力,确实也努力了、但说出的话还常常是索然无味…
期望人际人脉明显改善,但经常是有心无力…
期望能突破职业瓶颈,但发现障碍不断…
还有最常见的,眼看自己的体重逐年上升、赘肉越来越多,但真能成功减肥还是非常难、于是还是做一个快乐的胖子好了… 梦想没有行动就是空想,但确实也行动了、怎么还是收效甚微呢?这就与 “难度 / 客观环境 / 外在评价” 有关了。
认清这些原因后,就没办法了吗?不是的,这时候 “聪明的行动”和“控制期望” 是可能解决问题的。
这时候要想清楚的是要 花“多少”时间去改进“哪些”缺点 ?“新木桶新论”有建议
人的精力是有限的,不应把一生的重点放在不断改进自己的缺点,把自己培养成“完人”。而应经常分析发现自己的优点,并持续不断发扬光大,形成自己独特的优势,成为某一个方面的专家、强人。“木桶理论”是不太适合人的发展的,成功的捷径在于尽早发现自己的“长板”,然后无限聚焦。长板不断加长而成为栋梁,短板就成为点缀。
这么看,承认自己不完美、也不去追求事事完美,才是正确的选择。不管是周围人对你的期望、还是自己对自己的期望,都需要得到 控制,有基本的做与不做的判断、再以可达到为基础、寻找突破点,在期望范围内做到最好。
这篇文字、是经过了持续“近半年”的严酷加班、却并没有拿到应得的结果,才认真做的反思总结。其实很早就听主管说“控制预期”类似的话,但之前太傻、都没真正把这放在心上,傻傻的相信自己总是能“超出期望”。
现实工作当中,无论是 996 还是 KPI 压力,从公司和资本层面的目的:一是要充分“压榨”你的劳动时间,二是“尽快”产出“惊人”成果。
所以,学会「不过度承诺、聪明地做事」一是自己不至太累,二是也能给人「稳稳的信任」。另外面对现实、认识到人的局限性,不可盲目、头脑发热地认为自己与众不同、能创造非凡,要明白大的成就、有很多是机缘巧合比个人努力更重要。从利己的角度看,工作都是一阵子,思考自身长远价值,努力发现并相信自己的优势、借此做到极致。
]]>时间节点:
- 12.10 交互稿+功能评审: 后端“逻辑细节”是重点;前端只能感知到大的模块、判断能不能做。
- 12.15 视觉稿+细节评审: 后端“更加细化”出接口;前端细化功能点、产出“系分+粗略估时”。
- 12.18 产出 API 文档(前后端);前端“应用名、代码模块/组件抽象、mock 数据”等初步工作。
- 12.28 经过 12h x 6d 的全时投入开发、堆完了主要功能点(上日常),但“前端功能链路”未完全通顺、代码“基础架构”有漏洞。
- 12.31 新增两位同学共投入 8h x 2d 支援“头像、点赞、自动保存、局部模板”几个独立功能。
- 2021.1.5 主链路功能顺畅、底层架构更优、视觉还原度接近高保真版本。但仍有重要细节问题、bug 等。
- 2021.1.29 完成“富文本编辑器”、“移动端读的适配”、“选用户组”、“数据重复”、“体验细节进一步优化”等新的功能点或优化点。
细节拆解:
- 显然的:
- 联动筛选、列表分页、头像、已读未读/点赞/删除/修改;增删改/排序、多种模板、多种状态。
- 接口个数 30+,依赖三方工具库 5+,实际代码 5000+ 行、改动代码 1000+ 行(手写/非生成/非三方)。
- 三方的:
- 接口联调、环境部署、依赖三方组件问题、代码被改坏、测试问题和 edge-case。
- 产品细节要求高 & 认为的完成度(视觉还原/交互细节)不一样 & 未明确的功能点。
- 复杂的:
- 搜索->选择项目->查任务;弹窗的触发条件、位置。
- 富文本工具栏、特殊字符、图片上传。自动保存、数据重复。
- 困难的:
- 六层(
tpls -> pages -> nodes -> sections -> tasks -> extInfo
)嵌套的数据结构;- 数据关联:
tplID_pageID_sectionID
标记为全局projID
传给其他sections -> tasks
projId 变动后需再刷新数据;- 数据状态:“初始态、编辑态、提交态” 跨态部分同步、部分修改;
- 数据与事件:既有耦合又有分离,不能完全数据驱动。
- 架构的 “思考和设计 & 重构优化 & 踩坑” 成本。
- 举例:
- 带搜索的 TODO-list,可以加自定义 todo、也可以从搜索结果的 list 里选一个、但需要把“已选”的 todo、从搜索结果排除掉。
- 添加大模块、添加事项,有编程或点按钮方式、结果都是改变全局 pageData,怎么确定“只是”通过按钮触发?并且在 setPageData hooks 设置成功> 后?再保存到服务端。
- 几乎「同时」多次提交数据、后端处理是否有问题?
- 在列表项有“移动/增删”时,确保手动维护好 react key,并且持续唯一。
- react hooks 模式下同一 state 在 visibilitychange 事件和正常数据流 结果不一致。
- 性能和体验:一次性添加多个事项,需要多个“富文本实例”初始化、同时发送多个请求,导致页面卡顿。
从以上细节描述中不难看出,开发时间非常紧张(但这大概是所有项目共性)、交互复杂度高(虽然最复杂的编辑器还是三方组件),最终也导致了进度延期(其实是最初时间评估不合理)。
我们知道“开发全过程”就像画画(轮廓-线条-着色)、对应几个不同阶段,“POC”版本(主功能跑通/打牢基础) -> “低保真”版本(全功能跑通/交互视觉大致完善) -> “高保真”版本 -> 最终版本,阶段之间也难免有额外时间损耗。
大阶段内的工作再细化后,就能大致总结出一个公式: 总工作量(时间) ~= 业务功能点数量 x 单位工作量(时间),其中 “业务功能点数量 ~= 数据操作个数(增删改查)”,“单位工作量 ~= 复杂度(复用点/细节点/难点/未知点/维护难度)”。
也能据此公式区分出产品的 “简单与复杂”:
以上看到 “复杂产品” 大多都是专业性很强的“垂直”产品,偏“工具”性质、容易被替代,解决的是常见业务链路里的“单点”需求/问题。开发过程中有「大量耗时」的复杂点,导致产出“速度慢”、成果“不明显”;并不是上线就结束、而往往是漫长维护和优化的开始。另外因为真正对这些复杂点有经验的人又很少、不明真相的就肯定会疑问:这明明看起来不麻烦、怎么花这么多时间?缺乏真正的同理心。而在业务团队里,大多是讲究 “短平快”/“快速拿结果”,做这些很容易就吃力不讨好了。
富交互产品的困境在哪儿?在于“富交互”产生了高成本,但带来的价值究竟有多大?值不值得投入,适合什么样的团队投入?却没有明确的答案。于个人而言,从 4 月初开始做的「架构图设计器」到最近一个多月做的「日志文档」这两个富交互产品(期间对团队其他产品也临时支持时间一个多月),导致自己是每天 11~12h 的满负荷工作,身心俱疲、头也常常蒙蒙作痛。当然也正是这从未有过的这么痛的经历后、才『真正』体验到了这类产品的巨大潜藏成本,然而这就是仅有的“收获”吗?
]]>面对这些痛点问题、我们探索了一种解决方案,即 不用画的标准架构图工具、支持“快速做出标准的架构图”,可点击查看 简要操作视频 图示 (访问需注册)。
每个平台工具都有自己的初心和特点,接着就 “与使用 PPT 的区别”、“数据”、“技术实现” 三个方面做一些介绍。
我们大多数人都是用 PPT 画技术架构图,从零开始画的操作流程一般是这样的:
可以看到、这个过程中花费在“画/设计”上的时间是非常多的,除非确实很享受像画画这样艺术创作过程、不然这么繁琐的过程基本都会感到头大。
当然、现在也有能从“手绘草图”再经过 AI 艺术化生成网页或 PPT 的工具、但基本还是需要人工再调整,这就像是你使用一个现成的“PPT模板”做修改一样、仍然少不了“画”这个动作。
此外数据方面也极易有问题,比如术语的大小写准确性、是否是官方合规的图片图标、数据是否老旧过时,你很难确保找到的数据的准确性。
因此,我们希望通过自动布局的方式、免去了“画”这个动作;通过默认只给符合官方设计规范的 颜色/字号/字体 来确保最低的一致性效果;通过 规范标准 的数据来保证准确性,并能分析数据使用情况;通过 导出 PPT 功能、支持你使用强大的 PPT 来进一步做美化。
大家知道 PPT 在创作的 自由度 上几乎已达到了极致,但自由和规范天然有矛盾、就像技术的 应用框架 组件库 等等也都是在自由代码的基础上做一些符合最佳实践的规范化限制。因此“做规范”这个行为是普适的、这样主要问题就落在怎么取得“规范和自由”的平衡上,也许这个问题永远不能彻底解决、只需瞄准目标 持续做适度的调整取舍。
大家常说,一切业务数据化、数据像石油一样重要,同样我们最大的出发点和目的就是为了沉淀“结构化的标准数据”。我们主动接入各种官方数据源,目前已接入阿里云云知平台上的云产品数据源,后续也会支持用户接入自己的数据源。
说数据离不开场景,具体到交付上、除了云产品的 “价格/规格/用量” 等基础数据外,还有比如 “项目工时/成本/人员能力” 等人力数据、“项目和资源计划/问题跟踪/验收报告/过程纪要”等过程数据、“PRD文档/系统设计/模板代码/脚手架/服务接口”等研发数据。
这么多数据必然需要以 office 套件(Word Excel PPT)、图(xmind viso uml)、视频 等各种各样的载体来呈现,但也正是这种分散的载体及不同的数据格式、导致了数据之间难以链接、互通和分析,更遗憾的是、确实还没有一个通用的办法能解决这个问题。
抛开通用性、考虑特定的不同数据场景,还是能有一些解决办法。比如架构设计器、支持操作链路上的类似“下钻/上卷”后,便能做到上下游数据的链接。再通过支持 “图文互转” 等方式、就能达成特定数据内容的互通。但只有 架构图设计器 肯定还不够,还需要 “标准(PRD)文档” 等更多的工具、一起覆盖到尽可能多的场景中,才可能得以全面解决问题。
就像石油应用在交通工具上、会产生巨大的价值;数据也一样、适时出现在需要的场景中才真正有用。这么看来、数据的价值很大程度取决于数据组织上,具体做法是需要持续探索突破。
下图就是用我们这个工具,只用 5 分钟就做来的架构图!
这里主要想分享上图“绘图功能”技术块 why 的部分、即在技术选型上所做的调研和思考,暂不讲一个个单点的技术细节问题。快速的做架构图、主要就是免去“画”的过程,这种交互的刻意简单化后、也造成更多的可选技术方案:
1、使用开源的支持 dom 模块拖拽的组件;2、考虑直接复用 乐高(宜搭)的 页面搭建 引擎;3、使用一种基于 svg/canvas 实现的图形库。
我们知道第 1、2 种基于 dom 的方式、在细节控制上虽然能满足要求,但针对灵活的图形变换场景,代码实现上十分别扭、也难以具备扩展性。最终采用第 3 种方式、即通用的 web 画图工具做法,但也有代价、就是要反过来限制其过大的灵活性。接着调研了公司内外各种图形库,最终选择了 mxGraph 这个库。
这个选择有几点考虑,其一有名的 draw.io / online.visual-paradigm / processon 等产品的底层就是这个库、在多平台的导入导出图文件等场景互通上有优势。它的前身是 Java 版本的 jGraph,其代码整体架构、模块划分、变量命名、功能丰富度、兼容性、可扩展性等方面都做的非常不错。它就像 变形金刚或是一堆积木、能支持充分的自定义,也给出了许多玩法示例。在实际应用中、按我们的产品目标:需要把它的 “自由拖拽、自由调整尺寸、自由拷贝粘贴、灵活添加节点” 等等过于自由的功能做限制,又基于它已有的 “历史操作、导入导出” 等做了功能增强,后续还要添加 “协同编辑” 等高级功能。
基于灵活图形库的另一个原因,是以后可能需要支持灵活拖拽式“画”图的功能、比如形状随性的部署图。但画与不画都是表象、数据才是灵魂,即便支持了画、导致看起来与 draw.io 的交互区别不大,但重要的还是数据。另外自由度高了之后,也有机会覆盖更广阔的业务场景和用户人群。比如,
从产品能力上不能贸然做决定、但技术上的前瞻性需要有,有能力为充分的灵活度提供快速支持。
目前为止、我们这个也许是基于 mxGraph.js 之上做的 “自定义” 功能最多的产品,而且后续准备剥离业务数据后、开源出去,希望会对可能用到的人有一些帮助作用。技术上还是不得不提自研问题,自底向上的技术自研固然好,即便造的是重复轮子、好处是带来了完全的控制,但现阶段最重要的投入不能是在这里。
“不用画”是做架构图操作过程中能快速提效的核心、随之而来也确实需要牺牲一定的灵活度。透过表面的画布来看看本质,最终是为了解决什么问题,我们认为是规范性和结构化数据。总之,欢迎大家试用、提建议!
]]>同时阿里云发现大多数中大型客户、需要的不只是“云平台”等底层纯技术的产品,更需要阿里的电商/新零售/金融等方面先进的业务解决方案,比如阿里的“业务中台、数据中台”架构方案。整个社会各行业也从原来的“互联网+”进化到的“数字化转型”的浪潮里。而阿里云的交付技术团队,就是一群身处第一线、直面客户遇到的各类问题,帮助客户尽量顺利地完成数字化转型的前锋队员。
但就如战斗冲锋不能光靠人力和勇气,而是更需要先进的各类武器装备、战略战术。所以交付技术部需要做“交付平台、工具”,制定“标准化”的交付流程,设计和沉淀“可复用”的技术方案,攻坚重大项目里“个性化”的难题和优化技术架构,从客户现场孵化创新产品形成团队的价值闭环。参照黄金圈法则,当拥有了内在动力、即知道了 why,那 how 和 what 就能比较自然呈现了。这两个月,我们的第一步就是深入客户项目做调研、感受最实际的痛点。
首先通过看了一些项目代码,发现了一些常见问题:代码库没文档,多套代码库,因为权限问题页面运行不起来,钉钉联系不到代码作者(ISV),前端代码技术栈混乱落后、jQuery 等老技术栈居多,代码趋于腐化。针对这个初步情况,设计了一些调研问题:
一、通用调查
二、技术专项 (附评分 - 10分最高)
三、工程方案
我们的调研问题,已经尽力覆盖前端研发各个环节、各个场景,在整理和细化过程中、也自然成为解决方案所需要的基础数据。再对这些数据进行“评分、打标、归类”,就有可能自动化地产出各类场景化前端解决方案。
当然首先要探索可扩展的 “分层次评分体系”、“打标方式”,比如:
可能问题: 怎么保证“评分”的客观和公正性?是任何人都可以打分?分数的意义作用。
具体做法
虽然经过了许多思考、但以上解法其实并不完善,可行性和效果其实都很难说、而且确实还没有实际的产出。最后附上在这个过程里的思考图示。
]]>虽然书上道理没错,但其实所有技巧、努力和机遇等都是取得成就的必要条件、但大多不是充分条件。所以大概每个行业里知名和成功人士可能都只是该行业人数的百分之一左右…其他绝大多数是普通人、虽然也学习和付出了很多,但籍籍无名、没做出响当当的成就。
另外,最近公司内外有一些热议的关键词:996、拧螺丝、非我莫属… 目的都是在鼓励员工要拼命、要担当。大家其实都能理解其中意思,但也发出了很多不同的声音、没有内在动力做出这样的表现。
以上提到的“保持动机”、“反对 996” 引出这里想说的第一个问题,当然也是最根本的问题,就是经常被提到的“初心/源动力”。
十九大把“不忘初心,牢记使命”作为中国共产党的时代主题,这个国家层面的意思还是很容易理解的。不过联系到个人、那句经典语录”不忘初心、方得始终“可能更实在!
在白纸一张的年纪时对“不忘初心”除了觉得很有道理外基本是没有实质感受的。直到遇到些大大小小的当时觉得也是发愿自初心的行动(这里指工作),慢慢的走了样、逐渐地坚持不下去、甚至有不少拿不到结果而无奈结束,就会反思、当初想做这个事的初心是假的?这个事情本来就不适合做?甚至怀疑选这个职业是错的?能否笃定的把这个职业变成愿意为之终生奋斗的事业?就像从开始的 “初生牛犊不怕虎” 变成了 “拔剑四顾心茫然” 的状态。但最终是需要从茫然中走出去、这要反思回顾下自己过去的一些关键节点。
大到终极的人生梦想、算是初心;小到一件短期的工作事项、也能有初心。你的终极梦想是什么?这个梦想是怎么产生的?在走向她的过程中有没有变化过?有没有怀疑过是否正确?实在难以实现怎么办?也许很容易把短期的想法当长期的梦想,也许这一切问题都没有标准答案。也许反过来想想、如果在“错误”的道路上坚持走了一生,那或许这不是错误、而这就是你正确的理想吧。
动机和初心更多是听从内心、自己把握,而日常工作事务的方方面面基本都是一项项技能、就可以通过”刻意练习“而获得。在大篇幅讨论了”初心“之后、最终落到实际的日常工作中来。
这里不讨论具体的某些技术、技术学习方法,而是讨论一些都会遇到的问题。
我们经常说到的”以人成事 以事聚人“应该是互为因果的关系、但最终还是要围绕“事”出发。日常工作的事、就是一块块业务、一个个产品,能牢牢把握住事、把事做好,结果肯定也就好。
公司团队阵型也是基于此的体现,除了少数的“基础设施/支撑型”横向团队外、大多都是垂直的业务型团队。团队老板就是“业务架构师”,也是团队里业务和产品真正的 owner。
个人觉得:某产品创始人(或pd) 是 80% 的 owner;主开发、运营是 60% 的 owner;其他角色不是 owner。
但因为奖罚机制的存在,团队里各个角色都会想法设法做好分内/外之事,总结一些做法参考:
我们经常会碰到很多会做事的同事、除了专业能力外也有更好的为人处事软能力,往往不用太费力、也能把他负责环节的事情做好。
我们可能不是专业 PM,但都要面对“需求管理”这个问题。工作中各种事情都可以看做是需求,常见的比如:
长期业务支持,最好有计划、比如月度计划,主要方便 review、对焦主要目标或最终目标。这不是为了“每月/每周”一定完成什么,因为实际会经常遇到项目延期中止、穿插进其他需求等变化。
中短期的项目/产品开发,是我们日常工作的主旋律。而项目类型和要求的多样、也带来了不一样的问题,这类似普遍都说到的“效能”(时间和质量)问题,有没有好的规划是解决问题的关键。
有规划:比如部门“财年计划”列的事、都会画出各个里程碑的详细时间点和相应完成度,问题拆解的好、结果也可预期,也就几乎没有效能问题。
无规划:业务线里很多事情不是在财年初就能明确规划好的,这就很容易引起不同程度的效能问题。
问题“少”的:比如半年内有规划;产品发布日期相对宽松或可变,每个阶段时间都还算充裕、各个环节有时间打磨好,总体可以按部就班的展开,真正完善好了再发布。
问题“多”的:比如意外的运营需求、重大 bug 等;可能一会儿来一个,但发布日期是确定的、开发周期是倒排的,由于压榨了各个环节的时间、几乎肯定会导致完成质量不好。
还有一些“优先级突然拔高”的需求插进来,结果是打乱计划、容易导致整体目标难完成。
通常项目研发流程中,PD 管理需求和串业务流程,PM (一般项目后端开发同学兼任) 协调各方确定各个环节的时间点。比如关键时间点有:产品 PRD 定稿;设计定稿;完成开发、设计和产品验收通过、自测完成(提测)。项目的“时间风险”是最常见的问题,原因无外乎 “需求变更”、“评估不准确”、“实际投入度/熟练度”,具体来说:
关于“评估不准确”、“实际投入度/熟练度” 这是相关联的重要问题,也举一些实例:
回到标题和前半部门说的“初心”,大多人可能就是通过“刻意练习”对某个事情达到很擅长的程度、再有持续正向反馈的加成,那么这个事就变成了他的“初心”,慢慢变成了明确的人生目标。
但其实人生也可以有多个不相关的大目标,有时候不能一条道走到黑,而且精彩之处也是体现在变化中。这个过程中需要把握住什么机会,可能要经过很纠结的深思熟虑、也可能是一念之差,最终就改变了人生的航道。
最后活在当下,每一段正在走的人生旅程、大概都会遇到上边说的日常工作的问题和解法,这些观察、总结、记录,就是对这段旅程的热爱的体现吧。
]]>从功能上看,常用 SDK 的复杂度一般不算高、主要提供一些常见刚需功能,比如登录、分享、支付、人脸识别等。当然这不能一概而论,比如很多云平台的 SDK 功能就更多更复杂,甚至已经超出了 SDK 这个范畴。从结果上看,SDK 除了要达到“易用”、“可扩展”、“兼容性” 等通用的软件标准外,由于天生需要运行在第三方软件环境里,额外必须要确保“独立可运行”、“不与其他代码产生冲突”、“性能优良”等结果。
上边泛泛而谈的介绍过后,这里针对 js SDK 从几个方面讨论下如何做。
首先 js 的运行环境可以有很多,服务端 js (node) 跟 Java 类似、运行在纯粹定制化的环境里。服务端的 SDK 大多也是比较纯粹的功能开发、相对来说是比较“简单”的;另外使用方式也较统一、比如大都需要申请 AccessKey
/ SecretKey
再调用,这里不具体讨论。
而前端 js 比较统一的运行在各种浏览器或 Webview 里,相应 SDK 表现形式也就是 js 或 css,在这些环境里运行时会遇到哪些问题?我们详细列举下:
async
charset
等标记。总之、需要充分了解你的代码运行环境,这是在编写 SDK 之前要做的最基本准备。
环境问题很大程度上决定 SDK 的整体架构方式。接下来就是开发过程可能遇到的问题,仍然会有很多、也分几类讨论:
另外,一套 sdk 如果需要同时支持 mobile 和 pc 端,核心重逻辑都相同、区别只是在交互方式上,那么代码应该怎么维护?当然最好是放到一个仓库里维护,共享能复用的组件、有差别的地方分别放到 /m
和 /pc
的目录里,在构建时、需要写脚本生成不同平台的 dist 代码。如果不是单页应用,而是多页部署、那还需要判断 URL 里区分 m 或 pc 来分别加载不同页面即可。
支付宝登录安全验证 sdk 如下图
这个 sdk 就是使用原生 js 开发,除了依赖轻量级的 reqwest 请求库和 i18n 国际化处理库外、其他无任何三方依赖。另外必须要能支持灵活部署、避免和宿主代码冲突,也要确保体积不能大、性能不能差。
特别是对于比较复杂的 SDK、综合开发难度其实远大于普通的业务开发。不过,不管前端还是后端 SDK,面临的问题可能各不相同,但解决的思路往往能互相借鉴,希望后续能有更多深入思考和总结。
]]>