预感这个帖子要水深火热了, 但是看到理智的声音被点了最多的红心还是让我感到欣慰.

说一些新手司机对“快与慢”的误区好了

这个慢, 不是指你的“绝对速度慢”, 而是指你的“动作要慢”:
1. 旁边有其他车辆时, 要慢慢做动作, 留给其他车反应时间. 包括但不限于加速, 减速, 掉头, 变道等任何导致车辆改变轨迹的动作
2. 前方视线不佳时, 要减速或把脚放在刹车踏板上, 留给自己充足的时间观察路况. 包括但不限于雨雾天气时, 大车 /路牌 /围栏 /桥墩遮挡视野时


当然这个快, 也不是指你的“绝对速度快”, 而是指多数时候你至少应该“和旁边的车差不多快”.

新手司机有一个普遍的误区就是“慢即安全”. 事实上, 在你自以为“很安全”时, 往往你才是这条路上的唯一的危险因素.

想象一下, 一台慢车在其他车眼里和会移动的路障是没什么区别. 更别说频繁按着喇叭呼啸而过的车辆往往会使新手更加惊慌失措, 进一步提高事故的可能性.

其实 xmind 官方是有提供导图转图片的工具, 可以尝试用来组织一下自己的工作流:

https://github.com/xmindltd/xmindmark

另外关于 mermaid 语法复杂, 打乱思维的问题, 这个库也提供了专门用于描述“思维导图”的 DSL, 语法设计上也尽可能地简洁明了.

感兴趣的话可以加个绿色软件细说: cGFycm90ZGFuY2U=

https://xmind.works/

网页版 xmind

我第一次用 mac 的时候就完全抛弃了鼠标, 除了长按拖拽操作比较磨指头...

直到我发现了三指拖拽, 这最后的问题也解决了.

七八个小时算什么? 我天天七八个小时不知道用多少年了

借老东家老板, 也是前 QQ 开发的比喻来总结一句话, 希望能对楼主有所帮助:

**VM 是"上帝之手", 替你包办了模型层 (M) 到视图层 (V) 的映射.**

至于"上帝之手"的实现是和具体运行时紧密相关的. 网页端, Android, iOS 都有各自不同的实现, 但在"上帝之手"的帮助下你可以将大多数都精力集中在"数据如何变更"上, 而不太需要操心"数据如何影响视图"

同 HTML 转 PDF.

试过用 Markdown, 但本质上也是先转 HTML 再转 PDF, 排版和样式受文档结构和渲染器影响很大, 没法控制细节.
试过用 Word 和 Pages, 发现要做出想要的排版需要付出的学习成本太高, 而且对我来说没什么可复用性, 一直没动力去学.
试过用 PS, 但是由于是基于像素的设计工具, 没有基于逻辑的布局框架, 被图层管理和逐像素调节的工作劝退了.

最后还是回到舒适区了, 毕竟不是天天靠做简历吃饭.
人生苦短, 高效工作, 快乐摸鱼~

笑死 重新定义"无效社交"🤣

@tangjiepc 大排量, 磨合期, 上坡多, 启停多, GPF, 车重高, 喜欢大脚油门刹车等等, 导致油耗上升的原因非常多.

另外并不是"好车"开起来就一定"舒服", 悬挂调校取向不同在行驶时的感受也会不同. 03 / 03+ 属于偏运动的调校, 在通过不平坦路面时传递到乘客的抖动会更多, 说得通俗点就是"很颠", 而汽车媒体们喜欢用的话术叫"路感清晰".

不过在这帖子里讨论这个有点偏题了...

2022 款 03+ 车主, 去年 11 月初提车到现在已经 8000+ 公里了. 简单说说使用体验.

优点就不说了, 网上都能很容易了解到, 各种汽车媒体把这辆车捧上天了, 我只列举一下缺点:

1. 后排乘坐体验不是很好. 原因有三: 本身作为 A 级车就不大的后排空间; 四驱传动轴导致较高的地台; 以及为了凸显"运动感"减配了后备箱隔音导致排气声浪入侵 (在运动 /赛道模式下尤为明显)
2. 油耗略高. 这是由于加大马力; 四驱传动效率损失; 加装了 GPF 三重 debuff 导致的. 佛系驾驶前提下, 实测纯高速工况油耗在百公里 7L 以下, 市内工况在 9L 到 10L 之间. 短途会去到 12L 或更高.
3. 和油耗不太匹配的油箱. 只有 50L 的容积, 按我每天通勤 50km 的使用强度大概一周多就要跑一趟油站.
4. 变速箱有点拖后腿. 激烈驾驶时换挡不及时, 2 挡齿比不太合理. 当然这是最不重要的一点, 日常驾驶几乎感受不到.
5. 炫燃金 03+ 车主有时会被认为是"鬼火少年"

如果这些缺点你都能接受, 那么 03+ 在这个价位的各种配置秒杀 30w-40w 级别的 B 级 C 级车了.

顺带一提: 当时我也考虑了奥迪 A3, 毕竟也是个 BBA, 开着有面子. 但是看到 A3 的前驱, 170+ 匹的孱弱动力, 再看看这边的四驱, 250+ 匹......毕竟国产之光

我觉得我们团队的做法不错, 可以参考一下:

1. 每个 mr 至少对应一个 issue.
2. 编码之前开一个空 mr, 在其中简述问题原因 /需求拆解 /解决思路, 组员之间 review 并讨论.
3. 编码完成后编辑 mr 内容, 加入测试部分内容(截图或视频), 确认改动是有效的.
4. review 代码改动.

这样做的好处在于别人 review 的时候大概知道你这个改动想干什么, 再去看代码脑子里能够有个总体脉络, 另外换个人来看 mr 里描述的思路和测试结果也容易发现考虑不周的地方.

坏处嘛...可能就是对书面表达能力有一定要求

红金宝

曾经也因为类似的原因开了一个 repo 专门记录工作中遇到的经典操作...

https://github.com/parrotdance/worst_code_I_saw

另外"看了几天我自己都写错了"真是太艹了