工作轻松搞定，感觉啥都会？如何职场跃迁技术群聊天的时候，发现不同技术群或者集体也有过的一种景象：每日工作本人当初能够轻松拿捏，接下去如何破局？感觉工作内容也简略，仿佛没有很大的挑战性。我该如何解围，跃迁到职场或集体职业生涯下一等级？
遇到的另一个问题是，我的项目合作方面的问题我的项目内容很简略，感觉工作没挑战性
我的项目内容很简略，感觉工作没挑战性
技术群聊天的时候，发现不同技术群或者集体也有过的一种景象：每日的工作内容，以本人当初的能力能够轻松拿捏，感觉没有挑战性，不好玩。集体能力倒退到这个阶段，如何破局、如何解围，跃迁到职场或集体职业生涯下一等级？
就像群里这个前端同学所说“前端我该学该搞的都搞的差不多了，还要怎么扩大？”。这仿佛是他当下的问题。开发个别分为业务侧开发、根底技术开发（也就是架构组）。各有优缺点，不做具体探讨。
做为一个业务同学，参加需要评审、出技术计划、画 UI、写动画、设计组件、测试、交付、没有任何问题了，然而业务同学倒退的肯定阶段，就应该思考底层技术或者工程化相干的货色。比方 CI、CD 打包构建优化、线上稳定性、页面秒开、首屏渲染时长的优化。说起优化，那必须要聊监控，要可度量，有数据撑持才不便聊到底优化了多少、优化了百分之多少，否则理性说“我这个很牛逼，优化了好多”那就不是工程师的该有的做事格调。要做前端监控就必须理解从地址栏输出一个 url 到整个页面渲染进去都做了什么事件，晓得浏览器工作原理才晓得问题症结在哪，才晓得具体如何做优化。然而很多写业务的同学不晓得或者只知其一; 不知其二，很难系统化、全局剖析问题。那这个问题如何解决？那就是平时做货色之后，多问一步、多思考一步，为什么这么做、为什么这么设计？优缺点是什么？基于什么样的思考采取了目前的计划？该计划上线一段时间后去统计分析数据、复盘下符不合乎过后的预期，不是终极计划的话，要做什么样的调整。比方我就问了“tree-shaking”的原理是什么？ast 和 webpack 的一些 loader 如何工作的？可能就说不出来了。比方 React、JS、Weex、Vue、RN、Flutter 都有异样捕捉机制、捕捉之后如何还原出具体的案发现场，比方前端 js 打包就须要将 SourceMap 产物和版本号相关联做保留。后续不便符号化为原始数据。
根底技术也不是什么很神秘的货色。根底技术同学也有相似问题，感觉纯正的技术我的项目很乏味，但没啥问题、苦于降职。因为价值不够或者只是解决了某个单点问题，没有扩散到解决一类问题，没有推展到面。比方钻研出某个问题或者库，推广到不同业务线，宣讲接入落地。数据追踪并一直优化。缺的是价值闭环。缺的是业务 sense，可能技术上很赞，但业务同学不痛，或者不那么痛，接入的 ROI 不高。所以技术同学也要追踪业务问题，做到能解决理论业务问题（最好是很痛的业务问题）的技术我的项目。
所以平时应该多学多想多问为什、不设边界、不要只管好一亩三分地。如果只是做好本职工作，没有学“边界”之外的常识，没有当时储备好，要做某些事件可能连思路和一些可选项都没有。会比拟被动，相似于需要执行者，而不是需要或者技术我的项目开掘者
我的项目单干的痛
写单个技术问题可能你很在行，然而我的项目写起来可能不那么棘手。
看起来你是在写程序，其实你做的是产品，那就不是简简单单的编程，无奈像刷 Leetcode 那样，刷一刷就熟了，而是要面对软件工程中的各种问题。
所以你面临的问题始终在变，大部分时候你不是在解决代码的问题，是在解决相似于：
– 我怎么把需要形象成设计？
– 我该抉择哪个技术计划？怎么找到最佳实际？
– 这个技术、框架我没用过，怎么疾速用它实现我要的性能？
– 这个 Bug 我该如何定位和修复？
– 这个 Bug 是解决了，然而这段代码我怎么重构能力防止问题？
这外面其实最容易的反而是代码问题，要实现一个函数，搜寻一下可能他人曾经写好了，要解决一个 Bug，用错误信息搜寻一下可能 StackOverflow 曾经有人解决过。
难的是你怎么把这些代码放在一起能满足你的需要，还能运行的高效，还要好保护，这些事不是 ChatGPT 或者 AI 短时间能代替的了的，须要很多年的积攒。
其实也没啥捷径，只能是投入工夫去一直地学习优良的代码，一直地实际，比方实现性能，重构代码。
可能在一个我的项目中，你本人的局部写的很棘手，然而多人合作，你无奈大展拳脚。
有同学被我的项目合作方气死“遇到太菜的程序员队友，会被坑死”。可能是站在群里闲聊的一种话题，也可能是真的比拟有力吧，但呈现这个后果，有些起因是被动的，不可躲避，然而问题产生了，就须要躲避。呈现问题不可怕，继续呈现同一个问题（单点问题）、同一类问题（单点问题的解决能力拓展到面，问题形象剖析解决能力，可能是流程可能是机制）
任何我的项目，不论是互联网畛域的技术我的项目还是桥梁工程这种修建我的项目，最重要的是“过程治理”和“危险辨认”。kick-off 后规定好我的项目的几个要害节点，个别会从技术我的项目的参加同学中选定几个要害的 O，每日日会或者隔几天的我的项目站会（依据理论状况而定），须要同步我的项目进度、目前遇到的危险，须要依赖的外界因素是什么，失常吗？不失常的话，须要帮助什么资源，尽早干涉或者帮助。所以作为执行者，两头的一个角色，不要怄气，没啥用。
往往一个零碎一个我的项目是多个团队合作的，所以须要辨认上下游边界，对外该裸露什么能力或者提供什么接口（一句很相熟的话就是接口后行），协定先制订分明，依赖的节点是什么，各个工夫节点交付物是什么？
作为个体，我的项目中应该做做好本职工作，如果呈现危险，及时向要害的 O 同步问题。如果 O 不作为，本人能够被动推动上下游，或者向真正的项目经理同步问题裸露问题。要么遇到技术问题，本人有把握的话能够私下攻克，把危险给干掉。这些都是无效的。