5大法则助你成为更出色的开发者

在现在这个技术高速发展的时代，无论你是在校学生，还是技术职场中的精英，都会面临需要持续提升。但是如果只知道提升技术能力，忽略了一些技巧和技术素养的培养和习惯。你会发现你再有能力，也变得无用武之地。因为真正的强者是不会只依赖TA的装备。更多的是技巧，经验，应变能力还有思想。

这篇文章会教5大法则助我们成为更出色的开发者，在众多开发者中脱颖而出的诀窍，也会在我们的技术职业生涯中给我们很多的帮助。

1. 先思考，后设计，再下手

多数拿到新功能需求，大致有思路就直接下手开始写代码，半天下来发现这个需求或者功能越想越复杂。前进的路开始迷茫，内心越来越烦躁（甚至开始埋冤产品，这个需求怎么搞那么复杂，太坑了！），秃头的噩梦开始了。(╯ಠ_ ಠ）╯

其实开始写代码之前，思路就没有整理清楚或者目标不明确，想着想着就偏离了初衷。越深入考虑就越复杂，考虑到解耦代码，封装服务，设计数据库，扩展性，通用型等等这些因素。想想都已经迈入了从0到放弃的节奏了。甚至遇到过“杞人忧天”的程序猿小哥哥，小姐姐。TA们问我说：“如果那一天服务器在我处理的时候停电了怎么办呀，如果服务器爆炸了呢？！”（这种绝对不夸张，还真的有哈）

其实就是因为前期没有充分的思考和设计所以才会导致后面的手慌脚乱。

深度思考

投入代码的海洋之前，我们需要先深度思考这个功能需求，整理清楚它的目的，场景，难点。

明确目的 --- 明确功能需求的目的，了解清楚它是用来做什么，为了达到什么目的。好比如现在是要开发一个文章搜索。一听到这个，你会想到什么呢？文章标题搜索？全文搜索？拆词搜索？标签化搜索？还能想到更多各式各样的搜索功能可以在这个功能需求中实现。如果不明确目的是什么，可能一开始就想复杂了。最终可能只是需要一个简单的标题搜索而已。而我们花了半天在想一大堆的可能性，系统要承载这个功能需要如何设计。
使用场景 --- 场景因素决定了这个功能的技术架构，也决定它的难度等级。那场景到底是什么？其实就是这个功能规模的影响因素，举个例子：后端来说场景可以是这个文章搜索涉及的数据量级，还有使用的用户量级和并发量级。这些都是会直接关系到后端架构的设计，和代码的编写策略。那如果是前端呢？前端要考虑的因素有：这个搜索是否有重复使用性（是否需要封装成组件），是否需要加强的交互（比如，实时联想历史搜索或者关键词），是否涉及前端需要数据与交互结合处理数据来达到一些特殊交互。这些都是直接和前端的实现方式息息相关的。
分析难点 --- 明确目的，锁定场景后，就可以开始解刨功能需求找到技术难点。注意一个误区，这个思考过程不是决定技术架构和策略，这里只是单纯通过已有的关联性系统功能，技术能力范围，数据量级，用户量级，开发时效等因素排查出这个功能需求开发的难点。如果在这里就开始考虑到设计和策略，我们就会过多的花时间在一两个难点上，甚至过度设计。我们的重点是分析出某些部分的存在难度，先解刨出来，后面开始架构设计和策略的时候会特别注意到这些难点。

?小结一下：在设计和开发一个功能需求前，有一个系统化的思考模式可以让我们快速的明白一个功能需求和整理思路！==习惯先深度思考，可以大大提高自身技术的成长。慢慢我们会发现你分析一个功能需求会看的更加透彻，开发效率也会随之上升。==

设计与策略

开发任何一个功能，特别是大型系统，我们都是需要有一个架构设计的过程。系统架构设计会包括：

后端 --- 数据库，设计模式，编写策略（例如：服务层封装）等。
前端 --- 组件封装，底层工具类，代码接受，模块化等。

设计这个功能也是有一套方式方法可以提高这方面的效果和能力。

画图 --- 使用UML/思维导图/逻辑图等工具整理自己的功能逻辑流程，这个可以强化功能的背后的思路。通过画图可以完整的，可视化的整理了一遍你大脑中的功能逻辑思路。大大强化了这个逻辑在你脑海里的影响。在画图的过程中，你还会挖掘出一些细微的问题和缺陷，通过这个过程，你的逻辑思路会得到优化和强化。
探讨 --- “集思广益”，集合大家的力量必定比你一个人想强，所以设计出你的架构和逻辑图后，可以与你的伙伴一起探讨和分享。你会发现TA们可以看到你看不多的角度和观点。从而可以更加优化你的设计和逻辑。如果你有看过我写的《如果高效学习编程》，应该知道“小黄鸭教学法”，在你讲解你的设计和逻辑思路的过程，从思想转化为语言的过程，你已经在重新整理了一片你的设计思路和逻辑。你可能会在过程中发现一些你预想不到的全新观点。
ETC原则 --- “Easy to change” 易于改编原则来源于一本书叫《程序员修炼之道》，意思就是代码可以更容易被改遍的才是最好的代码 --- “Good code is easy to change”。设计和编程中最重要的一个点就是，保持代码灵活和易于改编重用的架构技术。（这里我先透露一下，近期我也又在准备写一篇专门讲解有关此原则的文章，感兴趣的童鞋，敬请期待，可先关注本博主哦）。在设计架构的时候如果遇到两个或者多个选择，那就遵循ETC原则，选择扩展性高，易于改编更好的方案。

?小结一下：做好功能需求整理和设计模式的建立，对于功能需求的了解已经可以达到一定的深度和理解的相对透彻。这个时候就可以开始一头扎进去代码的海洋了。你会发现自己的代码会写的很顺畅，一种乘风破浪的感觉，恍惚敲代码都带风。

2. 把功能需求分解成小任务

接到一个功能需求时，众多开发者都会觉得，这个需求含有多个功能点，感觉无从入手。还会有一种莫名的复杂感。这个是因为一个功能需求里面很多时候对开发来说都是参合了多个小功能。

这个时候最好的解决办法就是尽量的分解需求为多个小任务。在《如果高效学习编程》中也有提到一个观点 --- “化繁为简，小步快跑”，把复杂的功能拆分成多个小的点，也能让自己会迅速的开展工作。同时也会更有冲劲，每个任务如果太过复杂，实现时间太过长，会慢慢觉得枯燥无味，效率就会大大下降。

如何分解需求？

我团队的很多小伙伴一开始自己拆解功能需求的时候，经常会问我，“不知道需求怎么拆解，感觉拆的太细又不实际，但是如果不拆细，又觉得没有拆的必要“。这里我来给大家一些方法来拆解功能需求：

按流程 --- 每个功能需求都有一定有一个或多个的业务流，逻辑流，数据流。可以使用这个流程分解。
- 业务流 --- 可以按照业务的流程拆可，比如注册账号，短信通知，推荐联系人。这个系统的注册到通知到推荐联系人。其实都是注册流程中的，但是我们可以按照流程拆开3个独立任务进行开发。
- 逻辑流 --- 按照不同的业务逻辑拆分你的任务，使用相同注册账号的例子，可以拆分为：检测用户名重复，添加用户的逻辑，推送短信逻辑，建立短信发送服务等等。
- 数据流 --- 也可以理解为按照查询数据的逻辑来分割你的功能需求。比如建立账户体系仓库，建立短信发送记录查询仓库等等。
按功能模块/体系 --- 如果你接到的是一个大的功能需求，这个功能可能就含有多个功能模块在其中。比如我们要做一个财务模块，我们可以首先根据功能模块或者体系拆分：对账体系，提现体系，资金流水，银行账户管理，资金管理等等。

?小结一下：当我们接到的功能需求较大的时候，我们一定要把需求“化繁为简，小步快跑”的方式进行分解。这个会大大有利于我们提高效率。毕竟在技术开发中长跑是会精疲力尽的，小步快跑才能让我们高效使用脑力。分解需求还能让我们注意到更细微的功能点，那样我们不会在复杂的功能需求中遗漏一下微小的功能点。

3. 结队开发，代码评审

在开发的过程中，开发者们往往会沈醉于自己的完美代码之中。我一开始也是如此，自己写了一个服务，无论是命名，写法，封装，逻辑设计，架构设计等等，我都觉得是完美无暇了，甚至觉得都被自己的代码美到了。但是越是这个时候，我们就越是无法发现美中不足。我们要接受一个现实就是没有最好，只有更好。

首先要明白，自身的问题大部分人大概率都会是看不清自己的。内心的想法是：自己一直都是这么做的，所以不会觉得自己是有可以改善的点，也会总以为自己是对的。所以我们需要人来提点和指出我们的不足和缺点。人生如果有一面好的镜子是可以照出自己的不足，推动自己改变，成长，提升。不然人会深醉在自己的迷惑中无法找到自身的缺点，最终就是走入无法突破的瓶颈。

在开发中也是，找一个或多个开发小伙伴审查自己的代码。因为每个开发者都拥有不同的经验。一个优秀的团队，每一个成员都有自身特别专研的领域和技术能力。或多或少都是一种互补的状态下组成的团队。所以互相审查代码可以达到互相学习，互相吸收彼此的特长和优点，然而达到最大化的互补，共同写出最好的代码。

结队开发 --- 其实结对开发，就是每次开发一个功能，你会分配一个伙伴，或者建立一个小组。待开发的过程中，可以彼此讨论架构和设计方案，实现方案等等，互补也互相学习利于成长，“两人搭配干活不累”。结队开发也能有效避免很多功能中的细微细节被忽略，还是那句话“两个脑袋必定比一个脑袋强”！
坦诚的审查 --- 在开发完一个功能后，找到你的队员互相阅读并且审查彼此的代码，从而互相提出宝贵的意见。 但是其实很多时候，因为彼此是同事也是开发小组中的战友，在“审查”对方的优秀“作品”的时候给最真实的反馈意见，往往我们和对方心里会觉得这是一种“批判”，一种“批评”。然而因为这种顾虑和心态，让我们在审查的过程中有一种莫名的压力和负担。所以给出的意见不能一针见血。“真实坦诚的话大多数人都不爱听，赞美的谎言都很中听”，也可以说是“忠言逆耳”。但是往往就是最真实的反馈意见是对彼此最有价值。也是这样才能在技术的道路上，让自己看到与明白自身的不足并且更好的去改进，从而在这条道路上彼此都能越发的走的更快更远。所以如果都想让自己和队员有快速成长，那就更需要我们对彼此的知识成果予以尊重，予以坦诚相待的态度，给予队员代码中不足之处的反馈，也谦虚诚恳的接受别人的意见。这是代码审查重中之重！

在我的团队中提出使用结队开发，代码审查制的时候，我收到很多反馈：“我们本来就是敏捷迭代开发，时间很紧凑，不够时间去审查”，“每个人的技术能力参差不齐，有些人无法读懂彼此的代码”，“功能里面掺合着业务和功能需求的业务流程，对方没有做我的功能业务，看不懂呀”等等等等。一开始大家勇于提出了很多问题。

那我们怎么搞？不用慌让我们来分析一下，提出解决方案：

时间问题 --- 敏捷迭代中，都是小步快跑，迭代周期根据项目而定，但是大致都是1-4周的范围之内。时间确实是比较紧迫的。但是互相审查代码这个好处实在是很多，所以就算要在敏捷迭代中耗费一点时间也是非常值得的。
- 方案： 每个人在每天早上就花1小时，审查前一天小伙伴们提交审核的代码，然后在Gitlab这种代码管理平台中直接在代码中填写反馈意见。这样时间是可控的，也不会让开发者浪费太多时间在审查中。
能力参差不齐 --- 这个是审查中的问题，也是为什么更需要审查的原因。不触动互相审查，在团队中给彼此意见让团队的总体能力拉平，能力中的参差不齐的问题就永无法解决。
- 方案： 首先开个群，或者开个会议，互相提出自己的优缺点，还有提出自己今年想提升的方面。找到团队成员各自的强项其实问题就好解决了。把强项和有这方面想提升的人结队开发，这样就可以发挥有强项人的能力，同时帮助了有这块短板的战友。而且，别人的强项也可能是你的短板，很少有开发者是方方面面都很强的。别人身上肯定有你可以学到的东西。所以彼此都有良好的学习文化和心态。
业务不熟悉 --- 其实代码审核不是去测试对方的功能和业务，我们是写代码的开发者，不是测试工程师。代码审查的主要目的是为了，提高研发质量，把控代码规范，提高编写能力，提高技术知识。
- 方案： 所以我们让开发者互相审查的是，代码质量，实现方式，架构设计，代码规范，编写策略等方面，这种是不需要知道业务的，如果这些有涉及业务的需要才那么实现的，可以询问对方计算难点在哪里：是查询？数据的处理？审查的重点放在技术本事不是业务代码的层面上。

?小结一下：

开发者基本上都是抱团工作的，这种环境下都是很适合互补互相学习的环境。如果想彼此有快速的成长，那就需要我们互相去给彼此提出坦诚又宝贵的意见，从中吸取彼此的优点和强项。这样每个人在这个团队中都会得到高速的提升。
如果你所在的公司领导没有推行这种模式，可以提议一下，如果因为公司的情况不合适，可以自己组队互相分享代码探讨，这样还是能达到互相学习和提升的！

4. 在安静的环境中开发

开发者在日常工作中，都是要高度集中，脑力全开的状态下工作的。所以环境造成的干扰对开发者而言是很影响效率的。一个难题，一段代码的思路，都是需要高度集中，在大脑中1000QPS的输出速度来思考问题和逻辑。所以如果在过程中被声音，交谈，或者其它环境的干扰，就会被打断思路，然后陷入一个不停的思路重组的过程，大量的时间都被消耗掉了。

当年我刚刚当上了研发主管，开发与管理并行。发现自己每天都处于高并发状态，同时几件事情在处理，沟通，回答问题，协调工作，分析需求，与产品经理互怼，功能设计，功能规划，任务分解，然后就是研发。这一堆的事情都是日常必须要做的事情。我发现在研发的过程中，总会有那么一两个人来打断我的思路，当我大脑在全速前进的时候，突然在高速公路上出现了一个“程咬金”。解决了TA的疑问之后，重新投入研发，需要花至少10分钟重新整理思路和投入状态，大脑回归原来的速度。但是万万没想到，第二个人又来了。当时的我就感叹了一句，“做一个小小开发真的是太幸福了”。

其实不只是技术管理岗会遇到这种问题，做一个研发组的开发者也会遇到，会有产品经理，测试，其他同事来请教你，给你指bug等等的事情需要和你沟通。所以这种干扰是无法在岗位或者职责上避免的。

那我们怎么才能做一个静静的小开发呀？(ლ `Д ́ )ლ，我来告诉你一些小秘诀吧：

番茄工作法 --- 给自己定好20-60分钟的高度集中的工作时间，这个时间内谁都不要过来打扰你，如果这个时间段有人来找你，你问一句“不好意思，我现在有点忙，事情紧急吗？不紧急我过xx分钟过来找你“。如果对方的事情是不紧急的，你就可以继续投入开发。到了一个25分钟阶段结束的时候，你再起来跟对方沟通。时间是很宝贵的，为了可以让大家高效沟通，也高效率开展研发工作。我们要高效运用时间。
带上耳机 --- 如果音乐会打扰你思路的话，就开一点轻音乐，或者一些大自然环境的声音。这样可以帮助你高度集中，不让自己听到一些能打扰你的声音。这种也是有效的管理好自己的耳门，让自己高度集中在研发中。我一般不会告诉别人，别人看到你带着耳机，高度集中的样子，莫名的会给到TA人心理压力和心理负担，会想这一刻过去找你，会不会打扰到你的。
免打扰模式 --- 在你高度集中的时候，开启手机的免打扰模式，关闭你电脑里面一些与你现在工作无关的应用和网页。只要不是工作的群都可以开启消息免打扰。在你番茄工作法的休息时间段，再去看一看消息，加加水，走动一下放松一下。（但是记得一定要控制自己的休息时间，休息过长会导致完全脱离工作状态，要重新进入状态耗费的时间就会变长）

?小结一下：技术研发是一个需要高度集中的脑力活，大脑的QPS需要保持在较高的速度和状态才能达到高效。所以要学会自控，更要把控好自己所在的环境与人。时间是宝贵的，只有珍惜时间才会在最短时间内达到最大量度的产出。如果你能做到，你会发现你加班会变少，工作效率会提高。

5. 不要只追求速度

开发者的研发速度快固然是好，但是只追求速度，就会降低质量，到头来我们会发现总的完成速度可能更长。为什么？速度和质量是相辅相成的。速度过快，就会降低质量，质量降低了，后面你会累积很多技术债，你的功能就会出现很多BUG，还有可能出现性能，写法，规范问题。后面还需要花大量的时间给自己擦屁股，甚至还需要你的战友为我们擦屁股。所以呢？快不一定真的快，“正所谓急功近利，最后可能适得其反”。

所以在开发的过程中，一定要先养成重视自己的代码质量的习惯，包括：

规范 --- 良好的规范会高度提升可读性，后面回来修改，修复，扩展都会更加容易
策略 --- 一个运用好的编写策略的代码会更有“易改编性” （前面说到的ETC原则）
合理解耦/封装 --- 封装和解耦代码是一个优秀的开发者必备的技能和习惯，这个可以有效分组分块分逻辑来管理自己的方法和逻辑，也是高度提升“易改编性，易于后面维护和扩展。
重视备注 --- 在一些复杂业务逻辑中，一定要重点给自己写下详细的备注，没有备注就等同于别人在看一本英文书，看的一脸懵逼。但是也要记得不要过度备注，每一行代码都写几个字备注一下。这种就会反而降低代码的可读性，分逻辑块，分模块，分组备注相关内容。主要还是清晰明了才是重点。

?小总结一下：当你养成了好的编写代码的习惯，有了高质量的代码产出，你会发现你已经成为一个高手，“快，恨，准”。要知道，如果你一开始只最求速度，你最后的技术债会严重拖累你的。最后时间都花在插屁股上了。适得其反！

总结

看完这边文章我们发现做为一个开发者，不只是需要提升自己的技术能力，技术素养也是重中之重。只有技术能力，在职场中会有很多压力，职场中是不会给我们全世界的时间来开发，也不会给我们一个舒适的环境让我们集中。所以作为一个更出色的程序员，我们身上必须拥有更多的防身技能，才能在我们面对各式各样的情况和问题出现时，我们能处于泰然，游刃有余。往往也是这些能耐才能让我们与众多的开发者有明显的区别。

希望这5大法则可以助你在技术行业里成为更出色的开发者，在众多的开发者中脱颖而出，升级加薪，走上技术和人生的巅峰。

5大法则助你 成为更出色的开发者