前言
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）
谈谈我的看法
云原生是一种趋势，也解放了开发很多繁琐工作。但是从另外一个角度，开发的主动性受限了。比如说你想去干某件事，你需要跟运维去协作完成，以前可能是我们引入某个中间件，这样开发主动性更强~
规范 & 文档
架构组在初期需要做的重要的工作：制定规范，包括：引入新技术规范，技术文档编写规范，开发规范...
重要性
当没有规则的时候，我们做什么事都会很乱。只有我们定好规范，一定的流程、模板，大家严格按照这个模式去执行，才会仅仅有条。
文档
这也是我进架构组做的蛮多的工作内容，比如设计文档、架构图、工作总结
这些看似繁琐，但是必要的工作项。文档其实是我们想法一种展现，我们通过写出来，像大家描述方案可行性，全面记录某个项目各方面，比如：风险、可行性、技术以及非技术要求、工作内容、项目时间规划、大家的分工。
其次文档跟博客一样，是在锻炼逻辑能力，我们在思考过程中是发散的，在写出来的过程，需要去总结归纳，有一定的思路去编写。
业务
当看到这个标题，大家会不会感到意外呢？
曾经我带着类似的问题，请教了百度大佬肥朝😁
Q：您认为技术还是业务重要呢？我应该往哪个方向去发展？
🙋：我认为你能做到一方面突出，已经很了解不起了。毕竟人的精力跟时间是有限的。其次很多工作不是自己能决定的（PS：深有感触，不过我还是在工作上尽可能的主动）
在架构组也会遇到技术跟业务的抉择。我的看法：技术跟业务有所兼容，大部分公司技术是作为赋能的角色，来带动业务产出，全部精力放在技术是不行的。
那么哪些业务是属于架构组？
大家抓住公共的，比如说用户模块、权限、基础服务（对外调用微信、飞书。。。）、开放平台，公共模块沉淀下来，需要做的是变成平台化，这样才能承接更多的应用、服务。
项目管理
在架构组要求是需要单独、协作完成项目，所以要求工作能力也是比较高的。
架构组跟业务组的区别是什么
除了工作内容不一样，最核心的就是主动性。需要自己去发现问题，然后主动推进解决，不再是有人一直跟你指着方向说你要怎么去走。
在项目里面充当主人翁的角色，管理整个项目，规划好项目的未来工作，协调资源来实现工作目标。项目管理，本质就是管理资源，包括人、时间、项目、资源。
遇到的挑战
说完大致的工作内容，接下来讲下我在架构组遇到的挑战，以及我是如何去解决的
从上面内容中，大家开源了解到架构组跟业务组的区别。工作内部不同之外，对工作要求也会更高。
🚤 第一个挑战：主动性
我毕业的时候在一家美妆公司搬砖，to c，这类工作上来就是多少qps，当然我们当时qps也海星，哈哈，大概上千qps，微商城有上万qps👍️
但是有个问题，就是作为一个开发仔，工作基本是被安排明明白白的，就是完成什么工作，实现什么效果、功能，至于为什么实现，一无所知。
那么初到架构组，我就迎来第一个挑战：主动性
一开始完成一些比较简单的工作，你会发现一直是在按指定的路线去执行，即使有问题，也是到后面才发现。在这时，慢慢开始主动改变，第一步是主动推进项目，跟一些干系人了解业务场景，跟产品了解需求背后解决的问题，主动推进项目进度。第二步是独立负责项目，在这一步需要我们主导项目，包括项目管理（项目时间排期，资源分配，会议），需要有自己的思考，对业务有自己思考，对项目有长远的规划，有优化缺陷会持续跟进。
很开心经过个人的努力，目前可以独立负责一个项目，然后主动去推进项目的进展。
🏄🏻♀️ 第二个挑战：思考能力
这个也是主动性的一种类型，有价值的工作其实是决策型脑力劳动，而不是重复的体力劳动。
场景
1. 技术方案思考
比如说某项技术方案的实现可行性，然后它跟其他方案的优缺点。思考可以让你的方案更加健全可靠，而不是自己yy出来的一个假象方案，其次的话只有思考足够多的内容，才能形成文档里面思路。
在架构组，我们需要考虑到方案可扩展性、合理性、风险
2. 需求背后的问题
在业务小组的时候，我更关心的是如何去实现。当有了思考能力，我会去挖掘需求背后的问题所在，是否有更优的解决方案，这也是一种价值提升。
3. 项目未来的规划
这点很少人想到的，问题都能在另一个维度得到解决。
当我们站在终点的时候，可以发现我们走了很多弯路，也有很多不合理的地方，那么我们可以从后面往前去思考。比如说：我们可以去借鉴业界成熟的产品，然后对比现有的产品，差距在哪里，然后我们进步的空间在哪里。
方向比努力重要
🏄🏼 第三个挑战：未知挑战
在架构组会经常性的去挑战新技术，可能是之前你没有接触的知识，例如CICD，maven插件，自研中间件
是不是听起来很有挑战性
首先是习惯去面对，这是架构组必经的挑战，然后有自信去解决，毕竟我们不是唯一一个遇到这样的问题，或者新技术，新的领域，网上已经有成熟的方案解决。
经历调研、学习->制定可行方案->最小mvp->推广执行
🏄🏿 第四个挑战：日常PK
在工作和生活中，我们会面对很多PK，别人的质疑。一开始我会很不习惯，而且很害怕，因为人不喜欢被否定。
后面我觉得需要做出改变，那我是怎么做的呢？
在做方案的时候，细心、详细、用心的做，这样你才有自信，还有理论基础去支持你的方案，当别人PK的时候，才能不动摇。
其次就是虚心的听取别人的想法，思考背后的提问的出发点。有时是自己没有考虑到，有时是别人想法我们已经解决。
在架构组的成长
我觉得在架构组一年是其他普通公司业务部门n年，这个一点不夸张~
1. 知识面
你可以通过日常工作，接触的技术，不断丰富自己的知识面，发现自身不足点，然后去学习提高。
2. 自信
在日常PK中，慢慢习以为常，也在不断提高自己自信，当你有足够的理论支撑想法，不被别人推翻。
在面对不确定性的时候，会更自然去面对，以及有一定的经验的处理。
3.主动性
不管在生活还是工作，都需要我们去主动。主动点，一切都有可能，比如说主动点点赞，关注下博主~😜
4. 认识强者
在架构组，会经常跟很多优秀的人探讨技术，跟大佬学习优秀的思想，还有成熟的解决方案。这不比富婆少奋斗几年？哈哈
5.独当一面
大家去看阿里P6的要求，里面有一点就是独当一面，单独负责项目，有自己想法。这点很重要，新点子才能创造更大的价值，而且直击问题要害，可以节省很多无用功。
体验完架构组，接下来
体验完架构组工作内容，以及工作上挑战，还有了解博主的成长，如果对你有帮助，点赞、收藏、关注，感谢~😜
