几个月前听过一个老同事说早期 lyft 来国内交流的时候，展示过他们强大的线下开发环境，所有的前后端服务都可以在同一台电脑上启动，颇为羡慕，正好最近陶师傅分享了 lyft 的线下环境方案 [https://eng.lyft.com/scaling-productivity-on-microservices-at-lyft-part-2-optimizing-for-fast-local-development-9f27a98b47ee] ，感觉参考价值挺大的。 先来定义一下问题：现在微服务架构在国内互联网公司已经普及了，互联网公司的主流程服务比较复杂，尽管已经尽最大努力进行解耦，改造过后还是会依赖几十至上百的外部服务 。这样导致的最大的问题是，业务研发在线下测试主流程服务极其困难。 如果你恰好在这样的环境工作，想一想，你在修改了主流程的代码之后，是不是没有办法在本地完成测试？是不是必须得把你的开发分支部署到远端的某个环境去？或者是不是必须部署到有 QA 维护的 Staging 环境才能开发 debug？

最近有意无意地看到三个分享，正好都是和优化相关的，看看不同领域对性能的不同关注点还是挺有意思的。 databend 的性能优化 [https://github.com/datafuselabs/datafuse-presentations/blob/master/meetup-20211203-performance-tuning-in-databend/performance-tuning-in-databend.pdf] databend 是一个对标 clickhouse 的数据库，他们的性能目标是要比 ck 快，会追求一些比较细节的代码优化。 gvisor 在蚂蚁的优化 [https://gvisor.dev/blog/2021/12/02/running-gvisor-in-production-at-scale-in-ant/

最近在面试的时候，和面试官说 A 家有比较先进的业务架构和基础设施，被人要求一一列举，一时语塞(这么多东西，我半小时实在给你说不完)，才想起来去年本来答应老东家的同事要总结一些两家的业务和基础设施之间的 diff，都鸽了快一年了。看来面试的时候是遭报应了，该还的债总是要还的。 正好去年也没做什么技术方面的总结，从 A 家离职半年有余，这个时间点总结一下去年一整年的学习成果还是稍微有一点必要的，等明年说不定就忘了。 业务 单元化 在前一家公司工作的时候，碰到过 A 家来的人说稳定性问题可以用单元化来解决，所以进了 A 家，单元化也是我重点关注的问题。 单元化的方案原理比较容易理解，用户 id 按照常数做

这本书第二部分讲的是文化，对于技术人员来说稍微有点无聊，不过决定我们在一家公司工作舒服不舒服的，其实主要就是这些文化内容，如果用这一部分里的内容去考核那些我们日常工作中的人，可能结果也会令人失望。 这一部分的内容可以看出 Google 和国内公司的文化有巨大的差异，对国内的工程师和 manager 来说，有一些思想有借鉴意义，而另一些只当参考即可(全信的话，你一定会被坑得很惨)。 软件开发要依赖团队协作 Google 内部的代码管理系统收到过很多人的需求，希望能把项目设置成 private，这个需求来自于很多人在项目写完之前，不想让别人看到自己的代码，这种心态是由于研发人员的不安全感。比如他们可能害怕： * 别人嘲笑你，这样的错误你都犯，和你的工作年限是不是匹配啊，可能你其实是个菜鸡 * 明明是自己想出来的 idea，但是最终却被别人抢去邀功了 对代码的“

这个是这本书的读书笔记，这本书总共有四个部分。 第一部分只有一章，所以可以水一篇，开心。 第一部分：论题 什么是软件工程 软件工程是随着时间的推移不停地对代码进行集成(Programming integrated over time)，这本书将软件项目分成两种，一种是 programming，一种是 software engineering，具体的区别： * programming 指短期任务，比如一次性的脚本，一次性的算法题目，学校里的项目等等；一种是 software enginnering，要考虑你的项目要长期存活，所以要认真地考虑“时间”这个要素对软件本身的影响。 * SE