IDEAL Garden

这篇文章讨论了全栈开发的好处和如何开始转型，以及在需求分析和架构设计中如何分层和隔离业务变化。作者分享了不同类型知识的学习方法和针对语言和框架的练习建议，以及通过结对编程和TDD加速学习的技巧。

这里有四种离岸交付合作模式：Team Extension Model，Hybrid Collaboration Model，E2E Collaboration Model和Onshore/Offshore Collaboration Model。每种模式都有其优势和挑战，需要根据组织自身情况选择合适的模式。其中E2E Collaboration Model是一种全面的离岸交付模式，适用于团队成熟度较高、业务模块相对独立的情况。

Gherkin语言有时候又被称为小黄瓜语言，它是第一种有着类似自然语言可读性的业务语言，用来描述业务行为，而不必关心具体的实现细节。它也是一种领域特定的语言，用来定义Cucumber格式的测试。

冗杂繁复的数据初始化代码会影响单元测试本身的代码质量，造成单元测试编写成本高、易读性差、易维护性低等问题。

软件工程里一个重要的指标就是“可用的软件”，所以如何在提高代码质量，最大程度地减少软件中的Bug同时，平衡软件迭代速度与交付效率是我今天想跟大家讨论的问题。

数据出现问题相对比较严重，团队都会着急去排查原因，不过，在开始排查之前，有更重要的事情要做。我认为问题排查也分两个步骤：清晰识别问题、定位问题。

本文以真实项目实践总结为基础，选取了结对编程中的典型场景，叙述了在敏捷交付项目中，开发者在实践结对编程时经常遇到的挑战。

兼容性测试是一种软件测试，用于确保构建的系统/应用程序/网站与其他各种对象（如其他网络浏览器、硬件平台、用户、操作系统等）的兼容性。这种类型的测试有助于了解产品在特定环境中的表现。

谈论到引用透明(Referential Transparency)，我们都会聊函数式编程(FP)，会聊Effect和Side Effect，会聊纯函数(Pure Function)等，这些概念相互关联，有时甚至彼此引用定义，能够真正理解它们的含义非常重要。

AI系统本身的发展还不足以很好地替代人在测试分析和测试设计方面的工作，导致AI实现的自动化测试的准确性以及可维护性比人工的方式更差，不过它的时间和成本优势却远远超过人工，这个也是其越来越火的根本原因。所以在测试领域，AI需要更加努力,才能真正替代人的工作。

在团队成员向Tech Lead寻求帮助时，Tech Lead首先要做的是明确提示期望，识别能力差距，其次是引导团队成员自己得出解决方案，最后制定培训计划以提升团队能力。

在一定场景下，使用契约先行的合作方式可能更高效，比如契约足够简单直接，开发使用的技术适用于生成的代码，开发过程中已经有足够的集成测试或组件测试时，契约先行可以缩短团队间的反馈闭环，减少等待时间，提升开发效率。

简单设计五原则中，测试要确保通过（满足需求）、重复应该被消除、元素没必要就不要存在，这几条看起来相对具体，而且能见字如意。

测试左移之所以重要，是因为我们要在缺陷引入的最初阶段就发现它，把缺陷扼杀在摇篮里，而不是等着它像雪球一样越滚越大。

前后端分离本质上是技术的分离，而不是人员的分离。团队要不要分取决于你如何设计你的架构，也取决于你的业务模式，所服务的产品形态、团队能力、工程实践的成熟度。

Bug 对于软件来说显而易见，需求则不同，不适当的需求往往并不明显，而且暴露的很晚。错误的需求会增加工程师的额外工作量，因此怎么评审需求合理性需要慎重考量。

结对编程也只是程序员工作中会用到的一项技能而已，那么只要是技能，通过时间的堆积，去磨炼，去思考，就会有所提升。

敏捷的功夫是知行的功夫，实践要做，理论也要懂，丢了一个便是全丢。唯有在实践中丰富我们的认知，又用认知来指导实践，反复循环，培养既抽象也具体的知识，才能做到真正的敏捷。

技术债是不可避免的，有些技术债短期不会表现出明显的系统问题，但长久来看，技术债的增加会使系统的可维护性下降，产品质量下滑，导致线上故障。技术的构建不是一劳永逸的，是需要不断维护的，在日常开发中，团队要做好技术债管理，将技术债的解决日常化。

