从催逼盯，到串推破的进化；从点线面，到突破认知的格局；做认为对的事，心态定乾坤。

数据保存是Web端工具的基础功能，一般在产品和技术框架设计之初就已经确定了数据保存的方式，后续不太会频繁更改。

正因为如此，在日常需求迭代中，设计师很容易忽略数据保存的过程，也很少质疑当前的保存机制是否合理，但是当需要设计新模块或产品时就会对保存有疑惑。

此外，保存也是一个受技术限制较大的领域，设计师需要对保存的技术类型有基础认知，因为它会影响保存生效的逻辑和交互形式。 本文将会基于个人经验，从设计表现和技术实现的角度聊聊Web端工具的数据保存。

SaaS业务设计本质上属于B端产品设计， 但是房企业务因行业属性的独特性也带来了设计层面的差异性。笔者将自己在房产业务的设计心路分享跟大家，一方面希望帮助大家一定程度上了解面向大型B端地产客户的SaaS业务，另一方面也希望从“设计支撑”及“设计赋能”2个维度为大家带来新鲜的视角。

接口自动化是一种能提高服务回归效率，保证服务稳定性的重要方式。但是对很多做接口自动化的测试来说，往往痛苦大于快乐。主要问题还是在于接口自动化的校验。

写校验成本较高。很多接口响应字段可能非常多，结构体复杂，要做到详细校验编写成本很高。而越详细的校验，维护成本也越高。测试数据的变动，开发的改造，往往能让人崩溃。

校验不够详细。很多接口case为了急于求成没有写返回校验，或者校验深度不够，这会导致接口自动化流于形式，不能发挥真正的作用；

基于此，希望有一个快速编写接口响应校验的方法，要求简单、便捷、有效、可维护性高。

本以为接口自动化大家都在做，通用的响应校验网上应该有很多现成的，但是找了下却没有找到满意的。通用的json校验有，但是接口响应未必都是json格式的。DeepDiff在功能上基本满足要求，但是它是python的，而本人需要的是java的。

基于此，就考虑自己封装出一个基于java的通用的接口响应校验方法，降低接口响应校验的编写和维护成本。

对于以技术为核心竞争力的公司，往往会存在一些技术科研或技术实验室的团队，在主产品稳定后，避免不了要将实验室研究的其他技术进行孵化，衍生出新的产品来扩展新市场，完善公司更大的版图。技术创新通常分为2类，一类是成熟技术的改革，另一类是新兴技术的诞生，其中成熟技术的改革在一般公司更为普遍。

Litmus由测试效能开发，用于检测代码质量的平台。

Litmus支持代码异味、重复代码、复杂度、单元测试成功率、单元测试覆盖率等指标的获取。只有提测的代码质量越高，我们交付的产品的质量才有可能越高。

本文结合酷家乐施工图中台的实操案例，介绍规模化敏捷Scrum@Scale中Scrum of Scrums的协作经验。

本篇文章总结了交互新人在初工作过程中可能面临的疑惑与问题，并结合自身经历总结了相关设计经验，希望能够帮助新人设计师快速上手B端设计，游刃有余的应对工作中面临的各种机遇与挑战。

酷家乐有一套自己的UI自动化框架--Hades，其主要以puppeteer与playwright为核心进行了二次封装改造，并整合了许多酷家乐设计工具前端api。使得UI自动化对canvas交互、前端性能测试有比较好的支持。

除了能力上的扩展以外，Hades还有一个显著特点是:它将puppeteer/playwright中的api都代理到一个pyBell对象上，使得我们无需关注browser、page、element等对象，大大简化了用例编写的难度。

“抓重点”还是“好设计”？系统化思维辅助设计实现。

敏捷Scrum与传统的项目制运作能否双轨并行？来看看酷家乐如何用双轨运作来保障产研目标达成的。

在理解了服务端低代码平台设计实现的基础上，能够让大家更好的使用低代码平台扩展出更多的能力，丰富工具的打造，知道什么时候可以使用，如何使用。

kuta将来可能会走向内部开源，可以帮助kuta后来开发者对前面搭建的kuta架构有个高度概括的认识，在目前kuta中间层的基础上，扩展出更多的低代码能力，丰富目前kuta低代码平台所支持的功能。

现如今随着设备尺寸的多种多样，产品在设计过程中需要适配到更多尺寸，布局方案与栅格系统的搭配使用，可以很好的做到跨平台跨尺寸适配，极大的提升设计效率。之前有小伙伴分享过适配选型的文章中也提到过栅格，大家可以回顾一下【Web产品的适配设计选型】。

其实，绝大多数的设计师都知道栅格很重要，市面上很多企业级系统也都在用栅格系统去规范化信息内容的排版布局，但很多设计师直接面对结论大多是一知半解，自己做设计时有些无从下手。

作者浏览了大量文章结合工作中的经验总结分享给大家，希望能帮助理解栅格系统的本质，并能举一反三应用在产品设计中，首先从基础的栅格系统解析开始吧。

随着酷家乐业务快速成长，用户对于服务的稳定性要求也越来越高，再加上业务复杂度与日俱增，发生线上故障时，由于缺失合理预案、研发人员缺少应急经验，各种报警满天飞，导致自乱阵脚，延长故障持续时间，导致故障无法快速止血。

系统是否健壮？是否有完善且合理的应急预案？研发人员是否掌握基础应急止血能力？能否根据问题现状快速定位出故障根因？等等一系列问题需要有合理的手段和方法，早于线上故障发生前，进行锻炼和验证。

什么是研发效能？如何对研发效能进行度量？

这些是我们在产研效能改进及提升过程中会碰到的一个基础性问题，不同的理论提出了不同的思路，我们从需求角度提出了一些效能度量的思路，并在酷家乐选取了随机的敏捷组进行了小范围的验证，具体见下文。

在UI自动化的运行过程中，截取图片，对当前图片进行处理，定位&校验元素。