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

老田升职了，年薪涨到了百万级别！这时大刘在加班搞技术攻坚的时候，听别的同事聊了那么一嘴。大刘心里不是滋味儿。老田和大刘其实在这家公司之前就是同事了，老田能到这家公司，说起来还是大刘推荐的。但是，在公司的这几年，老田越来越受领导赏识，到如今，晋升成功，赫然成了大刘的上司。大刘百思不得其解。大刘和老田本身在前家公司都是高级程序员，前后脚跳槽到了现在这家公司。大刘来得早，成了架构师。老田呢，技术本就不如大刘，被大刘拉来后，先是当了个高级工程师，只是为了避嫌，没跟大刘一个团队。后来，老田被那时候的 Leader 赏识，做了带项目的组长，再后来，就是现在成功地晋升总监了。而大刘，好几年了却依然在架构师这岗位原地踏步，动弹不得。大刘陷入了浓浓的迷茫，他自问自己工作态度毫无问题，做事情也兢兢业业。公司的技术攻关，经常也是大刘牵头搞定。公司的技术培训，作为架构师的大刘俨然是一个非常权威的大牛讲师。就算是老田，也需要时不时去找大刘请教一些技术难题和技术方向。可是，即使这样，在公司技术领域造诣很深的大刘，却依然没有获得晋升之阶，被老田压了一头。

大刘没忍住，找了个不忙的日子，拉着老田去了个小饭馆，在饭桌上，大刘就说起了他自己的尴尬处境以及对老田升职加薪的不解。老田对大刘并没有藏着掖着，在饭桌上，他和大刘坦诚沟通了他的经验，并列出了他认为可以升职加薪的一些非常突出的能力。二人酒足饭饱，大刘回到家后，仔细琢磨深究，他总结了以下几点。

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

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

大刘阅读代码，特别喜欢看那些开源的好代码。跟着文档品读那些开源的优秀代码的卓越之处，每当看到妙处，大刘都觉得学到了新东西，感觉自己技术进步了许多。但是，当大刘阅读自己公司的各种代码的时候，大刘是相当没有耐心的。他觉得别人代码写得太次了，他把这些代码统统称为“屎山”。而老田恰恰相反。老实说，老田对市面上各种开源框架的了解水平，对各种中间件的内部原理理解都是远远不如大刘的，经常还需要咨询大刘。但是，对于公司的各项目代码，老田却是了如指掌，对各项目中的那些代码和问题都是有十分深入的了解。那么最终升职加薪不是大刘，这是为什么？

二人聊完之后，大刘终于明白了。首先，公司除了需要大刘的技术能力，更需要的是作为技术专家解决公司实际问题的能力。由于大刘抵触阅读公司很多项目的代码，所以，往往大刘的某些技术方案在落地的时候会出现脱节。有时候，又由于对项目代码的不理解，甚至没有给出有效的解决方案。而老田，由于对公司项目代码了解得很深入，虽然技术能力或者说知识面不如大刘，但是却总是能给出最合理的解决方案来。长此以往，老田反而比大刘更展示出了一位高级技术人员应该具有的能力。很多程序员和大刘其实是一样的，他们不喜欢自己公司的很多代码，认为这些代码质量极差，文档也非常欠缺，对自己的成长帮助不大。其实这个观念是很有问题的。对这些所谓“屎山”的代码，你如果全都读进去，研究下去，你起码会有两个好处:

你能具体知道代码烂在什么地方，那么以后你的代码就不会出现同样的问题——由于你知道了烂代码烂在哪里，你一定能写出更好的代码，从而让那些屎山的代码逐渐会被自己写的好代码所替代。这样一比较，你的专业能力会显得非常突出，让更多的人认可你这位架构师的能力。
你对公司这些代码读得越多，掌握得越多，你越不可替代——对公司这些代码读得越通透，你越能更快速轻松地把控这些代码，让以后对这些代码的变革变得更容易。而轻松修改、革新这些代码的能力，就会变成你在这家公司不可替代性的重要因素。

所以，各种代码，无论质量好坏，都需要能读懂读通，并且读得越多越好。能读懂读通任何质量的代码，才是真正地掌握了阅读代码的能力。读得越多，则能识别代码质量的能力就越强，将来自己就越能写出更好质量的代码。

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

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

