拼多多三面

工作中，尤其是研发侧，要谨慎地跟客户沟通。有的客户比较急，你说一个功能在开发，他可能天天就催你，导致大家加班加点 反而不如说此功能暂不支持。有一个更加含糊其辞的回答毕竟开发顺序的优先级是产品定的

调试代码确实挺容易焦虑的，一下午弄个BUG弄不出来很让人难受，记得当时搞32小车，左边轮子一直不跑，只有右边轮子跑，来来回回搞代码结果到最后发现Cubmax忘配置左边轮子了，调代码调烦了我就听听歌，点杯奶茶要不就是外卖好好吃一顿，吃完基本就好很多了，去外面再溜达一会儿消消食就差不多了

你是一个幸运儿，你过五关斩六将，拿到了大厂实习offer。你对性能优化了如指掌，你对锁和高并发倒背如流。你怀揣着满满的业务理解，希望在未来的几个月大展宏图。你的mentor经验丰富，组内的业务朝气蓬勃。你接到了第一个需求（怀揣着激动），你以为是设计xxx模块，优化xxx接口，定睛一看——为xxx功能编写单测！……开个玩笑，其实单测没那么可怕，它早已成为每个实习生入职的“必修课”。在大厂项目中，单元测试往往是新手最早接触、也最容易上手的一部分工作。原因主要有下面几点：一方面，大厂的项目庞大复杂，服务动辄数十个模块联动，启动一次应用可能就需要几分钟，甚至还要拉起一整套依赖服务。如果每改一行代码都靠本地全量启动来验证功能，不仅效率低下，还极容易被各种依赖卡住；另一方面，一个功能在真实环境中往往依赖多个组件，比如远程服务调用、消息中间件、定时任务调度、数据库读写等，很多逻辑在本地调试阶段难以构造出完整链路。这时候，单元测试就像是一把“放大镜”+“模拟器”，让开发者可以聚焦在某一个方法、某一个功能点上，通过精心构造输入、模拟依赖、验证输出，快速高效地完成逻辑验证。还有一点，这一点和我们相关性较强——借助单元测试可以帮我们更好的熟悉相关链路，因为实际在编写单元测试的时候你就会发现，不熟悉代码逻辑，单测就只能依靠伟大的ai大人了——你还得为对错战战兢兢。单测介绍单测，全称单元测试，就是对代码中的最小功能单元——通常是类或方法——进行测试，确保它们在各种输入条件下都能得到正确的输出。与集成测试不同，单测给我最大的感觉是隔离环境和快速见效。通过使用模拟对象（如 Mockito ）、断言库、Junit等框架，开发者可以非常精细地验证一个方法在特定边界条件、异常路径、依赖出错等场景下的行为。举个例子：一个订单处理函数可能依赖库存服务和用户服务，如果每次测试都要先确保库存服务可用、用户服务响应正常，测试效率将大打折扣；但用单测，你可以通过 mock 技术让库存服务“假装返回库存充足”，让用户服务“假装认证成功”，你要测的只剩核心业务逻辑本身。指导原则自动、独立、可重复执行边界值测试、正确的输入、与设计文档结合、强制错误信息输入（输入非法数据，得到预期的结果）哪些需要编写单测1. 底层模块，出了问题难以察觉，影响很广2. 自动化和手工测试成本高，难以模拟边界条件3. 重逻辑和规则的计算，而非流程编排和模块组装注意：一切跨类跨系统的测试都不是单元测试ps：实习以来，靠着单测多次查出潜在的bug（lz用的是mockito库），现在已经完全适应手写单测了

阿里巴巴杭州云谷园区真的超级新 超级大 一整个园区都是阿里云的每天刷卡(刷脸)上班跟上学一样 基本每天上下班都是同事 和一些上海的大厂还不一样“与世隔绝”但是随之而来的问题就是每天通勤很不方便 我基本每天上下班需要70分钟左右工作时间/工作强度这个相信大部分人很关心!我们组基本是早9:30晚8:00这样 观察下来园区基本也都是这个时间 基本能cover掉80%人的上下班时间周五基本 6-7点就可以下班了 且阿里是不打卡的理论上10点前到都无所谓 而且中午有一个半小时的休息时间 我基本都会在楼下吃个饭找个地方睡觉 等待下午干活(工作强度我觉得还是比较大的 虽然没有说网上那种加班到很晚 但是大家很...