作者：梁唐来源：早起Python大家好，今天跟大家随便聊聊。本来想写的题目是如何成为一名优秀的程序员，但是想了想，自己可能也算不上。所以我谦虚了一点，改了标题。这次就不写方法论或者感受了，可能不是每个人都有，也可能不被喜欢。这次写点实用的，只要照着做，基本不会算菜鸟，不会在职场踩雷。相信小习惯的力量。python菜鸟和大牛的区别不仅仅是写代码和调试的核心能力，还有一个很大的区别就是习惯。大牛通过努力养成了一系列的好习惯，而菜鸟还没有养成好习惯，有很多坏习惯。所以，作为菜鸟，一定要有规范感和习惯感，养成好习惯，改掉坏习惯，让自己越来越习惯于编写高质量的代码。每个人都有自己的习惯。我只提几个，给你一个好的开始。1.一个函数只做一件事如果有一天你接手另一个同事的代码，发现他有一个函数，里面有3000行代码，你会作何感想？这是我的亲身经历。我看到代码的第一反应是把这个人弄出来揍一顿。代码不同于其他文本信息，越拥挤越难阅读。高质量的代码与高质量的文章非常相似，结构清晰，层次分明，表达准确。一个函数几千行代码，分明就是老太太的裹脚布——又臭又长。对于一个函数应该写多少代码，每个人都有不同的理解。其实，我们也不必勉强，只要遵循一个简单的原则——一个函数只做一件事。举个简单的例子，假设我们要从上游读取一批数据，然后应用某个函数后绘制结果。我们简单分析一下。表面上看是画图的事情，其实这个事情包括几个步骤，比如从上游获取数据，获取函数的结果，最后画图。那么我们可以拆分成三个函数，一个函数获取数据，一个函数获取结果，一个函数画图。这样别人和未来的自己看这段代码都会很清楚，每个函数是干什么的一目了然。如果哪天老板无意中翻了一下大家的代码，别人的代码一个函数就几千行，你的代码层次分明，每个函数是干什么的一目了然，你猜老板会怎么想？2、对于长变量名的初学者来说，一个很大的问题就是总是喜欢用短的变量名，比如a、b、c、d。或者什么bd，aa什么的，看着很丑，可读性差。之前有几个同学让我帮他们看代码，给的都是这种代码。好像眼睛被针扎了一样……说实话，我在打acm的时候也喜欢短的变量名。虽然没有那么夸张，但一般一个变量名都不会很长。当然，这是当时比赛的需要。每个人都在与时间赛跑。别人的变量叫btn，而你的名字叫binary_tree_node。显然，您必须失去键入代码的速度。但问题是我毕业后一直保持着这种作风，不出意外就被老板和同事打了一顿。每个人都说他们不喜欢我的编码风格。我当时还是很坚持，认为这是我编码能力的体现。后来看了一些大牛的代码，尝试换一种风格后，发现真香。虽然写起来有点麻烦（其实还好，各种代码补全函数都有），但是读起来真的舒服，思路清晰多了。所以如果你现在的代码不是这种风格，请尝试改变它，这对自己和他人都有好处。还有一点就是我们在起名的时候可以用不规范的英文，即使不准确也可以，但是一定不能用拼音。读拼音比半懂半懂的英文还难，而且用拼音做变量或者函数名是一件非常非常低级的事情，绝对会让对方怀疑你的能力。市面上也有一些帮助命名的插件，有这方面需求的同学一定要看看。3.遵守代码规范。代码规范这个词在新手的意识中可能不存在，但这确实是从新手到高级的必经之路。不同语言的规范不一样。比如java和go中流行驼峰大小写，所有变量都是驼峰大小写。在Python中，只有类名可能是驼峰式，普通变量和包名往往全部小写，并用下划线分隔。当然，代码规范不仅仅是命名规范，还有很多很多的规范。比如中间件使用规范、多线程开发规范、数据库使用规范等等。我们为什么要遵守这些规范？因为我们的开发工作并不是实现了功能就完成了，需要在以后进行扩展和维护。遵守规范不仅可以避免日后给自己和别人埋下地雷，更重要的是可以让你的代码质量更高更专业。并且在一些规范中往往隐藏着真相。为什么套接字、线程和数据库连接需要维护一个“池”？这里必有路，不然何不走个简单的路来？当我们遵守这些规范的时候，我们也能更好地理解每个场景的原理和细节，这也是我们技术实力的一部分。当然，一开始我们可能做不好，但是代码规范不是很难。由于我们意识到遵守规范不需要花费很多时间，因此收益非常丰富。在之前的公司，听说因为代码风格不好，老板给的绩效很差。我觉得挺委屈的。可能是一时的疏忽给老板留下了不好的印象。如果我在写代码的时候能注意一点，完全可以避免，代码有点太大了。会用不等于懂。如果你是应届生，那么等你毕业步入职场，难免会面临一个适应的问题。别的不说，只说技术方面的。我们势必需要快速学习一些以前没有见过或了解的技术，以应对工作中的任务和挑战。这是很正常的。我想大多数程序员在刚毕业的时候都有过这样的经历，我也不例外。毕业后的头几个月是最艰难的。我们需要承受很大的压力，也没有完全适应转型后的生活。但当几个月过去，我们已经适应了生活，学会了一些基本技能来应付或胜任目前的工作时，一个潜在的陷阱就来了。有些人会不自觉地停止学习，因为他已经足够应付工作了。在工作中，他会有一种错觉，认为我目前在这方面的技能已经足够了。甚至有人认为，其他资历更高的同事也不过如此，似乎并不比自己知道多少。我一开始也是这样的，因为我发现我在工作中使用的东西非常流畅，好用。一时之间有些浮肿，心想自己已经是经验丰富的程序员了。直到后来面试的时候，被问到一个常用工具的技术细节，我才一句话也说不出来。这时我才明白，我所知道的只是表面的，甚至还不是表面的。当然，我们工作中对很多技术的要求只是知道如何使用。您知道如何使用它们就足够了。这不是问题。我认为我们不需要对我们使用的每一项技术都追根究底，但我们需要清楚地了解我们的优势，哪些是勉强可用的？哪些是真正被理解和掌握的？哪些需要掌握但很少使用？弄清这些问题，才能让我们保持清醒的头脑，对自身的现状和长远的发展目标会有清醒的认识。积累知识而不是经验新手或者小白有一个特点，他们往往更依赖经验而不是知识。让我举一个例子。比如后端新手经常遇到的问题之一就是maven打包失败。很多人解决冲突的方法就是mvnclean&mvninstall。也就是清空重新建立，因为大多数情况下这个命令就可以解决问题。所以很多新手都记住了这条命令，每次遇到maven失败的时候都会这样做。如果此命令不能解决问题怎么办？这些人可能会尝试另一个订单。您是否尝试了所有常用命令来解决问题？这些人可能就愣住了，认为这个问题解决不了，只好请大牛看看。这里的核心问题是新手积累的是经验而不是知识。他们只是简单机械地映射出现的问题和解决方案，而不是从原理和核心层面理解问题产生和解决方案生效的原因。那么结果就是，积累的只是经验，下次你能解决问题，并不是因为你学会了解决问题的方法，也不是因为你理解了这块技术内容，只是单纯的背了下来。这显然是一种伪生长。其实我以前也遇到过这样的问题，虽然每次遇到问题都会有意识的记录下解决方法，这样下次就不用问别人了。但是，虽然我记录的问题越来越多，但是每次遇到新的问题，还是解决不了，还需要请教别人。直到有一天，我问的大牛露出不耐烦的神色，才让我下定决心，要学会自己解决问题。于是我不再头疼脚踏地解决问题，而是学习问题背后的原理和机制，从错误日志中分析错误原因，思考解决方案，最终学会彻底解决。一类问题的方法。之后，你不仅可以独立解决问题，还可以帮助别人。后来我回过头来看，如果我在第一次遇到问题时尝试学习该问题的机制，而不是仅仅记住解决方案，我可以做得更好。少说废话，多写代码著名的Linux之父Linus有一句名言：talkischeapshowmethecode。翻译就是废话少说，带上代码。我觉得这句话非常符合这行工作的精髓。我们不靠文字谋生，而是靠实实在在的产出。此输出最终将在代码中实现。作为新人，我们可能会有这样的问题和困惑。但是，我们想这么多问题和困惑是没有用的，只能用硬实力来解决。著名的C语言作者谭浩强也有一句名言：初学者学习编程最重要的是写出10000行可以运行的代码，然后自然而然就上手了。道理其实都一样，少说废话，多做实事。多做多练，实力自然不会差。乌托邦式的吹牛没什么大不了的。所以如果你对学习一个新的领域犹豫不决，又不知道从何下手，不妨想想这句话，别着急，先开始写代码吧。做了之后自然就明白后面要做什么了。以上是我积累的一些心得和想法。如果你是新手，希望能帮助你顺利度过新手期，朝着大牛的目标迈进。
