下载掌阅APP，畅读海量书库
立即打开
每一个程序员都希望自己加速成长，并适应这个飞速发展的行业。本节就来讲讲程序员如何加速成长。
美国著名的管理学大师史蒂芬·柯维在自己的《高效能人士的七个习惯》一书中曾经说过：从依赖期走向独立期，第一个必须建立的习惯，也是最重要的习惯，就是积极主动。
每一个程序员的职业发展路径也必然要从依赖期走向独立期，而积极主动正是衡量一个独立开发者的重要指标。
对于一个程序员来说，主动可以表现在方方面面，比如主动申请承担一份有挑战的工作，主动选择使用新的开发框架，主动重构代码中不好的地方，主动向团队内的同事分享最近学习的知识点，主动优化代码中的性能问题等。
在很多大公司中，程序员们的分工越来越细致，从一开始的全栈开发，慢慢区分出运维工程师、开发工程师和测试工程师。慢慢地，开发工程师又区分出前端开发、后端开发和移动端开发。后端开发同样可以区分出业务开发、中间件开发；同样是业务开发，又可以深入地划分成不同业务领域的开发，比如电商业务开发、支付业务开发、游戏开发，等等。随着分工的细致化，程序员更要积极主动地去了解其他人所做的事情，只守着自己的“一亩三分地”，被动地工作，是无法成为一个优秀的程序员的。
空杯心态，是一个心理学概念，来源于一个小故事：
一位佛学造诣很深的人，去拜访一位德高望重的老禅师，在被老禅师的徒弟接待时，他态度傲慢，自认佛学造诣很深，这个徒弟不配接待自己。后来老禅师十分恭敬地接待了他，并为他沏茶，在倒茶时，明明杯子已经满了，可是老禅师还在不停地倒茶。他不解地问：“大师，为什么杯子已经满了，还要往里倒茶？”大师说：“是啊，既然已满了，为什么还要倒茶呢？”意思是，既然你已经很有学问了，为什么还要到我这里求教？
空杯心态，就是时时刻刻把自己想象成“一个空着的杯子”。空杯心态并不意味着要否定自己过去，而是怀着一种放空的态度融入新的环境，对待新的工作和事物。
程序员在职业生涯中有很多场景都需要空杯心态。比如进入一个新的项目组，对新的项目组使用的技术并不了解，这时就要清空自己对原有技术栈的执念等，努力学习新的技术和知识。又比如进入一家新的公司，更要清空自己过往的工作成绩，以一个新人的心态来主动、虚心地学习。
有句话叫“选择比努力重要”，笔者有一个亲身体会。笔者在大学毕业后在电信行业做软件研发，在此工作5年之后发现成长缓慢。在转到互联网公司工作后，发现自己的五六年工作经验在互联网领域内未必能胜过一开始就在这个领域工作并积累了三年工作经验的人。
所以，笔者的一点浅见就是选择合适的平台，等我们成长慢时，就应该到下一个平台：换一个业务、岗位或者公司。主动换平台是不太容易的，因为我们可能已经习惯做某些事务，这种习惯就在舒适区内。
很多程序员，尤其是新人程序员都很怕犯错误，导致自己畏首畏尾、不敢尝试。其实大可不必，无论多么成功的人都不可能不犯错误。
笔者刚刚入职阿里巴巴时，在一次百年阿里的培训课上，听到很多淘宝初期的程序员讲他们当年的故事，其中很重要的一部分就是每个人都会讲自己曾经犯过哪些错，导致哪些线上故障。这些人现在已经是各个事业部的架构师、技术负责人，他们也是从错误中摸爬滚打过来的。他们给新人很重要的一条建议就是：别怕犯错，最重要的是从错误中学习到什么。
阿里巴巴研究员毕玄就是一个特别爱总结和从错误中学习的人。他有一篇文章中专门深挖自己过去在系统设计上犯过的 14 个错误（https：//yq.aliyun.com/articles/33077），并且他有个博客（http：//hellojava.info/），主要用于记录自己在工作中遇到的线上问题及解决方案。这种不害怕犯错，并且善于从错误中总结和学习的态度在他的职业生涯中给了他很大的帮助。
需要注意的是，别怕犯错，不等于不敬畏错误。别怕犯错，鼓励的是别害怕尝试，别害怕犯高级错误，有很多低级错误还是要尽量避免的。
前面提到过，无论多么伟大的程序员，都是不可能不犯错误的。我们能做的就是在问题发生之前尽量避免问题，在问题发生之后以最短的时间解决问题，并且在事后进行总结和沉淀，避免再次出现同样的错误。错误往往是隐藏在细节中的，在软件开发领域也符合经典的二八原则：80%的错误可能隐藏在20%的代码中，这20%的代码可能是业务逻辑中非常边缘化的细节问题。
其实细节就是我们的习以为常之处。比如在开发中，多考虑是不是会发生并发问题，在远程服务调用时多考虑发生了超时怎么办，在做数据的写操作时多考虑需不需要加锁或者做事务等。
对于大部分程序员来说，工作时长一般都比较长，大部分会超过 12 小时，有的甚至是14～16 小时。但是，如果真的可以很好地管理时间，那么可能节省很多时间。很多人整天都很忙，手头的事情总是忙不完，其实是因为没有搞清楚该如何管理自己的额外时间，或者说不知道如何分配自己的时间。本节就来讲讲如何进行时间管理。
1.主动管理时间
前面提到工作要积极主动，在时间管理上也一样，需要主动管理自己的时间。一个程序员一天可能有很多事情要做：写代码，参加各种会议及讨论，进行问题排查、项目管理、工作沟通、答疑等。如果没有很好地管理时间，那么留给写代码的时间可能就很少了，这也是很多程序员在晚上6点下班后才开始写代码的原因。
笔者在这方面有一些经验，可以供大家参考。
（1）关于会议：参加必要的会议，尽量避免参加不必要的会议，在参加会议之前先了解会议的内容，最好能在参会前大致了解各个参会者的想法，尽可能在开会前有自己的大致想法。在参会过程中，一旦发现会议变成了注定无结果的讨论，就及时提出先结束会议，等大家回去整理好思路后再进行讨论，或者线下沟通有争议的内容。在敏捷开发中提倡开站立式会议，通过这种形式的会议，可以有效缩短开会时间。
（2）关于讨论：尽量不要让不紧急的讨论打断正在做的事。很多时候，我们正在写代码，这是一个需要大块时间并且思路流畅的过程，一旦被打断，就需要从头开始思考。在日常工作中，有些讨论是不紧急的，那就先告诉要找自己讨论的人，自己有更紧急的事情在做，等自己做完之后再进行讨论。
（3）关于答疑和工作沟通：可以提前与合作方约好，提前告诉他们自己有哪些时间是需要专注地写代码的，让他们尽量不要在这个时间段打扰自己。
总之，要主动管理起自己的时间，不要让自己处于被动中。
2.设置事情的优先级
美国的管理学家科维提出一个时间管理理论，把工作按照重要和紧急程度进行划分，基本上可以分为四个“象限”：紧急且重要、重要但不紧急、紧急但不重要、不紧急也不重要，如图2.1所示。
图2.1
对于工作繁杂的程序员来说，这套理论非常实用，可根据这套理论将手头的事情分一个优先级。
◎ 对于重要且紧急的事情，把它们安排在第一时间处理。
◎ 对于重要但不紧急的事情，要避免它们变成重要且紧急的事情，在处理重要且紧急的事情之余，要把重要但不紧急的事情进行拆解，并制定计划，按部就班地完成。
◎ 对于紧急但是不重要的事情，首先想办法看看能不能把它们变成不重要也不紧急的事情，如果还是无法改变，则可以考虑和同事分担。
◎ 对于不重要也不紧急的事情，不要做！
3.说不
在工作中，我们有时会遇到一些真的需要说不的事情。比如产品经理在需求不明确的情况下找我们做需求评审；项目开发到一半，产品经理突然提出一个不合理的需求变更；本该属于其他领域的事情，其他人为了不想做改造，需要使用你的系统进行改造和兼容等。遇到这些情况，要坚持说不。
当然，说不并不是为了节省时间毫无理由地拒绝。有一句话是这样的：对于需求，先通过讨论解决，解决不了再用代码解决。这才是正确的顺序。这不是指程序员要尽最大努力减需求，而是要对不合理的需求说不。
4.想清楚再做
笔者刚刚参加工作时，每接到一个需求，都是先动起手来，然后边写代码边思考。刚开始，对于小需求都能应付得过来，但是随着新的需求越来越重要，发现这样处理需求会浪费很多时间，因为经常会发现之前的代码有问题，需要推翻重写。后来笔者对每个很小的需求都会写一份设计文档，在彻底想好如何做之后再开始写代码。这么做便可以大大地节省时间。
在阿里巴巴，技术项目都是需要做设计评审的，这一方面是让合作方了解上下游之间的依赖关系，更重要的是让开发者彻底想清楚所有流程，这样才能在开发时按照自己的设计按部就班地实现。没有想清楚就动手写代码是会带来很多麻烦的，尤其是现在很多公司都在实施服务，各个应用之间依赖关系复杂，我们经常要给外部团队提供接口，如果在定义这个接口时没有想清楚，在上线后发现定义得不完美，就需要合作方配合修改，这样的成本要高很多。
其实，不管是做业务项目还是做技术改造，甚至对于小小的代码优化，都应该先思考一遍，尽量把涉及的细节都想清楚，在确认没问题之后再动手，这样可以大大节省后面的时间。
张一鸣曾经公开谈到自己做事从不设边界。他在负责技术时，若遇到产品上有问题，也会积极地参与讨论并构想产品方案。他说：“你的责任心，以及你希望把事情做好的动力，都会驱动你做更多的事情，让你得到更大的锻炼。”
不设边界，看起来吃亏且多做了事情，但成长最快的是自己。
写业务代码有成长机会吗？关于这个问题，答案非常肯定：必须有成长机会。对于大部分公司而言，能够写底层代码或者中间件代码的人总是有限的，写业务代码会面临更高的复杂度。这里分三个层次来看其中的成长机会。
◎ 第1个层次，让代码写得不一样。可从代码规范、可读性、可扩展性等角度着手，这也是程序员的基本功。
◎ 第 2 个层次，考虑业务问题和技术问题的匹配。可从写业务代码中理解需求，并做好分析与设计。被动接收需求和实现接口，确实成长空间不大。
◎ 第3个层次，总结相关方法体系，成为业务及技术双料专家。
下面通过例子分别针对这3个层次进行讲解。
1.让代码写得不一样
这里看一个例子，常见的代码如下：
这段代码其实可以写成这样：
2.考虑业务问题和技术问题的匹配
这里举一个烟囱型架构重构的例子。某团队在早期发展阶段对新来的每个业务都会搭建一套系统，业内人士将这种见招拆招、垂直化发展的架构称为“烟囱型架构”。烟囱型架构并非一无是处，在早期业务成败未知的情况下，不过度设计架构，能直接、有效地支持业务。
不过，随着业务的发展，“烟囱”越来越多，对这些“烟囱”的后续维护成为很大的问题，“成长”的烦恼如期而至，如图2.2所示。
图2.2
其中存在的问题如下。
◎ 人手不够，业务响应慢了下来。以一个5人研发团队为例，起初这个团队从0到1进行建设，5 个人花了 1 个月做出一个简单版的红包系统；几年后该团队增加到10个人，但手头要维护10个系统，每个人就要维护一个系统。这时又来了两个新业务，该团队派出 3 个人去做这两个新业务，大约要花 4 个月才能完成。这严重不符合前端业务的响应预期。
◎ 重复建设。在同类烟囱系统中有 80%的功能是类似的，从数据库模型到主要业务逻辑都是复制粘贴加补丁，一不留神就又踩到一个坑。
◎ 维护成本高。面对日常升级包、咨询支持服务，该团队疲惫不堪。
那么，能不能将其中80%甚至90%的共性问题抽象出来呢？核心领域模型是否可以稳定呢？如图2.3所示，这是可以做到的。
图2.3
在既要支持不断出现的各种业务，又要建设新平台的纠结中权衡之后，该团队首先启动了平台化项目，建设路径是存量业务继续使用烟囱架构，但新业务随着新平台一起接入，然后逐步迁移存量业务，实现烟囱系统的下线。如图2.4所示，优惠券平台对前端业务提供统一的能力输出。
图2.4
总结下来，平台化架构有如下好处。
（1）快速支撑、响应业务。
（2）抽象共性、边界清晰。快速支撑、响应业务是以终为始的出发点。
架构不服务业务，那么再高大上都是空话。技术不是炫技，要服务于商业。对于抽象共性的问题，业务平台化要解决业务的共性问题，比如天猫、淘宝都有各类营销活动，那就抽象出一个营销平台来管理营销活动、营销工具的整个生命周期，并提供给前端业务使用。
3.总结相关方法体系，成为业务及技术双料专家
举个例子，曾有一位做事非常努力、成长也比较快的小兄弟诉苦说，他之前在做网关程序，做得很细，除了完成了业务还保障了系统没有Bug，还使文档沉淀、效率提升，外部机构联调合作方比如银行对其反馈也很好，但大家对其印象是善于合作，技术貌似一般。这位小兄弟在最近一年又做了业务平台，觉得自己在分析设计、中间件技术的应用上已经进步很大，甚至对自己的成长也很满意，但其他人还是认为其技术貌似一般。这位小兄弟百思不得其解。
笔者的反馈如下。
（1）从量变到质变是有一个过程的，自我感觉总是良好的，外部感知可能会晚。如果坚持去做，“迟到的”一定会到。
（2）大部分人都是固定型思维模式和成长型思维模式的混合模式，如果你身边的人固守对你的原有看法，不是你的错，你需要做的就是不断拓展自己的能力。
再举个例子，小郭在几年前参与了一个接入类业务，当时已经有不少机构接入了这个业务，业务规模不大不小，产品经理换了几茬，研发团队也变更了三次。当大家日复一日地做业务接入、测试、发布时，有人发现这个业务缺少一个业务视图。也就是说，这个业务有对系统资源的检测、对接口调用的监控，但是没有对业务运行情况的监控，看不到地区粒度、子业务粒度的变化情况等，甚至BD在签订新业务时都不了解为啥某地区已经没有调用量了。小郭利用业余时间开发了一个业务视图工具，整个团队马上就感受到他的过人之处了。有人讲，大公司不是应该什么都就绪吗？实际情况是，大公司也是经历了业务的高速发展的，可以这样说，大部分公司并不缺少做得更好、做得不一样的机会！
所以，“写业务代码有成长机会吗”这个句式还可以改为“维护老系统如何晋升”“做商户接入如何走向高端”和“项目这么忙如何学习”，我们需要进一步将自己的知识和经验系统化，形成相关的方法体系。
在心态上，笔者提两点建议：一是欣赏自己的成长，二是做个有心人。