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

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

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

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

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

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

其实就是由于前期没有充分的思考和设计因此才会致使后面的手慌脚乱。

深度思考

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

1. 明确目的 --- 明确功能需求的目的，了解清楚它是用来作什么，为了达到什么目的。

比如如如今是要开发一个文章搜索。一听到这个，你会想到什么呢？文章标题搜索？全文搜索？拆词搜索？标签化搜索？还能想到更多各式各样的搜索功能能够在这个功能需求中实现。若是不明确目的是什么，可能一开始就想复杂了。最终可能只是须要一个简单的标题搜索而已。而咱们花了半天在想一大堆的可能性，系统要承载这个功能须要如何设计。

2. 使用场景 --- 场景因素决定了这个功能的技术架构，也决定它的难度等级。

那场景究竟是什么？其实就是这个功能规模的影响因素，举个例子：后端来讲场景能够是这个文章搜索涉及的数据量级，还有使用的用户量级和并发量级。这些都是会直接关系到后端架构的设计，和代码的编写策略。那若是是前端呢？前端要考虑的因素有：这个搜索是否有重复使用性（是否须要封装成组件），是否须要增强的交互（好比，实时联想历史搜索或者关键词），是否涉及前端须要数据与交互结合处理数据来达到一些特殊交互。这些都是直接和前端的实现方式息息相关的。

3. 分析难点 --- 明确目的，锁定场景后，就能够开始解刨功能需求找到技术难点。

注意一个误区，这个思考过程不是决定技术架构和策略，这里只是单纯经过已有的关联性系统功能，技术能力范围，数据量级，用户量级，开发时效等因素排查出这个功能需求开发的难点。若是在这里就开始考虑到设计和策略，咱们就会过多的花时间在一两个难点上，甚至过分设计。咱们的重点是分析出某些部分的存在难度，先解刨出来，后面开始架构设计和策略的时候会特别注意到这些难点。

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

设计与策略

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

• 后端 --- 数据库，设计模式，编写策略（例如：服务层封装）等。

• 前端 --- 组件封装，底层工具类，代码接受，模块化等。

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

1. 画图 --- 使用UML/思惟导图/逻辑图等工具整理本身的功能逻辑流程， 这个能够强化功能的背后的思路。经过画图能够完整的，可视化的整理了一遍你大脑中的功能逻辑思路。大大强化了这个逻辑在你脑海里的影响。在画图的过程当中，你还会挖掘出一些细微的问题和缺陷，经过这个过程，你的逻辑思路会获得优化和强化。

2. 探讨 --- “集思广益”，集合你们的力量一定比你一我的想强，因此设计出你的架构和逻辑图后，能够与你的伙伴一块儿探讨和分享。你会发想TA们能够看到你看很少的角度和观点。从而能够更加优化你的设计和逻辑。若是你有看过我写的《若是高效学习编程》，应该知道“小黄鸭教学法”，在你讲解你的设计和逻辑思路的过程，从思想转化为语言的过程，你已经在从新整理了一片你的设计思路和逻辑。你可能会在过程当中发现一些你预想不到的全新观点。

3. ETC原则 --- “Easy to change” 易于改编原则来源于一本书叫《程序员修炼之道》，意思就是代码能够更容易被改遍的才是最好的代码 --- “Good code is easy to change”。设计和编程中最重要的一个点就是，保持代码灵活和易于改编重用的架构技术。（这里我先透露一下，近期我也又在准备写一篇专门讲解有关此原则的文章，感兴趣的童鞋，敬请期待，可先关注本博主哦）。在设计架构的时候若是遇到两个或者多个选择，那就遵循ETC原则，选择扩展性高，易于改编更好的方案。

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

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

接到一个功能需求时，众多开发者都会以为，这个需求含有多个功能点，感受无从入手。还会有一种莫名的复杂感。这个是由于一个功能需求里面不少时候对开发来讲都是参合了多个小功能。

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

如何分解需求？

我团队的不少小伙伴一开始本身拆解功能需求的时候，常常会问我，“不知道需求怎么拆解，感受拆的太细又不实际，可是若是不拆细，又以为没有拆的必要“。这里我来给你们一些方法来拆解功能需求：

• 按流程 --- 每一个功能需求都有必定有一个或多个的业务流，逻辑流，数据流。可使用这个流程分解。

