架构师在公司里一般做啥的?感觉不同公司的不一样, 另外怎样才能成为一个合格的架构师,v 友们有啥建议 .
1
rrni 2023-04-19 17:49:55 +08:00
装装逼,挥鞭子
|
2
aLazarus 2023-04-19 17:55:55 +08:00
我觉得架构师至少能设计项目架构吧,要是能给手下拿出一套脚手架解决方案,我觉得是加分项
|
3
waitingChou 2023-04-19 18:13:01 +08:00 1
我理解的,架构师其实说白了和普通开发没有特别明显的界限区别,很多架构师平时可能也在写业务代码。
架构师的活,很多开发平时也在做,就是写技术方案,优化已有架构、设计新的系统架构。 要说区别的话,就是比普通的开发经验更多,对于技术方案和软件架构更有心得。 要成为架构师的话,我分享一些我的思考: 1. 要有经验和技术广度打底。 经验帮你了解 实用套路,技术广度则是熟悉常见的技术方案、组件,了解他们各自的优缺点、适用的场景(这点很重要)。 2. 技术之外的阅历经验累积。 很多时候设计一套架构不能简单完全从技术出发,你得开始考虑一些其他的东西,比如: 你得考虑这套技术方案的上手难度,维护团队水平咋样,搞不搞得定这套方案; 这套东西的成本会不会太高了,是不是换成本低点的方案,会让架构复杂一点,麻烦一点。 某个中间件虽然很适合现有的架构,但是社区不活跃,维护力度也差,如果出现 bug 比较难处理,是否退而求其次换个社区活跃点的。 3. 形成架构设计、评估套路 比如怎么评估现有的架构是否合理?让你从 0 开始新建一套系统的架构,你的思路是什么?这方面可以从别人分享的一些架构文章学习一点,但最重要的还是 结合自己多年的经验,总结出自己的一套思路,才能在日常工作中运用自如。 4. 牢记一些规则 没有一套架构可以打遍天下。阿里、京东、pdd 虽然都是电商,架构肯定是不一样的。 先有场景,才有架构。抛开具体的业务场景聊架构只能泛泛而谈。 要考虑业务发展,但不要过渡设计,合适的架构都是慢慢演化而来的。比如一开始业务还不知道有多少量的时候就上分库分表,异地多活多中心等复杂的方案, 会让初期项目落地的成本和时间压力变大。 清楚地知道自己架构为了什么场景设计的,在什么场景下会有问题,并清楚地向相关人员重点说明。(比如系统不适用于高并发,或者不适用于响应时间非常敏感的场景) ... |