大学可以学前端开发_所有开发人员在大学中应该学习的东西

大学可以学前端开发

忘记“代码行” (Forget About "Lines of Code")

Source

资源

As a developer, you'll hear a lot of crazy, unbelievable theories about what "lines of code" signify. Believe none of them. Lines of code is a ridiculous metric to base decisions on. In very rare cases it tells you something, in all the other cases, it tells you nothing. Using lines of code to make decisions is like rating book quality by number of pages.

作为开发人员，您会听到许多关于“代码行”含义的疯狂，令人难以置信的理论。 不相信他们。 代码行是用于制定决策的荒谬指标。 在极少数情况下，它告诉您某些情况，在其他所有情况下，则什么都不会告诉您。 使用代码行做出决策就像通过页数对书籍质量进行评分。

Some might make the case that the fewer the lines of code there are in an application, the easier it is to read. This is only partially true, my metrics for readable code are:

有些人可能会认为，应用程序中的代码行越少，读取起来就越容易。 这只是部分正确，我对可读代码的度量标准是：

• Code should be consistent
  代码应一致
• Code should be self descriptive
  代码应具有自我描述性
• Code should be well documented
  代码应有据可查
• Code should utilize stable modern features
  代码应利用稳定的现代功能
• Code shouldn't be unnecessarily complex
  代码不必太复杂
• Code shouldn't be un-performant (don't write intentionally slow code)
  代码不应表现不佳(不要故意编写慢速代码)

The moment reducing the number of lines of code interferes with any of those, it becomes a problem. In practice, it will almost always interfere and thus is nearly always a problem. But here's the thing, if you strive to meet the above criteria, your code will be the perfect number of lines, no need for counting.

减少代码行数的那一刻会干扰其中的任何一个，这将成为一个问题。 实际上，它几乎总是会干扰，因此几乎总是一个问题。 但是，如果您努力满足上述条件，那么您的代码将是完美的行数， 无需计算。

没有“好”或“差”的语言 (There Are No "Good" or "Bad" Languages)

Except for php, just kidding

除了PHP，只是在开玩笑

I see people say stuff like this, all the time:

我看到人们一直在说这样的话：

C is better than X, because performance

C比X更好，因为性能

|

|

Python is better than X, because conciseness

Python比X更好，因为简洁

|

|

Haskell is better than X, because aliens

Haskell比X更好，因为外星人

The notion, that a language comparison could be reduced down to a single sentence is almost insulting. They're languages, not Pokemon.

语言比较可以简化为一个句子的想法几乎是侮辱性的。 他们是语言，不是口袋妖怪。

Don't get me wrong, there are definitely differences between languages. It's just that, there are very few "unusable" languages (although there are many outdated/dead languages). Each language brings it's own unique set of tradeoffs. In that regard, languages are similar to tools in a toolbox. A screwdriver can do what a hammer can't, but would you ever say a screwdriver is better than a hammer?

别误会，语言之间肯定存在差异。 只是，很少有“不可用”的语言(尽管有许多过时/过时的语言)。 每种语言都有其独特的权衡点。 在这方面，语言类似于工具箱中的工具。 螺丝起子可以做锤子做不到的事情，但是您会说螺丝起子比锤子好吗？

obviously the hammer is better

显然锤子更好

Before I talk about how I evaluate languages, I want to make something very clear. There are very few cases where the language choice actually matters. There are things you can obviously not do in some languages. If you write frontend code, you don't get a language choice. But in general, language choice is usually one of the least important issues for a project.

在谈论如何评估语言之前，我想先说清楚一点。 在少数情况下，语言选择实际上很重要。 有些事情显然是某些语言无法做到的。 如果编写前端代码，您将无法选择语言。 但是总的来说，语言选择通常是项目中最不重要的问题之一。