• 业务流 --- 能够按照业务的流程拆可，好比注册帐号，短信通知，推荐联系人。这个系统的注册到通知到推荐联系人。其实都是注册流程中的，可是咱们能够按照流程拆开3个独立任务进行开发。

• 逻辑流 --- 按照不一样的业务逻辑拆分你的任务，使用相同注册帐号的例子，能够拆分为：检测用户名重复，添加用户的逻辑，推送短信逻辑，创建短信发送服务等等。

• 数据流 --- 也能够理解为按照查询数据的逻辑来分割你的功能需求。好比创建帐户体系仓库，创建短信发送记录查询仓库等等。

• 按功能模块/体系 --- 若是你接到的是一个大的功能需求，这个功能可能就含有多个功能模块在其中。好比咱们要作一个财务模块，咱们能够首先根据功能模块或者体系拆分：对帐体系，提现体系，资金流水，银行帐户管理，资金管理等等。

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

3. 结队开发，代码评审

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

首先要明白，自身的问题大部分人大几率都会是看不清本身的。心里的想法是：本身一直都是这么作的，因此不会以为本身是有能够改善的点，也会总觉得本身是对的。因此咱们须要人来提点和指出咱们的不足和缺点。人生若是有一面好的镜子是能够照出本身的不足，推进本身改变，成长，提高。否则人会深醉在本身的迷惑中没法找到自身的缺点，最终就是走入没法突破的瓶颈。

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

1. 结队开发 --- 其实结对开发，就是每次开发一个功能，你会分配一个伙伴，或者创建一个小组。待开发的过程当中，能够彼此讨论架构和设计方案，实现方案等等，互补也互相学习利于成长，“两人搭配干活不累”。结队开发也能有效避免不少功能中的细微细节被忽略，仍是那句话“两个脑壳一定比一个脑壳强”！

2. 坦诚的审查 --- 在开发完一个功能后，找到你的队员互相阅读而且审查彼此的代码，从而互相提出宝贵的意见。 可是其实不少时候，由于彼此是同事也是开发小组中的战友，在“审查”对方的优秀“做品”的时候给最真实的反馈意见，每每咱们和对方内心会以为这是一种“批判”，一种“批评”。然而由于这种顾虑和心态，让咱们在审查的过程当中有一种莫名的压力和负担。因此给出的意见不能一针见血。“真实坦诚的话大多数人都不爱听，赞美的谎话都很中听”，也能够说是“忠言逆耳”。可是每每就是最真实的反馈意见是对彼此最有价值。也是这样才能在技术的道路上，让本身看到与明白自身的不足而且更好的去改进，从而在这条道路上彼此都能愈加的走的更快更远。因此若是都想让本身和队员有快速成长，那就更须要咱们对彼此的知识成果予以尊重，予以坦诚相待的态度，给予队员代码中不足之处的反馈，也谦虚诚恳的接受别人的意见。这是代码审查重中之重！

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

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

• 时间问题 --- 敏捷迭代中，都是小步快跑，迭代周期根据项目而定，可是大体都是1-4周的范围以内。时间确实是比较紧迫的。可是互相审查代码这个好处实在是不少，因此就算要在敏捷迭代中耗费一点时间也是很是值得的。

• 方案： 每一个人在天天早上就花1小时，审查前一天小伙伴们提交审核的代码，而后在Gitlab这种代码管理平台中直接在代码中填写反馈意见。这样时间是可控的，也不会让开发者浪费太多时间在审查中。

• 能力参差不弃 --- 这个是审查中的问题，也是为何更须要审查的缘由。不触动互相审查，在团队中给彼此意见让团队的整体能力拉平，能力中的参差不弃的问题就永没法解决。

• 方案： 首先开个群，或者开个会议，互相提出本身的优缺点，还有提出本身今年想提高的方面。找到团队成员各自的强项其实问题就好解决了。把强项和有这方面想提高的人结队开发，这样就能够发挥有强项人的能力，同时帮助了有这块短板的战友。并且，别人的强项也多是你的短板，不多有开发者是方方面面都很强的。别人身上确定有你能够学到的东西。因此彼此都有良好的学习文化和心态。

• 业务不熟悉 --- 其实代码审核不是去测试对方的功能和业务，咱们是写代码的开发者，不是测试工程师。代码审查的主要目的是为了，提升研发质量，把控代码规范，提升编写能力，提升技术知识。

