2024年12月，如果我计算没错的话，我已经整整30岁零两个月了。
就像我今天上班以后，做到工位上，排查线上问题的时候才发现今天居然已经稀里糊涂地到了12月份一样，我同样稀里糊涂地过到了30岁。
30岁的我，已经不在热血了。 当想到这个title的时刻，没有丝毫的情绪起伏，甚至满满都是羞耻心。
像我这样的小孩可能不多。 我清清楚楚地记得，实习期参加的第一个年会，老板让大声说出自己的新年愿景。 我没什么计划的，更没什么想法。但是此时要正义凛然，这个事还是知道的。所以就很懂人情世故地说：“希望未来一年可以像晨哥一样搭建一个自己的技术博客”（晨哥可以理解为我当时的技术leader，拍了马屁又显得很上进，绝了！）
虽然是临时编造，但是大致还是有这样模糊的一个意愿的。年轻的时候会想要低调地做很多积极上进的事情。 后来很多很多次，我都在GitHub上搭建了项目，选定了框架，init了提交，开始做排版、DB设计、具体功能规划，然后就That's it了。
后来的很长时间内，我甚至都认为：年轻人就是太年轻了，总是拍脑袋想要做事情，哪有什么事是一蹴而就的呢？
到现在，我发现自己认为的还真是对的。没什么事是一蹴而就的。 但最大的问题在于：没有一蹴而就，更没有放弃而成。只有继续做下去，才会有希望。
老话怎么说来的？ “你相信光么？”
题外话，做人要世故一些，这样会显得我很圆滑。但这不能当做课题，研究过了就会迷失自己。 夜深人静的时候，左手一瓶酒，右手一只鸡，嘴里叼根烟。吨吨两口酒，呱嗒两口菜，噗噗两口烟，扪心自问：自己要的是什么？
今天又是一个开始，我不以为耻，反以为荣：我要当架构师！不是一个curder！
何为架构师？
之前愚蠢的见解就是，“架构师就是牛X的程序员”。
细分之下，架构师的工作包括：
1. 了解业务全貌并合理把握并引导技术整体
都知道的几个编程方式：面向过程编程、面向对象编程和面向领导编程。 前两个都是技术点了暂且不谈。 面向领导编程有必要着重说一下，首先不要以为面向领导编程是茶余饭后用来搞笑的谈资，这其实是一个十分正经且合理的编程模式。尤其是在大厂的小伙伴肯定都有所体会：
用户提了很多需求了，我们需要排期研究下技术方案啊～～～。 这个得慢慢来啊，着急不得～～
但是领导提的需求就会画风突变：
产品会拉技术负责人一起紧急会议：“看下吧，这个是L总的需求，今天下午要上线，现在手头有什么其他活儿么？可以先推一推，我去找负责人沟通去～” （所以用户都不再提反馈意见了，直接各种方式找到领导本人，把需求变成领导的需求就能很快解决了）
这件事听起来很滑稽（虽然确实是），但是需要考虑到它的合理性。 真相是，开发团队都是不接触用户的，更不知道什么是用户真正的需求，或者说值钱的需求。产品也是（我没做过产品，此为鄙人愚见）无法得知用户真正的需求。
无论是RD还是PM，大家都是向上负责的，也就是面向领导编程的另一种说法而已。 这让我想起了五层网络模型，每一层封装都是只对上层负责，可见这种模式还是没毛病的。
所以，作为技术团队的需求出发点，也就技术团队的总掌舵人，业务全貌意味着需求方向，一定要掌握。
那这个角色为什么不是老板掌握就好了？
举个例子：
- 老板是一个使用电脑的用户，他想要使用电脑赚钱，某天他有了个主意，于是打开了电脑。
- 架构师就是操作系统，越是智能的操作系统越能准确地理解老板的含义，甚至还能站在“电脑本身”的角度，帮老板分析问题。这不仅是有助于完善项目效果，更是对“电脑本身”的一种保护。
- 而团队成员也就是各个电脑硬件了，就是无情的开发工具，但是还要被要求“发挥主观能动性，考虑下需求合理性、代码健壮性、可扩展性等等”（我要是都考虑到了，我就是架构师了真是的！）
结论就是，架构师要像AI系统，根据经验辅助老板把控需求，还要根据知识引导团队开发。
2. 了解主流方案并有选择的制定技术方案
都说要了解国家大事，程序员的国家大事就是目前的主流技术解决方案。
- 当互联网兴起的时候，当然那时候还没有架构师这个职位。
- 当出现集群化服务时，架构师要了解微服务和服务治理。
- 当出现流行移动端时，架构师要了解多平台、跨平台开发。
- 当出现数据持续增长时，架构师要了解大数据应用和搭建。
- 当出现AI时，架构师要了解AI应用场景和AI自研和搭建。
涉及细分领域，又会分为前端和后端，随着发展，前端工具爆炸式、花样式增长，就更意味着广度的需求提高。
但是万变不离其宗，
- 前端说到底还是和样式排版打交道，浏览器，HTML、CSS、Pure JS是基础。
- 后端说到底还是数据结构和数据库是基础。
- DBA说到底还是Linux是基础。
架构师各个方便的基础都要涉猎，能够透过繁多复杂的各个工具表象看到本质基础，选型最适合的技术方案。
3. 了解技术发展趋势并有规划的制定项目路线
知天下事，不如知未来事，知晓现状的同时，还要时刻思考未来。 互联网技术日新月异，迭代迅速。现在还可以不代表明天还能运行，所以时刻关注技术发展也是必要能力之一。
前端举例（以下内容来自互联网）：
目前常用的开发模式是Webpack或Vite等脚手架组件化开发。要知道jQuery、Bootstrap、Layui也称霸距今才几年时间。 当然目前使用JQ，BT的仍大有项目在。但是流行意味着节省人力，也就是生产效率了。 目前主流浏览器都支持了Script Module能力，支持直接运行import模块化代码； 浏览器也优化了渲染逻辑，虚拟DOM的应用效果并没有想象中的那样立竿见影； Houdini：CSS Parser API, CSS Properties And Values API, CSS Typed OM, CSS Layout API, CSS Painting API, Worklets;
因此要对未来技术有所思考，才能不落后（不过落后也就落后吧，还能死咋地？！）
4. 了解团队特点并有能力凝聚起来
知己知彼百战百胜。
架构师在软件开发团队中扮演着至关重要的角色，他们不仅要负责技术架构的设计和规划，还要具备一定的团队管理和领导能力。了解团队特点并有能力凝聚团队是架构师职责中的一个重要方面。
团队评估与理解：
- 技术能力：架构师需要了解团队成员的技术背景、专业技能和经验水平，以便合理分配任务和资源。
- 工作风格：了解团队成员的工作习惯和风格，包括他们如何协作、沟通以及解决问题。
- 团队动态：评估团队内部的关系和互动模式，识别任何可能影响团队凝聚力的潜在问题。
沟通与协作：
- 建立沟通渠道：架构师需要建立有效的沟通渠道，确保信息流通无阻，团队成员能够及时获得必要的信息。
- 促进协作：鼓励团队成员之间的协作，通过定期的团队会议、工作坊和代码审查来增强团队合作。
目标设定与对齐：
- 共同愿景：帮助团队成员理解项目的长远目标和愿景，确保每个人都对项目的方向和目标有共同的认识。
- 目标对齐：确保团队的个人目标与团队和组织的目标一致，这样可以提高团队的凝聚力和动力。
领导与指导：
- 领导力：架构师需要展现出领导力，通过榜样的力量来激励团队成员，同时也要能够处理冲突和挑战。
- 指导与培养：对团队成员进行指导和培养，帮助他们提升技能，尤其是对于那些需要在特定领域成长的成员。
激励与认可：
- 激励机制：建立激励机制，通过奖励和认可来鼓励团队成员的出色表现和贡献。
- 个性化关怀：了解团队成员的个人需求和职业发展目标，提供个性化的支持和资源。
文化建设：
- 建立团队文化：塑造一种积极的团队文化，这种文化应该鼓励创新、尊重多样性，并支持持续学习。
- 团队活动：组织团队建设活动，增强团队成员之间的联系和信任。
适应性与灵活性：
- 应对变化：架构师需要具备灵活性，能够根据项目需求和团队动态调整策略和方法。
- 持续改进：鼓励团队持续改进工作流程和实践，以适应不断变化的技术环境和业务需求。
冲突解决：
- 识别和解决冲突：及时识别团队内部的冲突，并采取有效措施来解决，以维护团队的和谐与效率。
边整理边记录到此，发现最大、最重要、最拉高上线的能力是在这一部分。 闹了半天还是要看重人际能力，码农怪不得是码农，写代码的农民。 如果想要当村长，就还是得会搞人际关系
又是一天过去了
此时看着窗外慢慢从黑色慢慢变成灰色，不知不觉已经又过了一夜了。不知道这个决定还能继续走多远。
有这个想法的一刻我又意识到，也许正是对未来的忧虑使得我止步不前，不止是我自己，周围的环境，媒体信息的茧房也在不停地释放着各种令人焦虑的信息。
突破焦虑，注重当下，与君共勉
