专栏首页ThoughtWorks2015.1 技术雷达 | 技术篇

2015.1 技术雷达 | 技术篇

许多项目都存在外部代码依赖,这些依赖中很大一部分是由开源项目提供的。为了确保构建过程可被重现,我们总是与固定版本的外部依赖进行集成。但这就意味着我们与这些类库的新版本集成并不及时,这将导致后面大量的合并工作。我们见到的避免这个问题的方式之一是夜间的Canary Build,它会尝试使用所有外部依赖的最新版本进行构建。如果成功,就代表我们可以将外部依赖修改为相应的版本。

数据紧缩(Datensparsamkeit, martinfowler.com/bliki/Datensparsamkeit.html)来自于德国隐私法规,它表述了一种观点:仅保存在业务上或者合法性上绝对必要的个人信息。客户隐私依然是一个热门话题。像 Uber 这样的企业正在收集高度个人化的客户数据,然而他们的安全措施却非常糟糕(washingtonpost.com/blogs/the-switch/wp/2014/12/01/is-ubers-rider- database-a-sitting-duck-for-hackers)。这是一场注定要发生的灾难。即便是在尚无法律规定的地区,我们也应该尽量遵循数据紧缩的原则,或者使用“去身份识别技术”(en.wikipedia.org/wiki/De-identification)来减少所存储的信息——如果你根本就不保存这些信息,你也就用不着担心有谁会盗取它。

作为一种集成方式,通过HTTP使用ATOM风格的事件摘要(feed)最近受到了很多关注。大多数情况下我们并不需要维持一个实时更新的服务,使用旧式计划批处理进程来创建和发布摘要就够了。在和云技术结合后,比如Amazon的S3文件存储和超媒体链接,可以创建一个高度可用、简单而又可测试的解决方案。我们团队已经开始把这个新旧交替的方法叫做‘Hipster batch’。

当我们实现单页应用(single-page applications)时,“离线使用”这个问题迟早都会浮出水面。鉴于很难正确的将离线模式加入一个现有的应用中,“离线优先”的思想已经成为了开发单页应用的一种趋势。本地存储同步(local storage sync)就是一种我们曾经成功运用过的重要实现技术。使用这种技术,面向用户的代码将不再发送请求到后端系统,而是仅仅从本地存储(local storage)中获取数据。并由一个后台服务对本地存储和后端系统进行同步,通常,会调用某种形式的REST API。

NoPSD (thoughtworks.github.io/p2/issue02/continuous- design) 运动,旨在将设计活动整合进“迭代-反馈”循环中,以构建出优秀的软件。取这个名字,不是在讽刺Adobe的软件,而是要去除“PSD文件”这个“终极权威设计图”。团队不应在项目一开始就制定一个完美的像素级设计规范,而是要开始拥抱持续设计(Continuous Design):把设计师加入到交付团队中,使用低保真技术来做原型设计,并使用目标产品实际用到的UI技术(通常是HTML和CSS)来共同细化设计。

这种方法提高了对真实用户反馈的响应速度,支持横跨多种设备及其不同形态对设计进行测试,积极拥抱数码产品和产品创作过程的灵动本性。

依据团队边界分隔基础设施

我们的很多客户与负责构建、部署、支持他们的应用和服务的交付团队合作,在组织中实现了DevOps(技术运维)。然而不幸的是,在交付团队实施DevOps的道路上,经常会受困于生产环境中超级用户权限的归属问题。

在大多数组织中,生产环境是被共享的,因此提供宽泛的权限有很大的风险。一个行之有效的措施是将基础设施按照团队边界进行分隔,于是每个团队通过安全又相互隔离的访问进行工作,而不会影响到其他系统。如果是使用云环境,只需要对齐账户结构与团队边界,这种方式就更容易实现。

Middleman和Jekyll这样的静态网站生成器已经被广泛用于简单网站或博客的创建,同时我们也越来越多的看到它们成为更复杂技术栈的一部分。随着越来越多的团队开始尝试使用静态的预生成内容,认为“HTTP回复的内容只能根据请求来动态创建”的默认假设正在改变。

