...

一个技术总监的忠告:精通那么多技术,你为何还是受不到重用?

2021-07-19

这篇文章我们继续说架构师大刘的故事:

老田升职了,年薪涨到了百万级别!

这是大刘在加班搞技术攻坚的时候,听别的同事聊了那么一嘴。

大刘心里不是滋味儿。老田和大刘其实在这家公司之前就是同事了,老田能到这家公司,说起来还是大刘推荐的。

但是,在公司的这几年,老田越来越受领导赏识,到如今,晋升成功,赫然成了大刘的上司。大刘百思不得其解。

大刘和老田本身在前家公司都是高级程序员,前后脚跳槽到了现在这家公司。

大刘来的早,成了架构师。老田呢,技术本就不如大刘,被大刘拉来后,先是当了个高级工程师,只是为了避嫌,没跟大刘一个团队。

后来,老田被那时候的 Leader 赏识,做了带项目的组长,再后来,就是现在成功的晋升总监了。而大刘,好几年了却依然在架构师这岗位原地踏步,动弹不得。

大刘陷入了浓浓的迷茫,他自问自己工作态度毫无问题,做事情也兢兢业业。公司的技术攻关,经常也是大刘牵头搞定。公司的技术培训,作为架构师的大刘俨然是一个非常权威的大牛讲师。

就算是老田,也需要时不时去找大刘请教一些技术难题和技术方向。可是,即使这样,在公司技术领域造诣很深的大刘,却依然没有获得进身之阶,被老田压了一头。

大刘没忍住,找了个不忙的日子,拉着老田去了个小饭馆,在饭桌上,大刘就说起了他自己的尴尬处境以及对老田升职加薪的不解。

老田对大刘并没有藏着掖着,在饭桌上,他和大刘坦诚沟通了他的经验,并列出了他认为他可以升职加薪的一些非常突出的能力。

二人酒足饭饱,大刘回到家后,仔细琢磨深究,他总结了以下几点。

1. 尽量努力的多去阅读别人的代码,越多越好

这点大刘开始并没当回事,可是在和老田沟通的过程中,大刘发现,老田理解的阅读别人的代码和他理解的阅读代码是两回事。

大刘阅读代码,特别喜欢看那些开源的好代码。跟着文档品读那些开源的优秀代码的卓越之处,每当看到妙处,大刘都觉得学到了新东西,感觉自己技术进步了许多。

但是,当大刘阅读自己公司的各种代码的时候,大刘是相当没有耐心的。他觉得别人代码写的太次了,他把这些代码统统成为“屎山”。

而老田恰恰相反。老实说,老田对市面上各种开源框架的了解水平,对各种中间件的内部原理理解都是远远不如大刘的,经常还需要咨询大刘。

但是,对于公司的各项目代码,老田却是了如指掌,对各项目中的那些代码和问题都是有十分深入的了解。

那么最终升职加薪不是大刘,这是为什么?

二人聊完之后,大刘终于明白了。

首先,公司除了需要大刘的技术能力,更需要的是作为技术专家解决公司实际问题的能力。

由于大刘抵触阅读公司很多项目的代码,所以,往往大刘的某些技术方案在落地的时候会出现脱节。有时候,又由于对项目代码的不理解,甚至没有给出有效的解决方案。

而老田,由于对公司项目代码了解的很深入,虽然技术能力或者说知识面不如大刘,但是却总是能给出最合理的解决方案来。

长此以往,老田反而比大刘更展示出了一位高级技术人员应该具有的能力。

很多程序员和大刘其实是一样的,他们不喜欢自己公司的很多代码,认为这些代码质量极差,文档也非常欠缺,对自己的成长帮助不大。

其实这个观念其实是很有问题的。

对这些所谓“屎山”的代码,你如果全都读进去,研究下去,你起码会有两个好处:

  1. 你能具体知道代码烂在什么地方,那么以后你的代码就不会出现同样的问题——由于你知道了烂代码烂在哪里,你一定能写出更好的代码,从而让那些屎山的代码逐渐会被自己写的好代码所替代。这样一比较,你的专业能力会显得非常突出,让更多的人认可你这位架构师的能力。

  2. 你对公司这些代码读的越多,掌握的越多,你越不可替代——对公司这些代码读的越通透,你越能更快速轻松地把控这些代码,让以后对这些代码的变革变得更容易。而轻松修改、革新这些代码的能力,就会变成你在这家公司不可替代性的重要因素。

