Jimmy's Bloghttps://jimersylee.com/Recent content on Jimmy's BlogHugozh-cnMon, 22 Aug 2022 10:00:00 +080020200822-杭州永辉菜价https://jimersylee.com/posts/20200822-%E6%9D%AD%E5%B7%9E%E6%B0%B8%E8%BE%89%E8%8F%9C%E4%BB%B7/Mon, 22 Aug 2022 10:00:00 +0800https://jimersylee.com/posts/20200822-%E6%9D%AD%E5%B7%9E%E6%B0%B8%E8%BE%89%E8%8F%9C%E4%BB%B7/记录一下物价水平<link>https://jimersylee.com/posts/%E8%B0%B7%E6%AD%8C%E7%9A%84%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B-%E8%AF%BB%E5%90%8E%E6%84%9F/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://jimersylee.com/posts/%E8%B0%B7%E6%AD%8C%E7%9A%84%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B-%E8%AF%BB%E5%90%8E%E6%84%9F/</guid><description><h1 id="前言">前言</h1> <p>近期,阅读了&lt;<a href="https://u.jd.com/7ISYFMp">谷歌的软件工程</a>&gt;,记录一下.</p> <p>我对谷歌这家公司还是比较好奇和欣赏的,不管都是对于拉里佩奇,还是现在阿尔法特(谷歌母公司)的CEO 桑达尔·皮查伊, 个人都非常敬佩.毕竟都是有真正实力的大佬.</p> <p>谷歌运行着目前世界上最大的服务器集群,这个不容置疑.我个人也非常好奇,如此庞大的规模的机器,他们如何调度,如何监控,我们这种小公司是否有可以借鉴的地方.因此,当我发现这本书的时候,我觉得这就是我一直寻找的书.</p> <p>其实在这之前,我已经看过<a href="https://u.jd.com/7KSnc8z">&lt;Sre google运维解密&gt;</a>,收获良多,我的DevOps概念就是从这本书中学来的.个人在之后的工作中也引入了这套工作流程,砍掉了运维工程师,由开发自己负责从开发部署,持续运维监控的全流程,开发人员反馈良好,接触到了很多之前不可能接触到的生产服务器,积累了宝贵的线上故障处理经验,培养了项目主人公的感觉.</p> <p>以下为书籍内容的摘抄,仅供参考.</p> <h1 id="第一章">第一章</h1> <h2 id="失败奖励">失败奖励</h2> <p>在谷歌X部门——该部门负责研究自动驾驶汽车和通过热气球提供互联网接入等 &ldquo;登月计划&rdquo;——故意将失败次数纳入其激励系统。人们会想出一些稀奇古怪的想法，同事们也会受到积极的鼓励尽快实现它们。每个人都会得到奖励（甚至是竞争），看看他们能在一段固定的时间内反驳或否定多少观点。只有当一个概念真的不能在白板上被所有同行揭穿时，它才能进入早期原型。</p> <h2 id="无责的事后文化">无责的事后文化</h2> <p>在谷歌X部门——该部门负责研究自动驾驶汽车和通过热气球提供互联网接入等 &ldquo;登月计划&rdquo;——故意将失败次数纳入其激励系统。人们会想出一些稀奇古怪的想法，同事们也会受到积极的鼓励尽快实现它们。每个人都会得到奖励（甚至是竞争），看看他们能在一段固定的时间内反驳或否定多少观点。只有当一个概念真的不能在白板上被所有同行揭穿时，它才能进入早期原型。</p> <h2 id="谷歌味儿">谷歌味儿</h2> <p>谷歌最终解决了这个问题，明确定义了我们所说的“谷歌特质”（Googleyness）——我们所寻找的一套属性和行为，代表了强大的领导力，体现了 &ldquo;谦逊、尊重和信任&rdquo;：</p> <ul> <li><em>在模棱两可中茁壮成长</em> 即使在环境不断变化的情况下，也能处理相互冲突的信息或方向，建立共识，并对问题做出改进。</li> <li><em>重视反馈</em> 谦虚优雅地接受和给出反馈，理解反馈对个人（和团队）发展的价值。</li> <li><em>走出舒适区</em> 能够设定宏伟的目标并去追求，即使有来自他人的抵制或惰性。</li> <li><em>客户第一</em> 对谷歌产品的用户抱有同情和尊重，并追求符合其最佳利益的行动。</li> <li><em>关心团队</em> 对同事抱有同情心和尊重，并积极主动地帮助他们，提高团队凝聚力。</li> <li><em>做正确的事</em> 对自己所做的一切有强烈的主人感；愿意做出困难或不易的决定以保护团队和产品的完整。</li> </ul> <p><a href="https://www.notion.so/8a4678c8b20844dd9fe2543fe8a378a0?pvs=21">每个专家都曾经是菜鸟：一个组织的成功取决于其员工的成长和投入。</a></p> <p><a href="https://www.notion.so/4e666e67b8e94df5aff0e8046254d72d?pvs=21">离开营地时要比你发现时更干净</a></p> <h2 id="如何激励人们记录工作">如何激励人们记录工作</h2> <p>传统上，鼓励工程师记录他们的工作可能是困难的。编写文档需要消耗编码的时间和精力，而且这些工作所带来的好处并不直接，大部分是由其他人获益的。鉴于许多人可以从少数人的时间中获益，像这样的不对称权衡对整个组织来说是好的，但如果没有好的激励措施，鼓励这样的行为是很有挑战性的。我们在第57页的 &ldquo;激励和认可 &ldquo;一节中讨论了其中的一些结构性激励。</p> <h2 id="奖励方式">奖励方式</h2> <p>工作阶梯的期望是一种自上而下引导文化的方式，但文化也是自下而上形成的。在谷歌，同行奖金计划是我们拥抱自下而上文化的一种方式。同行奖金是一种货币奖励和正式认可，任何谷歌员工都可以将其授予任何其他谷歌员工，以表彰他们的超越性工作。例如，当Ravi将同行奖金发给Julia，因为她是一个邮件列表的顶级贡献者——定期回答问题，使许多读者受益，他公开承认她的知识共享工作及其对团队以外的影响。由于同行奖金是由员工驱动的，而不是由管理层驱动的，因此它们可以产生重要而强大的基层效应。</p> <h2 id="第三章-知识分享-内容提要">第三章 知识分享 内容提要</h2> <ul> <li>心理安全是培养知识共享环境的基础。</li> <li>从小事做起：问问题，把事情写下来。</li> <li>让人们可以很容易地从专家和有记录的参考资料中获得他们需要的帮助。</li> <li>在系统的层面上，鼓励和奖励那些花时间去教授和扩大他们的专业知识，而不仅仅是他们自己、他们的团队或他们的组织。</li> <li>没有什么灵丹妙药：增强知识共享文化需要多种策略的结合，而最适合你的组织的确切组合可能会随着时间的推移而改变。</li> </ul> <h2 id="第四章-公平工程">第四章 公平工程</h2> <ul> <li>偏见是默认的。</li> <li>多样性是正确设计综合用户群所必需的。</li> <li>包容性不仅对于改善代表不足的群体的招聘渠道至关重要，而且对于为所有人提供一个真正支持性的工作环境也至关重要。</li> <li>产品速度必须根据提供对所有用户真正有用的产品来评估。与其发布一个可能对某些用户造成伤害的产品，还不如放慢速度。</li> </ul> <h2 id="第六章-规模优先">第六章 规模优先</h2> <ul> <li>至此，假设我们已经知道了领导的本质，那么到底什么才能让你提升为一个真正优秀的管理者呢？这就是我们这里想要讨论的，我们称之为“管理上的三个总是”：始终保持决断力，始终保持离开，始终保持扩张。</li> </ul> <h2 id="第七章-测试工程效率">第七章 测试工程效率</h2> <ul> <li>如何测量软件过程 <ul> <li>在谷歌，我们使用目标/信号/指标（GSM/ goal signal metric）框架来指导指标创建。</li> <li><em>目标</em>是一个期望的最终结果。它是根据你希望在高层次上理解的内容来表述的，不应包含对具体测量方法的引用。。</li> <li><em>信号</em>是你如何知道你已经实现了最终结果。信号是我们<em>想要</em>衡量的东西，但它们本身可能是不可测量的。</li> <li><em>指标</em>是信号的代表。它是我们实际上可以测量的东西。它可能不是理想的测量，但它是我们认为足够接近的东西。</li> </ul> </li> </ul> <h2 id="第十章-文档">第十章 文档</h2> <ul> <li>工程师们越是把文档工作当作软件开发的必要任务之一，他们就越是不反感写文档的前期成本，也就越能获得长期的收益。此外，让文档工作变得更容易，可以减少这些前期成本。</li> <li>写文档的秘诀 <ul> <li>5W,who,what,when. where, why</li> <li>who: 文档受众</li> <li>what: 确定文档用途的内容</li> <li>when: 何时确定本文件的创建、审查或更新时间</li> <li>where: 文档应该放在哪里</li> <li>why: 设定文件的目的</li> </ul> </li> </ul> <h2 id="第十一章-测试概述">第十一章 测试概述</h2> <ul> <li>GWS的经验告诉我们的一个重要启示是，你不能仅仅依靠程序员的能力来避免产品缺陷。即使每个工程师只是偶尔写一些bug，当你有足够多的人在同一个项目上工作时，你也会被不断增长的缺陷列表所淹没。想象一下，一个假设的100人的团队，其工程师非常优秀，他们每个人每月只写一个bug。而这群了不起的工程师在每个工作日仍然会产生5个新的bug。更糟糕的是，在一个复杂的系统中，修复一个错误往往会导致另一个错误，因为工程师们会适配已知的bug并围绕它们编写代码。</li> </ul> <p>概要</p></description></item><item><title>20220823-<谷歌的软件工程>读后感https://jimersylee.com/posts/20220823-%E8%B0%B7%E6%AD%8C%E7%9A%84%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B%E8%AF%BB%E5%90%8E%E6%84%9F/Mon, 01 Jan 0001 00:00:00 +0000https://jimersylee.com/posts/20220823-%E8%B0%B7%E6%AD%8C%E7%9A%84%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B%E8%AF%BB%E5%90%8E%E6%84%9F/<h1 id="前言">前言</h1> <p>近期,阅读了&lt;<a href="https://u.jd.com/7ISYFMp">谷歌的软件工程</a>&gt;,记录一下.</p> <p>我对谷歌这家公司还是比较好奇和欣赏的,不管都是对于拉里佩奇,还是现在阿尔法特(谷歌母公司)的CEO 桑达尔·皮查伊, 个人都非常敬佩.毕竟都是有真正实力的大佬.</p> <p>谷歌运行着目前世界上最大的服务器集群,这个不容置疑.我个人也非常好奇,如此庞大的规模的机器,他们如何调度,如何监控,我们这种小公司是否有可以借鉴的地方.因此,当我发现这本书的时候,我觉得这就是我一直寻找的书.</p> <p>其实在这之前,我已经看过<a href="https://u.jd.com/7KSnc8z">&lt;Sre google运维解密&gt;</a>,收获良多,我的DevOps概念就是从这本书中学来的.个人在之后的工作中也引入了这套工作流程,砍掉了运维工程师,由开发自己负责从开发部署,持续运维监控的全流程,开发人员反馈良好,接触到了很多之前不可能接触到的生产服务器,积累了宝贵的线上故障处理经验,培养了项目主人公的感觉.</p> <p>以下为书籍内容的摘抄,仅供参考.</p> <h1 id="第一章">第一章</h1> <h2 id="失败奖励">失败奖励</h2> <p>在谷歌X部门——该部门负责研究自动驾驶汽车和通过热气球提供互联网接入等 &ldquo;登月计划&rdquo;——故意将失败次数纳入其激励系统。人们会想出一些稀奇古怪的想法，同事们也会受到积极的鼓励尽快实现它们。每个人都会得到奖励（甚至是竞争），看看他们能在一段固定的时间内反驳或否定多少观点。只有当一个概念真的不能在白板上被所有同行揭穿时，它才能进入早期原型。</p> <h2 id="无责的事后文化">无责的事后文化</h2> <p>在谷歌X部门——该部门负责研究自动驾驶汽车和通过热气球提供互联网接入等 &ldquo;登月计划&rdquo;——故意将失败次数纳入其激励系统。人们会想出一些稀奇古怪的想法，同事们也会受到积极的鼓励尽快实现它们。每个人都会得到奖励（甚至是竞争），看看他们能在一段固定的时间内反驳或否定多少观点。只有当一个概念真的不能在白板上被所有同行揭穿时，它才能进入早期原型。</p> <h2 id="谷歌味儿">谷歌味儿</h2> <p>谷歌最终解决了这个问题，明确定义了我们所说的“谷歌特质”（Googleyness）——我们所寻找的一套属性和行为，代表了强大的领导力，体现了 &ldquo;谦逊、尊重和信任&rdquo;：</p> <ul> <li><em>在模棱两可中茁壮成长</em> 即使在环境不断变化的情况下，也能处理相互冲突的信息或方向，建立共识，并对问题做出改进。</li> <li><em>重视反馈</em> 谦虚优雅地接受和给出反馈，理解反馈对个人（和团队）发展的价值。</li> <li><em>走出舒适区</em> 能够设定宏伟的目标并去追求，即使有来自他人的抵制或惰性。</li> <li><em>客户第一</em> 对谷歌产品的用户抱有同情和尊重，并追求符合其最佳利益的行动。</li> <li><em>关心团队</em> 对同事抱有同情心和尊重，并积极主动地帮助他们，提高团队凝聚力。</li> <li><em>做正确的事</em> 对自己所做的一切有强烈的主人感；愿意做出困难或不易的决定以保护团队和产品的完整。</li> </ul> <p><a href="https://www.notion.so/8a4678c8b20844dd9fe2543fe8a378a0?pvs=21">每个专家都曾经是菜鸟：一个组织的成功取决于其员工的成长和投入。</a></p> <p><a href="https://www.notion.so/4e666e67b8e94df5aff0e8046254d72d?pvs=21">离开营地时要比你发现时更干净</a></p> <h2 id="如何激励人们记录工作">如何激励人们记录工作</h2> <p>传统上，鼓励工程师记录他们的工作可能是困难的。编写文档需要消耗编码的时间和精力，而且这些工作所带来的好处并不直接，大部分是由其他人获益的。鉴于许多人可以从少数人的时间中获益，像这样的不对称权衡对整个组织来说是好的，但如果没有好的激励措施，鼓励这样的行为是很有挑战性的。我们在第57页的 &ldquo;激励和认可 &ldquo;一节中讨论了其中的一些结构性激励。</p> <h2 id="奖励方式">奖励方式</h2> <p>工作阶梯的期望是一种自上而下引导文化的方式，但文化也是自下而上形成的。在谷歌，同行奖金计划是我们拥抱自下而上文化的一种方式。同行奖金是一种货币奖励和正式认可，任何谷歌员工都可以将其授予任何其他谷歌员工，以表彰他们的超越性工作。例如，当Ravi将同行奖金发给Julia，因为她是一个邮件列表的顶级贡献者——定期回答问题，使许多读者受益，他公开承认她的知识共享工作及其对团队以外的影响。由于同行奖金是由员工驱动的，而不是由管理层驱动的，因此它们可以产生重要而强大的基层效应。</p> <h2 id="第三章-知识分享-内容提要">第三章 知识分享 内容提要</h2> <ul> <li>心理安全是培养知识共享环境的基础。</li> <li>从小事做起：问问题，把事情写下来。</li> <li>让人们可以很容易地从专家和有记录的参考资料中获得他们需要的帮助。</li> <li>在系统的层面上，鼓励和奖励那些花时间去教授和扩大他们的专业知识，而不仅仅是他们自己、他们的团队或他们的组织。</li> <li>没有什么灵丹妙药：增强知识共享文化需要多种策略的结合，而最适合你的组织的确切组合可能会随着时间的推移而改变。</li> </ul> <h2 id="第四章-公平工程">第四章 公平工程</h2> <ul> <li>偏见是默认的。</li> <li>多样性是正确设计综合用户群所必需的。</li> <li>包容性不仅对于改善代表不足的群体的招聘渠道至关重要，而且对于为所有人提供一个真正支持性的工作环境也至关重要。</li> <li>产品速度必须根据提供对所有用户真正有用的产品来评估。与其发布一个可能对某些用户造成伤害的产品，还不如放慢速度。</li> </ul> <h2 id="第六章-规模优先">第六章 规模优先</h2> <ul> <li>至此，假设我们已经知道了领导的本质，那么到底什么才能让你提升为一个真正优秀的管理者呢？这就是我们这里想要讨论的，我们称之为“管理上的三个总是”：始终保持决断力，始终保持离开，始终保持扩张。</li> </ul> <h2 id="第七章-测试工程效率">第七章 测试工程效率</h2> <ul> <li>如何测量软件过程 <ul> <li>在谷歌，我们使用目标/信号/指标（GSM/ goal signal metric）框架来指导指标创建。</li> <li><em>目标</em>是一个期望的最终结果。它是根据你希望在高层次上理解的内容来表述的，不应包含对具体测量方法的引用。。</li> <li><em>信号</em>是你如何知道你已经实现了最终结果。信号是我们<em>想要</em>衡量的东西，但它们本身可能是不可测量的。</li> <li><em>指标</em>是信号的代表。它是我们实际上可以测量的东西。它可能不是理想的测量，但它是我们认为足够接近的东西。</li> </ul> </li> </ul> <h2 id="第十章-文档">第十章 文档</h2> <ul> <li>工程师们越是把文档工作当作软件开发的必要任务之一，他们就越是不反感写文档的前期成本，也就越能获得长期的收益。此外，让文档工作变得更容易，可以减少这些前期成本。</li> <li>写文档的秘诀 <ul> <li>5W,who,what,when. where, why</li> <li>who: 文档受众</li> <li>what: 确定文档用途的内容</li> <li>when: 何时确定本文件的创建、审查或更新时间</li> <li>where: 文档应该放在哪里</li> <li>why: 设定文件的目的</li> </ul> </li> </ul> <h2 id="第十一章-测试概述">第十一章 测试概述</h2> <ul> <li>GWS的经验告诉我们的一个重要启示是，你不能仅仅依靠程序员的能力来避免产品缺陷。即使每个工程师只是偶尔写一些bug，当你有足够多的人在同一个项目上工作时，你也会被不断增长的缺陷列表所淹没。想象一下，一个假设的100人的团队，其工程师非常优秀，他们每个人每月只写一个bug。而这群了不起的工程师在每个工作日仍然会产生5个新的bug。更糟糕的是，在一个复杂的系统中，修复一个错误往往会导致另一个错误，因为工程师们会适配已知的bug并围绕它们编写代码。</li> </ul> <p>概要</p>