尽量努力的多去阅读别人的代码，越多越好
A阅读代码，特别喜欢看那些开源的好代码。跟着文档品读那些开源的优秀代码的卓越之处，每当看到妙处，A都觉得学到了新东西，感觉自己技术进步了许多。
但是，当A阅读自己公司的各种代码的时候，大刘是相当没有耐心的。他觉得别人代码写的太次了，他把这些代码统统成为“屎山”。
而B恰恰相反。老实说，B对市面上各种开源框架的了解水平，对各种中间件的内部原理理解都是远远不如A的，经常还需要咨询A。但是，对于公司的各项目代码，B却是了如指掌，对各项目中的那些代码和问题都是有十分深入的了解。
那么最终升职加薪不是A，这是为什么？
首先，公司除了需要A的技术能力，更需要的是作为技术专家解决公司实际问题的能力。
由于A抵触阅读公司很多项目的代码，所以，往往A的某些技术方案在落地的时候会出现脱节。有时候，又由于对项目代码的不理解，甚至没有给出有效的解决方案。
而B，由于对公司项目代码了解的很深入，虽然技术能力或者说知识面不如A，但是却总是能给出最合理的解决方案来。长此以往，B反而比A更展示出了一位高级技术人员应该具有的能力。
很多程序员和A其实是一样的，他们不喜欢自己公司的很多代码，认为这些代码质量极差，文档也非常欠缺，对自己的成长帮助不大。其实这个观念其实是很有问题的。
对这些所谓“屎山”的代码，你如果全都读进去，研究下去，你起码会有两个好处:
（1）：你能具体知道代码烂在什么地方，那么以后你的代码就不会出现同样的问题——由于你知道了烂代码烂在哪里，你一定能写出更好的代码，从而让那些屎山的代码逐渐会被自己写的好代码所替代。这样一比较，你的专业能力会显得非常突出，让更多的人认可你这位架构师的能力。
（2）：你对公司这些代码读的越多，掌握的越多，你越不可替代——对公司这些代码读的越通透，你越能更快速轻松地把控这些代码，让以后对这些代码的变革变得更容易。而轻松修改、革新这些代码的能力，就会变成你在这家公司不可替代性的重要因素。
所以，各种代码，无论质量好坏，都需要能读懂读通，并且读的越多越好。
能读懂读通任何质量的代码，才是真正的掌握了阅读代码的能力。读的越多，则能识别代码质量的能力就越强，将来自己就越能写出更好质量的代码。-
能准确判断项目的发展方向
A和B谈的时候，让A印象最深刻的就是，B对项目发展状态的精准判断。
三年前，俩人一起搞了个供公司所有业务项目用的监控系统，目的是解决公司项目错误无法及时发现和处理的问题。
当时，这套监控系统公司要的急，大家匆匆设计了一版，就赶紧赶鸭子上架的做了一版。
技术方案也没花太多心思，怎么快怎么来。搞完之后，A觉得这项目以后也就这样了，公司内部项目，既没有发展，也没有什么前景。
可是，如今和B沟通后，A才吃惊的发现，B居然一直跟着这个项目，并对这项目进行了无数次总结分析和优化。
随着不断地改进，这套项目竟然发展出来了一套非常完备的 APM 系统，使用体验非常不错。公司的商务给客户出解决方案的时候，经常也会连带着把这套监控系统包含到解决方案里。客户的反馈也很好，为公司拿下了更多的订单。
而A自己呢，为公司的核心系统设计了一套底层的服务调度编排框架，公司很多系统的底层都依赖于这套框架。
虽然这套框架大刘自己认为写的很棒，但是由于部署复杂，对应的一些辅助工具链也由于A的忽视，没有及时开发出来。导致后续的新项目，大家宁肯用一些开源框架自己改进，也不再使用大刘的这套框架。
分析起来，其实这也算是A和B对各自项目的发展判断能力的差距导致的。
B根据用户反馈和市场行情，他感觉监控系统本身应该是有前途的。并在调研了市面上竞对产品的基础上，让这套监控系统迸发出来了绚烂的色彩。
而A，高开低走，写出来一个好框架，但是由于对框架的预期判断错误，加上对用户反馈重视不够，最终导致本来应该非常出彩的框架就此沉沦了下去。 去主动管理会议
作为公司比较重要的技术专家，大量的会议是免不了的。
A对此非常烦恼，经常因为这些冗长的会议，耽误了许多手头的工作。
特别是，A作为架构师，需要大块连续的时间去思考技术难题，解决系统问题，以及考虑新项目的架构设计。但是频繁的会议，把大刘的时间搅和的支离破碎。
对于这个问题，大刘在饭桌上请教了B。B说，他也面对了这些问题，好在他通过一些自己的方法，很大程度缓解了这些问题。
B做了如下几个事情:
B对第二天的会议提前和参会各方沟通，开会时间尽量协调到一起，这样B能腾出一整块儿时间，把当日所有可能的会议都集中开完。后续B就会有连续的时间去深度工作了。
B会在开会前一天，把会议内容和可能出现的问题都预先做功课。一方面是防止会议开着开着跑题；二是万一出现争议问题，B可以列举出来事先准备的技术方案，这样也能加快会议进度。
还有，对于一些不那么重要的会议，B一定会态度坚决的避开或者指派别人参加。
- 版本控制工具的熟练应用
这个问题是B主动和A提出来的。
B发现，对于版本工具使用不当，会耽误开发人员很多时间。而版本控制工具，即使一些工作多年的程序员，往往也经常会使用不当。
这些不当的使用，会造成许多问题。比如，各种各样的代码冲突、版本重叠，莫名其妙的代码丢失。
对此，B每次负责一个新项目，都会严格指定版本工具的使用规范，会花时间对开发人员统一培训版本工具的使用。同时，也会把各种技巧、注意事项、常用命令整理好，放在内部的共享文档中。
B的这些举措，在实践中，大大改善了版本控制工具不当使用造成的问题。
有一个项目组在规范使用之后，竟然比之前的开发速度快了三分之一。可想而知，这个问题有多严重了。
- 不要把解决方案复杂化
B和A谈了谈关于技术和技术落地之间存在的问题。
B和A都发现有些程序员特别喜欢炫技，这些炫技某些时候会导致整个系统复杂化，最终产出反而不尽如人意。
B举了个例子，比如，一套内部使用的资产管理系统，中间有一个需要调用公司其他项目接口的小功能，这种简单的东西交给了一个比较年轻的程序员。
结果这个程序员又是考虑对方接口不稳定的情况，又是考虑这个功能会有使用过度频繁的情况，还使用了缓存去储存一些状态，防止频繁调用数据库。
对于这种情况，从纯技术角度，当然会鼓励人们想的越全面越好。但是，在实际落地的时候，你要明白这只是一个公司内部使用的小项目，没必要为了各种概率很低的风险，把明明很小的一个功能给做的很复杂。
针对这种问题，就需要技术 Leader 及早发现、介入，防止出现过度设计、过度开发。
- 把任务安排的井井有条
B其实和A一样，每天杂事儿很多，每天的任务也很多。大家对这些任务的管理能力自然就有高有低。
B对于任务紧急程度的判断都是经过深思熟虑、实际分析过的，任务之间的先后顺序，也和任务交付人认真沟通过。对一些根本没必要的任务，B会态度坚决的对这些任务说 No。
A自我总结，他这方面做的不好。首先，他安排任务容易被任务交付人的情绪影响，对方催的急，他就优先安排。其次，任何任务A都没有拒绝过，顶多是排期靠后。最后，A没有考虑任务和任务之间的关系，有些任务之间是关联的，完全可以融合一起搞定，A却没有思考，从而割裂开安排，这也是很大的问题。
比如上次，A接到两个任务：1、去掉 VMware；2、MQ 版本升级。
这两个任务都需要业务系统停服才能干，A当时也没在意，两个任务放在两天，连续两天停服，虽说每天停的时间不长吧……
这俩任务完全可以放在一起，利用一次停服集中解决。这样对用户影响更小，业务部门也不会那么不满。
- 不要死板的写代码
很多程序员知识面很宽，基本功也非常扎实。但是，有一种能力，是学校教不出来、面试也不容易看出来的，就是代码能力。
所谓的代码能力，有的是指写代码不出 Bug 的能力，有的是指算法落地能力……但这里想说的，是不写死板的呆代码的能力。
这是什么意思呢？
我们都知道，程序员少不了要维护老项目。在维护项目的时候，我们面对各种不断的新需求，经常要去修改代码。
修改代码是个很危险的事情，因为我们修改的代码往往会和别的功能耦合住。改了一点代码，结果影响一大片功能的情况经常出现。最虐心的是，这种连带影响可能不会马上出现，不知道哪天就突然冒出来折腾一把。
如果改代码经常出问题，这谁扛得住啊！别说你自己的技术话语权了，也别说在职场脱颖而出了，工作能不能保得住都不好说。
所以，对于修改代码的事情，我们需要学会的是不要写呆代码。再说的直白点就是，你不能写完代码运行下没问题就觉得正常了，你在写代码之前需要好好思考。
这种思考，既不是什么搞设计模式松耦合，也不是搞功能切分独立成块。这种思考本质是需要你写代码前去理解业务，去真正明白业务在实际是怎么运作的。
简单说两个例子：
7.1. 修改完代码后，用户会怎么使用你现在修改的功能？
比如，你修改了注册功能，可以兼容第三方登录。那么，可能有的老用户会重新注册一个账号，以方便第三方登录。那你对这种情况，其实该做的是绑定，而不是让用户重新注册个新账号。
这种疏漏，等到上线之后才发现就晚了。这不能完全依赖产品经理，作为一个技术人员本来就应该对自己的功能做通盘的考虑，这才是真正的负责。
7.2. 你现在修改的功能，会不会由于运营需要，会换成你完全没想过的用法？
比如，你搞一个用户充值功能。本来你只是想着用户游戏内购直接充值即可。但是，在实际上线后，有时候运营为了方便 vip 客户或者为了和第三方渠道互换资源，也会使用这个充值功能。
运营大批量的连续充值，并且这些充值转换成系统中的货币，就像游戏中的元宝，就有可能超出 Java 中的整数上限，从而造成问题。如果你提前知道用户、运营人员都是怎么使用这个功能的，你就会把数据类型修改成 Long 了。
类似的例子有很多，B还要继续说下去的时候，A给他打断了，“扎心了，你说这些坑我没少掉进去。”
后记
通过和B沟通，A知道自己的问题出在哪了。他明白了，技术只是技术人员的基础，在实际工作中想脱颖而出，除了要有过硬的技术，还需要你的态度、你的各种软实力，需要你把技术转化为实际生产力的能力。
