如何构建好纯技术开发人最重要的阶段

前言

我工作也有一段时间了，收获也有感悟也有变化也有，从刚开始的懵懂小白希望能做到独立完成业务需求到曾经想要又快又好又爽的写代码以及现在绞尽脑汁想要无限接近零Bug&榨干物理机的高质量高性能代码。我想要分享一些，在我的理解中作为一个纯技术开发（抛开管理、架构）进阶变化（个人理解，欢迎大家求同存异探讨），并且分享一下如何构建好我认为最重要的阶段。

我心中的纯技术开发阶段

再次防杠提醒，只是我的主观看法

如何完成开发

这个是最初级阶段，完成开发是指你对开发流程还是很不熟悉，你没有办法独立开发，你需要在其他人指导下才能勉强完成开发。

可能你刚入门、可能你甚至像我们公司一样校招进来没有权限看业务代码，需要在楼上专门的区域进行考核培训、可能你还在 mentor指导下进行你刚刚接触公司代码；这时候你很迷茫，你可能不知道公司的开发流程，你可能对开发有很多未知的好奇，可能你迫切想要成为能够完成公司业务需求的人。

在这一阶段我没有任何的建议，谦虚 用心 花时间 好好学习 大部分都可以完成部门的需求，如果完不成说明你可能不适合做开发……

如何高效开发

其实我重点想说的是这一部分，最重要的阶段我觉得也是这一个阶段， 高效开发是指写代码写的很快，只需要花时间就可以去解决问题，而不是需要停下时间去纠结一些问题，写起来很爽不痛苦。

当然并不是说其他阶段不重要，只不过我觉得我不适合分享其他部分，高效开发我自己确实有认真想过，所以有一些自己觉得很有用的东西，所以花时间总结下来了。

一方面希望总结持久化下来我自己可以坚持做到，贯彻到待过的每一个部门、应对的每一个需求、写下的每一行代码里面；另一个方面就是看看能不能给大家一些思路，觉得有用可以也自己思考思考，不一定要按部就班我的。

有自己的变量命名习惯

这个其实很多开发建议中都有给到，你频繁看到的东西你一定要注意。刚开始初级开发的时候其实没怎么在意，每次写名字随便就想一个。

这个随便想一个有很多缺点，第一很花时间，因为虽然随便想，但是你肯定还是想要和你自己的业务逻辑贴切一些，即便你就是不负责任想要瞎取，你还是要考虑一下同事白眼，所以你会花时间纠结（其实还是不想让同事看不起😂）。第二你每次都随便想，导致你命名风格乱七八糟，你大概率会记不起你的写过的方法名，要吭哧吭哧找半天。

我原来写过一篇，我自己的命名习惯的文章，希望能够大家一些参考。点击

有自己的代码习惯

代码习惯是真的很重要，它决定了你了你写起来爽不爽以及你同事跟你代码写的爽不爽

但是这个很宽泛，我这里说一些我比较在意的习惯

• 代码注释，尽量做到代码给机器看，注释给人看，很多时候并不是说大家看不懂代码，我在主业务代码里面看你调用了一个方法命名奇奇怪怪，进入以后还老长的方法，我就是想看一下主业务代码的逻辑而已，可能你写一行注释说这一行是处理xxx数据可能会节省我不少时间。最重要的是….这个会节省自己的时间，因为自己会忘记…停！你别反驳，我前几年也会反驳，现在不敢了，脸真疼。
• 避免重复造轮子，这个也意味着你需要多接触热门轮子，比如经常翻翻Hutool里面的源码，我经常看到有同事自己实现集合的交并集，代码写的老长还不健壮经常抛异常出现各种问题。但其实Hutool工具里面有非常好的求交并差集的方法实现。当然还有一个很重要的就是和同事沟通，如果别人在工具类写了一个和你一样需求的方法，你和自己调用就好啦，摸鱼++
• 善于总结常用代码，这里的常用代码指的是…一些判空之类的方法，我经常看到有Objects.isNull和==null混着用，当然我这里不是批评。我这是觉得这样写有两个原因，1没有养成自己的代码习惯，2代码是cv过来的….，再次强调我这里不是说这样写不行，我是想说明这背后的逻辑，我是想让大家养成自己的代码习惯，你在代码里面怎么写都行。有一些基本的东西其实大家可以总结出来，因为非常写着写着风格就统一就有自己的代码习惯了，然后写的也越来越快了，我这里随便列出几个
  • 常见对象和集合的判空
  • 集合常用需求，例如快速生成list几种方式
  • jdk8的时间和date互转和格式化
  • jdk8的Stream常用算子
  • jdk8的常用函数式接口总结