所以,各种代码,无论质量好坏,都需要能读懂读通,并且读的越多越好。

能读懂读通任何质量的代码,才是真正的掌握了阅读代码的能力。读的越多,则能识别代码质量的能力就越强,将来自己就越能写出更好质量的代码。

2. 能准确判断项目的发展方向

大刘和老田谈的时候,让大刘印象最深刻的就是,老田对项目发展状态的精准判断。

三年前,俩人一起搞了个供公司所有业务项目用的监控系统,目的是解决公司项目错误无法及时发现和处理的问题。

当时,这套监控系统公司要的急,大家匆匆设计了一版,就赶紧赶鸭子上架的做了一版。

技术方案也没花太多心思,怎么快怎么来。搞完之后,大刘觉得这项目以后也就这样了,公司内部项目,既没有发展,也没有什么前景。

可是,如今和老田沟通后,大刘才吃惊的发现,老田居然一直跟着这个项目,并对这项目进行了无数次总结分析和优化。

随着不断地改进,这套项目竟然发展出来了一套非常完备的 APM 系统,使用体验非常不错。公司的商务给客户出解决方案的时候,经常也会连带着把这套监控系统包含到解决方案里。客户的反馈也很好,为公司拿下了更多的订单。

而大刘自己呢,为公司的核心系统设计了一套底层的服务调度编排框架,公司很多系统的底层都依赖于这套框架。

虽然这套框架大刘自己认为写的很棒,但是由于部署复杂,对应的一些辅助工具链也由于大刘的忽视,没有及时开发出来。导致后续的新项目,大家宁肯用一些开源框架自己改进,也不再使用大刘的这套框架。

分析起来,其实这也算是大刘和老田对各自项目的发展判断能力的差距导致的。

老田根据用户反馈和市场行情,他感觉监控系统本身应该是有前途的。并在调研了市面上竞对产品的基础上,让这套监控系统迸发出来了绚烂的色彩。

而大刘,高开低走,写出来一个好框架,但是由于对框架的预期判断错误,加上对用户反馈重视不够,最终导致本来应该非常出彩的框架就此沉沦了下去。

3. 去主动管理会议

作为公司比较重要的技术专家,大量的会议是免不了的。

大刘对此非常烦恼,经常因为这些冗长的会议,耽误了许多手头的工作。

特别是,大刘作为架构师,需要大块连续的时间去思考技术难题,解决系统问题,以及考虑新项目的架构设计。但是频繁的会议,把大刘的时间搅和的支离破碎。

对于这个问题,大刘在饭桌上请教了老田。老田说,他也面对了这些问题,好在他通过一些自己的方法,很大程度缓解了这些问题。

老田做了如下几个事情:

  1. 老田对第二天的会议提前和参会各方沟通,开会时间尽量协调到一起,这样老田能腾出一整块儿时间,把当日所有可能的会议都集中开完。后续老田就会有连续的时间去深度工作了。

  2. 老田会在开会前一天,把会议内容和可能出现的问题都预先做功课。一方面是防止会议开着开着跑题;二是万一出现争议问题,老田可以列举出来事先准备的技术方案,这样也能加快会议进度。

  3. 还有,对于一些不那么重要的会议,老田一定会态度坚决的避开或者指派别人参加。

4. 版本控制工具的熟练应用

这个问题是老田主动和大刘提出来的。

老田发现,对于版本工具使用不当,会耽误开发人员很多时间。而版本控制工具,即使一些工作多年的程序员,往往也经常会使用不当。

这些不当的使用,会造成许多问题。比如,各种各样的代码冲突、版本重叠,莫名其妙的代码丢失。

对此,老田每次负责一个新项目,都会严格指定版本工具的使用规范,会花时间对开发人员统一培训版本工具的使用。同时,也会把各种技巧、注意事项、常用命令整理好,放在内部的共享文档中。

老田的这些举措,在实践中,大大改善了版本控制工具不当使用造成的问题。

有一个项目组在规范使用之后,竟然比之前的开发速度快了三分之一。可想而知,这个问题有多严重了。

5. 不要把解决方案复杂化

老田和大刘谈了谈关于技术和技术落地之间存在的问题。

老田和大刘都发现有些程序员特别喜欢炫技,这些炫技某些时候会导致整个系统复杂化,最终产出反而不尽如人意。

老田举了个例子,比如,一套内部使用的资产管理系统,中间有一个需要调用公司其他项目接口的小功能,这种简单的东西交给了一个比较年轻的程序员。

