质量检查架构师职位是什么意思？ 模因牧马人的完全不可理解的位置是什么意思？ 在构建体系结构时应该从什么时候开始连接测试人员？ 如何更改组织中的流程，以使参加第一次复杂会议的人不会重蹈覆辙？
尼尔·福特（Neil Ford）在他的网站上提供了三个选项：“ ThoughtWorker”（ThoughtWorks的员工，由于Martin Fowler而被很多人认识），“软件架构师”和“ Meme Wrangler”。 很快，在我们的Heisenbug会议上，他将谈论创建“进化体系结构”的方法，该方法可以随着外部环境的变化而改变。 同时，
Mikhail xomyakus Druzhinin （
Heisenbug计划委员会成员）问Neal：他的演讲与测试如何相交，等等。
-您可以先介绍一下自己和您的职业吗？-当然了 我在ThoughtWorks工作了将近14年。 在此之前，他是一家大约25人的小型咨询和培训公司的CTO，然后他开始尝试Java之类的技术。 我加入ThoughtWorks之前写的前三本书。 第一个是关于Delphi的，当时在俄罗斯和欧洲相当流行。
当我是CTO时，我已经厌倦了成为一名alpha怪胎。 当您了解的多于周围的人时，您就不会真正成长。 我开始在各种会议上发表演讲，我非常高兴能成为其他演讲者之一，因为他们非常聪明和感兴趣的人。 我开始不知不觉地寻找一家主要由真正聪明和感兴趣的人来工作的公司。 就像许多人一样，在Martin Fowler的网站上偶然发现ThoughtWorks。 在Cruise Cruise和NUnit测试库之类的东西上，我注意到它们为开源做出了巨大贡献，并做了很多非常有趣的事情。 因此，我无意中开始了ThoughtWorks的面试过程，最后我得到了工作机会。 这对我来说是迈出的重要一步，因为他们是非常聪明和非常热情的开发人员。
我可以成为一名独立顾问，但是担任这个职位我不喜欢两件事。 首先，您必须自己做所有事情：开账单，追逐别人的钱，调节现金流量等等。 我有能力做到这一点，但我对此并不感兴趣。 我的激情是软件和开发。
第二点：如果您是独立顾问，那么您很少会与某个团队进行协作。 您几乎总是一个人，我真的很喜欢团队发展。 我什至与其他作者一起写了几本书，包括我的最新著作《进化架构》。 在我看来，在一起工作时，结果要大于各个组成部分的总和。 当您在创作工作中进行协作时，无论是写作项目还是程序，您都可以获得更多观点和更一般的想法，因此效果会更好。
因此，从4月份到我进入ThoughtWorks，已经有14年了。 我非常了解这一点，因为在ThoughtWorks工作的有趣好处之一就是，如果您在公司工作了10年，便可以享受12周的带薪休假时间，无论您做什么都可以做。 之后，每5年您将获得为期6周的带薪创意假，所以我还有一年的时间直到第一个6周。 我真的很喜欢12周的课程，并期待下一个课程。 因此，您始终记得您来这里已有十年的时间：在如此愉快的假期里度过了美好的时光。
-这是一个很明显的假期，很酷。“我被ThoughtWorks聘为建筑师，并在担任董事一职之前担任了一段时间。” 现在，我的大部分工作都与软件体系结构领域相关，我在体系结构和工程实践的交集上花了很多时间（例如，连续交付）-我怀疑这里的兴趣与Heisenbug读者的兴趣相交。
特别是，最近我谈论最多的是我的最新著作《进化体系结构的构建》。 如果可以防止错误，那么测试应用程序的人员将变得更加容易。 演化架构包括用于关键架构功能的安全技术，例如可部署性，可测试性，可伸缩性，性能等。
“米姆·牧马人是什么意思？”-根据ThoughtWorks的规则，您可以选择任何职务，除了一些保留的职务，例如“ CEO”。 如果您想为自己找到一个有趣的职位，那么请。 当这套名片结束时，您可以提出一个新名片。
我的第一份工作是应用程序架构师。 这个职位反映了工作的本质，但是在大型公司中，这常常意味着您不再带来太多收益，花了更多的时间来绘制图片而不是创建任何东西。
定制开发的优点之一是您可以熟悉大量不同的项目。 我认为软件架构师天生就是“模式匹配者”：我们试图将模式应用于所看到的一切，甚至应用于现实世界中的事物。 因此，如果您是自定义开发的架构师，则必须看到很多不同的项目，看到其中的重复模式，然后看看其中哪些有效。 我意识到，实际上，我的工作是从软件生态系统中收集有趣的想法。 米姆牧马人从这里来了。
模因是作家理查德·道金斯（Richard Dawkins）创造的一个术语；它是用于指定思想的广泛单位。 每个人都可以从Internet上了解模因-这是一种机智的东西，像病毒一样传染和传播。 “纠缠”一词有两个有用的含义，第一个是在争端中担任法官，第二个是挤入人群。 我选择了Meme Wrangler的职位，因为它可以更准确地反映我现在在做什么。 而且，现在我要发行另一本书，我在Twitter上写道我“套用了另一个模因”并将其放入这本书。
-您能解释一下软件架构师应该做什么，作为软件架构师您应该做什么？“当然可以尝试，但是没有人能真正给这个定义一个成功。” 马丁·福勒（Martin Fowler）-非常乐于为编程领域的所有事物提供定义-他公开拒绝在他的
“谁需要一名建筑师？”一文中定义“软件架构师”
一词。 。
但是，如果您看一下软件架构师的角色，其中之一就是，他们应对所有难以更改的事情负责。 这都与软件系统的结构有关：您将使用哪些基本模式，使用哪种语言或使用哪种框架。 因为所有这些决定都会产生深远的影响。
架构师真正真正关心的一件事是我们所谓的“建筑参数”，也称为“非功能性需求”，但是我们不喜欢这个名字。 这些都是性能，可伸缩性，弹性，可部署性之类的东西，所有这些都是架构师的责任。 架构师可以创建一种结构，该结构将考虑程序本身的要求以及其中必须提供的所有这些架构参数。
假设您是一名架构师，并且需要创建一个软件系统结构来注册大学学生。 假设我们有一千名学生和他们必须注册的10门课程。 现在，根据我们对大学的组织方式的了解，您会如何看待：整个学期将平均分配学生，以便我们每门课程的学生人数相同，或者全部持续到最后一小时，并且然后急着一次全部记录？
这就是弹性，这是创建此类系统时必须确保的体系结构参数。 最有可能的是，这没有显示在任何地方，但是您仅基于主题区域就知道了。 这就是使软件系统的架构如此复杂的原因：您需要了解主题领域以及公司的技术能力和局限性。 例如，您可能会因为以下事实而受到限制：该关系数据库已被选择为我们公司的标准，因此我们需要提高生产率。 我们如何获得这些结果？
这是软件架构师的工作-处理所有与重要的决策有关的事实，因为它具有非常长的后果，并且以后很难对其进行更改。 该结构的许多元素（例如用户界面）非常易于开发，因为您只需要更改应用程序的一层即可。 而架构更多地是关于如何将所有这些层并置的，并且通常很难更改。
他们说微服务现在非常流行，并且这种架构是专门为不断变化的期望而创建的。 因此，对微服务结构进行重大更改要容易得多，但这是从一开始就创建的。 对于研究而言，这是一个非常有趣的话题-如何设计易于更改的体系结构，因为对于业界来说，这正是很长时间以来最困难的事情。
-关于架构和发布的问题：我越来越多地在名片和LinkedIn上看到“ QA Architect”。-这是“建筑师”一词的问题之一：每个公司都必须为此发明自己的名称。 我遇到了“ QA架构师”和“数据架构师”，“系统架构师”，“解决方案架构师”，“技术架构师”-我遇到了各种各样的架构师。 这是一个问题，因为没人能给出清晰的定义，也不能给出您想要的东西。
我什至不确定，“建筑师质量检查”对特定公司意味着什么。 这样的人会建立质量检查结构吗？ 对我而言，这更接近于架构师作为技术专家的职能，因为架构师通常也是技术项目经理。 但是架构师还处理演示文稿和文档。 因此，如果我是一名建筑师，并且对新架构有一个绝妙的主意，但是我无法发表演讲并用金钱说服人们我们应该这样做，那么我们将没有机会实现我的好主意。 这意味着沟通技巧。
这些技能适用于质量检查，执行此操作的人也可以称为“建筑师”。 您看，这是一个模糊的帖子。 许多组织只是简单地把高级工程师称为架构师，因为这听起来很酷，而且他们不知道该怎么称呼。 就像高级高级开发人员一样-好的，建筑师。 我遇到了只有一种类型的建筑师的公司，而我遇到了有数十种类型的建筑师的公司。 实际上，这些都是虚构的帖子。 从这个意义上说，我的“模因牧马人”更好，因为它显然是虚构的。
-让我们在Heisenbug的演讲方向上谈谈。 您将在测试会议上发言-您的软件质量如何？-我个人考虑系统体系结构组件的质量。 我知道，质量检查世界将软件更多地视为一个黑匣子，也就是说，从用户的角度来看，它是否存在错误和故障，功能是否正常。 当然，我对此也很感兴趣，但是我更担心错误的根本原因：为什么应用程序不可靠，为什么它会定期崩溃？ 在这里，我必须作为最后一道防线，弄清楚为什么会这样。 还有诸如性能和响应能力之类的东西。 现在在UI世界中有很多关于它们的讨论，它们有明确的指示：如果您的移动网站加载可见内容的时间超过3秒，则用户将离开并走到其他地方。
网页性能非常受关注：加载第一个可见内容之前的时间是多少，页面加载的总时间是多少。 所有这些都是质量参数，从外部观察者的角度来看，这些参数当然是可见的，我是一个应该弄清楚我们将如何构建实现这些指标的系统的人。 这可能会导致有关使用哪种Web技术的前端发生变化，但也可能导致后端发生变化。 也许，不是实时传输信息而是在数据包中传输信息，并在中间建立缓存机制？ 对我而言，质量看起来像这样：确定需求是什么，然后提出将体现这些需求的技术实施。
-您能从与质量相关的实践中给出最有趣的案例研究吗？-很难说，所有项目都是不同的，所以最好的永远是我从事的最后一个项目！
好吧，我以某种方式在一个要求与Lotus Notes部分相似的系统上工作。 还记得这么古老的程序吗？ 她是一个糟糕的程序，但是她做的非常非常好。 该程序的同步非常好：您可以下载邮件和便笺，然后乘出租车，去某个地方，当时回答所有字母，然后下次连接到网络时，所有内容都会自动卸载，同步并神奇地工作方式。
我们有一个销售系统的客户想要同样的工作原理。 因为销售人员总是在移动，并且他们必须在没有Internet连接的情况下下订单，然后一切都会同步并变得应有的状态。
我们意识到这是多么困难，因为需要提供一系列边界案例和方案。 首先，我们开发了一个完全不连接互联网的系统，然后开始同步。 而且还有很多令人头疼的问题-例如，与离线相比，在线应用程序的性能，连接时出现了明显的延迟，因为当时正在进行同步。 因此，在这种情况下，质量检查对我们来说是一个很大的分裂，因为他们发现破坏性案例破坏了整个系统。
从外部看，这似乎很简单。 像Dropbox和Google Drive这样的应用程序解决了这个问题，因此它变得不可见。 而且似乎很容易。 但是，当我们试图解决这个问题时，结果发现有一百万起边界事件。 因此，如果没有可靠的质量检查，很难找到所有的质量检查，必须将每个检查结果都返回以与应用程序结构保持一致，以确保整体结构仍然有效。
实际上，当我们在开发此系统时，对结构进行了根本性的更改，我们意识到边界事件将是经常发生且不可接受的。 这很好地说明了在体系结构设计和诸如QA之类的部件之间建立一个非常完善的反馈回路是多么重要。 太多的公司在最后一刻推迟了此操作，但如果这样做，最终很多事情都会做错了，您将不得不回去并花费大量时间来重做它。 如果您在架构开发和测试之间建立了紧密联系，则可以找到这些临界情况，并更快地更改结构。 幸运的是，我们在这个项目中非常灵活-因为这是ThoughtWorks项目，所以我们的周期非常快。 我们拥有一支非常强大的测试人员团队。
-许多测试人员问他们如何影响体系结构。 对他们来说，建筑是象牙塔中的东西。 该怎么办？-在我看来，测试人员来访建筑师并向他们解释他们的工作做得不好很有益，并且测试人员知道如何执行该工作会更好。 人们被告知时会喜欢它！ 实际上，不，他们不喜欢它，不会有任何好处。
对于这样的情况，我有一个最喜欢的口头禅：“展示比讨论更好。” 您需要证明自己的世界与他们的世界有多么不同。 如果您是测试工程师，则需要携带一个能清楚证明设计缺陷的用户案例。 如果将这种情况展示给架构师，那么这不仅是对某事的抱怨，而且是具体的演示：“现在，您的项目将无法在这种情况下工作，因此需要进行更改。” 如果他们不同意这一点，那么这意味着他们只是与现实失去了联系。 建筑师必须对现实世界中发生的事情敏感。
正如我所说，前国防部长唐纳德·拉姆斯菲尔德（Donald Rumsfeld）所写的
诗歌很少，其中谈到“著名的”和“未知的”。 因此，在每个软件项目中都有“未知的未知数”，因此任何体系结构的开发都应该是迭代的。 由于您思考的程度无关紧要，因此在尝试构建此结构时，您无法以任何方式预见的事情只会突然出现。
, , Docker. , , . , , .
. , , , — , .
, , ?
— .— ! ! , , , . (QA). , , , .
, , QA , . , , , . -, . -, .
, — . , QA , . , . , .
— , ?— . , , , - QA-, -, , data science, . , .
, . , , . - : « ». - : «, , , , , ». , , , . .
, ThoughtWorks, « » . , , deployment pipeline. , , , , , . , QA, , , , , , , . , -.
— . , «-», «QA» - ?— . ThoughtWorks , , , . , , . , , -, . , . , .
— QA ?— , , . — . , .
- , . , , , . - , . , , . , , , . , .
, . , — , 1975 , .
— 1975-?— « -» , . , . ( ), « ». , . , , - , . , . , .
, , , — , QA . , . , , . , , .
— .— , , Apple , . Wi-Fi , , . . UI, . QA, .
— , . , ThoughtWorks — ?— , , « , ». , , , .
, . ? UI, , , — , . , , , : «! !» , , 50 Jira, .
. , : , , , : , , , . , .
. , . , , , .
, — « , ». , . , , . , , . , , — , . , .
. HR, . . — , , . , - ? , , -, , , ? , - :
— ! , - ? ?
-是的
— .
15- Jira, , , . , , , , . , , - Slack, , , , Slack.
, , . , 30 . ? , . , , , . -. , . , .
: , , , , . - QA: , , email Slack, , . , , , .
— . . , -, , . .— , . , , . , , : , .
Slack! Slack — , . , , . « » , Slack. , « ». , , , , . - Slack, , , - .
, , .
-. , . — , , , . , . , - ?
— .— ! , . , . Slack, , . , Slack, , , , , , , .
— -. - , , .
. , IT-, , , , . . , , - - ?— . . - , , , -, . - , .
: - , . «, ». . , .
, . , , . ThoughtWorks, , , , . . , ThoughtWorks , .
, , , , , . « , ». , , - , — , . , - , . «»: , , , . . , , , .
, . -, . : «, , agile-, 1,3 , «», 30% ». , . : « , , , , ».
— , ?— : ? ? , . , - — . ? - — , , .
, , . , , , . , -, QA , , , , . , . , , , — , , , .
— , , , - ?— . , : , , -, , , , .
— , , , . , : « », , , .
— «architecture is abstract until operationalized», . , , ?-当然了 , , meme wrangler.
, DevOps-. , , . DevOps , , — , , .
, — , « » . . , . , : , , . , , ?
— .— , , ! , , . — , , , , , . , , , , : Docker -, - . , , .
, , — , , .
— . !Heisenbug , 17-18 , «Building evolutionary architectures: Fitness functions». , : , — .