在架构组工作是种什么体验?今天大鸡腿带你体验下~

·  阅读 17743
在架构组工作是种什么体验?今天大鸡腿带你体验下~

持续创作,加速成长!这是我参与「掘金日新计划 · 6 月更文挑战」的第1天,点击查看活动详情

前言

hello,各位大家好。先自我介绍下,我花名叫大鸡腿(PS:大家第一想法就是你为啥叫鸡腿,我也说不准一闪而过的灵感😁)我个人比较喜欢学习,平时不断提高技术能力,经常写博客总结知识,同时也希望能帮到其他开发者,一起进步~

在21年很幸运拿到阿里淘系口头offer,不过由于某些特殊原因无法去杭州,来到广州某家公司的架构组。我在这里遇到蛮多挑战,同时伴随成长了很多,这很符合我的职业规划里的理想的奋斗的地方。

你是不是也很好奇,在架构组工作是怎样的体验?接下来带你体验下

架构定义

架构,又名软件架构,是有关软件整体结构与组件的抽象描述。

大白话:梳理各个组件的关系,让他们井井有条,提高扩展性,更合理

工作内容

由于不能涉及到具体工作项目,这里我们是广泛的描述,让大家有个大概的了解

中间件

说到中间件,大家在日常开发中会经常用的,有些不是你负责的,但是流量肯定会经过。

什么中间件属于架构组管的呢?

公共的,大家经常使用的,必须还有非必须的。比如?

举个例子:网关(日常curd很少接触到,但是它是必须要有的)、apm、redis、MQ、ES、mysql and so on...

要求是什么?

当你去维护这些中间件的时候,不只是会去用,还要去了解里面的工作原理,(PS:比如有天某个中间件一些报异常,你得了解里面的工作原理,才有思路去排查)然后是可以解决中间件相关问题:需求、优化、改造。

举个栗子:基于网关做二次开发,新增额外的功能,比如说api管理、灰度发布、路由动态配置...

契约、公共工具类

这些也属于公共部分,某天我是技术群,有个大佬🙋‍♀️提了个问题:怎么在应用启动前就限死开发的相关操作?

其实有一部分,通过契约、maven 父类来指定引入jar版本,重写特定规范,比如说:序列化、协议...

至于公共工具类,这个大家都很熟悉,就是将一些好用的工具类封装起来,大家都能引用,提高开发效率~

要求是什么?

这块需要了解、熟悉maven生命周期,版本依赖的优先等级,甚至是maven插件来实现很多功能,还有就是sdk jar版本升级。

容器

一开始我也是不太熟悉这一块,慢慢工作中会有很多内容跟它挂钩,通过项目去学习。

K8S、云原生、CICD等等,以前很多工作,现在都交给云原生去解决,比如说灰度发布(istio)、限流、网关(ingress)

谈谈我的看法

云原生是一种趋势,也解放了开发很多繁琐工作。但是从另外一个角度,开发的主动性受限了。比如说你想去干某件事,你需要跟运维去协作完成,以前可能是我们引入某个中间件,这样开发主动性更强~

规范 & 文档

架构组在初期需要做的重要的工作:制定规范,包括:引入新技术规范,技术文档编写规范,开发规范...

重要性

f43b30108fbf491fcf54e915cb224d79.jpg

当没有规则的时候,我们做什么事都会很乱。只有我们定好规范,一定的流程、模板,大家严格按照这个模式去执行,才会仅仅有条。

文档

这也是我进架构组做的蛮多的工作内容,比如设计文档、架构图、工作总结

这些看似繁琐,但是必要的工作项。文档其实是我们想法一种展现,我们通过写出来,像大家描述方案可行性,全面记录某个项目各方面,比如:风险、可行性、技术以及非技术要求、工作内容、项目时间规划、大家的分工。

其次文档跟博客一样,是在锻炼逻辑能力,我们在思考过程中是发散的,在写出来的过程,需要去总结归纳,有一定的思路去编写。

业务

当看到这个标题,大家会不会感到意外呢?

曾经我带着类似的问题,请教了百度大佬肥朝😁

Q:您认为技术还是业务重要呢?我应该往哪个方向去发展?

