日前旅游平台Booking.com公开了去年提高软体交付效率的关键秘诀，在短短不到一年时间，让旗下金融科技团队的交付能力提高了近2倍的效率，等於开发战力翻了一倍。
Booking.com在2022年中，成立了这个金融科技部门，负责内部各种金融流程开发，因为这个团队直接采用了公司5年前发展出来的技术架构，所提供的金融服务，在前端是一只只不同金融功能的单体式网页应用，而後端服务则是Java程式，也需要串接到不少第三方金融服务。
为了改善开发生产力，他们从2023年初开始用DORA指标追踪团队开发效率，尤其聚焦部署频率（DF）和变更准备时间（LTFC）。在2023年三月部署频率每月不到20次，而变更准备时间更是长达了30小时。
虽然这个数据已经远比台湾许多企业的DevOps能力好，根据我们去年CIO大调查，台湾半数大型企业关键应用每月部署次数不到5次，部署时间短则一天，长则好几天。
Booking.com高层对这个团队原有的开发效率高度不满意，想要找出拖慢效率的瓶颈。
分析後发现，第一个影响部署频率不佳的瓶颈是，他们的程式码难以理解，但是又很容易修改，工程师若不小心改错，得花好几周才能找出问题，如此一来，更让工程师不愿意改进。
後来，他们参考了一条童子军规则「要让露营地比你来的时候更乾净。」也就是看到有垃圾就马上清理，来帮下一组露营的人改善环境。在去年三月开始推动许多小规模的重构和推动测试自动化，进行程式码更新或修复问题时，也同时改善周边的程式码，来提高程式码品质，并且同步要求开发团队刻意花时间来解重构的题目，透过大量练习来提高重构技能。
虽然逐渐改善程式码可读性，但因为许多小型重构计画，去年六月发现，出现了大量合并请求，程式码审查时间成了新的瓶颈。他们转而一方面改采少量批次合并请求的策略，来减少每次审查时间，也要求工程师优先审查程式码，来减少相互等待的时间，在七月逐渐解决这个问题。
七月时，他们转向处理拖慢部署时间的痛点，当时要进行两次金丝雀部署和验证，每次部署涉及许多手动作业，部署时间至少得花40分钟，因为有些功能的金丝雀部署出错机率几乎是零，因此，他们决定导入自动化部署，将合并请求直接合并到主版本，直接部署到正式环境，而不用手动验证。
另外，还采取了一些自动化部署作为配套，像是良好的测试自动化机制、同侪程式码审查和小变更策略，一次不做大变更而是尽量采取多次小变更策略，一但程式码品质指标检测没有达标，也会自动回覆到旧版，来确保既有服务的稳定。
金融科技部门这个新作法将部分功能的部署时间从40分钟缩短到4分钟，也同步提高了DORA的部署频率和更新准备时间。八月时，部署次数甚至一度达到每月43次，整体的平均部署时间约1.3小时。
不过，在前端的单体式应用的交付效率仍旧难解，在去年八月时，这一类应用每月部署次数只有6～8次，每次平均准备时间长达2-3天。
Booking.com团队决定导入微前端（Micro Frontend）开发模式，把前端单体应用，改成类似微服务的前端模组，并改用JavaScript来开发用户端的网页应用。在九月导入微前端开发模式之後，明显改善了开发效率，但是他们却发现，另一个DORA指标的数值变差了，开发准备时间反而比预期来得更长。
Booking.com团队回头查看了过去一整个月的合并请求纪录，包括提交、评论、批准、合并和部署的各种统计资料才发现新的问题。因为微前端应用的合并请求审查流程，比平常前端应用的开发更复杂，因此，开发流程上需要金融科技部门外部的内部其他专家社群来审查和批准，每次审查都得等上很久。光在外部专家程式码批准这个阶段，平均就得等待17.1个小时。
後来，金融科技部门找来这群专家，讨论初多项优化审查流程的作法，自己也避免进行大量的批次部署，尽量采取小型合并请求的方式，才将批准时间缩短到8分钟。最後，到了去年十月，终於将这类单体式应用的变更准备时间大幅减少到14小时。
从年初每月20次部署、每次30小时事前准备时间，到年底十一月时缩短到每月40次部署，每次平均14小时。Booking.com的金融科技团队就是靠DORA指标的监控，找出了一个又一个的开发团队瓶颈，逐一解决，才能在不到一年，达到交付能力翻倍的成果。
Booking.com开发团队主管更强调，这个做法不只提高了效率，更带来了一种新的工作态度和方式，让开发团队聚焦於内部品质和尝试，看重长期绩效而非短期效益。
