想成为高级别开发的七条建议之思考

基于张彦飞写的给想成长为高级别开发同学的七条建议中的七条建议进行思考。七条建议如下所示：

• 1.刻意加强需求评审能力。
• 2.主动思考效率。
• 3.加强内功能力。
• 4.思考性能。
• 5.重视线上。
• 6.关注全局。
• 7.归纳总结能力。

一、刻意加强需求评审能力

先从需求评审开始说。在互联网公司，需求评审是开发工作的主要入口。
对于普通程序员来说，一般就是根据产品经理提的需求细节，开始设想这个功能要怎么实现，开发成本大概需要多长时间。把自己当成了需求到代码之间的翻译官。很少去思考需求的合理性，对于自己做的事情有多大价值，不管也不问。
而对于高级别的程序员来说，并不会一开始就陷入细节，而是会更多地会从产品本身出发，询问产品经理为啥要做这个细节，目的是啥。换个说法，就是会先考虑这个需求是不是合理。
如果需求高级不合理就进行 PK ，要么对需求进行调整，要么就砍掉。不过要注意的是 PK 和调整需求不仅仅砍需求，还有另外一个方向，那就是对需求进行加强。
产品同学由于缺乏技术背景，很可能想的并不够充分，这个时候如果你有更好的想法，也完全可以提出来，加到需求里，让这个需求变得更有价值。
总之，高级程序员并不会一五一十地按产品经理的需求文档来进行后面的开发，而是一切从有利于业务的角度出发思考，对产品经理的需求进行删、改、增。
这样的工作表面看似和开发无关，但是只有这样才能保证后续所有开发同学都是有价值的，而不是做一堆无用功。无用功做的多了会极大的挫伤开发的成就感。
所以，普通程序员要想成长为更高级别的开发，一定要加强需求评审能力的培养。

我的思考：
关于这一点我体会很深，过去一年时间，团队规模从屈指可数到几十个人，我们的项目中标且合同签订。但过去一年多的时间确实浪费了很多时间，做了很多无用功。无用功的主要体现是，很多不合理的需求我们不得不做，做了又改，改了又放弃，最后推到重来，然后又推到重来，然后又改。那个时候我在思考，这样改来改去的意义是什么。很想反驳不做，但基于当前的形势而言，不得不做，因为那个时候对于我们团队而言，最重要的是让客户跟我们签合同，只要签订了合同，接下来的版本迭代就会有回款收益。之后版本迭代，面对一些需求我会向相关人员提出需求的疑问，这个疑问既包含需求疑惑点，也包含是否合理。由此而来，我的工作效率提高了很多。

二、主动思考效率

普通的程序员，按部就班的去写代码，有活儿来我就干，没活儿的时候我就呆着。很少去深度思考现有的这些代码为什么要这么写，这么写的好处是啥，有哪些地方存在瓶颈，我是否可以把它优化一些。
而高级一点程序员，并不会局限于把手头的活儿开发就算完事。他们会主动去琢磨，现在这种开发模式是不是不够的好。那么我是否能做一个什么东西能把这个效率给提升起来。
举一个小例子，我 6 年前接手一个项目的时候，我发现运营一个月会找我四次，就是找我给她发送一个推送。她说以前的开发都是这么帮他弄的。虽然这个需求处理起来很简单，改两行发布一下就完事。但是烦啊，你想象一下你正专心写代码呢，她又双叒来找你了，思路全被她中断了。而且频繁地操作线上本来就会引入不确定的风险，万一那天手一抽抽搞错了，线上就完蛋了。
我的做法就是，我专门抽了一周的时间，给她做了一套运营后台。这样以后所有的运营推送她就直接在后台上操作就完事了。我倒出精力去做其它更有价值的事情去了。
所以，第二个建议就是要主动思考一下现有工作中哪些地方效率有改进的空间，想到了就主动去改进它！

我的思考：
去年的时候系统重构就是因为太不合理(写一个功能，要分别在三个微服务上新增或修改，效率很低)，但因为一些客观因素不得不那样做，当客观因素变了，当前环境需要变更时，这无疑是一个很好的兆头，于是我不断做试验进行修改，以保障系统重构后，仍然持续稳定地运行起来。在领导没有让我重构之前，我自己已经做了多次不同组合的模拟重构。同样我每次给团队新成员做培训的时候，我都会着重强调三点：

• 1.能自动化就不要手动CV。
• 2.技术债务及时清理，清理不了，一定要记录TODO。
• 3.不要满足于做完就好，一定要充分考虑业务流程的正确性以及程序的性能。

同样有些时候，在做完和做好之间我们需要舍取，客户第一时间要看，时间非常紧促，为了保障成功上线，我们只能先完成以后再优化，而不是一下做的非常好再给客户。

三、加强内功能力

哪些算是内功呢，我想内功修炼的读者们肯定也都很熟悉的了，指的就是大家学校里都学过的操作系统、网络等这些基础。
普通的程序员会觉得，这些基础知识我都会好么，我大学可是足足学了四年的。工作了以后并不会刻意来回头再来加强自己在这些基础上的深层次的提升。
高级的程序员，非常清楚自己当年学的那点知识太皮毛了。工作之余也会深入地去研究 Linux、研究网络等方向的底层实现。
事实上，互联网业界的技术大牛们很大程度是因为对这些基础的理解相当是深厚，具备了深厚的内功以后才促使他们成长为了技术大牛。
我很难相信一个不理解底层，只会 CURD，只会用别人框架的开发将来能在技术方向成长为大牛。

