为了交付最好的结果，每个开发人员都应该既是架构师又是问题解决者。有时我的脑子里会冒出“微分辨率”这样的想法。基本上，微观决议是关于我应该开始做的事情，这些事情在重要性方面还没有达到我生命的高度。审稿过程中，发现了一个读者朋友提出的问题。你提到你自己并不喜欢“建筑师”这个头衔。我同意这一点，因为架构师这样的词在不同的企业有不同的含义。根据我个人的经验，架构师可能需要编写代码、设计UML图或简单地编写Word文档。您不认为开发人员应该是既是架构师又是问题解决者的程序员吗？就我的职业生涯而言，我担任过这里提到的所有工作，所以我的观点可能存在一定的偏见。但换个角度，我们不妨把问题组织成另一种形式，即“每个开发人员都应该有架构师的头衔”还是“每个架构师都应该有开发人员的职能”？在对问题进行了这种简化之后，我的回答是肯定的。是的，每个开发人员都应该是一个既是架构师又是问题解决者的程序员。此外，每个开发人员都应该拥有架构师的头衔。是的，每个开发人员都应该是“架构师”。话虽如此，我还是忍不住想探究一下架构师和开发人员之间的区别。再来看看程序员/软件工程师和架构师的区别：关注范围：程序员关注具体细节，而架构师关注“大局”。领导关系：程序员处于领导地位，架构师起主导作用。资历背景：架构师的职业生涯一般比程序员更长。气质特征：架构师是伟大的梦想家，而程序员是面向乏味任务的实干家。技术导向：架构师做出选择，程序员提供选项。技能：架构师的技能水平高于程序员。代码：平均而言，架构师需要编写的代码比开发人员少。组织互动：架构师参与的“业务”会议远多于程序员。薪水：架构师的薪水高于程序员。自我价值：架构师的价值高于程序员。这些是业界看待两者之间差异的方式。架构师经验更丰富，重要性更高，技术价值更可观，因此市场需求更迫切；而且因为他们太挑剔了，所以他们的主要精力常常用在其他事情上——而不是写代码——身体。这显然是一种令人困惑的定义方式，甚至是自相矛盾的，而且角色内部定位的模糊性，也让我们很难用一刀切的方式作为其评判标准。正因为如此，一些企业中的架构师将负责构建UML图，而其他架构师将做与开发人员完全相同的工作。问题是我们倾向于使用一个笼统的定义来概括实际上极其复杂的概念，而缺乏对细微差别的关注在定义和实质之间造成了巨大的差距。其实，我们的生活是稳步向前的，每个人都会经历年少、青涩的开始，逐渐完善、成熟，最终随着时间的推移收获努力的回报。我们的工作环境认识到这种逐渐改善的趋势，并基于精英制度奖励这种增长。在这条路上，我们会慢慢迎来自己的“高级”、“首席”等花环，而领导能力则体现在“架构师”、“经理”、“主管”等头衔上。头衔越高，肩负的责任和期望就越重要。此外，在这个提升过程中，我们必然会在领导层和业务层上加把劲，从原来的“注重细节”、“勤奋”的青年向“注重宏观”、“高瞻远瞩”的管理转变。到这个时候，我们已经不再执行特定任务，而是更多地成为“思想领袖”。在这种情况下，“建筑师”的角色以及“建筑师”这个头衔都有了明确的含义。两者都是对大家完成任务的一种认可，意味着你成长为一个比以前更重要、更有价值、功能更好的角色。这也意味着我们将从事与以往不同的工作，扮演不同的角色，承担不同的责任。但如果我们暂时搁置这些价值判断，这两个角色之间的其他区别是什么？我们可以将这种差异进一步形象化，这种差异往往广泛存在于各个行业和学科中。一类角色负责决策，是“大局观”，较少“动手”，而另一类角色执行更集中的任务，负责“动手”解决问题。说起来，我们可以把它比作在律师事务所工作。公司合伙人负责案件中的重要决策，而其他更具体、更简单的任务则由助理执行。但需要强调的是，人气小伙伴的工作和看似普通的小助手的工作没有本质区别——他们只是整个业务系统中的一个操作点，负责完成分配的任务。考虑到这一点，我们可以将相同的逻辑带入编程世界：有经验的开发人员负责做出技术决策（并围绕它们构建实现），编写最困难和/或最关键的代码段，同时，管理团队并将他们能力范围内的任务分配给新开发人员。回应文章开头，每个开发者都应该成为某种程度上的架构师，或者说每个开发者都应该同时关注软件的宏观定位和具体细节。有些开发人员技能更高、经验更丰富（当然报酬也更高），他们也了解应该做出多么重要的技术决策并分配给谁。不过，从根本上说，角色定义与普通开发人员的角色定义没有什么不同——它只是更高级别的信任，或者说是每个开发人员都应该拥有的信任级别。如果我要组建一个团队来构建软件解决方案，我绝不会寻求拥有两个截然不同的成员：一个作为思想领袖致力于广泛的规划和技术决策，另一个负责日常任务和细节工作。最理想的场景是团队中的每个成员都知道如何解决问题，并通过这两种不同的立场和视角来审视问题的定义和细节。从另一个角度来看，同时具备这两种能力的开发人员必将成为企业中的IT摇滚明星。原标题：每个开发者都应该是架构师
