TECHNIQUES（技术）

Implementing Continuous Delivery continues to be a challenge for many organizations, and it remains important to highlight useful techniques such as decoupling deployment from release. We recommend strictly using the term Deployment when referring to the act of deploying a change to application components or infrastructure. The term Release should be used when a feature change is released to end users, with a business impact. Using techniques such as feature toggles and dark launches, we can deploy changes to production systems more frequently without releasing features. More-frequent deployments reduce the risk associated with change, while business stakeholders retain control over when features are released to end users.

实现可持续交付对许多组织而言依然是一个挑战。强调如区分部署和开发等实用技术是尤为重要的。我们推荐严格区分”部署“和”发布“术语。应用组件或基本设施的代码或配置变更在产品环境中生效称为”部署“，而具有业务影响的功能变化对最终用户可见称为”发布“。使用特性开关或灰色发布等技巧可以使用我们频繁地部署变更到产品环境而不是发布功能。频繁部署可以有效降低变更带来的风险，同时业务负责人仍然保持对发布给最终用户的控制。

‘Just In Time Design’ is an important and useful concept for visual design that the NoPSD movement attempts to capture. You don’t need to design the whole application or every UI element up front. Design things as you need them with as lightweight tools as you can use. We have seen a corresponding growth in simpler tools with faster learning curves, such as Sketch, as well as an increasing return to pen-and-paper (especially when paired with an existing robust digital style guide). Because of the limitations of flat mock-ups when you’re designing for screens, creating prototypes of varying fidelity with tools such as Invision, FramerJS and Origami - or simply HTML/CSS and a bit of JavaScript - has also become increasingly common and valuable for communicating design intent.

NoPSD想要抓住的是”即时设计“这个在视觉设计中重用实用的概念。你需要事先设计整个应用程序或者每一个界面元素。尽可能使用轻量工具按需设计。我们已经看到简单易学的工具更多地使用，如Sketch；纸和笔也有更多回归的趋势，尤其在与现有强大的数字风格指南配合时。由于为屏幕设计时平面模型的限制，使用如Invision, FramerJS和Origami这样的工具，或者简单的HTML/CSS加一些JavaScript来创造各种保真效果的原型，已经成为沟通设计意图时常见有效的方式。

We’ve long been championing the idea that thinking of software development as a project - something budgeted and delivered during a limited time slot - doesn’t fit the needs of the modern business. Important software efforts need to be an ongoing product that supports and rethinks the business process it is supporting. Such efforts are not complete until the business process, and its software, cease to be useful. Our observation of this products over projects approach, both with our own projects and outside, makes us determine that it is the approach to use for all but exceptional cases.

我们长期坚信”软件开发作为一个项目（在有限的时间和预算内交付一些东西）“的观点并不适用于现在的商业模式。软件开发的主要努力应放在使软件成为支撑和反思业务并持续改进的产品。在其所支撑的业务失效前，这样的努力不应该停止。根据我们在我们以及外部项目的观察中看，”产品优于项目“的方法对除特殊情况外的所有情况都有效。

With the number of high-profile security breaches in the past months, software development teams no longer need convincing that they must place an emphasis on writing secure software and dealing with their users’data in a responsible way. The teams face a steep learning curve, though, and the vast number of potential threats - ranging from organized crime and government spying to teenagers who attack systems ‘for the lulz’can be overwhelming. Threat Modelling provides a set of techniques, mostly from a defensive perspective, that help you understand and classify potential threats. Turned into ‘evil-user stories’, threat models can give a team a manageable and effective approach to making their systems more secure.

鉴于这几个月以来备受瞩目的安全漏洞频发，软件开发团队已经不需要被说服他们必须重点关注编写安全的软件，并且要以更负责任的方式对待用户数据。然而他们面临陡峭的学习路线，从有组织的犯罪和政府监控，到青少年为了好玩而攻击系统，这些大量的潜在威胁让人难以招架。威胁建模提供了一系统的技术，主要从防御的角度出发，帮助对潜在威胁进行理解和分类。通过转化为“恶意用户故事”，威胁模型给予团队一种可以管理的、有效的方式来打造更加安全的软件系统。

