通知：与国同庆，代码随想录知识星球优惠活动进行中，这是全年加入代码随想录最低价格的机会。
跳槽到新公司的时候，一般都需要一些 成绩 来让自己在部门里立住脚。
校招其实还好，特别是社招，招你进来都是有所期待的，所以刚入职的时候 压力会比较大。
既要有产出，又不知道部门的整体习惯和风格。
以下知识星球一位录友的提问：
carl哥你好，想咨询一个职场问题
跳槽上海某书工作大半年了，与预期有一些差异之前以为技术水平会比较高，代码里很多反模式，依赖关系混乱（一个实体变更可能会影响到其他实体的一些判断，就是当一个实体变更时这个实体要去关心其他实体相关资源的维护）
技术实现和业务逻辑混杂在一起完全没有单测/充斥着硬编码，排障流程也比较混乱，文档很多但是一些标准行为的sop没有.
要说好处也有，业务量确实也大，很多部分接入了我们的服务，算是很重要的一个中台基建.
本来我想的是渐进式重构的方式从我入手到的接口逐步改造的，不过和身边工作年头较长的同事沟通时被认为过度设计。
我也比较倔，我从封装/单测/关注点分离的角度说了我的原因，我觉得我说清楚原因了，但我们好像都没有相互听进去。
然后还有个技术文档书写上，我更多是倾向于讲清楚思路，就是为了解决一个怎么样的问题/会是怎样的业务流程/用到什么技术组件/库表设计/稳定性设计与影响面。
而leader 是偏向于实施的风格。（理由是谁拿到这个技术文档都可以写出差不多的实现）比如要改动哪个代码文件里面的哪些函数，或者加一些什么函数/方法
基于上述背景我有四个问题：
1、虽然大多数我去执行的事情他没有很充分的理由我也不会去改，他也不会非常强硬的要求，就是可能要争执一个小时半个小时的，不过还是想问下有没有建议的相处方式
（我也不想妥协我这边的设计，另外这边业务复杂度/高性能要求也是我想要挑战的）
2、我能以怎样的方式让项目逐步变得易维护，最近其实在公开范围抛出了很多问题的（有点刺头了），也在着手去调整，但是易维护这个点很难定标准
3、cr应该重点关注哪部分？
4、技术文档应该侧重哪些内容，有没有模版推荐？
谢谢carl哥
Carl答：
1、能感受到你对技术还是比较有追求的，同时因为刚入职，也比较迫切希望 做出一些成绩，好在部门里 “立住脚”。
你在和你的老同事（可能是你的montor） 或者和 leader的交流过程中，要 始终贯彻一个中心点：就是收益， 你一波操作猛如虎的优化，带来的收益 是什么。
例如你说的 “技术实现和业务逻辑混杂在一起完全没有单测/充斥着硬编码” ，但目前的代码能跑，没明显bug，也足够支撑业务，你一波优化之后，会不会引入bug，甚至导致重大事故， 很多产品重大线上事故 都是因为优化代码导致的。
所以你的切入点，不能是为了改变 “逻辑混杂的代码”，改变“逻辑混杂的代码” 是手段，不是目的，目的是什么呢？你要说清楚。
我举个例子，你的目的可以是：目前的系统可以支持百万的QPS，但随着我们业务发展，如果想支持 上千万QPS，我们系统可扩展新差，需要 重构 “逻辑混杂的代码”。
这样的说辞 就完整了。上面的大领导，不看你的 代码混不混乱， 能跑能用就行，他们关心的是 你的系统 能否支撑业务。
例如你把目前的系统 “逻辑混杂的代码”，花了 大半年，十几个人都去重构， 这后台代码逻辑清晰了， 十几个人 工作大半年，对公司来说 人力成本投入有多大，保守来说上百万 投进去了吧， 收益是啥？
重构前的系统 支持 百万的QPS，现在还是 支持 百万的QPS 。 这还是全程没bug的情况， 有点bug很正常，如果有个重大bug，那完了，今年这个组的绩效GG。
这么一个成绩，你的leader 如何向他的leader交代呢。
所以，高T 或者高P 的程序员，在表明自己观点的时候，都是要从业务出发，代码优化 仅仅是手段，不是目的。
我还想到一个你可以说的目的，就是可以和leader聊 目前的项目代码 可维护性太差，这样对部门新人适应 项目开发的周期会拉长，而且非常容易引入bug。
让新人更快融入项目开发，这也是你能给项目组带来的收益， 优化前 新人要学半年 才能开发，优化后，新人一个月就能开发，你为项目组 节省了 5个月人力成本。
这也是实实在在的收益。
2、 “最近其实在公开范围抛出了很多问题的（有点刺头了）” 刚入职，不了解 项目组里的情况 和 项目组的发展历史，建议不要 公开抛问题， 很有可能你抛的这些问题，leader都知道，leader 看着这个项目组发展起来的，他知道 有很多历史问题。
例如：leader可能知道这个业务也就需要 百万的QPS 就够了，业务在可预期的范围内不会增长，重构系统没有意义，目前能用就行。
建议是 如果抛问题，就带上对应的解决方案和所需时间。而不是单纯的抛出问题。
如果这个问题 你没有解决方案，或者 你有解决方案但是一个很大的工程，那这个问题 可以先不抛。
因为如果是大问题 例如 “工程逻辑混杂的代码” ，可能大家都知道，但为什么一直都没有去改善，一定是有 项目组自己的原因的，大家都知道的问题，没有去改，要不就是不重要，要不就是碍于某些阻力 而不能实施。 你抛出这种问题，只能让大家都比较尴尬。
“我能以怎样的方式让项目逐步变得易维护” 正如问题一 我说的，你在 优化代码的过程中，leader 最担心的是 引入重大bug。
建议是你 先以你自己的需求为试验田， 项目组也要给你安排开发工作，你先自己的模块写的 易维护 就好，在组会分享上可以多分享自己开发的设计理念。
慢慢大家如果认可你的设计的话，其他新模块 也会采用你的 设计方法，至于老模块，还是轻易不要动。
3、代码的规范，是没有标准的，每个项目都有自己的风格，所以 Code Reiew 要遵循项目组的整体风格，但 Code Reiew 的时候 你可以说自己的意见 和 大家去交流。
4、你说的那种技术文档 “就是为了解决一个怎么样的问题/会是怎样的业务流程/用到什么技术组件/库表设计/稳定性设计与影响面” 有点像 需求文档 和 设计文档 的结合。
正常来说，你这个出发点是没问题的， 写文档没有统一要求，只要leader没有明确反对这么写，你都可以按照你想写的这种方式来写。
自己的文档风格 影响整个项目组 不是一蹴而就的，是一点一点 慢慢影响的。
你按照自己的想法写出的文档，可能某个契机 你的文档被leader看到 就发群里了（或者你主动发群里），说XX小伙这个文档写的不错，比之前咱们项目组写的好多了。
这就代表官方认可了，那么后面项目组都会按照你的这种风格来写。
或者你满足里成为高T之后，话语权慢慢提高了，可以更容易主导这种事情。
加油
最后，代码随想录知识星球优惠活动进行中，这是全年加入代码随想录最低价格的机会，录友们可以抓紧一波。