因为有像Clojure这样的函数式编程语言的默认支持,不可变数据结构(Immutable data structures)开始变得越来越流行。“不可变性”使得代码更容易被写、读和理解。使用“只追加”式的数据存储(append-only data store)同样带给数据库层面一些这方面的优点,同时也使得审计和历史查询更加简单。实现方式有很多种,从专门使用Datomic (datomic.com) 这样的“只追加”数据库,到简单以“只追加,不更新”的方式来使用传统数据库。

尽管比特币和其他各种密码货币(cryptocurrencies)现在备受关注,但让我们同样激动的是,Blockchain很有可能代替比特币和财务交易。Blockchain是一种不依赖于中央服务就能验证共享账簿的机制。我们已经看到Blockchain(不管是底层技术或是公开的比特币Blockchina)被用在身份验证、所有权、记录、投票、云存储甚至管理智能设备网络等各种系统的核心部分。如果你正在构建的系统需要在去中心化的网络中建立信任,那么Blockchain是一项值得尝试的技术。

一个企业级数据湖(Data Lake)是对大量原始格式的数据进行的不可变数据存储,它不仅作为其它处理流的资源,还可以为大量使用高效处理引擎的内部技术消费者(Consumer)—— 例如HDFS或基于Hadoop的HBase,Spark或Storm处理框架 —— 提供直接访问通道。与典型系统相比,这些系统会将原始格式的数据收集到严格受限的空间中,而且只会把严格受控的ETL过程生成的结果提供给这些消费者使用。

拥抱“数据湖”的理念就是要去除因缺少ETL开发人员或是堆积了太多前台数据模型设计而造成的瓶颈。它旨在帮助开发人员以敏捷的模式,基于他们需要数据的时机和方式(在合理的限度内),来创建他们自己的数据处理管道。这也与我们评价很高的另一模型——技术运维(DevOps)模型有很多相同点。

Gitflow是基于Git的一个严格的分支发布模式。虽然不是一个糟糕透顶的模式,但我们经常看到它被滥用。如果特性(feature)分支和开发(develop)分支是短暂并且频繁合并的,那么你确实是在发挥git的威力,它让团队合作变得更容易。然而,我们经常看到的一个问题是,这些“长寿分支”导致可怕的合并冲突,很多人重新开始使用git来避开这个问题。合并就是合并!无论你使用代码控制工具还是使用模式都不会改变这一点。如果你等一天或两天以上再合并,你就很有可能会遇到一个大的合并冲突。如果你在一个更大的团队中,这将成为一个真正的“问题”。如果你有更多的人在等待合并,这将进一步成为一个严重的瓶颈。成功引入像Gitflow这样的模式需要团队遵守“频繁合并、成功合并”的纪律。所以,当然可以使用这个模式,然而必须严格遵守“防止出现长寿分支”的纪律。

我们依然深信,在提高团队自主权和应对更加快速频繁的变更方面,微服务能给组织提供显著的优势。然而分布式系统所带来的额外的复杂性,需要更多的成熟度和投入。要做好微服务,就必须了解微服务给开发、测试和运维带来的变化。我们担心的是,一些团队在还没有弄清楚这些变化之前,就仓促地采用了微服务的方式。我们的建议非常简单,不要迷信微服务,在一股脑地开发更多微服务之前,从一个或两个服务开始,让你的团队有时间来调整并探索合理的微服务粒度。

我们仍然看到,一些团队会直接把复杂的多行命令插入到CI或CD工具的配置中。通常,这些内嵌的命令也包含了一些只在构建环境起作用的步骤,包括CI相关的环境变量,一些只会在CI环境创建、修改文件和模板的步骤,等等。这让构建环境变成了一头“怪兽”——其结果在开发人员的本地机器上是无法复现的。

这个问题之所以非常严重,是因为 — CI/CD工具本应该去暴露你代码中的问题,然而它自己却成为一个“复杂性怪兽”,其行为难以调试,结果也难以复现。

我们可以将复杂的构建过程提取成一个简单的脚本,这个脚本能通过一行命令来调用,这样就避免了在CI/CD工具中编程。它能够在任何一台开发者的机器上执行,这样也就消除了构建环境本身的独特性超。

