关于架构师与团队建设能力的一些想法(Some ideas about architects and team building capabilities)

原创不易,转载请注明出处: https://www.cnblogs.com/bee0060/p/15580245.html
作者: bee0060
发布于: 博客园

原创不易,转载请注明出处: https://www.cnblogs.com/bee0060/p/15580245.html
作者: bee0060
发布于: 博客园

前言

最近在公司参与了一些关于架构师的讨论,有了一些想法,特此写下来记录下。

最近在公司参与了一些关于架构师的讨论,有了一些想法,特此写下来记录下。

我想的问题是,对架构师来说,团队建设的能力是否重要呢?

我的看法是: 很重要

为什么呢?

我们应该时不时会听说、或参与到一些项目,这些项目越写越大,越来越难以维护,最终成为祖传代码,初始的架构原本就没有或早已不见踪影。原因有很多,如:

  • 千奇百怪的需求,加上工期紧张,开发时先实现功能,想着之后再重构,但是“稍后等于永不”,实现后基本就没重构了,长此以往,积重难返,重构的难度也越来越大,重构的热情也越来越低,最终成为祖传代码,团队成员只希望项目“能跑就行”了
  • 随着项目进展,初始架构已经无法满足,但是架构师已经脱离项目,不再提供建议,开发团队根据自己的理解和水平进行实现和扩展。如果再工期压力等,也很容易落到上一条的结果。

原因虽各有不同,导致的结果往往很相似,就是项目越来越难维护。

站在不同人的角度,对此可能会有不同的看法, 如:

架构师视角

初始架构是好的,架构都有一些基本的模式和思路,但实现过程中开发团队不理解或不能遵照架构的基本思路,也没有很好的对架构进行扩展,最终导致这个结果

初始架构是好的,架构都有一些基本的模式和思路,但实现过程中开发团队不理解或不能遵照架构的基本思路,也没有很好的对架构进行扩展,最终导致这个结果

开发团队视角

架构师给完架构设计就走了,加上需求和进度压力,我们只能优先实现功能。随着功能越来越多,原来的架构已经不满足需求,也没人可以问,只能按我们的理解先把功能实现。

架构师给完架构设计就走了,加上需求和进度压力,我们只能优先实现功能。随着功能越来越多,原来的架构已经不满足需求,也没人可以问,只能按我们的理解先把功能实现。

综合来看,我想到的主要原因有:

  • 架构被不正确的实现,以致慢慢失控
  • 架构逐渐无法满足需求

以我个人经历来说,过去有过好几个项目,架构师都只在前期参与项目,甚至只给出架构设计就很快撤出项目,之后也不跟踪项目进展和给出调整建议。如果这个是业内的大多数情况,那可能这个就是根源所在。

首先,为了避免过度设计, 架构可以有扩展性,但是不可能也不应该面面俱到为将来可能的需求做过多的设计,因为项目走向是不确定的,过度设计往往弊大于利,所以架构是有适应范围和有效期的,随着需求的增加和演变,架构会慢慢变得不适应。所以很多人说,好的架构是演化来的。对此我深以为然。所以项目的不同阶段,需要将架构按不同的需求进行调整。

这之后如果架构师不再支持团队,项目前期架构师与开发团队的沟通是否足够,是否将设计思路很好的传达给了团队?如果没有一个很好的沟通渠道让开发团队可以定期咨询架构师架构上的问题,加上团队人员流动,一个项目进展一段时间后,团队里有没人和架构师打过交道都不知道,那项目的实现自然很难和架构师所期望的一样。

那怎么解决这些问题呢?

首先,我觉得架构的实现过程,不光是实现,也是一个验证过程。
实践是检验真理的唯一标准。

一个架构,无论多被看好,或用了多好的模式和方法论,如果没有被实现出来,终究还是有点像纸上谈兵。只有被真正的实现出来,才能判断其最终的优劣和价值。

加上前面提到的问题,对成功实施一个架构,我认为以下几点都很重要:

  • 架构师对团队的持续支持
  • 靠谱的开发团队
  • 架构师和开发团队之间的良好沟通

