话说回来，我最近在搞的那个小工具，刚开始就我一个人瞎捣鼓。那会儿更新日志这玩意儿，根本没当回事儿，随手写两句就得了。什么“改了个小bug”，“加了个按钮”，糊弄自己嘛反正自己知道就
本站为89游戏官网游戏攻略分站，89游戏每日更新热门游戏，下载请前往主站地址:www.gm89.me
结果，项目稍微一复杂起来，又拉了两个朋友进来帮忙。好家伙，灾难开始了。大家写日志那叫一个五花八门，有的人写得跟写诗一样，什么“优化了用户体验的感性交互逻辑”。我一看，这到底改了还有人写得跟代码注释一样，“提交：修复了#101的空指针异常”。普通用户谁看得懂这鬼东西？更别提我过一个月自己回头看，都得挠头半天，这更新日志压根儿就没法用了，完全是浪费时间。
我们是怎么开始动手改的？
我当时就火了，这不成，得立个规矩。我赶紧跑去网上查那些大厂的更新日志都是怎么搞的。翻了一圈，发现很多标准都太复杂了，什么`Conventional Commits`，看得我头晕，不适合咱们这种小团队，执行成本太高了。
我琢磨着，这日志最核心的作用就俩：第一，让用户知道他能得到啥新东西；第二，让我自己知道，到底是谁、啥时候、改了什么。只要能达到这两个目的，简单点没关系。于是我拍脑袋，决定把写日志这事儿拆成三个最实用的技巧，定个规矩，以后都照着这个来。
技巧一：分门别类，说清楚你动了哪块蛋糕
以前大家就是一坨文字。现在我要求，日志必须先写个“标签”，告诉大家这回更新的性质。这叫“分类”。
- 新增：加了新功能，以前没有的。
- 修复：改了bug，程序以前跑不起来或者跑错了。
- 优化/改进：功能没变，但变快了，变好看了，或者后台的运行效率提高了。
你看，光是加了这三类，日志一下就干净多了。以前那个“改了个小bug”，现在就得写成“[修复] 登录框在安卓10上的闪退问题”。一目了然，谁都明白。
技巧二：别扯技术，直接说人话，说价值
这是个大问题。技术人员老喜欢写自己干了啥技术活。我要求大家，甭管你写了多少行代码，日志里要体现的是“用户感觉到了什么”。
举个例子，我把后端的API接口重构了。以前的日志可能写“重构了v2版本的用户服务RESTful接口”。现在不行，你得写“[优化] 个人设置页面的加载速度提升了三倍，等待时间大大缩短。” 这么一写，用户看得开心，我这个做产品的也知道这回更新的意义在哪里。
这个技巧用起来，就是逼着我们跳出自己的技术圈子，用客户的视角去审视自己干的活儿，特别实用，对大家都有好处。
技巧三：动词开头，像发号施令一样简洁有力
第三个技巧是关于“语气”的。以前的日志，有写“我们修复了...”的，有写“已新增...”的，五花八门的语态。这看起来就很拖沓。
我定了个规矩，日志描述必须用动词开头，使用祈使句（命令句）的语气，就像你在给程序下命令一样。比如：
- “增加”而不是“新增了”
- “修复”而不是“已修复”
- “优化”而不是“对...进行了优化”
这样写出来，所有的日志条目都是统一的，简洁、有力、不废话。你看最终的日志就是这样式的：“[新增] 支持批量上传图片功能。[修复] 聊天界面偶尔出现的卡顿问题。[优化] 启动速度加快了。”
我把这三个小技巧，也就是这套简单规矩，整理成了不到一百字的文档，扔到项目群里，让所有人执行。刚开始大家有点不习惯，但执行了两周之后，效果简直立竿见影。以前乱七八糟的日志，现在变得非常工整，我自己维护项目的效率都高了一大截。所以说，解决问题，不一定非要用大而全的框架，有时候，定几个咱们自己能舒服执行的小规矩，反而更管用！
