看懂别人的代码，只是成为高效程序员的第一步！
作者 | SeattleDataGuy
译者 | 弯月，责编 | 屠敏
出品 | CSDN（ID：CSDNnews）
在为面试做准备的时候，很多软件工程师都花费了大量时间做编程题和完善简历。
最终在找到一份工作后，无论是在创业公司、Google、亚马逊或是其他地方工作，他们会发现之前为这份工作而学习的技能其实在日常工作中根本用不上。
在本文中，我们将根据自身的心得呈上高效程序员的七大技能。
学习如何阅读他人的代码
只要不是自己编写的代码看起来都不顺眼。
所以说，能够理解他人的代码是一项伟大的技能，而且你可以从中受益良多。
不论前一位工程师的代码多么杂乱或思虑不够周全，你仍然需要仔细阅读所有的代码。毕竟，这是你的工作。何况那位工程师可能就是一年前的你。
这项技能有两种好处。第一，能够阅读别人的代码，这是了解什么是不良设计的绝佳机会。在浏览其他人的代码时，你可以了解哪些代码有效，而哪些无效。更重要的是，你将了解哪类的代码方便其他工程师理解，而哪类的代码很难理解。
你需要尽可能多地阅读别人的代码。如此一来，其他工程师就会知晓你是一名高级工程师。
同时在阅读时，你需要指出有关代码可维护性以及良好注释的重要性。这可以进一步彰显你在编程领域的主导地位。
你的代码应该设计得井井有条，不需要任何文档。实际上，如果你是一名优秀的程序员，则应该不需要编写有关代码的任何文档。编写文档很浪费时间，你应该把时间花在编程和参加会议上。
能够读懂他人凌乱的代码也可以方便你在必要的时候进行修改。有时这意味着你需要修改并不熟悉的代码。例如，我们曾将脚本从Powershell转换到Python，再转换到Perl。我们的Perl经验很有限，但是我们仍然有足够的背景信息来弄清楚该如何编写脚本并进行必要的改动。
这是因为我们很了解现有的代码，而且还能够阅读Perl脚本。
阅读他人的代码能够提升自身的价值，因为你遵循的都是精心设计的系统，而其他人可能不太理解。
感知不良项目
有很多技能需要付出大量的时间才能学会。我们认为值得学习的技能之一就是了解哪些项目不值得做，以及哪些项目显然是死路一条。
大公司的项目往往更有可能顺利完成，而且影响力也更大。有些项目可能没有任何业务意义（至少对你而言没有意义），有些项目则管理不善。但并不是说如果你不同意就可以否认项目。然而，如果利益相关者自己都解释不了项目的最终结果，那么该项目可能就不值得做。
此外，有些项目可能过于关注技术而不是解决方案，因此从一开始就很明显不会产生太大影响。在真正能够理解什么是不良项目之前，你需要经历很多不良项目，才能培养起这种技能。因此，不要花费太多时间在甄别每个项目上。
等到职业生涯达到某个点时，你自然而然就能拥有良好的直觉。
避免会议
无论你是软件工程师还是数据科学家，会议都是不可避免的，因为你需要与项目经理、最终用户和客户互通有无。但是，会议常常会塞满你的整个日程。因此我们要学会如何避免不必要的会议。或许这里使用“管理”比“避免”更为妥帖。目标是确保你花在会议上的时间能够推动决策并帮助团队前进。
最常见的方法是，在每天的日程安排上留出两小时的固定会议。很多人都会在他们认为合适的时间段设置例会，然后利用这段时间来抓紧时间赶开发工作。
还有一种避免会议的方法是提前到公司。就个人而言，我们喜欢早到公司，因为通常这个时段办公室比较安静。大多数早到的人都和你一样，只想完成工作，所以没有人会打扰你。
对于独立工作的人来说这很重要，因为我们的工作需要专注，而且不需要与其他人交谈。虽然有时候你需要与他人合作来解决问题，但一旦问题得到解决后，你只需要编写代码。在精神高度集中的时候，你的大脑高速运转，处理当前工作的各种复杂想法。如果你经常被打断，那么就很难拾取被打断的记忆重新开始。
Github…说起Git就头疼？
有些计算机科学专业的学生一生下来就开始使用Git。他们了解每一个命令和参数，甚至超越了一些专业人士。
而有些人则在第一份工作中才开始尝试Git。对于他们来说，Git是一堆非常费解的命令和进程。他们从未百分百确定自己的做法是否正确（因此Git命令大全非常受欢迎）。
无论你的公司使用哪种代码存储系统，只要使用正确都会很有帮助，但如果使用不当则会成为阻碍。看似只是一次简单的推送或提交，但不经意期间就很有可能会演变成一场多个分支和分叉的混战。此外，如果你经常忘记拉取最新的版本，那么还需要为处理合并冲突而头痛不已。
如果有必要的话，还是保留一份Git命令大全吧，或者其他能够减轻你负担的资源。
编写易于维护的代码
https://xkcd.com/974/
年轻的工程师常常希望在一个解决方案中实现他们所学的一切。在这种愿望的驱使下，你学习了面向对象编程、数据结构、设计模式以及所有新技术，并希望在你编写的每一段代码中使用所有这些技术。这种思想会导致不必要的复杂性，因为这很容易在过去使用的解决方案或设计模式之上画蛇添足。
你需要寻求复杂的设计概念和简单的代码之间的平衡。设计模式和面向对象的设计理应简化总体方案中的代码。但是，随着越来越多的流程被抽象化、封装和黑盒化，调试的难度则越来越加剧。
学会说不和排列优先顺序
无论你是财务分析师还是软件工程师，所有工作岗位的人员都需要学会说“不”和排列优先顺序。尤其是技术岗位，因为似乎每个人都需要他们提供帮助。如果你是一名数据工程师，则可能需要承担开发数据流水线之外的工作。有些团队需要数据提取，有些需要负责仪表板，而有些则需要为数据科学家提供新的流水线。
虽说排列优先顺序和说“不”可能是两种不同的技能，但是二者紧密地交织在一起。排列优先顺序意味着你需要将时间花费在对公司有重大影响的工作上，而说“不”则意味着避免应该由其他团队处理的工作。对于所有岗位而言，二者都是同时发生的。
做到这一点很难，因为我们都希望处理好每个请求。尤其是刚刚毕业的大学生。你不希望让任何人失望，而且希望手头有大量的工作。
在大公司，工作似乎没有尽头。关键在于只接受能够完成的工作。
很多技能在实际的面试中根本不会被问及，甚至大学也不会教。大学生未能接触实际开发环境中的问题往往是因为受到了环境的限制，而不是说他们没有这种欲望。
运营设计思维
在大学学习期间，有一项技能很难在面试中体现和复制成功，那就是思考最终用户会如何错误地使用你的软件。通常我们称之为运营设计思维。
然而，这个词的背后含义是你要编写怎么用都不会出问题的代码。
例如，由于许多编程都属于维护工作，因此常常需要修改与其他代码高度纠缠的代码。即使是简单的更改也需要调查对象、方法和/或API可能会被引用到的所有地方。否则，就很容易导致意外的模块被破坏。即使你只是修改了数据库中的某个数据类型也是如此。
此外，你还需要在开发之前仔细考虑边缘情况，以及整个高层设计。
在开发新模块或微服务时，情况就更复杂了，重要的是你需要花时间仔细考虑所构建内容的运营场景。考虑一下将来用户可能会如何使用新模块，他们可能会通过哪些错误的方式使用新模块，可能需要哪些参数，以及将来程序员是否可能通过其他方式使用你的代码。
保持代码的简单性只是问题的一部分。创建能够在你自己的计算机上良好运行的软件很容易。但是部署代码会出现各种错误。一旦投入生产，就很难确保代码的使用方式以及原始的代码中会添加哪些代码。从现在开始的五年后，程序员可能会对这段代码的局限感到失望。
原文：https://medium.com/better-programming/7-habits-of-highly-effective-programmers-563ee3b63f33
本文为 CSDN 翻译，转载请注明来源出处。
推荐阅读
真香，朕在看了！