然而,好的团队不会从天上掉下来,也不是每个架构师都有好运气遇到好团队的。

那怎么办呢?

所以,就引出开篇时的论点:

团队建设技能对架构师很重要!

架构师与团队建设

如果架构师有很好的团队建设技能,那么应该能大大提高项目成功的概率。

我认为的架构师和开发团队的理想合作方式是:

架构师给出设计,并持续支持开发团队,持续跟踪项目进展,主动或被动给出关于架构和实现的建议。

架构师给出设计,并持续支持开发团队,持续跟踪项目进展,主动或被动给出关于架构和实现的建议。

而比这个更好的合作方式是:

架构师给出设计,持续支持团队,且参与团队的建设与管理。

架构师给出设计,持续支持团队,且参与团队的建设与管理。

我们可以参考历史,古代能打善战的将领们不光擅长用兵,同样擅长练兵!
很多名将们都有自己练出来的军队,如明代戚继光有戚家军,岳飞的岳家军,孙传庭有秦兵等等
要打胜战,先要练兵!
难道做项目不是这样吗?

在项目范围内, 我觉得将一个持续支持团队看成项目的将军并不为过,而开发团队则是他的军队。

一个项目的成败,不光开发团队有责任,架构师也有责任。
开发抱怨架构,或架构师抱怨开发团队,最终都不能解决问题。
无论架构师还是开发团队,都应尽己所能提高项目的成功率。
如果架构师具备建设出一个靠谱开发团队的能力,无论对架构师还是开发团队或是对项目、公司,都是非常重要且有益的。

反面的例子是: 如果一个架构师,掌握很好的架构技术,但是参与架构的项目都失败了,那这个架构师的价值如何体现、如何证明呢?

结尾

综上所述,重提我的论点:

团队建设技能,对架构师来说,非常重要!

谢谢观看。

欢迎提出你的观点和经验,互相交流学习。

————————

Original is not easy, please indicate the source: https://www.cnblogs.com/bee0060/p/15580245.html
Author: bee0060
Published in: blog Garden

Original is not easy, please indicate the source: https://www.cnblogs.com/bee0060/p/15580245.html
Author: bee0060
Published in: blog Garden

preface

Recently, I participated in some discussions about architects in the company and had some ideas. I hereby write them down and record them.

Recently, I participated in some discussions about architects in the company and had some ideas. I hereby write them down and record them.

The question I want to ask is, is the ability of team building important to architects?

My opinion is: < strong > is very important < / strong >.

Why?

We should hear or participate in some projects from time to time. These projects become larger and larger, more and more difficult to maintain, and finally become ancestral code. The initial architecture has not been or has long disappeared. There are many reasons, such as:

  • Due to the strange demands and tight construction period, the functions are realized first during development and then reconstructed. However, “later is equal to never”. After implementation, there is basically no reconstruction. In the long run, it is difficult to return, the difficulty of reconstruction is becoming greater and greater, and the enthusiasm for reconstruction is becoming lower and lower. Finally, it becomes ancestral code. Team members only hope that the project “can run”
  • With the progress of the project, the initial architecture can not be met, but the architect has left the project and no longer provides suggestions. The development team implements and expands according to its own understanding and level. If the construction period is under pressure, it is easy to fall to the result of the previous article.

Although the reasons are different, the results are often very similar, that is, the project is becoming more and more difficult to maintain.

From the perspective of different people, they may have different views on this, such as:

< strong > architect perspective < / strong >

The initial architecture is good. The architecture has some basic patterns and ideas, but the development team does not understand or follow the basic ideas of the architecture in the implementation process, and does not extend the architecture well, which eventually leads to this result

The initial architecture is good. The architecture has some basic patterns and ideas, but the development team does not understand or follow the basic ideas of the architecture in the implementation process, and does not extend the architecture well, which eventually leads to this result

< strong > development team perspective < / strong >

