我认为一名高效程序员可以扮演5种基本角色来高效地完成他/她的工作，这些角色以某种方式组合后更符合开发团队中的某些“人物”。你是其中的哪个（或哪些）角色？
编码者
当我们在低层次积极参与编写代码并解决问题时，我们所担任的就是这样一种角色。编码者在编程同时致力于其他小问题，但通常专注于某一项特定任务而非整体架构。如果一个非IT人员询问你工作，你告诉他们你是一名程序员，这就是他们想象中你整天所做的事。
调查者
我们想要理解一个系统需要如何工作时，我们就会担负起这种角色。调查者不会让事情有任何不明之处；她/他对事物的工作原理以及事物固定的行为方式的理解有着与生俱来的渴望。这种对代码工作原理理解的内在意愿使得调研者成为优秀的捉虫者。
理论家
在思考并解决抽象问题时，我们扮演这种角色。理论家善于将抽象问题分解成具体方案，并且善于构建系统架构，即使她/他不是非常善于实际用代码来实现这些方案和架构。
逻辑者
该角色允许我们有批判性和逻辑性地思考问题。逻辑者是这些角色中最善于分析的，他们会思考这段代码为何以某种方式运行，而不仅仅是代码如何运行。她/他能够以同等权重来考虑所有可能的情况，并做出无偏见的决定，而不允许他/她的未经证实的观点来影响他们的判断。
沟通者
该角色允许我们与其他人交流并解释复杂问题。沟通者能够理解深奥的技术思想和策略，并向技术和非技术人员解释清楚。她/他善于以多种方式沟通，无论是书写（例如评论或文档），还是口头表达（例如他/她的经理提出“这个按钮是干什么的？”）。
在任何特定时间，所有的程序员都担任过这五种角色，并且能够按照意愿在这些角色之间转换。然而，在我看来能够最大程度利用这五种角色的人非常少，实际上我们中大多数人会发现只有一种或两种固有角色最适合我们。
例如，你可能是一位优秀的逻辑者但却不善沟通，正因为如此你也许能够确定一段代码如何进行优化却可能无法向你的老板解释为何这样做很重要。同样地，你也许是 一位一流的编码者但是一位糟糕的理论家，因此你在开始编写代码解决问题前需要获取该问题的详细解释。这里有许多可能的组合，其中一些更为高效。
#p#
角色组合
何时可将这些基本角色组和成更加复杂的角色。也许你在职业生涯中已经遇到一个或多个扮演这些角色的人。在你的团队中，有没有一些这样的人？你是这些人中的一员吗？
编码者 + 逻辑者 + 理论家 = 优化者
优化者是能够快速有效提高代码质量的人，无论她/他是否编写了最初的代码。他们是查找哪里存在或可能引起性能问题的专家，因为他们是一流编码者，可能已经在一个框架或者另一个框架中实现过类似解决方案。当出现性能问题时，我们可以让优化者来帮我们修复问题。
编码者 + 调查者 + 沟通者 = 问题解决者
问题解决者是你在特定问题上需要帮助时可以求 助的人。她擅长获取一个给定问题并将其细分成许多组成部分使它们更易于独立研究。问题解决者是专门帮助你修复bug和重构代码的人。
理论家 + 逻辑者 + 沟通者 = 架构师
架构师负责系统设计以满足规定的要求。为完成系统设计，她能够抽象思考并对比许多彼此不同的方案以寻得最优方案。她还要能够向实际实现设计的程序员解释她的架构。
上述角色源于一些角色的组合。我们可能还会发现一些效率低下的组合，通常是由于一个人忘记担任一种或多种角色而导致。
理论家 + 编码者 + 沟通者 – 逻辑者 = 空想架构师
空想架构师为解决方案设计了架构，但却忽视了他的团队要用代码来实际实现描述方案。他不能从长远角度考虑或公正分析他的设计，他所谓的“完美”设计，一旦编写后，往往最终陷入不可维护的混乱。
编码者 + 逻辑者 – 沟通者 = 象牙塔开发者
象牙塔开发者善于依据自己的理解编写代码。他得到一个问题后将自己锁在象牙塔内，直到他“完善”了自己的方案时才出现，并且从为他的代码编写文档。他也许很聪明，但他不能（或不愿）将自己的才华与任何人分享，所以他的代码艰涩难懂，难以维护。
编码者 + 理论家 – 调查者 – 逻辑者 = “我永远没错”的开发者
“我永远没错”的开发者不能或不愿批判性地分析她自己的代码，因为他坚信代码是完美的，不需进行测试或研究。他的代码永远不会出现bug，因此总是其他人的错误。
这些仅仅是一些我在职业生涯中遇到的组合。我见过各种不同水平的五种角色，这些角色组合深深吸引了我。你遇到哪些角色的组合？除这些外，是不是还有其他角色我遗漏了，可以加入到列表中？请在评论中告知！
