无论哪个公司换了 CTO 或者架构师,系统必然迎来一波重构
最近被折腾惨了,也就吐槽一下
体现价值的时候到了
这个是必然的,马斯克进推特还得血洗一波呢。
It's Fucking Truth.
如果一家公司大部分的人都是 Leader ,那这个公司也没有搞头了。
重构难道不好吗?非得要像一坨屎之后,推倒重来?
自然规律,不然站不住脚啊,重构的过程正好是培养嫡系树权威的时候了。
是不是类似于修路...?
怎么看都是必然的。
1 、当前架构肯定有前任 CTO 的个人偏好。而新 CTO 未见得熟悉与擅长。
2 、当前架构肯定有各种妥协和取舍,甚至是雷。新 CTO 肯定不为此负责。
所以即便是客观角度看,也一定会调整的。
重构得动说明没那么屎
重构还好吧,重写就厉害了,说明之前是屎山中的屎山。
重构 996 ,很恶心的事情
不然怎么体现 CTO 的价值,新官上任都得折腾一下
我觉得这不只是树立权威的问题。每个人( CTO )有自己的技术取向和对公司现状的判断(稳定优先、效率优先、新技术优先...),需要通过一波重构来落实自己的理念,并留下愿意接受自己理念的、排除无法接受理念的人,这样后续才好管理。
假设一个 CTO 的目标就是死守线上稳定性(例如公司拉投资要求一定不能有 downtime ),那就要把现有系统里的不稳定因素取代掉,同时让技术上太激进的走人,以免动不动搞进来点新东西闹出大问题。
反过来,一个 CTO 就是想全面更新技术栈(让产品更现代化、同时打出公司技术先进的招牌),那就要把老旧的组件替换掉,同时让技术上太保守、懒得更新的走人,省的以后想搞新东西遇到很多阻力。
从老板的角度看,不重构的话,换 CTO 有什么意义
换位思考一下, 你是这个新来的 CTO, 会怎么做? 不重构继续做原来的, 做好了算你的还是算前任的? 做差了要你来干什么的?
重构质量与 CTO 任职时长呈负相关...
大家都忙起来
不重构,维护屎山的话,无非两个结果:
- 没出问题,那肯定是前任路铺的好的功劳
- 出问题了,新 cto 不行。
新 CTO 不想玩扫雷,也不想大难临头的时候推卸责任,尽早重构其实挺合理的。不过如果要加班搞的话,那就不合理了。
重构,客户的数据怎么办呢?
对比一下改进收益
会不会就是因为下了决心想重构,所以才换 CTO 的呢?
重构是个持续的过程,并不是一个阶段
很好
重构没问题,但楼上为什么都认为重构会带来一个 “好的结果”
之前是 Go 写得微服务,阿里出来的新架构看不上,开会必侃侃而谈 ava 有 xx 种解决方案,我在阿里用了 XX 框架。老总被忽悠,遂开始轰轰烈烈的 java 重构。
事实证明,阿里 NB ,javaNB ,但是从里面出来的螺丝钉啥也不是。加班几个月,上线后的服务一天炸九回。
本人不想写 java ,已离职,不知道现在情况如何,已知的是旧研发部的所有开发已经全部离职,一个不剩。并且原研发部的经理带着旧部下,旧源码出去拉投资搞竞品公司去了。
重构需要对原有业务有极深理解,了解现有的痛点和难点。
要对底下人的技术水平和能力有很深了解。
要有充足的时间和试错机会能抗住市场部门压力。
底下人辛辛苦苦,机会一点不给。空降过来的吊毛还要在你头上拉屎拉尿,还要带几个狗腿子过来搅浑水。
重构个 JB 。
天天加班不说,出问题是你的,有功劳是它的。
其实大部分所谓架构,CTO ,都是眼高手低,提批评意见的本事很大,干实事解决问题的本事很小。
只能在原有熟悉的领域里面如鱼得水。(阿里架构 yyds)
羡慕那些能有大牛带飞的人。
不管要不要重构,起码自己要对自己写的代码负责吧。有时候重构是被逼的,代码写完能跑就不管了, 后面也没有好好的整理,写注释, 到最后自己都看不懂。
我不重构前任,都是直接重写.我只重构我自己的代码 每开一个新仓库都要优化很多代码 相当于小重构
不重构大部分是因为懒,不想学新东西
看样子还是呆过的公司少
那不一定。还是看这个人的思路。
之前也没有实际上手接触过 NAS ,仅仅是看过一些介绍视频,因此 DIY NAS 这一部分就不在考虑范围内了。 预算在 1200CNY 以下(不含硬盘) 用途/需求: 用作照…
下面的这些经典的引言来自英文,也许有些我翻译的是不很好,所以,我提供了中英对照,如果有问题,请大家指正。 过早的优化是万恶之源。Premature optimizatio…
以下是原文: 我们发送此电子邮件是为了通知您,您的 Google Play 发布商帐号已被终止。 状态:帐号已被终止 Google Play 发布商帐号被终止与开发者的行为…