三年前，俩人一起搞了个供公司所有业务项目用的监控系统，目的是解决公司项目错误无法及时发现和处理的问题。当时，这套监控系统公司要得急，大家匆匆设计了一版，就赶紧赶鸭子上架地做了一版。技术方案也没花太多心思，怎么快怎么来。搞完之后，大刘觉得这项目以后也就这样了，公司内部项目，既没有发展，也没有什么前景。可是，如今和老田沟通后，大刘才吃惊地发现，老田居然一直跟着这个项目，并对这项目进行了无数次总结分析和优化。随着不断地改进，这套项目竟然发展出来了一套非常完备的 APM 系统，使用体验非常不错。公司的商务给客户出解决方案的时候，经常也会连带着把这套监控系统包含到解决方案里。客户的反馈也很好，为公司拿下了更多的订单。而大刘自己呢，为公司的核心系统设计了一套底层的服务调度编排框架，公司很多系统的底层都依赖于这套框架。虽然这套框架大刘自己认为写得很棒，但是由于部署复杂，对应的一些辅助工具链也由于大刘的忽视，没有及时开发出来。导致后续的新项目，大家宁肯用一些开源框架自己改进，也不再使用大刘的这套框架。

分析起来，其实这也算是大刘和老田对各自项目的发展判断能力的差距导致的。老田根据用户反馈和市场行情，他感觉监控系统本身应该是有前途的。并在调研了市面上竞对产品的基础上，让这套监控系统迸发出了绚烂的色彩。而大刘，高开低走，写出来一个好框架，但是由于对框架的预期判断错误，加上对用户反馈重视不够，最终导致本来应该非常出彩的框架就此沉沦了下去。

3. 去主动管理会议

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

大刘对此非常烦恼，经常因为这些冗长的会议，耽误了许多手头的工作。特别是，大刘作为架构师，需要大块连续的时间去思考技术难题，解决系统问题，以及考虑新项目的架构设计。但是频繁的会议，把大刘的时间搅和得支离破碎。对于这个问题，大刘在饭桌上请教了老田。老田说，他也面对了这些问题，好在他通过一些自己的方法，很大程度缓解了这些问题。

老田做了如下几个事情:

老田对第二天的会议提前和参会各方沟通，开会时间尽量协调到一起，这样老田能腾出一整块儿时间，把当日所有可能的会议都集中开完。后续老田就会有连续的时间去深度工作了。
老田会在开会前一天，把会议内容和可能出现的问题都预先做功课。一方面是防止会议开着开着跑题；二是万一出现争议问题，老田可以列举出来事先准备的技术方案，这样也能加快会议进度。
还有，对于一些不那么重要的会议，老田一定会态度坚决地避开或者指派别人参加。

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

这个问题是老田主动和大刘提出来的。老田发现，对于版本工具使用不当，会耽误开发人员很多时间。而版本控制工具，即使一些工作多年的程序员，往往也经常会使用不当。这些不当的使用，会造成许多问题。比如，各种各样的代码冲突、版本重叠，莫名其妙的代码丢失。对此，老田每次负责一个新项目，都会严格指定版本工具的使用规范，会花时间对开发人员统一培训版本工具的使用。同时，也会把各种技巧、注意事项、常用命令整理好，放在内部的共享文档中。

老田的这些举措，在实践中，大大改善了版本控制工具不当使用造成的问题。有一个项目组在规范使用之后，竟然比之前的开发速度快了三分之一。可想而知，这个问题有多严重了。

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

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

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

老田举了个例子，比如，一套内部使用的资产管理系统，中间有一个需要调用公司其他项目接口的小功能，这种简单的东西交给了一个比较年轻的程序员。结果这个程序员又是考虑对方接口不稳定的情况，又是考虑这个功能会有使用过度频繁的情况，还使用了缓存去储存一些状态，防止频繁调用数据库。对于这种情况，从纯技术角度，当然会鼓励人们想得越全面越好。但是，在实际落地的时候，你要明白这只是一个公司内部使用的小项目，没必要为了各种概率很低的风险，把明明很小的一个功能给做得很复杂。

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

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

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

老田对于任务紧急程度的判断都是经过深思熟虑、实际分析过的，任务之间的先后顺序，也和任务交付人认真沟通过。对一些根本没必要的任务，老田会态度坚决地对这些任务说 No。大刘自我总结，他这方面做得不好。首先，他安排任务容易被任务交付人的情绪影响，对方催得急，他就优先安排。其次，任何任务大刘都没有拒绝过，顶多是排期靠后。最后，大刘没有考虑任务和任务之间的关系，有些任务之间是关联的，完全可以融合一起搞定，大刘却没有思考，从而割裂开安排，这也是很大的问题。

比如上次，大刘接到两个任务：（1）去掉 VMware；（2）MQ 版本升级。这两个任务都需要业务系统停服才能干，大刘当时也没在意，两个任务放在两天，连续两天停服，虽说每天停的时间不长吧……这俩任务完全可以放在一起，利用一次停服集中解决。这样对用户影响更小，业务部门也不会那么不满。