• 善用工具，人生苦短，我…善用工具。idea的功能，我们实在是探索的太少了，仔细去研究里面有非常多的可以增强我们效率的功能。当然不仅仅是idea工具，还有抓包工具、接口管理工具、笔记管理工具、编码转换工具、技术文档查询工具、中间件可视化客户端等等，身处技术行业我每次都会感叹，我实在是太幸福了。

有良好的理清业务习惯

业务和技术哪个更重要呢，当然每个人心里都有自己的答案。不管你的答案是什么，每个人肯定都会接触到需求。

我们的代码是根据需求来实现的，可能一个大需求里面有纷繁复杂的业务。怎么又快又好的理解这些业务，并且把它转化成实现思路也是这一阶段需要提升的能力。有可能代码写着写着突然发现自己理解错误，又推翻重来，有可能写着写着发现不行业务太复杂，自己没清楚技术方案没有选对。这耽误的都是时间成本，付出双倍的精力。

这一部分我只能给我是怎么做的，这个其实也是需要培养，不是说了就能懂，感性思维要飞跃到理性思维还是需要大量的实践。确定要自己要做的步骤，然后按部就班先来一遍，等形成了习惯再仔细打磨，下面我分享一下我的方法。

• 如果是小需求，在宣讲弄清楚以后。我会直接先写wiki，每个公司可能都不太一样，我们的内部wiki充当着接口文档的作用。先把大概业务逻辑wiki复盘一遍，确认自己理解的是没问题，和上下游对接好接口参数，直接把文档给出了。然后开始按照wiki的业务，写代码的时候先写每一步注释的伪码，在写注释的时候如果有方案不适合可以及时调整。把注释写完然后开始在每一个注释下面开发，这样又快效果又好。

• 如果是复杂一点需求，可以先把流程图画出来，请大家不要就看看一定要自己试试，实在是太太太好用啦，对业务的理解upup，如果不花开发过程中，无论是交流还是rollback的坑，都是血泪史

  

大概这样简单画一下(已高斯模糊处理)

有良好的交付习惯

后两个都不属于技术但是又和技术密切相关，这种就容易道理听得比较多，但是依然做不好，其实我原来也这样，但是要走出自己的舒适圈，还是要发挥自身的能动性去改变一下。交付是一个很广泛的概念，在我看来养成良好的交付习惯后自己写代码舒服一些，同事也开心一些，大家会更加享受工作一些。下面我分享一下我自己平时的一些习惯。

• 注重上下游沟通， 可能我这边平时写接口比较多，所以上下游都是数据提供的上游或者需要我提供数据的下游，我很少直接甩文档或者钉钉发个消息，一般我能跑过去我都会到对方工位上碰一下，一方面即时性强一些，另外一方面让对方也觉得比较尊重一些。关于一些争端，很多东西不是我这边改，就是对方那边改，所以就是看哪边方便一些，把一些事情说清楚，大家也都是工作嘛，也希望把工作做好，肯定可以达成一致的。另外也要注意回溯，不管是对方提供接口给你，你调测没问题或者有问题最好还是和对方说一声，让别人心里有个底。你提供接口给别人，如果别人长时间没反应你也最好询问一下。
• 指定好自己的DDL， 自己应该对项目或者需求有自己的时间把控，即便是质量管理部门没有来问，你也应该在自己心里有一把尺子，给定的时间应该力求交付。如果项目组已经给定了deadLine，你发现遇到问题应该及时反馈，不要因为自己耽误整个版本的工期。
• 做好自己的checklist，这个也是非常重要的，自己的一些ddl语句、添加的mq的topic、nosql的一些key之类的自己有记录，不管部门是否有专门的记录，自己动过的东西都应该自己有一个记录。在关键时候这个可以非常大的节省你的时间。

如何高质量开发

这应该是纯技术人一直所追寻的，高质量开发是指代码质量极其高同时与业务耦合低，逻辑严密的同时重复利用物理机效率。

实话就是这也是我努力的方向，我觉得我现在还不够资格告诉大家怎么达到，没准这永远没有上限。比如我会经常看优秀同事的代码，看喜欢框架源码，在GitHub上看优秀轮子代码，研究408的四本书，自己尝试多种方式重写项目代码比较差异，每次看到自己有类似的需求实现，但是看到别人做法不一样我就很好奇会去研究比较一下，询问一下作者他的想法，有时候真的是很有收获呢，比较不好的做法就是带着偏见看别人的代码，觉得自己代码的天下第一。emmm….其实我也在不断地试错努力希望可以代码质量越来越高。我也很希望大家可以分享大家是怎么做的，就算大家各抒己见吧。

后言

自己也在成长，可能因为知识范围，心智水平，眼界水平现在的认知可能是有失偏颇的，但是人的成长不就是不断地走出偏见，不断地进行修正嘛。我希望再过几年我再来总写，会有不一样的收获和不一定的理解。我也期待大家分享出自己的看法。