我的思考：
当年在创业公司的时候，我接触了很多技术框架以及不同编程语言的项目，然后我自认为自己很牛逼很厉害，随后当我来到教育Saas公司的时候，被多次啪啪打脸(最严重的是我把生产环境弄垮了，幸而当时我的Leader力挽狂澜解决了，不然铁定被开，也是从那以后我开始着重内功，也就是基础)，之所以被打脸就是因为我的学习框架以及解决问题框架出了问题，而这些框架是需要掌握内功知识的。

四、思考性能

普通程序员往往就是把需求开发完了就不管了，只要需求实现了，测试通过了就可以交付了。将来流量会有多大，没想过。自己的服务 QPS 能支撑多少，不清楚。
而高级的程序员往往会关注自己写出来的代码的性能。
在需求评审的时候，他们一般就会估算大概的请求流量有多大。进而设计阶段就会根据这个量设计符合性能要求的方案。
在上线之前也会进行性能压测，检验一下在性能上是否符合预期。如果性能存在问题，瓶颈在哪儿，怎么样能进行优化一下。
所以，第四个建议就是一定要多多主动你所负责业务的性能，并多多进行优化和改进。我想这个建议的重要程度非常之高。但这是需要你具备深厚的内功才可以办的到的，否则如果你连网络是怎么工作的都不清楚，谈何优化！

我的思考：
记得我在创业公司的时候，我从来不会思考性能，只管完成就好，至于性能与我无关。最开始物联网产品基本没人用，问题也就没表现出来。后来编程教育产品在长沙上线给学员使用，结果问题出了很多，其中有几个功能就是因为我写的代码性能不够好导致的，那个时候为了掩饰自己的不足和失败，假装说没问题，重新启动就好，实际上我改了很多代码。所以很多时候，写一个功能并不是完成就好，还需要思考它的性能，比方说是十几个人用起来没问题，但一百个人使用起来就会出现问题，从我个人经验来看，很多时候随着人数增多出问题也多，大多是由于代码写的太差导致性能差从而出现一堆问题。

五、重视线上

普通程序员往往对线上的事情很少去关注，手里记录的服务器就是自己的开发机和发布机，线上机器有几台，流量多大，最近有没有波动这些可能都不清楚。
而高级的程序员深深的明白，有条件的话，会尽量多多观察自己的线上服务，观察一下代码跑的咋样，有没有啥 error log。请求峰值的时候 CPU、内存的消耗咋样。网络端口消耗的情况咋样，是否需要调节一些参数配置。
当性能不尽如人意的时候，可能会回头再来思考出性能的改进方案，重新开发和上线。
你会发现在线上出问题的时候，能紧急扑上前线救火的都是高级一点的程序员。
所以，飞哥给的第五个建议就是要多多观察线上运行情况。只有多多关注线上，当线上出故障的时候，你才能承担的起快速排出线上问题的重任。

我的思考：
要想让自己更值钱，线上的重要性不言而喻，重视每一次线上问题，每一次线上问题都是让自己增值的机会。之所以在M2公司做架构做的比较成功，原因在于我在教育Saas公司经受过非常系统且全面的锻炼，而衡量锻炼的关键指标就是解决线上问题的能力。

六、关注全局

普通程序员是你分配给我哪个模块，我就干哪个模块，给自己的工作设定了非常小的一个边界，自己所有的眼光都聚集在这个小框框内。
高级程序员是团队内所有项目模块，哪怕不是他负责的，他也会去熟悉，去了解。具备这种思维的同学无论在技术上，无论是在业务上，成长的也都是最快的。在职级上得到晋升，或者是职位上得到提拔的往往都是这类同学。
甚至有更高级别的同学，还不止于把目光放在团队内，甚至还会关注公司内其它团队，甚至是业界的业务和技术栈。写到这里我想起了张一鸣说过的，不给自己的工作设边界。
所以，建议要有大局观，不仅仅是你负责的模块，整个项目其实你都应该去关注。而不是连自己组内同学做的是啥都不知道。

我的思考：
曾经作为初级开发工程师或者中级开发工程师，我可以注重自己的一亩三分地。但当我成为高级开发工程师的时候就不能了，我需要关注全局，全局包含整个团队以及我们团队所做的事情。技术对于我来说仍然很重要，但团队的合作与管理更重要。而如何做好团队的管理以及不同团队的合作，你就需要了解不同的团队以及不同的岗位所做的事情，了解的目的在于为了让沟通更顺畅，沟通顺畅利于合作。

七、归纳总结能力

普通程序员往往是工作的事情做完就拉到，很少回头去对自己的技术，对业务进行归纳和总结。
而高级的程序员往往都会在一件比较大的事情做完之后总结一下，做个ppt，写个博客啥的记录下来。这样既对自己的工作是一个归纳，也可以分享给其它同学，促进团队的共同成长。

我的思考：
我在前面的文章中提到复盘的概念，复盘的三部曲包括回顾、反思、提炼等，而提炼相当于归纳总结。今年于我最重要的事情之一就是要注重培养自己复盘的能力。