结果这个程序员又是考虑对方接口不稳定的情况,又是考虑这个功能会有使用过度频繁的情况,还使用了缓存去储存一些状态,防止频繁调用数据库。

对于这种情况,从纯技术角度,当然会鼓励人们想的越全面越好。但是,在实际落地的时候,你要明白这只是一个公司内部使用的小项目,没必要为了各种概率很低的风险,把明明很小的一个功能给做的很复杂。

针对这种问题,就需要技术 Leader 及早发现、介入,防止出现过度设计、过度开发。

6. 把任务安排的井井有条

老田其实和大刘一样,每天杂事儿很多,每天的任务也很多。大家对这些任务的管理能力自然就有高有低。

老田对于任务紧急程度的判断都是经过深思熟虑、实际分析过的,任务之间的先后顺序,也和任务交付人认真沟通过。对一些根本没必要的任务,老田会态度坚决的对这些任务说 No。

大刘自我总结,他这方面做的不好。首先,他安排任务容易被任务交付人的情绪影响,对方催的急,他就优先安排。其次,任何任务大刘都没有拒绝过,顶多是排期靠后。最后,大刘没有考虑任务和任务之间的关系,有些任务之间是关联的,完全可以融合一起搞定,大刘却没有思考,从而割裂开安排,这也是很大的问题。

比如上次,大刘接到两个任务:1、去掉 VMware;2、MQ 版本升级。

这两个任务都需要业务系统停服才能干,大刘当时也没在意,两个任务放在两天,连续两天停服,虽说每天停的时间不长吧……

这俩任务完全可以放在一起,利用一次停服集中解决。这样对用户影响更小,业务部门也不会那么不满。

7. 不要死板的写代码

很多程序员知识面很宽,基本功也非常扎实。但是,有一种能力,是学校教不出来、面试也不容易看出来的,就是代码能力。

所谓的代码能力,有的是指写代码不出 Bug 的能力,有的是指算法落地能力……但这里想说的,是不写死板的呆代码的能力。

这是什么意思呢?

我们都知道,程序员少不了要维护老项目。在维护项目的时候,我们面对各种不断的新需求,经常要去修改代码。

修改代码是个很危险的事情,因为我们修改的代码往往会和别的功能耦合住。改了一点代码,结果影响一大片功能的情况经常出现。最虐心的是,这种连带影响可能不会马上出现,不知道哪天就突然冒出来折腾一把。

如果改代码经常出问题,这谁扛得住啊!别说你自己的技术话语权了,也别说在职场脱颖而出了,工作能不能保得住都不好说。

所以,对于修改代码的事情,我们需要学会的是不要写呆代码。再说的直白点就是,你不能写完代码运行下没问题就觉得正常了,你在写代码之前需要好好思考。

这种思考,既不是什么搞设计模式松耦合,也不是搞功能切分独立成块。这种思考本质是需要你写代码前去理解业务,去真正明白业务在实际是怎么运作的。

简单说两个例子:

7.1. 修改完代码后,用户会怎么使用你现在修改的功能?

比如,你修改了注册功能,可以兼容第三方登录。那么,可能有的老用户会重新注册一个账号,以方便第三方登录。那你对这种情况,其实该做的是绑定,而不是让用户重新注册个新账号。

这种疏漏,等到上线之后才发现就晚了。这不能完全依赖产品经理,作为一个技术人员本来就应该对自己的功能做通盘的考虑,这才是真正的负责。

7.2. 你现在修改的功能,会不会由于运营需要,会换成你完全没想过的用法?

比如,你搞一个用户充值功能。本来你只是想着用户游戏内购直接充值即可。但是,在实际上线后,有时候运营为了方便 vip 客户或者为了和第三方渠道互换资源,也会使用这个充值功能。

运营大批量的连续充值,并且这些充值转换成系统中的货币,就像游戏中的元宝,就有可能超出 Java 中的整数上限,从而造成问题。如果你提前知道用户、运营人员都是怎么使用这个功能的,你就会把数据类型修改成 Long 了。

类似的例子有很多,老田还要继续说下去的时候,大刘给他打断了,“扎心了,你说这些坑我没少掉进去。”

后记

通过和老田沟通,大刘知道自己的问题出在哪了。他明白了,技术只是技术人员的基础,在实际工作中想脱颖而出,除了要有过硬的技术,还需要你的态度、你的各种软实力,需要你把技术转化为实际生产力的能力。

大刘的故事这次先说到这里。 


来源:DotNET技术圈