少走弯路，给Java程序员的唯一一条建议
极客时间编辑部
讲述：杜力大小：1.48M时长：03:14
做了 3~5 年 Java 开发，你已经积累了不少项目经验，扩宽了技术广度，也许已发力成为团队管理者。而到了这个阶段，却常有这种感受：感觉自己卡在瓶颈进步缓慢，技术水平很难像早期一样实现大幅突破。
其实很多人往往忽略了这一点——提升自己的架构认知。工作 5 年左右程序员必须重视架构认知的提升，这会很大程度推动你今后的成长。
架构的本质在于面对业务场景给出优雅的解决方案，使得业务能够快速迭代和持续交付，从而达到降本增效的目标。
提升架构认知高度，就像达克效应所描述的一样，要敢于从愚昧之巅跳到绝望之谷，通过爬升开悟之坡，从而达到架构认知的巅峰时刻。
提升架构认知，要紧抓 3 个关键点，即业务洞察力、技术视野和原创力 / 执行力。
首先，业务洞察力是技术战略层面的问题，在当下能够做出合理的判断，清楚公司做什么事情收益最大；
其次，技术视野即技术选型能力，是技术战术层面的问题，在清楚做什么事情后，需要进一步解决怎么做的问题，也就是能够给出合理的技术选型方案：是完全基于开源的方案，还是基于开源二次开发的方案，还是完全自研的方案；
最后，原创力也就是执行力，是技术落地执行层面的问题，一旦技术设计方案确定后，需要能够快速 Rush 完成。
这 3 点层层递进，最重要的是先把技术战略问题思考清楚，然后再进一步解决技术战术问题，最后是快速落地执行的问题。
工作 5 年左右的程序员，在原创力（执行力）层面比较有竞争力，但往往欠缺技术视野以及业务洞察力。而后面 2 点更加重要，这 2 点解决的是架构设计哲学问题，是架构师能够持续拥有竞争力和影响力的立身之道。
举个场景的例子来详细说明：一提到分布式锁问题，大多数人想到的方案是基于 Redis 的 Master-Slave 模式来实现。这个实现方案行不行？分布式锁本质是一个 CP 需求，基于 Redis 的实现是一个 AP 需求，乍一看基于 Redis 的实现是无法满足的。脱离业务场景来谈架构都是耍流氓。
从技术战略的需求层面来看，如果分布式锁在极端情况下获取锁的不一致，社交业务场景能够接受，那么基于 Redis 的实现是完全可行的。如果业务是交易场景，分布式锁在极端情况下获取锁的不一致性无法接受，那么基于 Redis 的实现方案是不可行的。在锁强一致性的场景下，需要采取基于 CP 模型的 etcd 等方案来实现。
以上就是今天的内容，一切事物的本质是相通、相同的。 学习架构也是如此，掌握了架构设计背后的哲学，那么一切工程问题也就迎刃而解了。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论