原文标题 ：These 7 Programming Habits Are Making You a Less Productive Data Scientist
这 7 个编程习惯让你成为一个效率低下的数据科学家
改正这些习惯可以让你成为更高效的数据科学家
我敢肯定，在我们走向数据科学的集体旅程中，我们都至少在某个时候养过这些坏习惯中的一个或另一个。
无论我们是在刚开始学习时才这样做，还是后来因为我们相当擅长我们所做的事情而变得懒惰才这样做，我们都至少犯过这些编程错误中的一个。
不管是什么原因，清理你的编程行为并成为一名更有生产力、更高效的数据科学家永远不会太晚。幸运的是，您已经完成了困难的部分并自学了编码。现在，我们只需要改进您的技术并养成一些良好的习惯，以帮助您从数据科学项目的最佳部分之一中获得更多乐趣。至少，你今天学到的东西会让你免于被软件部门责骂。
直接从软件开发学生的经验来看，这些习惯肯定会让你无法成为最有生产力的自己——让我们现在就改变它。
1. 不评论你的代码
注释您的代码是代码文档的关键部分，可确保三件事：
- 其他人可以理解您的代码。
- 其他人可以维护您的代码。
- 一段时间后重新访问代码时，您可以理解您的代码。
至少，您的代码中必须包含三种类型的注释——它们是不可协商的：[0]
- 第一个是描述您个人或团队存储库中任何新提交或共享代码的注释。这个注释可以是你的 Git 提交消息的一部分，但它也应该出现在代码中，通常在你刚刚提交的代码块之上。我喜欢通过在它周围创建一条包含代码和注释的虚线来进一步分隔此代码部分——只是为了更清晰地查看，仅此而已。此注释应描述代码的功能。
- 第二个是描述代码中每个函数的注释。这个评论应该直接放在每个函数的顶部，解释它的输入和输出，以及函数逻辑。
- 您应该拥有的最后注释应该位于代码中任何一行的顶部。一行代码描述了代码中的逻辑，这些逻辑通常分布在多行中，但实际上是写在一行中。有时这些单行代码可能难以理解，因此描述其作用以及每个部分如何工作的评论是让您保持条理的好方法。
通过与其他软件开发人员的合作，我发现区分好代码和好代码的是其中注释的级别和细节。换句话说，简洁、准确、自由地注释您的代码。如果某些事情对您来说很明显，请发表评论，以防其他人（或您将来就此而言）不明显。
2. 不使用 GitHub 进行版本控制
从事技术工作的人真的没有理由不使用 GitHub。 GitHub 不仅是一个版本控制工具，还是一个生产力工具，可以帮助您轻松地处理代码并与他人协作。
GitHub 通常是黄金标准，也是大多数科技公司对其代码进行版本控制的标准。即使您是在公司工作的单身数据科学家，如果您与软件部门共享代码并将其转化为生产代码，GitHub 也是一个重要的工具。
曾几何时，我们都宣布我们将真正学习如何一劳永逸地使用 GitHub。 GitHub 有很多有用的功能（包括跟踪代码中的更改以及处理旧版本的代码），但老实说，数据科学家通常可以使用它来简单地提交到主分支，有一些用于运行替代场景的分支。就这么简单。
好吧，这是你开始使用它的标志——这次是真的。
3. 不测试你的代码
我们都去过那里，我们尽可能避免运行和测试我们的代码，因为我们害怕会发生什么。 1% 的时间我们可能很幸运，一切都正常运行，但我可以向你保证，其他 99% 的时间一切都乱套了。
他们接受过软件开发方面的教育，定期对我们进行测试。不定期测试您的代码被视为一种罪恶，而我们很快就做到了。它不仅帮助我们立即发现错误和错误，而且还意味着我们不必筛选数百行代码来查找问题。
测试代码就像编写单元测试一样简单，单元测试是一种涉及检查函数、对象或类（单元）是否正常工作的测试。执行单元测试的一种简单方法是根据您提供的输入打印函数的输出。[0]
4. 不把复杂的问题分解成简单的变量和函数
数据科学问题通常很复杂，涉及许多活动部分。这些问题可能令人生畏，如果不分解成简单的部分，可能会导致您坐在电脑屏幕前盯着电脑屏幕，直到回家时还没有编写一行代码。
诀窍是在开始一个问题时考虑到最终结果，然后将其分解为简单的变量和函数——因为实际上，代码就是变量和函数。[0]
首先，您需要问自己这个问题试图解决什么问题，以及这个解决方案的结果是什么。这将帮助您开始弄清楚需要哪些代码片段才能达到最终目标。一旦确定了解决方案的外观，就可以开始布置实现它所需的各个变量和函数。[0]
看，您已经将复杂的问题分解为可管理的任务！这样不是更好吗？
将这些任务添加到您的看板后（我最喜欢在处理复杂问题时保持井井有条的方式），您就可以开始创建项目的较小部分，从而形成一个完整的解决方案。
5. 不重构你的代码
代码重构是指在不改变其原有功能的情况下重构你的代码。虽然重构通常出现在软件开发场景中，但数据科学家也可以使用它来清理代码。[0][1]
重构比听起来容易：看看你写的一些旧代码，问问如何才能更有效地编写它。然后，应用良好的编码实践，清理您的代码，直到它看起来比以前更好。[0]
重构是在您编写了可以运行的代码之后最好完成的任务。例如，当您第一次处理数据科学问题时，您希望确保您的代码有效，无论它是否漂亮。然后，一旦你确保它提供了正确的输出，你就可以返回并澄清变量名，适当地缩进你的代码，使用 python 语法标准来创建消除冗余的函数，并且通常重写任何看起来像一堆意大利面。[0]
我建议只有在您脱离流程状态并让您的代码工作后才进行任何重构。每次写一行就停下来重构你的代码，这会让你脱离状态，并使完成代码的时间延长十倍。就像建议您在将想法写在纸上之前不要担心拼写或语法一样，等到您编写了所有代码以使其看起来很漂亮。
6. 没有让你的代码井井有条
糟糕的组织能力是我在大学学习软件开发期间经常遇到的事情。尽管我的许多同学都是出色的开发人员，但组织能力并不是他们的强项，因此在查看他们的代码时还有很多不足之处。
尽早学习正确的代码组织技能可以帮助您创建易于导航和使用的代码，并且这将减少您推出项目所需的时间。
根据 Karl Broman 的说法，代码和数据组织非常简单：[0]
- 将项目的所有内容保存在一个目录中。此目录应包括项目的所有数据、代码和结果，这使得将来的工作或移交给其他人更容易。
- 将原始数据与派生数据分开。保留两个子目录，一个包含原始数据，另一个包含派生数据。包含数据摘要的子目录也有助于组织数据。
- 将数据与代码分开。将您的代码保存在一个子目录中，将您的数据保存在另一个子目录中（或如上所述的三个子目录）。
- 远离绝对路径，而是使用相对路径：当涉及到与可能没有您的项目目录副本的其他人在完全相同的位置进行协作时，使用相对路径以允许他们打开和访问您的所有项目很重要文件。
- 选择好的文件（以及变量和函数）名称：原始数据文件名称应与您获得它们时的名称保持一致，但代码文件名称应尽可能具有描述性。自然地，变量名和函数名也是如此。
- 永远不要在文件名中使用“final”：正如 Broman 所说，“没有什么是最终的”。一个文件的多个版本应该附加一个版本号，但“最终”版本永远不应该这样标记。
- 编写文档和 README 文件。文档对于解释一切是什么和做什么是必要的。好的文档涉及描述文件及其包含的过程。保持 README 为最新很重要，如果有人有进一步的问题，请提供您的联系信息也很重要。
我在以前的项目中承担的任务之一是组织我团队的代码。这不仅是了解代码如何工作的好方法，而且也是精通的一项重要技能。制作一个适合你的组织系统（我的与上面描述的非常相似）并将其付诸实践每个项目，无论大小。
7. Not taking breaks
我会告诉你一个小秘密：如果你不休息，你就会写出糟糕的代码。
忙碌的文化在科技领域仍然存在，而且很流行，每周工作 90 小时并不反常，只是偶尔起床补充汽水，连续几天不见阳光。
虽然看起来您的老板拥有您，但他们并不拥有您的健康（身体、心理和情感）。
所以我要你现在保证，你每天至少要进行一小时的活动，每天至少喝两次苏打水以外的东西（水是一个很好的开始，咖啡不算） ，你会每天至少出去一次，你会尝试吃不是外卖的食物。
相信我，我已经记不清有多少次我在遛狗的时候解决了编码或逻辑问题。新鲜空气似乎对大脑解决问题的部分有奇效。
每天坐在电脑前敲打代码八个小时或更长时间，没有任何休息时间，这会让您筋疲力尽，并且比现在更缺乏生产力。换句话说，生命是短暂的，你的工作不是一切，从长远来看，照顾好自己会让你成为更好的数据科学家。
订阅以将我的故事直接发送到您的收件箱：故事订阅[0]
请使用我的推荐链接成为会员以无限制地访问 Medium（我将收取少量佣金，您无需支付额外费用）：Medium Membership[0]
通过捐赠来资助创作更多像这样的故事来支持我的写作：捐赠[0]
文章出处登录后可见！