大部分时候，技术的决策是专制的。如果我在这个技术领域有丰富的经验，如果我解决过足够多的问题，哪怕我只是在这个项目中待的足够久，那么对于当下任何一个新的问题，我给出的解决方案一定会更完善。

随着测试人员陆续开始尝试角色转变，坚守的QA需要找到自己的发展之路。兴趣和性格是客观因素，好奇心和发散性思维则是帮助成为优秀QA的必要因素。

敏捷文化的核心或者源泉，是对团队的”信任和Ownership“，团队的每个人知道项目想要取得的结果，并对结果肩负责任，它们是团队活力和创新的基础，也是高绩效的基础

编程高手不是能够快速写出可用代码的人，而是能够快速写出别人一眼就能看懂的代码的人。

本文分析了如何在测试金字塔的指导下制定数据应用的测试策略。测试金字塔可以给我们带来对质量的信心，以及测试集成度，帮助我们更深刻地理解测试金字塔背后的指导原则。

我们每个人都知道的是，在一份内部质量优秀，技术债不多的代码库中增加新功能，要比在一个内部质量相对差一些的代码库中增加新功能容易得多。我想用我经历和见证的不同项目、不同情况来和你聊聊为什么只有保证质量才能保证速率。

对于敏捷软件开发者来说，及时获取完成任务所需的信息及实现共识，包括业务价值、技术方案、验收标准以及反馈，显得更为重要。因为这些决定了他/她将以什么样的方法、多少成本去交付何种价值的可工作软件。

数据和智能类的项目管理内容仍然是基于传统软件项目管理所定义的范围和领域，但近年来新概念和新技术的出现给数据和智能类项目的管理带来了新的挑战，所以项目管理者在管理的思路、方法、策略上也存在不同。

标准化、自动化做的那么好的，那都是别人家的公司。而我们大多数的公司或团队，由于企业文化、组织架构、思维习惯、人员能力、基础设施等因素的影响，要做好质量保障赋能非常地难。

Code Review 的好处虽然被广泛认可，但想做好 Code Review 并不容易。首先团队需要对开展 Code Review 达成共识，然后针对自己团队的特性，采用相匹配的实践方式。关于工具，可以尝试文中提到的 Code Review 插件以及电子看板。在提升自动化程度的同时，积累 Code Review 数据，指导团队针对性地提升技能。

团队由一群身怀绝技又各不相同的人所组成，大家有共同的目标，并愿意为之而努力。打造你的全明星团队，和团队一起设立愿景，这是你团队走向成功的基石！

前端测试的重点不是机械地去追求测试覆盖率，而是尽可能在成本和信心值中间找到一个平衡，应用一些好的实践去降低写测试的成本，提升写测试带来的回报，让大家对于项目质量越来越有信心。

软件开发者在刚接触和运用TDD时可能会陷入一些教条主义而走一些弯路，本文通过一个实际业务系统的小案例来探讨TDD应提倡的教条和可以规避的教条，探寻TDD的本真~

验证软件具备基础的体验能力后，测试人员不妨故意“犯傻”，反向验证一下软件的防呆能力。

在Thoughtworks，我们通过对最佳实践(Sensible Default Practices)、能力和度量的持续治理和改进，在保障交付正确的客户价值和减少浪费的基础上，使交付质量更好，速度更快，反馈更及时，从而达到追求工程卓越和形成发展工程师文化的目的，最终产生客户影响力。............

契约测试不是一个新鲜东西，但在实际项目经历中发现用好契约测试真的会大大增强开发的效率，因此写下这篇文章来简单总结一下契约测试的一些内容。

本文从“团队协作的五大障碍”出发，首先对团队协作过程中遇到的各种问题进行抽象归类，然后分享我们在团队中试过且效果很好的一些敏捷实践，最后展示建设成果，最后展示建设成果。

大部分客户其实并不在乎你做的什么敏捷，他在乎的其实是你能不能在规定的时间内交付应该交付的软件。你告诉他我们用的是故事点估算，他会告诉你我不懂你们的故事点，你就告诉我这个功能几天做完。......

编程高手不是能够快速写出可用代码的人，而是能够快速写出别人一眼就能看懂的代码的人。

金字塔建议底层单元测试占比应该最多，而顶层UI层测试占比较少，中间层的集成测试居中，整体呈现金字塔结构。这适合比较理想的项目，而实际项目中可能有很多不适合测试金字塔的情形。

尽管在远距离办公的时候，PR开发模式越来越流行，但我们仍然需要小心谨慎地使用它。