欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

作为一个空降的架构师,如何开展新工作? 工作面试网络协议金山Firefox 

程序员文章站 2022-07-06 13:45:42
...
我是今年三月作为架构师加入当前公司的。

作为一个空降的架构师,如何开展新工作?

先来介绍一下公司背景:

技术部在公司属于辅助部门,主要工作是开发软件给业务部门用
业务部门负责赚钱,在公司业务部的话语权非常高,因此,我们技术部老大反复强调,业务部就是上帝。
我所在的组有一个开发了快7年的产品,由于刚开始开发时没有想过什么架构的问题,因此,整个项目代码十分混乱,每一个模块除了该模块的开发者外,其他人根本看不懂。
用管技术的副总的话来说,系统再不重构迟早有一天会出问题。因此,副总把我招进公司,挑头负责架构设计和系统重构。但是,除了副总,公司里其他人却不愿意重构。

存在的问题

技术部老大的观点是,可以重构,但必须在完成旧系统的维护工作和新功能之后再重构。
我所在组的老大的观点是暂时不要重构,等过两年实在维护不了再说。
其他开发人员的观点是千万不要重构,因为重构相当于重新开发,会大大增加他们工作量。
测试人员同样不支持重构。
这两个多月我不断地和开发人员探讨重构的意义,也写了好多Demo给他们证明重构后的架构能降低新需求的开发难度。但是,大多数开发人员还是不愿意重构,他们宁肯在旧系统上赖着,也不愿意学习一些新的东西。

我试图强制开发人员按照我设计的架构编写代码,结果各种磨洋工,然后向上级反映我的架构严重拖累了开发进度。

总而言之,除了管技术的副总在面试我时流露出较强的重构系统的想法,其他人员都不愿意重构。而我和技术副总之间隔了两层领导,我不大好绕过组老大和部门老大向副总汇报工作。

我问了几个朋友的建议,他们是这样告诉我的

A: 你和别人的冲突点在于:你的重构加重了我的工作量,那么我不愿意做。

所以,你需要为重构争取时间,比如需求hold 60%,大家来做重构,或者专人来做这件事,之后做整体架构迁移。

当架构成型后,逐步让大家将新需求移往新架构,而有同学负责做老架构的迁移工作。

首先要保证的,是在沉重的开发压力下,不能加重现有研发同学的负担。否则想推动,几乎不可能。也许我做半年一年就走了,为什么要为你的kpi加班呢?

其次要保证的,是架构的稳定性,新架构不能动摇现有业务。

最后要说服现部门的leader,在能够争取到减少新业务开发的情况下(最好是停止),使用新架构在之后会带来减少工作量、规范代码结构、稳定架构的作用,并且不会让大家有额外的负担。和leader协商,用哪种途径去解决这件事。

否则,你重构就要我工作量double,工资又不double,我才不做呢。

B:不分析政治的事情,光从做事的角度来讲步骤:

分析业务,流程,文档,代码。
在完全不依赖其他开发人员的前提下,理清系统的大致脉络,列出功能蓝图。
基于1/2步工作完成的情况下,再评估到底要不要重构!
这是作为架构师接手一个陌生项目所必须的前期布局。千万不要为了重构而重构。重构可能只是手段,而非目的。
4、融入到原来的那群技术人员内部去,并把最重要的设计、最核心的代码,抓到自己手里。

5、理想状态就是业务部门需要什么新功能,你起码可以评估出工作量

到一个公司,最重要的是完成对关键岗位的站位,不仅仅需要领导的任命,更需要落实成一个事实。后者更重要。
C:我的建议:首先你要确定,公司目前的代码究竟有没有必要进行重构,重构的成本有多高?重构的受益有多大?

其次,如果你真的确定要重构,那么你要想明白别人究竟想不想重构,因为你是管理岗,管理岗意味着你不是具体敲代码的那个人,而是你要指挥一堆人按照你的想法敲代码,那么别人支持不支持你,就显得至关重要了。

事实上,人和人想法各异,就算大家都想重构,他们究竟想重构到什么程度,是部分重构还是完全推倒重来,这差别很大。如何协调意见向左的人,如何求同存异,是管理人员的必备技能。

而一切的基础是,首先你要取得大家的信任。让大家服气你。作为架构师,你起码技术过硬,作为主导重构的核心人员,你又要表现出足够的胸怀和气度以证明你可以肩负起这个任务,很多情况下总有谈不拢的时候,在这个时候,你本人是否有服众实力,直接决定了你的想法是否能够如期推进。

如果大家有什么好的建议可以评论告诉我,也可以加入架构师交流群:671017482一起交流,学习。
大家觉得作为一个空降的架构师,得如何开展新工作呢?