Debugging CSS problems can be painful. How many times have you had to trawl through thousands of overridden styles to work out the source of your problem? This has led many of our teams to introduce various guidelines such as avoiding cascading and overrides, making styles opt-in and emphasizing thoughtful naming. BEM is a simple CSS naming convention (standing for Block, Element, Modifier) that helps give semantic clarity and structure to your CSS. By using BEM, it becomes much easier to understand which CSS rules are influencing the appearance of an element and, more importantly, the intent of those rules. This approach can be seen as moving the OO lesson of favoring composition over inheritance to the world of CSS.

调试CSS是非常痛苦的，有多少次你不得不从成千上万的样式覆盖中找出问题所有。为减少这种痛楚，很多团队引入了各种各样的代码规范（guidelines），比如避免级联与覆盖，使用真正需要的(opt-in)样式，并强调有意义的命名。BEM（代表Block, Element, Modifier)是一种简明的CSS命名规范，它能把你的CSS变得更语义化和结构化。通过使用BEM, 可以更容易地理解CSS规则是怎么影响第一个元素的，并且更重要的是理解CSS规则本身。这个方法可以被看做是将面向对象中“组合优于继承”的经验搬到了CSS世界中一样。

Valuable services support many variations in clients, such as mobile versus、 web and different forms of web interface. It’s tempting to design a single back-end API to support all clients with a reusable API. But client needs vary, as do constraints such as bandwidth for mobile devices versus the desire for lots of data on fast web connections. Consequently it’s often best to define different back-end services for each kind of frontend client. These back ends should be developed by teams aligned with each front end to ensure that each back end properly meets the needs of its client.

有价值的服务支持多种客户端，比如移动设备、网站及各种形式的网络终端。能够设计一个可复用并且支持多个客户端的API是具有很大的诱惑力的。但是客户端需求总是不同的，比如移动设备对带宽的限制，而在网络速度快的情况下又对更多的数据有需求。因此通常情况下，为不同的客户端设计不同的后台服务是最好的方式。这些后台服务应该由与前台服务一致的团队开发从而保证后台服务能够满足其前端需求。

One of the many innovative uses of Docker that we’ve seen on our projects is a technique to manage buildtime dependencies. In the past, it was common to run build agents on an OS, augmented with dependencies needed for the target build. But with Docker it is possible to run the compilation step in an isolated environment complete with dependencies without contaminating the build agent. This technique of using Docker for builds has proven particularly useful for compiling Golang binaries, and the golang-builder container is available for this very purpose.

管理构建时依赖是Docker在我们项目上诸多创新型用法之一。在过去，通常的作法是在操作系统上运行具有构建目标所需依赖的构建代理。Docker使得在一个具有所需依赖并完全隔离的环境里运行编译而不污染构建代理。这种使用Docker来进行构建的技术的有效性已经在Golang的编译场景中被部分证明。而Golang-builder容器的存在正是为了此目的。

Event Storming is a useful way to do rapid “outside-in” domain modeling: starting with the events that occur in the domain rather than a static data model. Run as a facilitated workshop, it focuses on discovering key domain events, placing them along a timeline, identifying their triggers and then exploring their relationships. This approach is particularly useful for people taking a CQRS or Event Sourcing approach. Getting the right people in the room is important - a blend of business and technical people who bring both the questions and the answers. Ensuring that you have enough wall space for modeling is the second key to success. Look to discover the big picture, with the goal of collectively understanding the domain in all of its complexity, before diving into solutions.

事件风暴是快速领域建模的一种方式，它由外及内，以领域中的关键事件而不是传统的静态数据模型作为起点。它以工作坊的形式展开，主要目的是识别领域关键事件，将它们以时间轴的方式组织，确定它们的触发条件，并探索它们之间的关系。这种方式对于采用CQRS或者Event Sourcing的开发者来说尤为有效。它成功的第一要素是找到合适的人。这组人需要融合业务和技术人员，能够提出问题并一起发现答案。第二，要确认你有足够的白板空间来建模。它可以通过可视化的方式，帮助我们一起发现全景，共同了解目标领域以及它的复杂度，确保在讨论解决方案之前对于问题的一致理解。

Flux is an application architecture introduced by Facebook. Usually mentioned in conjunction with React.js, Flux is based on a one-way flow of data up through the rendering pipeline. Flux embraces the modern web landscape of client-side JavaScript applications in a way that avoids the venerable MV* clichés. ThoughtWorks teams are now starting to gain some experience with this architectural style and find that it meshes well with service orientation and solves some of the problems inherent in two-way data binding.

