架构师如何跳出程序员的陷阱(从程序员到架构师开发运维场景实战)

如何成为不可或缺的人?

如何成为一个优秀的架构师?这个问题其实分为两种情况。

1)面霸型架构师。

2)领导眼中不可或缺的人。

前面的一种,如果你做到以下两件事,很大概率可以做到。

1)认真学习16次架构经历,完全理解背后要解决的场景问题。

2)把里面用到的技术及其在这些经历中用法背后的原理搞清楚。

下面主要讨论如何成为领导眼中不可或缺的人。为什么把这两个问题分开谈?因为面霸型架构师不一定就是领导眼中不可或缺的人。

下面讲几个笔者的真实经历。

无关职责,帮领导解决技术难题

我工作第三年的时候,认识了一个老板,他有个做国外外包的公司,觉得我技术不错,一直希望我加入。不过我没答应,只是愿意给他兼职当顾问。某个周六,他打电话给我,说他们的系统碰到一个问题,做了某一个操作后,整个页面就会冻结,怎么点都没有用,他们的技术人员没有头绪,客户一直在催,让我赶紧帮忙看看。

我打开看了一下,的确是做了操作后,整个界面都无法点击或输入信息了。然后我重现了很多次问题,发现整个界面冻结的时候,好像颜色有点不一样,会不会是一个透明的浮层置顶了?

最终确认,确实是bug造成浮层没退出。

那么为什么他们的技术人员都没有头绪?因为他们主要是后端开发,JS经验比较少。看了我的经历,你应该猜得出来,其实我也是偏后端的。

可是,你可以跟领导说,这个问题不属于我的专业范围,因为我是做后端的吗?

领导不在乎你的职责是什么,老板最喜欢的是可以帮他解决技术难题的人。

理解领导的非技术问题

再说第二个经历,这是在外企碰到的一个问题。

有一天,公司的领导过来问我:“你有没有觉得我们的开发速度很慢?是不是我们的技术不行?”

“您能跟我详细说说,是哪些地方慢?”

“产品部的人跟我说,他们现在提一个需求,经常需要好几个月才能上线,有时候一个简单改文字的需求都是这样。”

这个问题确实不好解释清楚,因为这次沟通一开始就不在一个维度上。

开发人员认为,说开发速度慢,应该是指开始开发到最终上线的时间久。

可是领导认为,一个需求从提出到最终上线的时间久,就是开发速度慢。

另外,开发速度慢算是一个技术问题吗?可以算,也可以不算。

那么最终怎么解决?

开发团队一起讨论后列出了所有影响开发效率的问题,然后能用技术解决的就用技术解决。

表18-1所列为其中两个典型问题。

表18-1 影响效率的问题

架构师如何跳出程序员的陷阱(从程序员到架构师开发运维场景实战)(1)

所以有时候领导跟你谈的问题并不是单纯的技术问题。你需要把领导的问题转化成技术可以解决的问题。

弄清领导对你的期望值

可能有人会想,开发效率低这种事情不应该找架构师,这是管理的问题。

下面接着讲第三个经历。公司原来的系统用了4年,架构相对比较老旧。然后有一个新的项目,需求比较多。

一位架构师就提议,能不能趁着这次的需求把架构更新一下。之后,他就跟另一位负责这个项目的技术总监仔细讨论了架构更新的代价和好处,最终达成了一致的意见。

然后,他们一起将这个提案给了CTO,向CTO陈述了新架构的好处及代价。

代价就是多花3周的时间,好处就是以后系统会更稳定,问题更少,迭代速度也会更快。

CTO是产品经理出身,爽快地同意了,然后团队就开始了如火如荼的项目开发。

当然,任何一个项目都有各种各样的变数。

比如业务方临时的需求变更:他们之前没考虑清楚,还有一部分流程的遗漏,这部分遗漏必须解决,否则系统无法使用。

再比如更新为新架构时,有些系统要迁移过来,有些系统决定不迁移,直接对接。但是开发过程中发现,原来决定不迁移的某个系统,因为数据库耦合的原因也必须迁移。

当然,也有部分人员因为不熟悉新架构,就需要多花一点时间去学习。

最终,项目果然延期了。

某一次会议期间,CTO就说:“咱们的架构师不行啊,这次系统上线以后如果不稳定,就把他开了。”

开发这边惊讶地问道:“为什么?还有其他的原因吗?”

CTO说:“你看这次项目,本来要一个半月做完,因为加了新架构的迁移工作,变成两个多月了,现在都快拖到三个月了。这明显是架构师的问题,早知道这样的话,还不如不换新架构。”

然后开发这边就帮忙解释道:“这其实不全是架构师的问题,项目中不是还有一些需求变更吗?”

CTO说:“我知道,但是那些需求我看了,改动不大,不至于拖期一两个月。”

开发这边都沉默了,心想:“当初迁移新架构,领导也是同意的。”然后在CTO离开后,开发团队的两个总监私底下商量,一定要保住这个架构师,不能让他一个人担责任。

后来一次聚餐的时候,CTO跟开发团队解释道,他的压力也很大,本来跟老板说好可以按时完成,结果拖了这么久。关于架构迁移,老板原来是同意的,可是第二个月他已经忘记这件事了。老板对软件研发没什么概念。

团队事后回顾了一下,这件事情之所以是架构师担责,其实最重要的一个原因在于:老板对架构师的期望值是什么?是开发效率、系统稳定性保障,还是复杂问题的突破?

而这整件事情会由架构师承担的原因就是,大家对架构师的期望值是不一样的。

所以我认为,作为架构师最重要的一点就是要明白公司对你的期望值。

小结

这就是我的3段经历。当然,架构师的优秀有很多的维度可以讲,以上经历并不代表所有公司的评判标准。

不过,希望这些分享能给你一点启发。当然,如果能够让你感同身受,那将是我最大的荣幸。

本文给大家讲解的内容是开发运维场景实战:如何成为不可或缺的人?
  • 1.觉得文章不错的朋友可以转发此文关注小编;
  • 2.感谢大家的支持!!
  • ,

    免责声明:本文仅代表文章作者的个人观点,与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺,请读者仅作参考,并自行核实相关内容。文章投诉邮箱:anhduc.ph@yahoo.com

      分享
      投诉
      首页