Views: every programmer should be architect-architect, programmer-IT information
If you want to deliver the best results, every developer should both architects and the twin role of problem solvers.
Sometimes I will pop up in my head like "micro-resolution" of this idea. Basically, micro resolution are to be discussed, I should do it, but could not reach the height of life in importance.
During the review process, I found the one reader's questions.
You mentioned that you actually don't like "architect" titles. I agree, because the architect the vocabulary in different enterprises have different meanings.
According to my personal experience, the architect might need to write code, design UML diagrams or simply compose Word documents.
Don't you think the developers themselves should be someone who is also the architect role and problem solving are two types of programmer?
In my professional life, I served as the jobs mentioned here, so my opinion may be biased to some extent. But from another point of view, we think of the problem into another form, that is, "if every developer should have the title of architect" or "is not every architect should developers functions"?
After you make such simplification of issues, my answer is Yes.
Yes, every developer should be one who is also the architect role and problem solving are two types of programmers. In addition, each developer should have title of architect. Yes, every developer should be charged with "architect" duties. Having said that, I can't help but want to explore the difference between architects and developers.
Programmer/software engineer and architect under where the difference between:
? Focus range: programmers focus on details, and architects focus on "macro perspective".
? Leadership: the programmer was in a leading position, the architect is playing a leading role.
? Qualifications: background: Architect working time is generally longer than programmers.
? Quality characteristics: architects dream is important, and the programmer is a tedious task-oriented doers.
? Technical orientation: architect to make a choice, and the programmer provides options.
? Skills: architect's skill level is higher than a programmer.
? Code: Architects need to write code with an average of less than developers.
? Organization of interaction: architect involved in "business" Conference far more than programmers.
? Remuneration: architect salary levels higher than programmers.
? Value: the architect in a higher value than programmers.
View on the difference between these is the industry for both ways. Architect experience richer and more importance, value, technology are even more impressive , and therefore has a more urgent market demand; and because they are so key, focus has often been used in other services-rather than writing code-the body. The definition of apparent chaos, or even contradictory, and the inherent ambiguity of roles also made it hard for us to adopt a broad-brush approach as its criteria. Because of this, some enterprise architects are responsible for building UML diagrams, and other architects, working with developers work exactly the same.
The problem is that we tend to use a general definition to summarize in fact extremely complicated concept, and the lack of attention to nuances led definition and essence of great dislocation.
In fact, our lives steadily forward, everybody experienced the beginning of young, inexperienced, and over time gradually increased, mature and ultimately stems from efforts to return. We recognized this trend of gradual improvement of the working environment, and based on meritocracy system rewards such growth. In this way, we will slowly have their own "senior" as well as "Chief", Garland, and the leadership is reflected as "architect", "Manager" and "competent" and other titles. Title rank higher, our responsibilities and expectations are more important. In addition, in this process, we will inevitably rise in the leadership and operational level step by step, and the original "attention to detail" and "diligence" youth in transition "focuses on macro" and "visionary" managers. At this time, we did not perform a specific task, and more a "thought leader."
In this context, the "architect" role and "architect" title has a precise meaning. Both task execution results to all of a recognition, means that you have grown to more than had been more important and more valuable and better functional roles. This also means that we're engaged in is different from the past work and play the different roles and responsibilities of different responsibilities.
But if we put aside these values, then what other differences are there between these two roles?
We can further visualize this difference, then such differences often exist widely in the various sectors and disciplines. A role is responsible for making decisions, that is focused on "macro" and less "personally", and the other roles perform more specific tasks, is responsible for "hand" to solve the problem. Here, we compared it to working in a law firm. Partner is responsible for important decisions in cases, while others are more specific and simple task done by assistants.
But it needs to be stressed is that hot partners work with ordinary Assistant in essence no different – they are just set one of the operating system running, charge has been entrusted with the task. Bearing this in mind, we can apply the same reasoning applied to the programming world: experienced developers responsible for technology decisions (and set up with the core of its implementation system), preparation of the most difficult and/or key code fragments, and operations teams and assign them to new developers can do the task.
In response to the beginning, each developer should have in part become architects, or that every developer should also focus on the software of macro-localization and specific details. Some developer skill levels and more experienced (naturally with better pay and benefits), and they also know how to make important decisions at the technical level and who assigned the task to complete. But from a fundamental perspective, role definition and no different from ordinary developers--just its trust level higher, or up to each developer should reach the level of trust.
If I build a team to build a software solution, never deliberately sought two distinct types of members: part specifically as thought leaders implement generalized planning and decision making, and others responsible for day-to-day tasks and details. The ideal scenario is that everyone in the team knows how to solve the problem, through which two different positions and look at the definition and details of the problem to. From another perspective, and has the ability to both look at the developers will IT become rock stars.
观点：每个
程序员都应该成为架构师 - 架构师,
程序员 - IT资讯
要想交付最出色的成果，每位开发人员都应当身兼架构师与问题解决者这两大角色。
有时候我的脑袋里会突然出现像“微决议”这样的念头。基本上，微决议所要探讨的是我应该开始做，但在重要性方面还达不到人生高度的事物。
而在审视过程当中，我发现了一位读者朋友提出的问题。
您提到您自己实际并不喜欢“架构师”这样的头衔。我对此表示赞同，因为架构师这样的词汇在不同企业当中有着不同的意义。
根据我的个人经历，架构师可能需要编写代码、设计UML图表或者单纯只是撰写Word文档。
您难道不觉得开发人员本身就应该是一位身兼架构师与问题解决者两类角色的程序员吗？
就我的职业生活来讲，我担任过这里提到的全部工作岗位，因此我的观点可能在一定程度上存在偏差。不过换个角度来看，我们不妨将问题整理成另外的形式，即“是不是每位开发人员都应当拥有架构师头衔”或者说“是不是每位架构师都应该承担开发者职能”？
在对问题做出这样的简化之后，我给出的答案是肯定的。
是的，每位开发人员都应当是一位身兼架构师与问题解决者两类角色的程序员。另外，每一位开发人员都应当冠有架构师头衔。是的，每位开发人员都应当身负“架构师”职责。说到这里，我不禁想对架构师与开发人员之间的差异进行探讨。
下面来看程序员/软件工程师与架构师之间的区别所在：
• 关注范围：程序员专注于具体细节，而架构师专注于“宏观视角”。
• 领导关系：程序员处于被领导地位，架构师则扮演领导角色。
• 资历背景：架构师的从业时间一般比程序员更长。
• 气质特性：架构师是重要的梦想家，而程序员则是面向繁琐任务的实干者。
• 技术取向：架构师做出选择，而程序员提供选项。
• 技能：架构师的技能水平高于程序员。
• 代码：架构师需要编写之代码平均少于开发人员。
• 组织互动：架构师所参与之“业务”会议数量远多于程序员。
• 薪酬：架构师薪酬水平高于程序员。
• 自身价值：架构师的价值要高于程序员。
这些就是整个行业对于两者之间区别的看待方式。架构师从业经历更丰富、重要性更高、技术价值更为可观，因此拥有更迫切的市场需求；而正因为他们太过关键，因此主要精力往往被用于其它事务——而非编写代码——身上。这显然是种混乱的定义方式，甚至自相矛盾，而角色的内在定位模糊性也让我们很难通过一刀切方式作为其评判标准。也正因为如此，某些企业中的架构师会负责构建UML图表，而另一些架构师则干着跟开发人员完全一样的工作。
问题在于，我们往往倾向于用一种笼统的定义来概括实际上极为复杂的概念，而对细微差异的关注缺失则导致定义与实质间存在巨大错位。
事实上，我们的生活稳步前行，每个人都经历过年轻、缺乏经验的起步阶段，并随着时间的推移而逐渐提高、成熟且最终获得源自努力的回报。我们的工作环境认可这种逐步完善的趋势，并立足于唯才是举的制度奖励这种成长。在这条道路上，我们会慢慢迎来属于自己的“资深”以及“首席”等花环，而领导能力则体现为“架构师”、“经理”以及“主管”等头衔当中。头衔等级越高，我们身上肩负的职责与期许就越是重要。另外，在这一推进过程中，我们会不可避免地在领导及业务层面步步上升，并由原本“注重细节”及“勤奋”的青年转型为“着眼于宏观”且“有远见”的管理者。到这时，我们已经不再执行具体的任务，而更多成为“思维领袖”。
在这样的背景之下，“架构师”角色以及“架构师”头衔都有着确切的意义。二者皆是对大家任务执行效果的一种表彰，意味着各位已经成长为较原先更重要、更有价值且更出色的职能角色。这也意味着我们接下来要从事的是不同于以往的工作内容、扮演不同于以往的角色并承担不同于以往的责任。
但如果我们暂时抛开这些价值判断，那么这两种角色之间还有哪些其它差别？
我们可以将这种差异进一步加以具象化，那么此类差异往往广泛存在于各行业及学科当中。一类角色负责制定决策，即着眼于“宏观”而较少“亲自上阵”，而另一类角色则执行更具针对性的任务，负责“亲手”解决问题。说到这里，我们可以将其比作律师事务所中的工作。事务所合伙人负责案件中的重要决策，而其它更具体、更简单的任务则由助理完成。
但需要强调的是，炙手可热的合伙人与看似平凡的助理所负责的工作在本质上并无区别——他们都只是整套业务体系中的运行点之一，负责完成被委以的任务。考虑到这一点，我们可以将同样的道理引入到编程世界当中：经验丰富的开发人员负责制定技术决策（并建立以其为核心的实现体系），编写难度最高以及/或者最为关键的代码片段，同时运营团队并为新晋开发人员们分配他们力所能及的任务。
响应文章开头，每一位开发人员都应当在一定程度成为架构师，或者说每位开发人员都应当同时着眼于软件的宏观定位与具体细节。有些开发者技能水平更高及经验更为丰富（自然也拥有更理想的薪酬待遇），而他们同时也了解应当如何制定技术层面的重要决策并将任务分配给谁来完成。不过从根本角度讲，其角色定义与普通开发人员并无区别——只是其信任层级更高，或者说达到了每位开发者都应达到的信任水平。
如果我构建一支队伍以构建软件解决方案，那么绝对不会刻意寻求两种截然不同的成员：一部分专门作为思维领袖执行广义规划与技术决策，而另一部分负责日常任务与细节工作。最理想的场景是团队里的每位成员都知道该如何解决问题，并通过这两种有所区别的立场与眼光审视问题的定义与细节走向。从另一个角度讲，同时拥有这两种审视能力的开发人员也必将成为企业中的IT摇滚巨星。