Flux是Fackbook推出的应用程序架构，通常与React.js被同时提及。它基于一个通过渲染流水线向上的单项数据流。Flux拥抱基于客户端JavaScript的现代网络应用风格，避免了古老陈旧的MV*架构。ThoughtWorks团队开始在这一方面获得了一些经验，我们发现它与面向服务结合的很好，并且解决了双向数据绑定所带来的一些问题。

Many services, especially legacy services, are written with the assumption that any request will occur only once. Networks being what they are, this can be difficult to arrange. An idempotency filter is a simple component that merely checks for duplicate requests and ensures that they are sent to the supplier service only once. Such a filter should do only this one task and be used as a decorator over existing service calls.

现在有很多服务，尤其是传统的服务，在编写时都假设请求仅会发生一次。做为网络本身而言，这很难保证。幂等过滤器是个简单的组件，他通过检查重复请求并保证发给服务器的请求只有一次。过滤器应当做为装饰器叠加在现有的服务调用上，并且它应该仅做这一件事情。

Modern web pages tend to contain a plethora of JavaScript widgets and snippets coming from a variety of third-party sources. This can have a negative impact on both security and performance. While we are still waiting for fuller JavaScript isolation with web components, our teams have benefited from using HTML5 iFrames for sandboxing untrusted JavaScript.

现在的网页往往含有过多的来自第三方的JavaScript部件和代码片段，这对安全和性能都会产生负面影响。虽然我们仍在等待基于Web组件的JavaScript完全隔离方案，我们的团队已经从使用HTML5 iframe来沙盒化不可信的JavaScript中受益匪浅。

The JavaScript world has a plethora of dependency and package-management tools, all of which rely on the Node Package Manager (NPM). Teams are starting to see these extra tools as redundant and are recommending that if you can use solely NPM for package and dependency management, you should. The simplification of using NPM for all the things helps reduce some of the churn in the JavaScript tools space.

JavaScript的世界中有太多的依赖和包管理工具，它们全都基于NPM（Node Package Manager）之上。许多团队慢慢开始发现这些额外的工具有点冗余，他们推荐在条件允许的前提下只用NPM来管理包和依赖。使用NPM的简化方案有利于减少JavaScript工具世界的噪音污染。

The time taken to provision and update environments continues to be a significant bottleneck on many software projects. Phoenix Environments can help with this delay by extending the idea of Phoenix Servers to cover entire environments. We feel this is such a valuable and time-saving technique that you should consider trialing this approach. Using automation, we can create whole environments - including network configuration, load balancing and firewall ports - for example by using CloudFormation in AWS. We can then prove that the process works by tearing the environments down and recreating them from scratch on a regular basis. Phoenix Environments can support provisioning new environments for testing, development, UAT and disaster recovery. As with Phoenix Servers, this pattern is not always applicable, and we need to think carefully about things like state and dependencies. Treating the whole environment as a blue/green deployment can be one approach when environment reconfiguration needs to be done.

在很多软件开发项目中，准备和更新环境所花费的时间依然是重大的瓶颈。通过扩展Phoenix服务这个概念到整个环境上，Phoenix环境可以有效地降低这种延迟。我们觉得这是一种很有价值的节省时间的技术，你也可以考虑采用这种方式。通过自动化，我们可以创建包括网络设置、负载均衡和防火墙端口在内的整个环境（比方说使用AWS上的CloundFormation）。之后，可以通过定期销毁、重建这个环境来验证这个过程是工作的。Phoenix环境能够支持测试、开发、UAT和灾难恢复所需的新环境准备。仅仅使用Phoenix服务器不总是可行的，并且还需要仔细的考虑状态和依赖这些因素。当需要对环境进行配置时，把整个环境当做一次蓝绿部署也是一种可行的方式。

Traditionally, QA roles have focused on assessing the quality of a software product in a pre-production environment. With the rise of Continuous Delivery, the QA role is shifting to include analyzing software product quality in production. This involves monitoring of the production systems, coming up with alert conditions to detect urgent errors, determining ongoing quality issues and figuring out what measurements you can use in the production environment to make this work. While there is a danger that some organizations will go too far and neglect pre-production QA, our experience shows that QA in production is a valuable tool for organizations that have already progressed to a reasonable degree of Continuous Delivery.