7. 不要死板地写代码

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

所谓的代码能力，有的是指写代码不出 Bug 的能力，有的是指算法落地能力……但这里想说的是，不写死板的呆代码的能力。这是什么意思呢？

我们都知道，程序员少不了要维护老项目。在维护项目的时候，我们面对各种不断的新需求，经常要去修改代码。修改代码是个很危险的事情，因为我们修改的代码往往会和别的功能耦合住。改了一点代码，结果影响一大片功能的情况经常出现。最虐心的是，这种连带影响可能不会马上出现，不知道哪天就突然冒出来折腾一把。如果改代码经常出问题，这谁扛得住啊！别说你自己的技术话语权了，也别说在职场脱颖而出了，工作能不能保得住都不好说。

所以，对于修改代码的事情，我们需要学会的是不要写呆代码。再说得直白点就是，你不能写完代码运行下没问题就觉得正常了，你在写代码之前需要好好思考。这种思考，既不是什么搞设计模式松耦合，也不是搞功能切分独立成块。这种思考本质是需要你写代码前去理解业务，去真正明白业务在实际是怎么运作的。

简单说两个例子：

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

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

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

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

比如，你搞一个用户充值功能。本来你只是想着用户游戏内购直接充值即可。但是，在实际上线后，有时候运营为了方便 vip 客户或者为了和第三方渠道互换资源，也会使用这个充值功能。运营大批量的连续充值，并且这些充值转换成系统中的货币，就像游戏中的元宝，就有可能超出 Java 中的整数上限，从而造成问题。如果你提前知道用户、运营人员都是怎么使用这个功能的，你就会把数据类型修改成 Long 了。

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

后记

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

一个技术总监的忠告：精通那么多技术，你为何还是受不到重用？相关推荐

《王者荣耀》技术总监：我们为什么要在技术架构与网络同步方案上做出这些改变？
<王者荣耀>技术总监:我们为什么要在技术架构与网络同步方案上做出这些改变? https://blog.csdn.net/D_Guco/article/details/78091910 版权 ...
专访七牛云技术总监陈超：浅谈开源技术选型考量
编者按:最近一次见到陈超(@CrazyJVM,七牛云技术总监)是在SDCC架构和数据库峰会的上海站,当时他给大家带来的是一个时间序列数据库的话题--"InfluxDB".这是一个令 ...
一个技术总监的忠告：精通那么多技术有毛用啊，你还不是不被重用？
这篇文章我们继续说架构师大刘的故事: 老田升职了,年薪涨到了百万级别! 这是大刘在加班搞技术攻坚的时候,听别的同事聊了那么一嘴. 大刘心里不是滋味儿.老田和大刘其实在这家公司之前就是同事了,老田能到这 ...
一线互联网技术总监的忠告：我们精通那么多技术为何还是做不好一个项目？
4.5 症结 3:抽象不够.逻辑纠缠--High Level 业务逻辑和 Low Level 实现逻辑纠缠当我们说"代码中包含的业务逻辑"的时候,我们到底在说什么?业界并没有一个 ...
做一个合格的技术总监
做一个合格的技术总监 1. 技术总监的定位企业内负责技术的最高负责人, * 长期技术方向(战略性) * 短期技术方向(战术性) * 管理研究对公司经营活动和营利的影响 * 公司中使用的软 ...
怎样才能胜任技术总监
技术总监是企业团体里的高阶主管职位之一,是企业内负责技术的最高负责人,类似总工程师.技术总监需要有多年的行业内技术开发工作经验,精通行业相关技术及了解同行技术发展状况,并且还要有一定的技术前瞻性和团队 ...
#为何程序员百万年薪，CTO技术总监架构师不写代码还这么牛逼？
[此文章转自乐字节] 真的是一点不服气我的领导,每天就在座位上看看头条,到时间开开会,每天写代码的时间可能不到两小时,到底是为什么他的收入有年薪百万?我们都是985研究生毕业,是什么铸就了他的价值? ...
技术总监到底要不要写代码？
https://www.toutiao.com/a6698485180505522695/ 这是一个非常敏感的话题,每次谈论到技术总监要不要写代码的时候,总会引起一片争论. 有的程序员说技术总监如果不 ...
研发管理（2）---技术总监的三板斧
说说技术总监的三板斧 2018一转眼就过去了1/6还要多,这个时间想必很多人都在思考职业规划,甚至是要不要另谋高就,作为一个老技术人,今天不聊技术,就聊点技术人员职业发展的事情:对技术管理岗位的认知, ...

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