业务场景和技术选型需要考虑的因素

成长和思考

1、当小A 接到需求后的反应 🏌️

对于一个需求来说，我们应该站在一个评审的态度去看待他。

接到产品经理的需求后，我们应该从有利于业务的角度出发思考，对这个需求进行删、改、增。

同时最重要的一个地方是，你需要有自己的一个思考和自己的实践，并去落实他和推动一些东西，让你的思考能够落地并看到成效。

有自己的思考和整体业务的理解，将有助于你整体的一个职业生涯，对于你目前所做的事情，也许在未来某个地方，能够结合你当时的一个背景，做出有点酷并很有用的东西。

2、提高某件事情的效率 🦖

对于项目中的现成代码，我们应该去理性思考，

• 第一，这些代码为什么这么写呢，写的逻辑是什么，有什么好处呢。
• 第二，这些代码能够优化吗，哪些地方存在瓶颈呢，如何优化。优化的解决方案有哪些，我们应该怎么处理。
• 第三，保持持续学习，了解程序实现的底层逻辑，对于计算机操作系统、数据结构、组成原理等能够有比较好的认识和理解。
• 第四，对于 ToC 的项目，我们应该考虑一下服务 QPS 能支撑多少，心里对于流量阈值有一个清楚认知，针对这个阈值如何提高优化，性能是否符合预期，是一个需要考虑很多方面和内容的问题。
• 第五，对于生产环境和测试环境的区别，是非常大的，生产环境遇到的复杂性问题，我们需要随时养成关注线上服务运行的一个情况；一些基础的内容，比如请求峰值的时候 CPU、内存的消耗、网络端口消耗等都是我们需要去关注的一些点，并在实践中养成这个习惯。
• 第六，了解整个项目整体业务，不要给自己的工作设定边界。
• 第七，归纳总结复盘。

关于第二点，在 JavaGuide 网站文章中一句话写的很好，借鉴引用一下：

主动思考一下现有工作中哪些地方效率有改进的空间，想到了就主动去改进它！

3、学习的时候一些坑不要去碰 🤕

• 多去看官方文档，多去看实际的源码，尽量少的去看一下垃圾博客
• 关注细节
• 及时反馈
• 规范，以及规范（代码，注释，接口，方法名称，文档，技术名称，日志，测试）
• 多实际去写代码（不要一说就会，一写就废）
• 重要的变更和接口内容一定要写文档
• 理解需求后，再开始写代码
• 多思考，有自己的理解后再去询问一些东西（积极沟通）
• 生产环境不要动

未来就业方向选择

在目前这种趋势的未来中，对于顶层设计的要求从业人员其实是越来越高的，需求量也要减少（已经有很多现成的解决方案），未来的就业市场需要的反而是中低层人员，而随着GPT等人工智能的发展，技术人员的可替代性其实是很强的。

义无反顾的抓住每一个管理岗机会。

• 驾驭管理
  • 模仿周围优秀管理者
  • 找机会锻炼 展示能力
• 顶层架构
  • 大量研读吸收 架构设计方案

推荐书籍：《软件平台管理架构设计与技术管理之道》