传统方式下，QA的角色主要专注于保证软件产品在类产品环境下的质量。随着持续交付的出现，QA的角色逐渐转变到需要分析软件产品在产品环境下的质量。这需要引入产品系统的监控，制定检测紧急错误的警报条件，持续质量问题的确定以及找出在产品环境下使用的度量以保证这种方式可行。这有可能会导致有些组织走的太远而忽视产品上线前的质量保证。我们的经验表明，产品环境下的QA只对那些已经执行并有一定程度持续交付实践的组织有价值。

Immutable data structures are becoming more popular, with functional languages such as Clojure and Scala providing immutability by default. Immutability allows code to be more easily written, read and reasoned about. Using an accumulate-only data store can confer some of these benefits in the database layer, as well as make audit and historical querying simple. Implementation options vary, from specific accumulative data stores such as Datomic to simply using an “append-don’t-update” approach with a traditional database. Accumulate-only is a design strategy whereby data is removed via retraction rather than update; append-only is an implementation technique.

不可变的数据结构正在变得越来越受欢迎，函数式语言，如Clojure和Scala默认就提供不变性。不变性使得代码更容易编写、阅读和理解。在数据库层，采用“只积累”的数据存储也给予了一些同样的好处、并且使审计和历史查询更为简单。实现选择各不相同，从使用Datomic这样特定的积累数据存储，到在传统数据库中采用简单的“只追加，不更新”的手段。“只积累”是一种设计策略，数据删除通过撤回而不是更新，而“只增加”只是一种具体的实现技术。

More and more organizations are starting to use bug bounties to encourage reporting of what are often security-related bugs, and in general help improve the quality of their software. To support these programs, companies like HackerOne and BugCrowd can help organizations manage this process more easily. We have limited experience with these offerings ourselves, but we like the idea of encouraging people to help come forward and highlight what can often be damaging vulnerabilities in an open and transparent way. It’s worth noting that there might be some legal issues with encouraging users to find vulnerabilities in your software, so please do check that out first.

越来越多的组织开始通过bug bounties鼓励记录常见的安全相关的bugs，帮助提高软件质量。为了支持这些方案，诸如HackerOne和BugCrowd公司的出现可以更容易地帮助企业管理这个过程。我们在这方面经验有限，但是我们喜欢这种鼓励人们以很开放、很透明的形式来提出常见的漏洞的想法。值得一提的是，在鼓励用户发现你们软件中的漏洞的前要先确认清楚是否会引发法律问题。

A Data Lake is an immutable data store of largely unprocessed ‘raw’ data, acting as a source for data analytics. Whereas the more familiar Data Warehouse filters and processes the data before storing it, the lake just captures the raw data, leaving it to the users of that data to carry out the particular analysis that they need. Examples include HDFS or HBase within a Hadoop, Spark or Storm processing framework. Usually only a small group of data scientists work on the raw data, developing streams of processed data into lakeshore data marts for most users to query. A Data Lake should only be used for analytics and reporting. For collaboration between operational systems we prefer using services designed for that purpose.

作为数据分析的来源，数据湖泊是一种不可变的数据存储，其中存有大量未加工的“原始”数据。而数据仓库在存储之前，先要过滤、处理数据，不同的是，湖泊仅捕获原始数据，把剩下的留给用户根据他们所需进行特定的分析。这样的例子包括HDFS或者基于Hadoop、Spark或Storm处理框架之内的HBase。通常只有一小部分数据科学家针对原始数据进行工作，他们制定处理过的数据流入数据集市，为大多数用户提供查询。数据源泊应该只用于分析和报表。对于业务系统之间的协作，我们更倾向于使用专门为其设计的服务。

Many organizations want to leverage distributed or offshore development but have security concerns with their code and other intellectual property sitting outside their control. The result is often to use high-latency remote-desktop solutions for development, adhering to an organization’s security controls but crippling developer productivity. An alternative is to use a Hosted IDE delivered to a browser via VPN. The IDE, code and build environment are hosted within the organization’s private cloud, easing security concerns, and the developer experience is significantly improved. Tools in this space include Orion and Che from the Eclipse Foundation, Cloud9 and Code Envy.

很多组织希望能充分利用分布式或海外交付，但对于其控制外的代码和知识产权的安全性深表担忧。其结果往往是采用能维持安全控制，但牺牲开发人员生产力的高延迟的远程桌面进行开发的解决方案。另一种方案是使用通过VPN接入的浏览器访问托管IDE。IED，代码和构建环境托管在组织内的私有云上既消除了安全忧虑，又大幅改善了开发者的体验。来自Eclipse基金会的Orion和Che，以及Cloud9和Code Envy都是这个领域的佼佼者。

