程序员的看家本领你得练好
毕业后我就加入了一家跨境电商企业，至今我还清晰地记得，我第一次提交代码的时候，短短的 100 多行代码，被同事 review 出了 n 多问题，来来回回改了不下十几个版本才提交上去。我当时有很大的逆反心理，觉得有必要浪费这么多时间在如此细节的编码上吗？只要代码能用、能解决问题不就够了吗？
工作一段时间之后，我才发现自己当时的想法有多幼稚。写代码可以说是程序员天天要干的事情，要是代码都写不好，最基本的看家本领都练不好，成天堆砌烂代码，写代码还有啥意思呢？那还干啥程序员啊！写出“能用”代码的人比比皆是，但是，并不是每个人都能写出“好用”的代码。只会写能用的代码，我们永远成长不成大牛，成长不成最优秀的那批人。
后来我熟练掌握了各种编写高质量代码的技巧、方法和理论，我发现，实际上，写烂代码和好代码花费的时间是差不多的。当你把写高质量代码培养成一种开发习惯之后，在你在编写代码的时候，自然就有一种代码质量意识，自然而然就可以写出不错的代码。即便在我离开加入其他公司之后，项目的代码质量因为各种原因有所妥协，但我起码知道什么样的代码是高质量代码，丝毫不影响我具备写出高质量代码的能力。
我相信，很多工程师都很重视代码质量，毕竟谁也不想写被人吐槽的烂代码。但是，就我的了解来看，毫不夸张地讲，很多工程师，甚至一些 BAT 的员工，代码都写得惨不忍睹。一方面，在目前这种快糙猛的开发环境下，很多工程师并没有太多时间去思考如何写高质量代码；另一方面，在烂代码的熏陶下，在没有人指导的环境里，很多工程师也搞不大清楚高质量代码到底长什么样。这就导致很多工程师写了多年代码，代码功力一点都没长进，编写的代码仍然只是能用即可，能运行就好。平日的工作就是修修补补、抄抄改改，一直在做重复劳动，能力也一直停留在“会干活”的层面，就像高速路上的收银员，只能算是一个“熟练工”。
一个人闷头看书效果并不好, 当然，也有一些比较上进的工程师，会去找设计模式、编码规范、重构等类型的书籍去看，学习如何编写高质量的代码。实际上，我也买了很多这类的书籍来看，从这些经典的书籍中，我也学到了很多编程技巧和提高代码质量的方法。不过，这些书籍都有一个特点，那就是比较偏重理论讲解，喜欢拿猫、狗之类生活中的例子来举例。当然，这样的例子也有优点，那就是能在简短的时间和篇幅内，很好地帮你理解原理。但同时也存在一个严重的问题，那就是过于脱离真实的软件开发。而且例子本身没有难度，你一看就觉得懂了，但是看完之后，可能还是不清楚如何将理论落地到实际的项目编码中。
比如，我们都知道著名的 KISS 原则（Keep It Simple and Stupid）。这个原则理解起来很简单，一看貌似就懂了，那我问你，怎样的代码才算是足够简单呢？怎样才算不够简单需要优化呢？估计很多人都回答不上来，因为大部分书籍都没有讲清楚。 除此之外，一个人自己闷头看书，在很多时候效果并不好。一方面，每个人的理解能力是不一样的。对于同一本书，不同理解能力的人看完之后收获也是不一样的。跟着有经验的老师学比闷头自己看书要更高效、收获更多、成长更快。另一方面，编码本身就是一门 实践 课，光闷头看书本理论肯定是不够的，更重要的是在实践中学习如何应用这些理论。
一对一手把手指导才最有效
从我的经验来看，我觉得最有效、最快速提高编码能力的方法就是，找一个比你资深的工程师，一对一、手把手地指导你写代码。你提交代码，他来指出你的问题，你再优化，这样一来一往，要不了多久，你就会发现，自己的代码能力突飞猛进。但是，理想很丰满，现实很骨感。且不说能不能找到这样有资格指导你的人，即便能找到，他愿不愿意、有没有时间来手把手指导你，还是另外一回事。而我比较幸运，在毕业之后就加入了一家跨境电商企业，得到了顶尖工程师的指导，一对一地给我 review 代码，手把手地指导我如何优化代码。正因如此，在跨境电商企业的那段时间也成为了我编码能力提高最快的一段时间。
!> 独立思考能力对一个人来说是非常重要的！对于成天跟程序逻辑打交道的程序员来说，逻辑思维能力是一项非常重要的能力。我们平时要多多加强这方面的锻炼。
我正在参与2023腾讯技术创作特训营第二期有奖征文，瓜分万元奖池和键盘手表
