一个开发团队的剖析
一个开发团队由几个角色组成，每个角色都有自己独特的贡献。有时，感觉就像每一部关于一群稍微失调的朋友(咳嗽朋友、IT人群、硅谷咳嗽)的电视节目，每个开发者不仅在产品上，而且在公司氛围上都添加了自己的独特风格。他们每个人都对团队的成功至关重要，贡献了自己的特殊才华和能力，确保了团队的顺利运行。
但是当一个问题出现时会发生什么呢？例如，您从后端获得了某条数据，但该数据是不正确的和/或具有误导性的。它看起来和您预期的一样，但并不能反映您的应用程序的真实状态。这取决于你的用户是否以及何时注意到它，这可能是热爱和拥抱你的产品之间的区别，或者(可怕的是！)。而忽略了竞争对手的这一点。所以让我们来玩一个虚拟的“猜猜是谁”的游戏，看看谁是开发团队的成员。
作为领导者的开发人员通常是对大多数事情都有整体看法的人。这就是彻底阅读代码、理解代码功能并避免分心的开发人员(这是一个小小的奇迹！)。由定向注意力疲劳引起。该开发人员还与团队的其他成员进行有效的沟通，以了解可能的问题域，绘制控制流程图(智力或物理上的)，知道在哪里设置日志或断点-并最终使用所有这些来解决问题。
当遇到问题时-尤其是与误导数据相关的问题-这些是每个团队成员都可能采取的步骤。然而，领导类型是不同的，因为他们创新并激励他人，但不一定是团队的经理。他们独立理解并沟通困难、挑战、可能的解决方案和问题原因的能力，使他们成为乐团(即开发团队)的大师。
根据他们是忙是闲，他们可能会选择将问题委托给相关的一两个团队成员，或者只是使用他们非凡的解决问题的技能来自己做。
我们都认识这位开发人员。他们绝对肯定每个人都想要得到他们。如果他们在微服务X上工作并得到损坏的数据，那么肯定是微服务Y或Z导致了问题(当然与他们的😑完全无关)。偏执狂到处放置日志，这满足了他们感受到保护的需要。作为一个额外的好处，他们还咒骂了很多-可能是他们现在正在整理的大量原木线条，但嘿，不要问我们-无论他们走到哪里，都要随身携带一杯咖啡。这两者有关联吗？我们会让你决定的。😉。
这就是开发人员，他们大多相当擅长他们所做的事情；他们知道如何在问题和他们的领域之间建立联系，他们知道系统的大多数组件，即使他们不是每天都与所有组件一起工作，而且他们是伟大的导师和问题解决者。
当涉及到不正确或具有误导性的数据时，这个开发人员会发疯。它们在调用一个函数的每个文件中喷洒15条不同的日志语句，该函数可能会对我们的数据处理过程产生最小的影响。他们以某种方式设法通过审查，或者可能被迫删除一两个无用的日志行，只留下13-14个其他日志语句。它们被部署到生产中。
当来自生产环境的数据到达时-它是一团乱七八糟的东西。它包含许多数据，这些数据可能有用，也可能无用，但有几个上下文。然而，果然，它帮助我们的开发人员找到问题。他们可能需要另外5-6个日志语句，与基础架构团队进行一些咨询，以及一两个部署，但嘿，最终他们还是成功了。太棒了！
这位开发人员认真对待他们的工作。作为一个可能的超常成功者，他们早上到办公室，拿一杯咖啡，坐在办公桌前，努力做任何他们需要做的事情来实现他们的个人目标-可能是，也可能是与实际的商业目标无关，而完全与他们自己对事情应该是怎样的个人标准有关。当人们在办公室里随意的谈话中提到他们时，首先想到的就是现在，这是一个角色！。
除了对他们所做的事情非常认真之外，这些开发人员非常善于解决问题，是某种人类版本的瑞士军刀。他们可以从A到Z，几乎不依赖其他各方，而且在他们所做的事情上表现出色。
角色会试图通过拿出大炮来解决我们的问题：他们会先看看客户端应用程序触发了哪些查询，然后他们会在一个战略位置系统地添加一条日志语句，以避免在公司的日志聚合服务中制造太多噪音。然后，他们将等待该日志的代码审查，在其获得批准后，他们将合并到试运行/主控并部署到生产中。
希望不久之后，会出现一个野生日志！它包含了我们心爱的开发人员一直在等待的信息。他们确切地知道问题是什么，或者至少知道它是从哪里产生的。他们知道如何着手来解决这个问题，而且他们会用到目前为止使用过的同样的策略自己去做。最终，他们跟踪恶意SQL查询并独立修复错误。喜乐。
哦，看哪！一个新的JavaScript框架！&“虔诚的希普斯特”，改天吧。也许吧。可能吧。(好的，当然可以)。
在我们所有的超级明星中，忍者、摇滚明星、独角兽，或者你想叫他们什么都行--这一位脱颖而出。不是因为他们在所做的事情上特别出类拔萃，而是因为他们对事物的看法。这些开发人员对他们公司回音室外正在发生的事情了如指掌。他们很清楚其他公司正在做什么来解决他们的问题，他们在开发人员社区中茁壮成长，他们与其他程序员分享他们的问题，以想出最佳的解决方案-即使这些解决方案有点夸张。这位开发人员想要用他们可以使用的最新工具来做这一切，如果依赖于他们-它不会花费多少钱。
为了解决数据不正确或误导的问题，他们不想浪费时间，但他们可能没有意识到，这种确切的抱负可能会让他们寻找错误的、可能不是最优的、耗时的解决方案。
他们会花半天的时间寻找能让他们进行实时调试的解决方案。这将使他们在StackOverflow上得到一些关于如何使用gdb等工具(取决于平台)将调试器附加到他们的实时测试/试运行环境中的答案。他们会偶然发现流行的GitHub存储库，这些存储库在Reddit上获得了一定的吸引力，在他们的机器上运行其中的一些存储库进行测试，结果却发现有些东西不起作用，或者存储库本身没有得到维护。
当他们意识到这可能是一种矫枉过正之后，他们已经白白浪费了很多时间-他们会选择经典的方法，可能会咨询同事，并将日志放在需要的地方。两小时后呢？砰，问题解决了。
团队合作很重要。你肯定有自己的一群天才，在你的团队中每个人都在自己的领域，但让他们一起工作对你的团队的成功至关重要。在这个分布式技术的时代，拥有一种分布式的心态，让所有各方至少部分了解对方的领域和他们所做的事情，加上可能的调试策略，以及对他们的责任和工作流程的理解，可以使您的团队获得两倍的成功，如果不是更多的话。
最终，让你的团队彼此分享他们的知识，无论你是团队负责人还是个人贡献者，都会扩大和增强他们中的每一个人和你自己的能力。让您的团队以最佳方式运作的最好方法是为他们准备好3件事：可理解性、独立性和异步通信--其中可理解性是最突出的。
理解和独立是通过指导和让团队成员偶尔深入研究他们不熟悉的主题来实现的，甚至是通过解决不熟悉领域中的错误来实现的。让您的前端开发人员查看一下基础架构错误，并提供最少的指导，可以为团队和他们各自创造奇迹。
提高代码和软件的可理解性将造就一支熟练、有能力的员工队伍。那么，什么是理解的圣杯呢？根据金融行业的说法，这意味着系统的信息需要以这样一种方式传递，即接收信息的人很容易理解。将其转化为您的开发团队，这意味着创建软件的开发人员能够轻松地接收和理解来自该软件的数据，从而理解该软件中正在发生的事情。把所有这些理解加在一起，砰的一声！你给自己带来了一支运转良好、运转顺畅的开发团队。