• 方案： 因此咱们让开发者互相审查的是，代码质量，实现方式，架构设计，代码规范，编写策略等方面，这种是不须要知道业务的，若是这些有涉及业务的须要才那么实现的，能够询问对方计算难点在哪里：是查询？数据的处理？审查的重点放在技术本事不是业务代码的层面上。

🌟小结一下：

• 开发者基本上都是抱团工做的，这种环境下都是很适合互补互相学习的环境。若是想彼此有快速的成长，那就须要咱们互相去给彼此提出坦诚又宝贵的意见，从中吸收彼此的优势和强项。这样每一个人在这个团队中都会获得高速的提高。
• 若是你所在的公司领导没有推行这种模式，能够提议一下，若是由于公司的状况不合适，能够本身组队互相分享代码探讨，这样仍是能达到互相学习和提高的！

4. 在安静的环境中开发

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

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

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

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

1. 番茄工做法 --- 给本身定好20-60分钟的高度集中的工做时间，这个时间内谁都不要过来打扰你，若是这个时间段有人来找你，你问一句“很差意思，我如今有点忙，事情紧急吗？不紧急我过xx分钟过来找你“。若是对方的事情是不紧急的，你就能够继续投入开发。到了一个25分钟阶段结束的时候，你再起来跟对方沟通。时间是很宝贵的，为了可让你们高效沟通，也高效率开展研发工做。咱们要高效运用时间。

2. 带上耳机 --- 若是音乐会打扰你思路的话，就开一点轻音乐，或者一些大天然环境的声音。这样能够帮助你高度集中，不让本身听到一些能打扰你的声音。这种也是有效的管理好本身的耳门，让本身高度集中在研发中。我通常不会告诉别人，别人看到你带着耳机，高度集中的样子，莫名的会给到TA人心理压力和心理负担，会想这一刻过去找你，会不会打扰到你的。

3. 免打扰模式 --- 在你高度集中的时候，开启手机的免打扰模式，关闭你电脑里面一些与你如今工做无关的应用和网页。只要不是工做的群均可以开启消息免打扰。在你番茄工做法的休息时间段，再去看一看消息，加加水，走动一下放松一下。（可是记得必定要控制本身的休息时间，休息过长会致使彻底脱离工做状态，要从新进入状态耗费的时间就会变长）

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

5. 不要只追求速度

开发者的研发速度快当然是好，可是只最求速度，就会下降质量，到头来咱们会发现总的完成速度可能更长。为何？ 速度和质量是相辅相成的。速度过快，就会下降质量，质量下降了，后面你会累积不少技术债，你的功能就会出现不少BUG，还有可能出现性能，写法，规范问题。后面还须要花大量的时间给本身擦屁股，甚至还须要你的战友为咱们擦屁股。因此呢？快不必定真的快，“正所谓急功近利，最后可能拔苗助长”。

因此在开发的过程当中，必定要先养成重视本身的代码质量的习惯，包括：

1. 规范 --- 良好的规范会高度提高可读性，后面回来修改，修复，扩展都会更加容易

2. 策略 --- 一个运用好的编写策略的代码会更有“易改编性” （前面说到的ETC原则）

3. 合理解耦/封装 --- 封装和解耦代码是一个优秀的开发者必备的技能和习惯，这个能够有效分组分块分逻辑来管理本身的方法和逻辑，也是高度提高“易改编性，易于后面维护和扩展。

4. 重视备注 --- 在一些复杂业务逻辑中，必定要重点给本身写下详细的备注，没有备注就等同于别人在看一本英文书，看的一脸懵逼。可是也要记得不要过分备注，每一行代码都写几个字备注一下。这种就会反而下降代码的可读性，分逻辑块，分模块，分组备注相关内容。主要仍是清晰明了才是重点。

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

---

总结

看完这边文章咱们发现作为一个开发者，不仅是须要提高本身的技术能力，技术素养也是重中之重。只有技术能力，在职场中会有不少压力，职场中是不会给咱们全世界的时间来开发，也不会给咱们一个温馨的环境让咱们集中。因此做为一个更出色的程序员，咱们身上必须拥有更多的防身技能，才能在咱们面对各式各样的状况和问题出现时，咱们能处于泰然，游刃有余。每每也是这些能耐才能让咱们与众多的开发者有明显的区别。

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