您现在的位置是:网站首页> 内容页

另一个角度的架构师

  • js56金沙线路
  • 2019-04-23
  • 262人已阅读
简介架构师要做什么?ADMEMS矩阵,明确介绍了架构师需要思考的问题,而在这个矩阵中,做完一个架构师最需要了解的什么呢?技术?业务?都不是,最需要了解的是你的领导,其次是你的团队成员。如果

架构师要做什么?

ADMEMS矩阵,明确介绍了架构师需要思考的问题,而在这个矩阵中,做完一个架构师最需要了解的什么呢?技术?业务?都不是,最需要了解的是你的领导,其次是你的团队成员。

如果你的领导是不懂且不放权的类型,那你的好架构要如何实现呢。如果你的团队技术烂的一塌糊涂,又如何开发出成熟的产品?看看ADMEMS矩阵,理论上是先上后下,先左后右。而现实中,应该是先右后左,先下后上。

 

看了ADMEMS矩阵,最重要的就是约束,最最重要的就是开发需求对应的约束。那么架构师要如何分析这些呢。

首先分析你的领导

1,  确定他是否能清晰的分辨出团队成员技术的高下,这个清晰很重要,要十分清晰。

2,  确定他支持你架构设计的力度,(强烈支持,还是设计的好就用不行就不用)

3,  确定他是否真的理解了架构的重要性,还是他只是为了给工作计划戴个好看的帽子,还是两者都有。

以上三点只要有一点不满足你的架构基本上就很难实现,为什么是很难而不是不能呢?因为团队成员足以弥补一些领导的能力不足。

接着分析你的团队成员

1,  你的团队成员能力差距是否过大。

2,  你的团队成员能力高的和低的比例是多少。

正所谓巧妇难为无米之炊,即使你再棒,也没办法一个人做项目。团队成员当然都是高手最好,如果是2:1也可以接受,如果是能力低的多,那就要看领导了,如果他不符合上面三点,那软件开发流程就只会是和稀泥式的前进。架构与否就不那么重要了。当成员和领导都是优秀的时候,那么在分析其他需求又有何难呢?

 

架构设计要思考的问题

一个软件架构师最重要的问题,就是他所设计的产品必须是满足客户战略规划的需求,能够帮助客户解决实际问题的。

这是理论上,或者说是书本上的知识点,现实中的变数太多。首先要考虑着三个问题,who,what,why。

Who:为谁设计?

你设计的架构是为客户设计的吗?你的客户理解你的架构的重要性吗,也许连什么是架构都不懂吧。如果你的客户理解,那么恭喜你,你是在为客户设计一套理想的架构。如果不理解,那么很遗憾,你并不是为你的客户在设计,你是在为你公司的领导在设计。那么你设计的东西就需要为他们讲解。记得,有时候领导比客户更笨拙。并且他们会要求不断解释那些1+1=2的问题。有些架构师太久不去温习那些基础,只是记得1+1=2,却忘记了如何解释,那么很遗憾你的架构将遭到怀疑。我记得以前带我的前行一位架构师和我说过这么一句话,“信则灵,不信则不灵”,这不是迷信,为什么呢?因为架构师要能把所有的东西都给领导和团队成员讲明白,那大家就都是架构师啦,不是架构师讲不明白,是对手听不懂啊。

What:要解决用户的什么问题?

性能低下?结构转换?可维护性差?领导面子?(一点不好笑,真的有公司这么做的)。

我见过一个公司,他们的产品还能运行,但改起来很难受,程序员天天抱怨。于是就请了一个架构师,目的有二,(1)修改产品结构,降低维护成本(2)使员工不要抱怨。结果当然是无疾而终了,新架构上不去,又折腾了好久。最后不愉快的离开。原因是什么呢?首先领导并不是全力支持他,这会导致什么结果呢?他必须设计出完美无缺的架构,并且拥有神一样的讲解能力,否则新架构永远是有风险的。而现在的程序还能运行,不可能去冒这么大的风险。由于这个强力矛盾的存在,那么其他问题也就应运而生了。至于性能低下,结构转换,可维护性差等等,这些技术层面能解决的问题就显得不那么重要了。

Why:为什么要解决这些用户问题?

提高用户体验?用户强制要求?合理化软件程序?为业务拓展做基础?首先要确定,这些真的是用户需求吗?还是程序员们和业务们总结出来的理想建议。如果真的是从用户那里得到的,那么恭喜你,对症下药,功德无量。如果不是,那就是事倍功半,褒贬不一。抑或在根本无法得到客户需求,那么你就只能摸着石头过河了,至于成败,就只能谋事在人成事在天了。

 

总结

其实业界很多架构师都是摸着石头过河的。又有许多架构师失败并不是因为架构和技术,只是没读懂领导的心。架构师首先要分析公司的现状,然后再设计,当然发现公司现状根本不可能完成架构时,那就要早做准备,不要等到最后背个黑锅离开。如果公司问题太多,新就架构根本是无稽之谈,那就着手于小分区的修改,这也是个长存之道。

 

, 1, 0, 9);

文章评论

Top