Here are the core aspects (ordered), that I believe should dictate your choice of language (these are it's Pokemon stats)

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

• Density of available online resources (StackOverflow density)
  可用在线资源的密度(StackOverflow密度)
• Development Velocity (vroom vroom)
  开发速度(vroom vroom)
• Bug proneness (eeek)
  错误倾向(周)
• Quality and breadth of package ecosystem (yea npm, it says quality)
  软件包生态系统的质量和广度(是npm，表示质量)
• Performance characteristics (more dots)
  性能特征(更多点)
• Hirability (sorry COBOL)
  可信赖性(对不起，COBOL)

There are also some strong couplings that are out of your hands. If you're working in data science, you realistically need to use Python, R or Scala (maybe Java). If it's a hobby project, use whatever will make you happiest. There's only one non-negotiable rule I have. I refuse to use languages that don't have most of the problems I will encounter, directly solved on StackOverflow. It's not that I can't solve it, it's just not worth the time.

还有一些无法控制的牢固耦合。 如果您从事数据科学工作，则实际上需要使用Python，R或Scala(也许是Java)。 如果这是一个爱好项目，请使用使您最快乐的任何东西。 我只有一条不可谈判的规则。 我拒绝使用不会遇到大多数问题的语言，这些语言可以在StackOverflow上直接解决。 不是我无法解决问题，而是不值得花费时间。

阅读别人的密码很难 (Reading Other People's Code is Hard)

Source

资源

Reading other peoples code is difficult. Robert C. Martin talks about this in "Clean Code":

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

Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write.

确实，读与写所花费的时间比例远超过10：1。作为编写新代码的一部分，我们不断读取旧代码。 ... [因此，]使其易于阅读使其易于编写。

For a long time, I assumed that I just sucked at reading other peoples code. Over time, I realized that it's something almost every programmer struggles with on a daily basis. Reading other people's code almost feels like reading a foreign language. Even if you're comfortable with the programming language choice of the writer, you still have to adjust to differing styles and architecture choices. This also assumes that the author wrote consistent and reliable code, which can be hit or miss. This is a really difficult one to overcome. There are a few things I've found helped a LOT.

很长时间以来，我以为我只是在阅读别人的代码上很烂。 随着时间的流逝，我意识到几乎每个程序员每天都在为此烦恼。 读别人的代码几乎就像是读一门外语。 即使您对编写器的编程语言选择感到满意，您仍然必须适应不同的样式和体系结构选择。 这也假设作者编写了一致且可靠的代码，可能会遇到麻烦。 这是一个很难克服的难题。 我发现很多东西可以帮助很多。

Reviewing other peoples code will improve your code reading skills immensely. In the past two years, I've reviewed quite a few Github PR's. With each PR, I feel slightly more comfortable reading other peoples code. Github PR's are especially great for these reasons

查看其他人的代码将极大地提高您的代码阅读技能。 在过去的两年中，我已经审查了许多Github公关。 有了每个PR，我都会更轻松地阅读其他人的代码。 由于这些原因，Github公关特别出色

• Can be practiced anytime, just find an open source project that you feel like you want to contribute to.
  可以随时练习，只需找到自己想贡献的开源项目即可。
• Practice reading in a scoped context (driving feature or bug of PR).
  在一定范围内练习阅读(驱动功能或PR的错误)。
• Attention to detail required, which will force you to evaluate each line.
  注意所需的细节，这将迫使您评估每一行。

The second hack which can help you read other peoples code is a bit more unique. It's a technique I came up with, and it's really reduced the amount of time it takes for me to feel comfortable in a foreign codebase. After looking at the style of the code I want to read, I first open up vi and starting writing code in the style used by the project. When you write code in the new style, it will also improve your reading skills. The style will feel less foreign, as you've actually experienced it. Even if I'm just browsing a random project on Github, I'll quickly do this. Try it out.

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

您将永远不会编写“完美”的代码 (You'll Never Write "Perfect" Code)

Source

资源

I was a "lone wolf" developer for 4 years before I started working on a team. For most of that time, I just had this assumption that every programmer in the industry wrote perfect code. I figured it was just a matter of time and effort before I also wrote "perfect" code.It's something I used to feel really anxious about. Once I joined a team, it quickly became clear that no one was writing "perfect" code. But the code going into the system was almost always "perfect", what gives? The answer, code reviews.

在开始为团队工作之前，我曾是“孤独的狼”开发人员4年。 在大多数时间里，我只是假设行业中的每个程序员都编写完美的代码。 在我还编写“完美”的代码之前，我认为这只是时间和精力的问题。这是我以前经常感到非常焦虑的事情。 加入团队后，很快就会发现没有人在编写“完美”的代码。 但是进入系统的代码几乎总是“完美”的，这有什么用呢？ 答案，代码审查。

I work with a team of really brilliant engineers. These are some of the most competent, confident programmers money can buy. Every single member of our team (including me) would have a full blown panic-attack if someone ever suggested committing un-reviewed code. Even if you think you're the next Bill Gates, you will make mistakes. I'm not even talking logical mistakes, I'm talking typos, missing characters. Things that your brain tunes out and will never pick up on. Things you need another set of eyes for.

我与非常出色的工程师团队合作。 这些是一些最有能力，最有信心的程序员可以买得到的东西。 如果有人建议提交未经审查的代码，我们团队中的每个成员(包括我在内)都会遭受彻底的恐慌攻击。 即使您认为自己是下一个比尔·盖茨，您也会犯错。 我什至没有在谈论逻辑错误，在说错别字，缺少字符。 您的大脑会调整并永远不会加快的事情。 您需要另一双眼睛的事情。

Strive to work with others that are attentive to detail and willing to criticize your work. Hearing criticism is difficult at first, but it's the only consistent way to improve. Do your best to not become defensive during a code review, and never take any comments personally. You're not your code.

努力与注重细节并乐于批评您的作品的其他人一起工作。 刚开始时很难听到批评，但这是唯一持续改进的方法。 尽最大努力避免在代码审查过程中产生防御，也不要亲自发表任何评论。 您不是您的代码。

When I'm reviewing someone else's code, I just Google search every choice they make and see if it differs from strong popular opinion. Often times, looking at the same problem with a "beginners mind", can catch things the person would have never gone back and looked at.

当我查看别人的代码时，我只是Google搜索他们做出的每一个选择，看看它是否与流行的看法有所不同。 通常，以“初学者的头脑”看同样的问题，可能会抓住人们永远不会回头看的东西。

程序员的工作并不意味着每天要编程8个小时 (Working as a Programmer Doesn't Mean 8 Hours of Programming a Day)

This is a very common question, but people never seem to give a clear answer.

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

Very few people are writing code for more than 4 hours a day

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

People who disagree with this are either the exception to the rule or work at companies that should treat them better. Programming is a mentally draining, focus intensive task. It's entirely unreasonable to expect anyone to write code for 8 hours a day, 5 days a week. There will be rare cases where you need to meet a deadline or pull a little extra for a stretch, but those are few and far between. When I say "rare", I mean almost never. Do not tolerate a workplace that abuses you and makes you work overtime due to poor planning/under-hiring.

对此不同意的人要么是规则的例外，要么就是在公司中应该更好地对待他们。 编程是一项耗费精力，集中精力的任务。 期望任何人每周5天每天写8个小时的代码是完全不合理的。 在极少数情况下，您需要按时完成任务或多花些钱以延长工作时间，但这种情况很少而且相差甚远。 当我说“罕见”时，我的意思是永远不会。 不要容忍由于规划/招聘不足而虐待您并导致您加班的工作场所。

For the record, it's not even in your companies best interest for you to work 8 hours a day. Your boss might think that's the case, but it's shortsighted and ignores the longterm implications, on productivity and mental health.

根据记录，每天工作8小时甚至都不符合您公司的最大利益。 您的老板可能会认为是这种情况，但这是短视的，并且忽略了对生产力和心理健康的长期影响。

I highly recommend taking regular breaks during the day, and exercising (even if only briefly). The benefits of exercise on mental fatigue are well documented. I've personally found that exercise especially helps if I'm having trouble focusing.

我强烈建议您在白天定时休息并锻炼身体(即使只是短暂的锻炼)。 运动对精神疲劳的好处已得到充分证明。 我个人发现，如果我无法集中精力，锻炼特别有帮助。

结论 (Conclusion)

These are a few of the things I wish they were teaching at university instead of pure theory. In the process of writing this, I came up with a ton of other items but those will have to come in the next post!

这些是我希望他们在大学教授的一些事情，而不是纯粹的理论。 在撰写本文的过程中，我提出了很多其他内容，但这些必须在下一篇文章中介绍！

翻译自: https://www.freecodecamp.org/news/things-all-developers-should-learn-in-college/

大学可以学前端开发