第一章「什么是软件工程」
-
编程和软件工程之间有三个关键的区别：时间、规模和权衡取舍。 在软件工程项目中，工程师更多关注时间成本和需求变更 时间和规模增长的不确定性的预估
-
”软件工程是随着时间推移的编程“ 编程任务（开发） 软件工程任务（开发、修改、维护、时间维度）
-
软件工程”与“编程”在维度上不同：编程是关于编写代码的。软件工程扩展了这一点，包括在代码的生命周期内对其进行维护。
-
海勒姆定律：当一个 API 有足够的用户的时候，在约定中你承诺的什么都无所谓，所有在你系统里面被观察到的行为都会被一些用户直接依赖。
-
客观数据驱动，大多数决策都是基于数据、假设、先例、论据的混合 随着时间的推移，数据驱动意味当数据变化时，需要改变方向
-
编程是产生代码的直接行为。软件工程是一组策略、实践和工具，这些策略、实践和工具是使代码在需要使用的时间内发挥作用，并允许整个团队的协作。
-
学而不思则罔，思而不学则殆 Fail Early, Fail Fast, Fail Often
第二章「如何融入团队」
-
结对编程：The Bus Factor Best work：编写一个新函数compile，添加一个测试，编译。重构一些代码，编译 当前DevOps对技术生产力的理念明确了这些目标：尽早获得反馈，尽早进行测试，尽早考虑安全和生产环境。这一切都与开发人员工作流程中的“左移”思想捆绑在一起；我们越早发现问题，修复它的成本就越低。
-
Best团队的讨论：我们觉得折中的方案是最好的解决方法。在小房间（或大办公室）将四至八人组成小组，方便大家轻松（且不令人尴尬）地自由对话。
-
In short, don’t hide 软件工程是一个团队的努力 humility, respect, and trust
- 支柱1：谦逊 你不是宇宙的中心（你的代码也不是！）。你既不是全方位的，也不是绝对正确的。你愿意不断提升自我。
- 支柱2：尊重 你真诚地关心与你一起工作的人。你善待他们，欣赏他们的能力和成就。
- 支柱3：信任 你相信其他人有能力并且会做正确的事情，你可以让他们在适当的时候牵头。
寓意是：不要低估社交游戏的力量。这不是欺骗或操纵人们；这是关于建立关系来完成事情。关系总是比项目更长久。当你和你的同事关系更融洽时，他们会更愿意在你需要他们的时候帮助你。
-
编程是一项与其他技能一样的技能：它随着实践而提高 “嘿，我对这部分的控制流感到困惑。我想知道XYZY代码模式是否能让这更清晰、更容易维护？”
-
托马斯·爱迪生的话说：“如果我发现有一万种方法不能成功，我就没有失败。我并不气馁，因为每一个被抛弃的错误尝试都是向前迈出的另一步”
-
Best 事后文化：正确事后总结应该总是包含对所学到的内容的解释，以及作为学习经验作为后续的改进落地 工程本质上是关于权衡的
-
重视反馈、走出舒适区、客户第一、关心团队、做正确的事
第十二章「单元测试」
-
Best：与其为每个方法写一个测试，不如为每个行为写一个测试 绝大多数的单元测试只需要一个 “when “和一个 “then “块
-
以被测试的行为进行命名测试
-
在测试代码中，坚持使用直线代码而不是复杂的逻辑，并在测试更具描述性的时候考虑容忍一些重复 好的库可以帮助我们更容易写出有用的失败信息
-
DRY—“Don’t Repeat Yourself.”
-
DAMP—that is, to promote “Descriptive And Meaningful Phrases.”
-
Oops!
知识共享-文档
-
code review时注意事项：LGTM、PTAL 在假设该方法是错误的之前，最好先问一下为什么要这样做
-
虽然第一行应该是整个更改的摘要，但描述仍然应该详细说明更改的内容和原因
os: 个人对CR严格的公司好感很多
第五章「如何领导团队」
- 谷歌通常通过要求一个人在晋升到该级别之前，必须在其目前的级别上完成高于当前水平的工作一段时间（即达到 “超出预期 “的目前级别）来避免这种情况。
os：怪不得需要晋升的话，必须拿到至少两次m+，或者一次e，说明在当前等级完成超出预期表现
-
彼得原理推导：每一个职位最终都将被一个不能胜任其工作的职工所占据。层级组织的工作任务多半是由尚未达到胜任阶层的员工完成的。
-
抵制管人的冲动，应该“服务性领导”，你能做的最重要的事情就是为你的团队服务，就像一个管家或大管家关心一个家庭的健康和福祉一样。作为一个服务型领导者，你应该努力营造一种谦逊、尊重和信任的氛围。这可能意味着消除团队成员自己无法消除的官僚主义障碍，帮助团队达成共识 尽管单纯关注团队的技术健康可能很诱人，但团队的氛围健康也同样重要（但往往更难管理）。
-
从事大型代码库工作的软件工程师可能需要几个月的时间才能在一个新的团队中适应。与可替换的装配线工人不同，这些人需要培养、时间和空间来思考和创造。
-
不应该保姆级关注成员们工作情况，高效完成只关注得到的成果/效果
os：我目前就需要搞清楚关键、重要的事情是哪些，集中精力专心致志的、高效完成 复盘，总结不断提升不足的地方，编码、技术方案设计、一开始没考虑的地方，为什么没考虑到，后续怎么处理
-
失败是允许的，失败也是快速学习的方式，只要不要在同一件事情上重复犯错。重要的是把失败看作是一个学习的机会，而不是指责或推责。相反，目标是强烈关注问题的核心，并一劳永逸地解决它。这非常困难，但相当有效（和宣泄）。不要担心身边比你优秀的出现，他们的出现反过来，定期的挑战（除了在你犯错时只有你自己知道），能更大程度的指导自己
-
如果你立即处理一个低绩效员工，你往往会发现他们只需要一些鼓励或指导就能走向更高的生产效率状态。如果你等待很长时间再来处理低绩效员工，他们与团队的关系就会变得非常糟糕，你也会感到非常沮丧，以至于你无法帮助他们。
os：讲的太好了，不管低绩效还是其他绩效的普通成员视角，上头的帮助和鼓励是多么的重要和鼓舞人心！
- 当有人质疑你的决定或声明时，记住这个人通常只是想更好地了解你。如果你鼓励询问，你就更有可能得到那种建设性的批评，使你成为一个更好的团队的领导者。
os：转化思路，获取内心轻盈和收获建设性方案！
- “他会把一只手放在胸前，用手托着下巴，对问题进行提问，通常是向完全惊慌失措的工程师提问”
os：需要真正掌握了在任何时候都保持冷静的能力！情绪稳定太重要了！
- 问问题。当一个团队成员向你征求意见时，这通常是非常令人兴奋的，因为你终于有机会解决一些问题了。这正是你在进入领导岗位之前多年所做的事情，所以你通常会立即进入解决方案模式，但这是你最不应该做的。寻求建议的人通常不希望你解决他们的问题，而是希望你能帮助他们解决问题，而最简单的方法就是向这个人提问。这并不是说你应该用 “魔力8球 “来代替你自己，那样做会让人发疯，而且没有帮助。相反，你可以运用一些谦逊、尊重和信任，通过尝试完善和探索问题，尝试帮助这个人自己解决这个问题。这通常会引导员工找到答案，而且这将是这个人的答案，这又回到了我们在本章前面所讲的所有权和责任。无论你是否有答案，使用这种技巧几乎总是会给员工留下你有答案的印象。很狡猾，是吗？苏格拉底会为你感到骄傲的。
os：狡猾至极！学会自我提问，会把没考虑的细节考虑到，和锻炼表达的能力！
- 这可能是一个技术上或组织上的障碍，但帮助团队重新行动是一种常见的领导技巧 在许多情况下，了解正确的人比知道正确的答案更有价值。 成为一名导师：对团队的流程和系统的经验，向别人解释事情的能力，以及衡量被指导者需要多少帮助的能力
os: 保持一颗真诚助人的心，保持稳定的情绪，帮忙别人同样是帮助自己！（回顾复习知识+帮忙合作方大家任务早点完成下班）