开发 -- 编程内功
一、内功
本质思维：沉下心，把握不同事物核心的各自规律。 见一叶而知深秋,窥一斑而见全豹。一叶到底是什么？
逻辑思维：100% * 100% * 100% * 100% .... 像下棋一样，每个步骤的准确率。越是天才，越深。
抽象思维：架构对现实问题合理、多元的抽象，选择最好的一个。
流程思维：不完全依赖人的仔细，不断将工作流程化，依靠流程的完善提高工作的能力。
二、业务架构
-
业务上下层：
i.分析业务逻辑的依赖，下层不依赖上层
ii.上层的业务禁止放到下层，而是应该 新增平级函数 或者 抽象上级业务层。 -
先本质，后延展。
本质的问题决定能不能做，延展的问题决定能不能cover所有业务场景。 -
先设计，后开发。
前期设计方案【反复思考+同事讨论+评审+...】确保可行性，才能继续。 -
管理方式是不一样的。
技术管理的本质，围绕解决业务问题；
人力管理的本质，围绕发挥人的潜力；
都遵循管理，大多数不是人越多越好。
三、需求阶段
- 给足咀嚼时间
每种结构体设计，一定既要结合真实情况，也要考虑设计的结构体合理性。当下可以设计，但是需要不断反复的思考。 - 安静的想一想
我的天性，性子比较急，思考比较浅层。所以不要那么多的理所应当，学会用大脑思考和推理。【Coverity的一次问题排查】
四、模块设计
-
安全设计
1）入口不合规拦截
2）流程完整性
3）流程持久化
4）流程失败处理
5）流程清理 -
交互设计
1）配置文件
2）入参设计 -- 用户自定义流程 -
数据结构设计
1）算法设计
2）时序设计 -
类设计（可扩展设计）
1）封装设计
2）接口设计
3）设计模式 -
高可用设计
1）稳定性（超时、异常、中断）
2）日志 -
性能设计
-
开源设计
-
文档
五、协作流程
六、设计模式
-
场景
1.1 业务接近，行为不同
接近的业务抽成父类，不同的行为归纳为子类
1.2 业务不同，功能内聚
模块之间的功能归一，真的太重要了。涉及到组件之间的升级和回滚。 -
具体实现
层级关系用【继承/组合】、同功能属性，方便未来上层调用 【接口】
如：参考kubekey的实现方式
分层 -- 规划接口（多态，将方法变成通用的管道） -- 规划父子 （继承，将相同的实现放到父中统一管理） -- 根据对象设计类，将函数很长的传参抽类等（封装，将函数根据类别形成类）
如：远程操作容器的sidecar操作容器文件
上层下发（如https）根据type类型创建具体的类 === 通用的管道（如调度函数） === 接口判断类型，执行具体类的函数（实现调度函数的抽离） -
设计模式实战
类或者函数之间的创建和交互（结构、方法、交互）
3.1 创建这模式
3.2 方法类模式
策略模式：传入具体的字符串到类或者函数，执行具体的函数。
3.3 交互类模式
七、编码阶段
- map 取 key 要判断
- 不可在for 循环中delete
- 封类的好处： 逻辑归类、传参统一、接口抽象
- 对异常的嗅觉：日志异常、功能异常、流程繁琐等保持钻研的态度，死磕，才能真正避免bug。因为有些历史bug，只是前期需求未做，会因为新的需求暴露。
- 线程开发模型：
| 底层需求 | 实现方式 | 备注 |
|---|---|---|
| I/O密集 | 线程：异步事件驱动模式（单线程循环等待事件） | |
| CPU密集 | 线程：同步并发处理（来一个任务起一个线程） | |
| 混合模型 | 由工作线程处理，主线程保持响应 |
- 结构体设计：
-
业务层次决定结构，而不是代码技巧决定！
不同的业务理解，结构也是不一样的。而且最拟合的抽象，主结构体层次几乎是定的，其他辅助结构体可以设计。【参数模板的for循环取数据，应该是根据组件来取，而不是统一取】 -
开发过程比较高效率的是map，但是前端或者展示的结构体，往往是List类型。
不同阶段需要的结构体不一样，也需要支持转换 -
当数据存在多个阶段的结构体时候，这个时候，衡量下以哪个为准。
参数开发的需求，param cr -- configmap。不断迭代的过程中，为了升级，保持configmap的数据是唯一的，param cr是可以不断优化使用方式。
-
语言开发
python -- 单继承（大属性）+ 多组合
golang -- 组合 和 接口，分开设计 -
基础设计模式
| 关系类型 | 自然语言描述 | 设计原则 | 适用场景 | 代码体现 |
|---|---|---|---|---|
| 继承 (Inheritance) | Is-a (是一个) | 复用父类代码，建立类型层级 | 子类确实是父类的一种特化，且需要复用父类的默认实现。 | class Dog extends Animal |
| 接口 (Interface) | Can-do (能做...) / Like-a (像...) | 定义契约，解耦，多重继承能力 | 多个不相关的类需要具备相同的能力；或者需要对外暴露统一的标准。 | class Bird implements Flyable |
| 组合 (Composition) | Has-a (有一个) | 复用功能，降低耦合 | 类A需要使用类B的功能，但A不是B的一种。(你提到的“包含关系”应归于此) | class Car |
黄金法则：优先使用组合，而非继承 (Favor Composition over Inheritance)。
这是《Effective Java》和《设计模式》中最核心的原则之一。
八、架构优化/改造
- 如果技术储备够，更好的设计是相对容易的，难点在于，对既往业务的代码梳理。【分层 + 抽象 + 总结，才能得出最适合的架构。而不是纸上谈兵，拿着设计模式的书指点江山】
- 架构优化，既要参考历史的代码逻辑，又要跳出之前代码的框架，目的为了新的代码，更贴近贴近业务的本质。
状态翻转的架构调整：
crdUtils.GdbDataHeadlessServiceReady: r.CheckIpBoundImage,
最开始自己的想法：
- 为了让自己的架构去适应旧的代码逻辑，做到面面俱到，顾此失彼。
- 重点不是stage的设计，而是整个流程返回值的处理。
正确的想法：
- 旧的代码逻辑适配新的代码框架：把握大方向，再贴合业务的情况下，旧的代码逻辑适配新的代码框架。r.CheckIpBoundImage 合并了之前的两个函数 check && reconcile。
- 新的代码框架不可能面面俱到：大方向已经优化的前提下，适配的过程中，小方向可以增加算法复杂度。翻转之后，不需要引入额外的cr stage更新，先做到代码层级的更改。
pipeline
-- child module 【通过chlid module 子函数实现stage注册，然后通过 father module 通用函数实现通用逻辑 】
-- child stage 【通过chlid stage 子函数实现action注册，然后通过 father stage 通用函数实现通用逻辑】
-- child action 【执行具体指令】
九、代码实现
- 学习顶级的项目框架，初期复制顶级的就是最好的
- AI生成
- 不得已自己来写，但是要100%投入，代码每一行需要的严谨性是逆天的。
十、汇报
在腾讯时，老板对我说的原话：我知道你慢慢做可以做的非常完美，但是我们没有时间。结果呢？在李老板的敲定下，我就是做出了一坨屎，然后大家反复开会研究这坨屎该怎么更好的run起来，满朝文武竟无一人敢言这是一坨屎啊后来，我才明白李老板也有苦衷，他刚接手不久，面临汇报压力，几个月后，传言，李老板去跟更大的老板汇报的时候，不是很满意再后来，李老板就不再负责我们的saas业务了再后来我在知乎上看到了一句醍醐灌顶的话：你在顶级互联网大厂里工作，技术能力并非是最重要的，最重要的是要向上管理，要敢于跟上面画大饼，你就可劲吹就行了，这样你才能拿到更多的资源，得到更大的重用，千万别傻不拉几的要去彰显自己的技术能力和深谋远虑，没人愿意跟傻子一起玩。你可能会问，那达不到预期怎么办？这点你就真外行了，在大厂里，少说百分之八十的项目都会在两三年内完蛋，你的老板都会被调走，懂了没有，这个，才是核心技术没有编故事，下面有本人在腾讯的offer和履历egonlin.com/offer.html所以，呼应一下主题，并不是进了国企你就废了，
作者：Egon林海峰
链接：https://www.zhihu.com/question/447150952/answer/40942139954
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
你分享的经历，在大厂环境中颇具代表性。技术能力是立身之本，但若想放大个人价值、影响决策，“向上管理”与“做好汇报”确实是另一项核心技术。
这并非提倡虚浮，而是一种将个人专业判断，高效转化为组织共识与资源的专业生存技能。下面，我从PPT制作、向上管理、演讲汇报三个维度，拆解这项技能的具体要求。
🎨 PPT制作：不止是美观，更是“决策工具”
在大厂，PPT常被视为一种“权力舞台”，其核心目标是辅助决策，而非简单记录。
- 逻辑为王，结论先行：这是PPT的灵魂。内容组织应遵循“金字塔原理”，以“结论先行”为原则。结构上可采用“执行摘要—目标与范围—KPI仪表盘—里程碑—问题与风险—资源请求—下一步”的框架。每页PPT最好只讲一个核心观点。
- 用数据讲故事：数据要转化为洞察。每张图表标题都应是结论句，且所有数据都应有对比基准（如目标值、去年同期）。
- 视觉服务于逻辑：页面设计应简洁、清晰，确保风格统一、排版整洁。使用专业模板是捷径，切忌堆砌花哨动画。
避坑指南：要警惕“形式压倒内容”。PPT能力不等同于画图能力，核心永远是对业务的深刻认知。若组织推行“去PPT化”，本质是要求更精炼的结论导向沟通，需要随机应变。
🚀 向上管理：主动经营与老板的“信任账户”
向上管理的核心是与上级建立信任，从而为自己和团队争取到更有利的工作环境与资源。
- 切换视角，对齐目标：要尝试站在上级的角度思考问题，深刻理解其KPI/OKR，并思考自己的工作如何帮助他达成目标。汇报时要避免陷入执行细节，多展现对业务整体目标和ROI的思考。
- 建立“信任闭环”：通过持续、透明、可预期的沟通建立可靠的职业形象。
- 主动汇报，管理预期：在项目关键节点主动同步进展，管理好上级的预期。一个实用技巧是让上级“看见”你的付出，如在周报基础上增加简短的日报。
- 带着方案提问题：汇报问题时，必须同步提出合理的解决方案，而不是把问题抛给老板。
- 识别风格，投其所好：观察老板是结果导向、过程控制还是细节控，据此调整沟通的颗粒度。
- 洞察“潜规则”，管理信息差：大厂信息层层传递容易失真，你的工作成果需要主动、有效地“被看见”。同时，要厘清自己在组织中的位置（如是否是“嫡系”），并利用出差等场合进行非正式的、务虚的沟通。
🎤 演讲汇报：把“思想”精准“植入”听众大脑
这是将PPT和向上管理策略落地的临门一脚。
- 演讲前的准备：
- 预演与准备：重要的汇报可能需要一周的准备时间。要提前设想老板可能提出的尖锐问题并准备好答案。
- 控制时长：通常需要在15分钟内讲清核心，重点突出，避免信息过载。
- 演讲中的表达：
- 清晰的逻辑：表达要有条理、有说服力。可采用“情境-冲突-问题-答案”（SCQA）的叙事结构。
- 自信的台风：保持眼神交流，使用自信、专业的肢体语言。你的表现会直接影响听众对你所汇报内容的信心。
- 精准回答提问：回答提问也是汇报的一部分。对于尖锐问题，冷静、专业地回应，这正是展现你深度的机会。
💎 总结
你提到的“核心技术”——做好PPT、向上管理和演讲汇报，本质是一套将个人专业能力转化为组织影响力的方法论。
你的故事也印证了，在大厂，很多项目可能失败，老板也可能调走。但在这个过程中，如果你掌握了如何思考、如何表达、如何争取资源的能力，那么在任何地方，你都具备极强的生存和发展的底气。这并非投机取巧，而是一种值得投入的“元能力”。
浙公网安备 33010602011771号