Lambda 的不同之处
我们经常听到 Lambda 的运作方式与其他公司不同。与我们合作的许多人称赞我们交付的速度和质量。我们将这一切归功于一套任何人都可以应用的原则，可能会使其他人受益。可以总结为：观察、迭代、简化，与代码保持密切关系，无论是在其静态形式还是动态形式，并在正确的时机融入流程，以满足工程需求而非管理需求。让我们分解一下：
保持好奇，专注于学习和解决问题
我们提倡一种文化，让工程师可以感受到将事物投入生产和将他们的技能应用于有趣挑战的快乐。
观察和测量
工程就是在给定成本/收益权衡下应用知识来解决问题。你无法解决看不到的问题。看到就是测量。利用你的工具诊断问题，制定成功的指标，然后在应用解决方案后再次测量。
将可观察性构建到你的系统中。你看到的越早，你就能越早对变化的需求和变化的指标做出反应。
这同样适用于性能工程。优化只有在变成需求之前并在测量之前时是过早的（因此是有害的）。
在你感知-行动循环中频繁迭代以缩短反馈。
公开讨论工程问题
一旦识别出一个问题，就要公开讨论。当然，如何与其他人沟通在与人交流时非常重要，但如果框架正确，技术讨论不应冒犯任何人，因为任何技术解决方案的优点或缺点仅反映其自身，而不是实施它的人或群体的价值。
问题（或解决方案）越早沟通和讨论，最终的解决方案就会越好，风险和成本就会越低。
“骄傲并不是羞耻的对立面，而是其源头。真正的谦卑是对羞耻的唯一解药。”
与复杂性（或缺失）之间的关系
如果有一个我们不断重复且可以在任何情况下应用的口号，那就是 KISS，保持简单，傻瓜。
关于这个已经有很多的书写，在其他许多明智的反思中也有所体现，例如乔·阿姆斯特朗的著名引述 “先让它工作，然后让它美观，如果你真的、真的必须，让它快速。90% 的时间，如果你使其美观，它将已经很快。因此，真正的，只需让它美观！”；或在 Python 之禅的一些理念中：
美观胜于丑陋。
显式胜于隐式。
简单胜于复杂。
复杂胜于复杂化。
扁平胜于嵌套。
稀疏胜于密集。
可读性重要。
这些一般性的格言有时可能看起来像陈词滥调或同义反复。它们的价值在于时刻牢记并问自己“这在这个上下文中如何适用？”
自我食用（Dogfooding）
代码库应该在所有目标环境中轻松、干净地构建。项目的新成员应该能够毫无障碍地进行设置。以拥有最新的自述文件而自豪，让人们可以跟随，并让你的代码在他们的机器上迅速运行。尽可能多地进行开源。将你的代码放到世界上。
开发者应该对基础设施进行亲身实践，而不仅仅是熟悉通常的开发工具，还要了解将其投入生产的管道和代码。你的管道应该干净，并具备可观察性和可调试性，和产品代码一样。
泛化应该是最终目标
在绝对需要之前不要进行泛化。重复代码两到三次是可以的。解决你需要解决的问题，不要纠缠于如何抽象或泛化解决方案，只需以最简单的方式完成它。泛化和抽象随着时间自然产生。
大多数新挑战性项目通常有两个不同的阶段：
前几周：实验和原型
事情刚刚开始。正在解决的问题尚未得到很好的理解，存在很多不确定性；有些人对问题了解得刚好足够，以意识到这是一个困难的任务，但又不够去解决它。这造成了很多对事情应如何进行以及最佳前进方式的焦虑；无休止的争论交替进行，毫无进展。有时一些知识比什么都不知道更糟糕。
度过这个阶段需要认识到你并不完全知道如何做事情，这是正常的；你必须通过试错来弄明白。这时的口号是 快速前进，尝试，快速失败，弄明白。
在这个阶段引入大量流程是适得其反的，当你甚至不确定自己在构建的是什么时，你无法制作甘特图并制定截止日期。这样做只会减缓你的进度，或者把你引向错误的方向。
这个阶段的士气也非常重要；人们担心项目可能不会成功，问题不可解决。如果长时间没有任何更新或进展，他们就会感到泄气。解药是快速编码一些执行最终所需基本行为的东西，并且每过一周应该扩展和改进功能。不要在创造大量仍然无法执行基本功能的代码的情况下让周数过去。展示定期更新，快速合并更改并进行尝试，定期部署以及拥有快速反馈循环对于让人们保持兴奋和专注是至关重要的。
稳定下来
经过几周的工作，项目开始成型，问题得到了更好的理解，解决方案也正在顺利实现。人们开始在项目周围发展一种共同的词汇，他们知道接下来需要解决的问题是什么以及如何去做。焦虑逐渐消退。
在这个阶段，有两件事情变得重要：
- 组织即将到来的工作。项目此时不超过原型，还有大量工作需要完成以使其准备好生产。
- 记录迄今为止的进展。在前几周/月的工作中积累了大量知识，因为想法被尝试和丢弃。这些知识不应该丢失。
解决这些问题（尤其是第一个问题）需要引入 流程。记录下所有剩余任务，制作甘特图，定义里程碑并相应地分配工作，此时都是必要的。主要障碍不再是那么多不确定性，而是正确的规划和执行。
随着项目持续成型和发展，合并新更改变得越来越困难；其复杂性使你无法知道每一个细节。此外，破坏事物的成本在开发时间和生产中的潜在费用上都更高。因此，全面的测试和代码审查变得至关重要。
流程是一个 成熟 项目的标志。它是非常重要的，但在必要之前不应引入。
来回反复
大多数项目经历这些阶段不止一次。通常，每当项目获得涉及具有挑战性任务的新需求时，其中一部分必须回到实验阶段。
这里的关键是 不确定性。当你发现某项任务困难并且人们花费过多时间争论如何解决，而始终未尝试（因害怕打破事物或做出错误选择）时，你需要回到第一个阶段。这并不意味着将所有流程抛弃；从事其他常规任务的人员可以照常工作。只是应对这一新挑战的部分团队需要改变其方法。
引入流程
在众多无尽的流程管理工具和图表中，我们发现最有用的是甘特图。
以下是我们在项目需要时制作甘特图的过程大纲。
- 以非常宽泛的方式理解项目中有哪些领域。例如，网络、状态转换、API、数据库、外部服务、基础设施。架构图可能在这个阶段有所帮助。
- 将领域划分为任务。
- 重复步骤2几次。这种细化将有助于指导研究并防止“在编码之前我想知道一切”。
- 研究并不意味着仅仅阅读，这是一个很好的阶段去开始一些你不理解的事情的小型 PoC。有些 PoC 甚至可以作为任务委托给其他团队成员，同时仍然在弄清楚任务。不过，你稍后需要深入检查这些。
- 跟踪任务之间的依赖关系。依赖图在这里可能是一个不错的输出。
- 使用依赖关系进行优先级排序，并将任务按垂直切片分组。这些是提供一些高级功能的端到端集成，通常包括所有领域的一小部分。
- 第一个垂直切片应是基本版的，也许提供一个无用的功能，但应能让你得到“某种”工作。它应具备数据库、API、网络、持续集成、测试和代码审核（如有必要，也包括其他工具）。这将迫使你从第一天起就始终保持生产心态，避免后来进行巨大的集成。这也迫使你开始尽早进行各种工具的 PoC，以减少不确定性并为下一次切片解除阻碍。
- 使用这些切片制定发布计划。大致估计每一个所需周数。这不是精确估算的时间。此外，根据你的乐观程度和你对项目了解的多少，将该数字乘以 1.5 或 2。
- 现在你可以制作一个反映发布计划的甘特图，并根据你拥有的人数进行调整。