🙋:我认为你能做到一方面突出,已经很了解不起了。毕竟人的精力跟时间是有限的。其次很多工作不是自己能决定的(PS:深有感触,不过我还是在工作上尽可能的主动

在架构组也会遇到技术跟业务的抉择。我的看法:技术跟业务有所兼容,大部分公司技术是作为赋能的角色,来带动业务产出,全部精力放在技术是不行的。

那么哪些业务是属于架构组?

大家抓住公共的,比如说用户模块、权限、基础服务(对外调用微信、飞书。。。)、开放平台,公共模块沉淀下来,需要做的是变成平台化,这样才能承接更多的应用、服务。

项目管理

在架构组要求是需要单独、协作完成项目,所以要求工作能力也是比较高的。

架构组跟业务组的区别是什么

除了工作内容不一样,最核心的就是主动性。需要自己去发现问题,然后主动推进解决,不再是有人一直跟你指着方向说你要怎么去走。

在项目里面充当主人翁的角色,管理整个项目,规划好项目的未来工作,协调资源来实现工作目标。项目管理,本质就是管理资源,包括人、时间、项目、资源。

遇到的挑战

说完大致的工作内容,接下来讲下我在架构组遇到的挑战,以及我是如何去解决的

从上面内容中,大家开源了解到架构组跟业务组的区别。工作内部不同之外,对工作要求也会更高。

🚤 第一个挑战:主动性

我毕业的时候在一家美妆公司搬砖,to c,这类工作上来就是多少qps,当然我们当时qps也海星,哈哈,大概上千qps,微商城有上万qps👍️

但是有个问题,就是作为一个开发仔,工作基本是被安排明明白白的,就是完成什么工作,实现什么效果、功能,至于为什么实现,一无所知。

那么初到架构组,我就迎来第一个挑战:主动性

一开始完成一些比较简单的工作,你会发现一直是在按指定的路线去执行,即使有问题,也是到后面才发现。在这时,慢慢开始主动改变,第一步是主动推进项目,跟一些干系人了解业务场景,跟产品了解需求背后解决的问题,主动推进项目进度。第二步是独立负责项目,在这一步需要我们主导项目,包括项目管理(项目时间排期,资源分配,会议),需要有自己的思考,对业务有自己思考,对项目有长远的规划,有优化缺陷会持续跟进。

很开心经过个人的努力,目前可以独立负责一个项目,然后主动去推进项目的进展。

🏄🏻‍♀️ 第二个挑战:思考能力

这个也是主动性的一种类型,有价值的工作其实是决策型脑力劳动,而不是重复的体力劳动

场景

1. 技术方案思考

比如说某项技术方案的实现可行性,然后它跟其他方案的优缺点。思考可以让你的方案更加健全可靠,而不是自己yy出来的一个假象方案,其次的话只有思考足够多的内容,才能形成文档里面思路。

在架构组,我们需要考虑到方案可扩展性、合理性、风险

2. 需求背后的问题

在业务小组的时候,我更关心的是如何去实现。当有了思考能力,我会去挖掘需求背后的问题所在,是否有更优的解决方案,这也是一种价值提升。

3. 项目未来的规划

这点很少人想到的,问题都能在另一个维度得到解决。

当我们站在终点的时候,可以发现我们走了很多弯路,也有很多不合理的地方,那么我们可以从后面往前去思考。比如说:我们可以去借鉴业界成熟的产品,然后对比现有的产品,差距在哪里,然后我们进步的空间在哪里。

方向比努力重要

🏄🏼 第三个挑战:未知挑战

在架构组会经常性的去挑战新技术,可能是之前你没有接触的知识,例如CICD,maven插件,自研中间件

是不是听起来很有挑战性

首先是习惯去面对,这是架构组必经的挑战,然后有自信去解决,毕竟我们不是唯一一个遇到这样的问题,或者新技术,新的领域,网上已经有成熟的方案解决。

经历调研、学习->制定可行方案->最小mvp->推广执行

🏄🏿 第四个挑战:日常PK

在工作和生活中,我们会面对很多PK,别人的质疑。一开始我会很不习惯,而且很害怕,因为人不喜欢被否定。

后面我觉得需要做出改变,那我是怎么做的呢?

在做方案的时候,细心、详细、用心的做,这样你才有自信,还有理论基础去支持你的方案,当别人PK的时候,才能不动摇。

其次就是虚心的听取别人的想法,思考背后的提问的出发点。有时是自己没有考虑到,有时是别人想法我们已经解决。

在架构组的成长

我觉得在架构组一年是其他普通公司业务部门n年,这个一点不夸张~

1. 知识面

你可以通过日常工作,接触的技术,不断丰富自己的知识面,发现自身不足点,然后去学习提高。

2. 自信

在日常PK中,慢慢习以为常,也在不断提高自己自信,当你有足够的理论支撑想法,不被别人推翻。

在面对不确定性的时候,会更自然去面对,以及有一定的经验的处理。

3.主动性

不管在生活还是工作,都需要我们去主动。主动点,一切都有可能,比如说主动点点赞,关注下博主~😜

cc59d129918ec7b6cd209b4c14373921.jpeg

4. 认识强者

在架构组,会经常跟很多优秀的人探讨技术,跟大佬学习优秀的思想,还有成熟的解决方案。这不比富婆少奋斗几年?哈哈

5.独当一面

大家去看阿里P6的要求,里面有一点就是独当一面,单独负责项目,有自己想法。这点很重要,新点子才能创造更大的价值,而且直击问题要害,可以节省很多无用功。

体验完架构组,接下来

体验完架构组工作内容,以及工作上挑战,还有了解博主的成长,如果对你有帮助,点赞、收藏、关注,感谢~😜

分类:
后端
标签:
分类:
后端
标签:
收藏成功!
已添加到「」, 点击更改