In monitoring, the common approach is to conceive of erroneous conditions and set alerts when these appear. But it’s often difficult to enumerate the myriad failure modes in a software system. Monitoring of invariants is a complementary approach to setting expected normal ranges, often by examining historical behavior, and alerting whenever a system goes outside those bounds.

在监控中，常见的方法是设计错误场景，设置相应告警。但是，这种方式往往难以穷举软件系统中的无数失败模式。不变量监控是对预期正常范围监控的补充，一般通过检查系统历史行为，并在系统行为超出正常范围时发出告警。

We firmly believe that long-lived version-control branches harm valuable engineering practices such as continuous integration, and this belief underlies our dislike for Gitflow. We love the flexibility of Git underneath but abhor tools that encourage bad engineering practices. Very short-lived branches hurt less, but most teams we see using Gitflow feel empowered to abuse its branch-heavy workflow, which encourages late integration (therefore discouraging true continuous integration).

我们坚定地相信长期存在于版本控制中的分支会破坏像持续集成这种有价值的工程实践，这也正是我们不喜欢Gitflow的原因。我们喜欢Git带来的灵活性，却又痛恨Gitflow引入不好的工程实践。生命周期越短的分支集成时越容易。我们发现大多数使用Gitflow的团队受其滥用分支的工作流影响，推迟了集成点，最终阻碍了真正的持续集成。

We see many teams run into trouble because they have chosen complex tools, frameworks or architectures because they ‘might need to scale’. Companies such as Twitter and Netflix need to be able to support extreme loads and so need these architectures, but they also have extremely skilled development teams able to handle the complexity. Most situations do not require these kinds of engineering feats; teams should keep their web scale envy in check in favor of simpler solutions that still get the job done.

我们看到很多团队因为觉得“系统可能会需要扩展”而选择复杂的工具、框架和架构遭遇问题。公司如Twitter和Netfix之所以需要这样的架构是因为他们需要支持极端负载的情况，并且他们拥有非常熟练的开发团队能够处理所带来的复杂性。在大多数情况下，这样的工程技艺是不必要的，团队应该克制他们的互联网级规模的情结而倾向于简单可行的解决方案。

Gartner’s Pace-layered Application Strategy approach appears to be creating an unhelpful focus on the idea of layers within an architecture. We find thinking about the pace of change within different business capabilities (which can be made up of several architectural layers) to be a more useful concept. The danger in focusing on layers is that many types of change cut across multiple layers. For example, being able to add new class of stock to a website is not just about having an easy-to-change CMS; you also need to update the database, integration points, warehouse systems, etc. The recognition that some parts of an architecture need to be more maneuverable than others is useful. However, a focus on layers is proving unhelpful.

Gartner提出的节奏分层的应用策略似乎在软件架构的层次方面创造出了一个无益的聚集点。我们发现考虑业务能力（可能由几个架构层次构成）的不同变化节奏是一个更有用的概念。仅仅聚集于层次的危险之处在于，很多类型的变化是在多个层次上纵切的。比方说，在网站上添加新的股票类型，不仅仅是要有一个易于变化的CMS，你还需要更新数据库、集成点、仓库系统等等。识别出一个架构中的某些部分比起其他部分需要更强的机动性是很有用的。然而，聚集于层次被证明是没什么用的。

The Scaled Agile Framework® (aka SAFe™) continues to gain mindshare in many organizations at scale. In addition, tools and certification are becoming a significant aspect of the adoption of SAFe™. We continue to be concerned that actual adoptions are prone to over-standardization and are tending towards large release practices, resulting in practices that hinder agile adoption. In its place, we continue to recommend lean approaches that include experimentation and incorporate continuous improvement practices like the Improvement Katas offer organizations a better model for scaling agile.

规模化敏捷框架Scaled Agile Framework(又名SAFe)继续获得很多大型组织的心理份额。此外，工具和认证正在成为是否采用了SAFe的一个重要的判断依据。我们依然担心的是，在这个过程中容易过度标准化，并且趋向于大型发布，结果在实际上阻碍了敏捷的实行。在这方面，我们继续推荐精益方法，包括实验和持续改进实践的整合（如改进道场Imporvement Katas），从而为企业提供更好的规模化敏捷模型。