把敏捷实践扩大到企业级,是一项持续的挑战。SAFe™在相关的众多方案中脱颖而出。虽然SAFe™为一些需要关注的方面提供了一份很有用的检查单,然而因为囊括了像“发布火车(release train)”和“门控流程(gated control processes)”这样已不再被敏捷社区认可的大型发布策略,此类方案往往容易被误用。企业倾向于寻找的具有一定程度通用性、可横跨多方努力的方案,看起来,这正是SAFe™所提供的,它所具有的某种程度的可定制性使它更具价值。事实上,其他的精益方案,比如像“改进道场(Improvement Katas)”这样,主张边试验、边持续改进的实践,为不断扩大敏捷实践的规模提供了一个更好的模型。

对于安全,传统的方式依赖于前期的规范以及最后阶段的验证。这种“安全三明治”的方式很难应用于敏捷团队,因为大部分设计都贯穿于整个过程,而且也没有利用到持续交付所提供的自动化便利。公司或组织应着眼于如何在整个敏捷开发周期中注入安全实践。这包括:正确评估威胁模型以做前期设计;考虑何时将安全问题划分为独立的故事(Story)、验收标准或全局的非功能需求;在构建流水线(Build Pipeline)中引入静态或动态的自动化安全测试;考虑如何将更深层的测试,如渗透测试,引入到持续交付的发布过程中。正如DevOps的出现使得过去相互博弈的团队能够重新合作一样,同样的事情也正发生在安全人员和开发人员身上。

本文分享自微信公众号 - 思特沃克(ThoughtWorks)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2015-01-29

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 团队空间:敏捷团队的办公室设计

    Martin Fowler在他的一篇博客(Team Room)中介绍了ThoughtWorks对敏捷软件开发团队所应采用的“团队空间”的观点:团队空间内部应当完...

    ThoughtWorks
  • 获取信任和确立愿景 | 驱动变革

    很少有人会对改变自身行为习惯感到舒适,特别是对于指引改变的人没有足够了解和信任的时候,这种感觉尤为强烈。由此便会出现观望、消极、非暴力不合作、甚至是抵触反对的态...

    ThoughtWorks
  • 持续交付模式下的安全活动|洞见

    在上一篇文章《开发团队面临的三大安全挑战》中,我们对现如今敏捷精益团队所面临的安全挑战进行了总结和分析,这三大挑战分别是: 一次性的安全检查无法匹配持续性的交付...

    ThoughtWorks
  • 解决IE响应式的解决方案css3-mediaqueries.js不生效问题

    前阵子解决了博客在低版本 IE 下会假死的问题,发现居然是因为我自定义 CSS 的闭合误用了中文大括号导致的! 解决这个问题之后,又发现了另外一个坑:发现博客在...

    张戈
  • 【开源】微信小程序、小游戏以及 Web 通用 Canvas 渲染引擎 - Cax

    用于分组, group 也可以嵌套 group,父容器的属性会叠加在子属性上, 比如:

    用户1654868
  • 对象深拷奥秘

    用户7873631
  • 从工程师转变为工程经理过程中所学到的

    导师很重要——尤其是在公司内部 当开始第一份工作时,我确信已经找到了软件工程相关的工作。这是由于在上半年就完成了硕士课程,并在这方面完成了一些比较成功的小型项目...

    CSDN技术头条
  • 真正的高手,都有增长思维!(深度好文)

    讲的是aha moment和AARRR,本身就是要和产品紧密结合的,是产品层面的事,所以也符合做好一个产品的基本规律。

    用户6983566
  • Python解释器的安装步骤

    Python是一门强大的语言,目前已支持所有主流操作系统,在Linux,Unix,Mac系统上自带Python环境,在Windows10系统上需要安装一下,超简...

    郭楷丰
  • js根据经纬度换算行驶里程

    最近在做有关车辆定位及历史轨迹的项目,需要显示车辆当前位置信息、车辆历史轨迹及行驶公里数,需要这样的效果。

    青年码农

扫码关注云+社区

领取腾讯云代金券