架构师

装装逼，挥鞭子

我觉得架构师至少能设计项目架构吧，要是能给手下拿出一套脚手架解决方案，我觉得是加分项

我理解的，架构师其实说白了和普通开发没有特别明显的界限区别，很多架构师平时可能也在写业务代码。
架构师的活，很多开发平时也在做，就是写技术方案，优化已有架构、设计新的系统架构。

要说区别的话，就是比普通的开发经验更多，对于技术方案和软件架构更有心得。

要成为架构师的话，我分享一些我的思考：
1. 要有经验和技术广度打底。
经验帮你了解 实用套路，技术广度则是熟悉常见的技术方案、组件，了解他们各自的优缺点、适用的场景（这点很重要）。
2. 技术之外的阅历经验累积。
很多时候设计一套架构不能简单完全从技术出发，你得开始考虑一些其他的东西，比如：
你得考虑这套技术方案的上手难度，维护团队水平咋样，搞不搞得定这套方案；
这套东西的成本会不会太高了，是不是换成本低点的方案，会让架构复杂一点，麻烦一点。
某个中间件虽然很适合现有的架构，但是社区不活跃，维护力度也差，如果出现 bug 比较难处理，是否退而求其次换个社区活跃点的。

3. 形成架构设计、评估套路
比如怎么评估现有的架构是否合理？让你从 0 开始新建一套系统的架构，你的思路是什么？这方面可以从别人分享的一些架构文章学习一点，但最重要的还是 结合自己多年的经验，总结出自己的一套思路，才能在日常工作中运用自如。

4. 牢记一些规则
没有一套架构可以打遍天下。阿里、京东、pdd 虽然都是电商，架构肯定是不一样的。
先有场景，才有架构。抛开具体的业务场景聊架构只能泛泛而谈。
要考虑业务发展，但不要过渡设计，合适的架构都是慢慢演化而来的。比如一开始业务还不知道有多少量的时候就上分库分表，异地多活多中心等复杂的方案， 会让初期项目落地的成本和时间压力变大。
清楚地知道自己架构为了什么场景设计的，在什么场景下会有问题，并清楚地向相关人员重点说明。（比如系统不适用于高并发，或者不适用于响应时间非常敏感的场景）
...