今天搜索了一些资料，无意中发现thoughtworks technology radar这个词，google一下，技术雷达竟然是一座金矿。。。特别记录在这里。

还在读研的时候就已经关注thoughtworks了，Martin Fowler大神的公司啊。不过自己对thoughtworks的认知一直很肤浅，一直觉得它是一家专业搞java的公司。今天发现的技术雷达颠覆我对它的认知。

可以认为技术雷达其实是thoughtworks的一项免费信息服务，可以使用邮件订阅此服务，它将技术/平台/工具/语言&框架等技术领域不同的关注点都划分到了4个阶段：

• 采纳(Adopt)。强烈主张业界采纳这些技术。thoughtworks会在在适当时候将其用于他们的项目。
• 试验(TRIAL)。值得追求。重要的是理解如何建立这种能力。企业应该在风险可控的项目中尝试此技术。
• 评估(ACCESS)。为了确认它将如何影响你所在的企业，值得作一番探究。
• 暂缓(HOLD)。谨慎推行。

在技术雷达中搜索了golang。在2014年1月被认为是试验阶段，在2014年7月和2015年1月两次被认为是应该采纳的技术。不得不说，大神的公司就是有眼光和远见！最新一期的技术雷达，将最近很火的rust列为了试验阶段。

雷达中的最新动态很有意思，是非常有技术广度和深度的思考。为了验证其思考的正确性，专门将其历史数据找出来了，比如，2017年11月版的技术雷达，就将kubernetes列为了容器编排首选的技术。真的很有远见！在最近一期的最新动态中，以下观点值得学习和思考：

架构师和开发人员应该密切关注各种工具和模型提供的新功能，同时保持勤奋好学，不要完全以对待现有工具的常用方法来使用新工具。我们必须认识到数据形势正在发生重大变革，并坚持寻找合适的策略和工具。

开发人员喜欢抽象层，原因很明显，因为他们可以将复杂问题封装到抽象层中，从而集中精力处理更高层级的问题。一开始他们关注的是Docker及其生态系统。然后焦点开始转向Kubernetes。现在，我们发现主要活动总体上都集中在基础设施即代码方面，尤其是集中在Terraform生态系统上。

随着“一切即代码”理念的盛行，以前难以改变的绝大多数环节（基础设施、安全、合规性和运营），几乎都变得可以通过编程来处理，这就意味着开发人员可以采纳更完善的工程实践。请避免将业务逻辑放在配置文件中（并且避免使用要求将业务逻辑放在配置文件中的工具），尽可能减少必须执行的编排操作，不要让编排功能主导你的系统。

一切即代码，这个应该是一个趋势。这样看来，程序员是一个面向未来的职业了：）

在12-FACTORS中，配置是非常重要的一点，技术雷达中还进行了细化，提醒大家不要将业务逻辑放在配置文件中！这个绝对是实践后的总结，非常贴心！

在技术百花齐放的年代，技术雷达能给我们过滤掉很多无效信息，并将一些最佳实践传递出来，感谢thoughtworks！

PS: 前段时间买了Martin大神的重构第二版，也算支持他们公司了吧：）