The architect left after finishing the architecture design. With the pressure of demand and schedule, we can only give priority to the implementation of functions. With more and more functions, the original architecture can no longer meet the requirements, and no one can ask. We can only realize the functions according to our understanding.

The architect left after finishing the architecture design. With the pressure of demand and schedule, we can only give priority to the implementation of functions. With more and more functions, the original architecture can no longer meet the requirements, and no one can ask. We can only realize the functions according to our understanding.

Overall, the main reasons I think of are:

  • The architecture was implemented incorrectly and slowly got out of control
  • The architecture is gradually unable to meet the requirements

In my personal experience, there were several projects in the past. Architects only participated in the project in the early stage, and even withdrew from the project soon after giving only the architecture design, and then did not track the project progress and give adjustment suggestions. If this is most of the situation in the industry, it may be the root cause.

First of all, in order to avoid over design, the architecture can be extensible, but it is impossible and should not do too much design for possible needs in the future. Because the project trend is uncertain, the disadvantages of over design often outweigh the advantages, so the architecture has an adaptive scope and validity period. With the increase and evolution of requirements, the architecture will gradually become unsuitable. So many people say that good architecture evolved. I think so. Therefore, in different stages of the project, the architecture needs to be adjusted according to different needs.

After that, if the architect no longer supports the team, is the communication between the architect and the development team sufficient in the early stage of the project, and whether the design ideas are well communicated to the team? If there is no good communication channel for the development team to regularly consult the architect on the architecture, coupled with the flow of team personnel, after a project progresses for a period of time, it is not known whether anyone in the team has dealt with the architect, the implementation of the project is naturally difficult to be the same as expected by the architect.

So how to solve these problems?

First of all, I think the implementation process of the architecture is not only an implementation, but also a verification process.
Practice is the only criterion for testing truth.

No matter how promising an architecture is or how good models and methodologies are used, if it is not implemented, it is still a bit like talking on paper. Only when it is truly realized can we judge its final advantages and disadvantages and value.

In addition to the problems mentioned above, I think the following points are very important for the successful implementation of an architecture:

  • Continuous support of the architect to the team
  • Reliable development team
  • Good communication between architect and development team

However, a good team will not fall from the sky, and not every architect has good luck to meet a good team.

Then what shall I do?

Therefore, this leads to the opening argument:

< strong > team building skills are important to architects

Architects and team building

If the architect has good team building skills, it should greatly improve the probability of project success.

I think the ideal way for architects and development teams to work together is:

The architect gives the design, continuously supports the development team, continuously tracks the project progress, and actively or passively gives suggestions on architecture and implementation.

The architect gives the design, continuously supports the development team, continuously tracks the project progress, and actively or passively gives suggestions on architecture and implementation.

A better way to cooperate is:

The architect gives the design, continuously supports the team, and participates in the construction and management of the team.

The architect gives the design, continuously supports the team, and participates in the construction and management of the team.

We can refer to history. In ancient times, generals who were good at fighting were not only good at using troops, but also good at training troops!
Many famous generals have their own trained troops, such as Qi Jiguang’s Qi family army in the Ming Dynasty, Yue Fei’s Yue family army, sun chuanting’s Qin army and so on
To win the war, we must train our troops first!
Isn’t it like this?

Within the scope of the project, I don’t think it’s too much to regard a continuous support team as the general of the project, and the development team is his army.

The success or failure of a project is not only the responsibility of the development team, but also the responsibility of the architect.
Developers complain about the architecture, or architects complain about the development team, and ultimately they can’t solve the problem.
Both the architect and the development team should do their best to improve the success rate of the project.
If the architect has the ability to build a reliable development team, it is very important and beneficial to the architect, the development team, the project and the company.

The negative example is: if an architect has a good grasp of architecture technology, but the projects involved in architecture fail, how can the value of the architect be reflected and proved?

ending

To sum up, I repeat my argument:

< strong > team building skills are very important for architects

Thanks for watching.

Welcome to put forward your views and experience, exchange and learn from each other.