所有开发人员应该在大学里学到的东西


忘掉“代码行”

资源

作为一名开发人员,您会听到很多关于“代码行”所代表的疯狂,令人难以置信的理论。不相信他们。代码行是一个基于决策的荒谬指标。在非常罕见的情况下,它告诉你一些东西,在所有其他情况下,它告诉你什么。使用代码行进行决策就像按页数评估书籍质量一样。

有些人可能会认为应用程序中的代码行越少,就越容易阅读。这只是部分正确,我的可读代码指标是:

  • 代码应该是一致的
  • 代码应该是自我描述的
  • 代码应该有详细记录
  • 代码应该利用稳定的现代功能
  • 代码不应该是不必要的复杂
  • 代码不应该是不兼容的(不要故意写慢代码)

减少代码行数的那一刻会干扰其中任何一行,这就成了一个问题。在实践中,它几乎总是会干扰,因此几乎总是一个问题。但这就是问题,如果你努力达到上述标准,你的代码将是完美的行数,无需计算。

没有“好”或“坏”的语言

开玩笑,除了开玩笑。资源

我看到人们总是说这样的话:

C优于X,因为性能

Python比X更好,因为简洁

Haskell比X好,因为外星人

语言比较可以简化为单句的概念几乎是侮辱性的。他们是语言,而不是口袋妖怪。

不要误会我的意思,语言之间肯定存在差异。就是这样,很少有“无法使用”的语言(尽管有许多过时/死亡的语言)。每种语言都带来了自己独特的权衡。在这方面,语言类似于工具箱中的工具。螺丝刀可以做锤子不能做的事,但是你会说螺丝刀比锤子更好吗?

显然锤子更好

在我谈论如何评估语言之前,我想要做一些非常清楚的事情。很少有语言选择真正重要的案例。在某些语言中,有些事情显然无法做到。如果您编写前端代码,则无法选择语言。但总的来说,语言选择通常是项目最不重要的问题之一。

以下是核心方面(有序),我认为应该决定你选择的语言(这些是口袋妖怪的统计数据)

  • 可用在线资源的密度(StackOverflow密度)
  • 发展速度(vroom vroom)
  • 臭虫倾向(eeek)
  • 盘点生态系统的质量和广度(是的npm,它说质量)
  • 性能特点(更多点)
  • 可用性(对不起COBOL)

还有一些强大的耦合不在你的手中。如果您从事数据科学工作,那么您实际上需要使用Python,R或Scala(可能是Java)。如果这是一个爱好项目,使用任何会让你最快乐的东西。我只有一个不可谈判的规则。我拒绝使用没有遇到大多数问题的语言,直接在StackOverflow上解决。这不是我无法解决它,它不值得花时间。

读其他人的代码很难

资源

阅读其他人的代码很困难。 Robert C. Martin在“清洁代码”中谈到了这一点:

实际上,阅读与写作的时间比例远远超过10比1.我们不断阅读旧代码,作为编写新代码的努力的一部分。 …(因此,)使其易于阅读使其更容易编写。

很长一段时间,我认为我只是在阅读其他人的代码。随着时间的推移,我意识到这几乎是每个程序员每天都在努力的事情。阅读其他人的代码几乎就像读外语一样。即使您对编写器的编程语言选择感到满意,您仍然需要适应不同的样式和架构选择。这也假设作者编写了一致且可靠的代码,可以命中或遗漏。这是一个非常难以克服的问题。我发现有一些东西有很多帮助。

查看其他人的代码将极大地提高您的代码阅读技能。在过去的两年里,我已经回顾了很多Github PR。对于每个PR,我觉得阅读其他人的代码会更舒服一些。由于这些原因,Github PR特别出色

  • 可以随时练习,只需找到您想要贡献的开源项目。
  • 练习在范围内容中阅读(驾驶特征或PR的错误)。
  • 注意细节需要,这将迫使您评估每一行。

可以帮助您阅读其他人代码的第二个hack更加独特。这是我提出的一种技术,它确实减少了我在外国代码库中感到舒适所需的时间。在查看了我想要阅读的代码的样式之后,我首先打开vi并开始以项目使用的样式编写代码。当您以新风格编写代码时,它还将提高您的阅读技能。你实际上经历过的风格会让人感觉不那么陌生。即使我只是在Github上浏览一个随机项目,我也会很快做到这一点。试试看。

你永远不会写出“完美”代码

资源

在我开始组建团队之前,我是一名“孤狼”开发人员已有4年了。在大多数时间里,我只是假设行业中的每个程序员都编写了完美的代码。在我写“完美”代码之前,我认为这只是时间和精力的问题。
这是我过去常常感到焦虑的事情。一旦我加入团队,很快就会发现没有人在编写“完美”的代码。但进入系统的代码几乎总是“完美”,是什么给出的?答案,代码审查。

我与一群非常出色的工程师合作。这些是一些最有能力,最自信的程序员,可以买到钱。如果有人建议提交未经审核的代码,我们团队的每个成员(包括我)都会遭受全面恐慌。即使你认为你是下一个比尔盖茨,你也会犯错误。我甚至不是在说逻辑错误,我在说错字,缺少字符。你的大脑调整并永远不会接受的东西。你还需要另外一双眼睛。

努力与注重细节并愿意批评你的工作的其他人合作。听力批评起初很难,但这是唯一一致的改进方法。尽力在代码审查期间不要变得防御,不要亲自接受任何评测。你不是你的代码。

当我查看其他人的代码时,我只是谷歌搜索他们所做的每一个选择,看看它是否与强烈的流行观点不同。很多时候,用“初学者的头脑”来看同样的问题,可以捕捉到这个人永远不会回头看的东西。

作为程序员工作并不意味着每天8小时的编程

这是一个非常普遍的问题,但人们似乎从来没有给出明确的答案。

很少有人每天编写代码超过4小时

不同意这种情况的人要么是规则的例外,要么是那些应该更好地对待他们的公司的工作。编程是一种精神上耗费精力,注重焦点的任务。期望任何人每周5天,每天8小时编写代码是完全不合理的。在极少数情况下,您需要满足最后期限或拉一点额外的延伸,但这些是很少的。当我说“罕见”时,我的意思是几乎从不。不要容忍滥用你的工作场所,并且由于计划不周/招聘不足而让你加班加点。

根据记录,您的公司最好每天8小时积极编程,这对您而言并不是最有利的。你的老板可能会认为是这种情况,但它是短视的,忽视了对生产力和心理健康的长期影响。

为了清楚起见,我并不是说你一天只工作四小时。其他四个小时通常是最好的花费:

  • 研究工作相关和非工作相关的主题
  • 与同事讨论你的工作
  • 帮助正在为自己的工作而奋斗的同事
  • 规划你未来的工作
  • 代码评测
  • 会议

我还强烈建议您在白天定期休息,并进行锻炼(即使只是短暂的)。运动对精神疲劳的好处有很好的记录。我个人发现,如果我无法中心化精力,锻炼尤其有用。

更新:/ u / terriblesarcasm建议我添加开发人员应该在他编程的4小时内做的事情。我添加了一节解决这个问题。

结论

这些是我希望他们在大学教授而不是纯粹理论的一些事情。在写这篇文章的过程中,我想出了大量的其他项目,但这些必须在下一篇文章中出现

资讯来源:由0x资讯编译自DEV,原文:https://dev.to/taillogs/what-developers-should-actually-learn-in-college-2nen ,版权归作者所有,未经许可,不得转载
你可能还喜欢