程序员实用小程序

In short: old but gold.

简而言之：古老而又黄金。

Published in 1999, The Pragmatic Programmer is a book about how to become a Pragmatic Programmer. Which really means a ‘Good Programmer’.

《实用程序员》于1999年出版，是一本有关如何成为一名实用程序员的书。 真正的意思是“优秀程序员”。

Yes, it was published about 20 years ago. But this book still provides many insights that are very relevant to programmers or software engineers, as some people might call them these days.

是的，它大约在20年前出版。 但是，这本书仍然提供了许多与程序员或软件工程师非常相关的见解，就像有些人如今所说的那样。

You might have heard about this book before and questioned what actually it's actually about. Well, today I will share with you some of the interesting things I learned while reading the book.

您可能以前已经听说过这本书，并质疑它的真正含义。 好吧，今天我将与您分享我在阅读本书时学到的一些有趣的东西。

成为一名程序员不仅仅是技术技能 (There is more to being a programmer than technical skills)

When reading the book's title, you might expect it to give out a lot of technical lessons. But in fact it does not. What makes this book still relevant 20 years later is that it teaches us that being a programmer is not all about technical strength. And we often overlook this fact.

阅读本书的标题时，您可能希望它会提供很多技术课程。 但实际上并非如此。 使本书在20年后仍然有意义的原因是，它告诉我们，成为程序员并不仅仅涉及技术实力。 而且我们经常忽略这一事实。

The book teaches us that there is more to programming than technical abilities.

这本书告诉我们，编程不仅仅是技术能力。

猫吃了我的源代码 (The cat ate my source code)

This is the first chapter in the book and is a very interesting concept.

这是本书的第一章，是一个非常有趣的概念。

Remember that one day when we didn’t finish our homework and we said that the dog ate it? (Actually I don’t remember it, because I always finish my homework 😜)

还记得有一天我们没有完成作业，我们说那只狗吃了吗？ (实际上我不记得了，因为我总是完成作业home)

What that - and this chapter - teaches us is actually responsibility. When you have responsibility for something, you should be prepared to be held accountable for it.

那以及本章告诉我们的实际上是责任。 当您对某事负有责任时，您应该准备对此负责。

If you make mistakes and cannot fulfill those responsibilities, you have to make up for it and find a solution. Don’t make up excuses and play the finger pointing game. You can’t just go into work and tell everybody that a cat just ate your source code.

如果您犯了错误而不能履行这些职责，则必须弥补并找到解决方案。 不要找借口玩指责游戏。 您不能仅仅上班告诉所有人猫都吃了您的源代码 。

Provide options, don’t make lame excuses.

提供选择，不要做la脚的借口。

都是关于窗户破了 (It’s all about a broken window)

In the book, there is a story about an urban area that became very messy and run-down, all because of one broken window.

在这本书中，有一个关于城市地区的故事，这个城市变得非常混乱和破败，这都是由于一个破窗户造成的。

This is much like our code: when we see some dirty code (which we can see like it's a broken window), we might start to think that it’s okay to let the code be dirty. That it’s okay to just go back later, which most of the time we never do.

这很像我们的代码：当我们看到一些肮脏的代码(我们可以看到它是一个坏的窗口)时，我们可能开始认为让代码变得肮脏是可以的。 以后再回去是可以的，大多数时候我们从不这样做。

Try not to leave “broken windows” unrepaired. When you find that kind of code, fix it up as soon as possible. When you continue to think that no one has the time to fix that broken code, you might as well go and buy yourself a dumpster just to keep your code.

尽量不要让“破损的窗户”得到修复。 找到此类代码后，请尽快对其进行修复。 当您继续认为没有人有时间修复该损坏的代码时，您不妨去买一个垃圾箱只是为了保留您的代码。

What this chapter discusses is actually simple: it’s about initiative and taking care of your stuff.

本章讨论的内容实际上很简单：它涉及主动性和照顾您的东西 。

主动，成为催化剂 (Take the initiative, be the catalyst)

There also might be times when you know that either something is all good or something needs to actually get done. It comes to your mind and you just think to yourself that it’s the right thing to do.

有时候，您可能知道有些事情是一件好事，或者实际上需要完成某件事。 它浮现在您的脑海，您只是想自己，这是正确的选择。

If you just keep thinking, nothing will happen. Or if you just ask for it to be on the project timeline, you might be met with huge feature development requests and technical debt. So it ends up in another year in discussion.

如果您一直在思考，什么都不会发生。 或者，如果您只是要求将其显示在项目时间表上，则可能会遇到巨大的功能开发要求和技术债务。 因此，讨论结束了一年。

It’s time to step up your game. Work out what you can, don’t overdo it, but also make it reasonable. Once you got your complete idea, show it to people. They might think that “Yeah, it might be better if we had that.”

现在该加强您的游戏了。 尽你所能，不要做得过大，但还要使其合理 。 一旦有了完整的想法，就向人们展示。 他们可能会认为“是的，如果我们这样做的话可能会更好。”

Show them a glimpse of the future and people will rally around you. Be a catalyst for change.

向他们展示未来，人们会聚集在您周围。 成为变革的催化剂 。

更重要的是，这本书还教会了我们一些程序员常会忘记的基本基础知识。 (More so, this book also teaches us about basic fundamentals that we often forget as programmers.)

Sometimes, the more we delve deeper and deeper into our work, the more often we forgot about the basic things that we learned a long time ago.

有时，我们对工作的研究越深入，就越容易忘记很久以前学到的基本知识。

Busy chasing features and new tech improvements, we often forget that there are actually a lot more things that we need to pay attention to beforehand before going deeper.

忙于追逐功能和新技术改进，我们常常会忘记，在深入研究之前，实际上还有很多事情需要我们事先注意。

干净的代码 (Clean code)

One of the most basic principles we often forget about is clean code. As features are piling up more and more, the codebase become fatter and technical debt rises.

我们经常忘记的最基本的原则之一是干净的代码。 随着功能的堆积越来越多，代码库变得越来越胖，技术债务也随之增加。

But we must always remember to keep our code consistent and clean every time we write it.

但是我们必须始终记住，每次编写代码时都要保持代码的一致性和整洁性。

One of the things that is mentioned in the book is the DRY principle (Don’t Repeat Yourself). It is related to code reusability. Duplication is evil and that's the truth. Duplicate code will make maintaining your code very hard, and it can cause confusion when you need to change a feature or fix a bug.

本书中提到的一件事是DRY原则(不要重复自己)。 它与代码可重用性有关。 复制是邪恶的，那是事实。 重复的代码会使维护代码变得非常困难，并且在您需要更改功能或修复错误时会引起混乱。

Remember that time when you needed to fix some of your code? And you realized that there was code that was very similar to the bit you just changed? So then you gotta change that part too, and another too, and then maybe this bit too…you get the picture.

还记得那个时候需要修复一些代码的时候吗？ 您是否意识到有些代码与您刚刚更改的代码非常相似？ 因此，您也必须更改该部分，也需要更改另一部分，然后也许也要更改一下……您就知道了。

找到正确的工具 (Find the correct tools)

Like a woodcutter, finding the correct and proper tools is very important. Before a woodcutter starts cutting trees. they have to decide - do they need a chainsaw? Or is an axe good enough? Or maybe there is a brand new lightsaber they can use. But using kitchen knife might take some time to cut down a tree.

就像a夫一样，找到正确和适当的工具非常重要。 a夫开始砍树之前。 他们必须决定-他们需要电锯吗？ 还是斧头足够好？ 也许他们可以使用一种全新的光剑。 但是使用菜刀可能需要一些时间才能砍伐树木。

It's similar for programmers: this book teaches us that it’s very important for us to find the proper tools before we start working (like a good code editor). We shouldn't jump right to coding.

对于程序员来说，情况是相似的：这本书告诉我们，对于我们来说，在开始工作之前找到合适的工具非常重要(就像一个好的代码编辑器一样)。 我们不应该直接进行编码。

For example, it’s actually possible to code using Windows notepad and compile it using the console. But is it the right tool for you? Try to find the best editor that you are most comfortable using. Learning and mastering it and it will increase your productivity by several times.

例如，实际上可以使用Windows记事本进行编码，然后使用控制台进行编译。 但这是适合您的工具吗？ 尝试找到最舒适的最佳编辑器。 学习和掌握它，它将使您的生产率提高数倍。

There are several editors mentioned in the book, such as Emacs or Vim. But nowadays you can find more modern code editors such as Visual Studio Code. Find one that suites you. It's like your taste in coffee – some people prefer lattes and others prefer cappuccinos.

书中提到了几种编辑器，例如Emacs或Vim。 但是如今，您可以找到更多现代代码编辑器，例如Visual Studio Code。 找到适合您的一个。 就像您在咖啡中的口味一样-有些人喜欢拿铁咖啡，有些人喜欢卡布奇诺咖啡。

不要巧合编程 (Don’t program by coincidence)

This is one very important point noted in the book. In all of our programming journeys, there have likely been times when we were just coding blindly and unexpectedly… and somehow it just worked.

这是书中提到的非常重要的一点。 在我们所有的编程旅程中，可能有时候我们只是盲目地和意外地进行编码……并且某种程度上它才起作用。

You probably weren't sure what you were actually doing, so you kept adding more and more code and it still worked. That is, until one day when there was an issue and you tried to remove some chunk of code and it completely broke everything. And you were not sure which piece caused it.

您可能不确定自己到底在做什么，所以您不断添加越来越多的代码，但它仍然有效。 也就是说，直到有问题的一天，您尝试删除一些代码，它完全破坏了所有内容。 而且您不确定是哪块引起的。

Relying on unknowns is very dangerous. When you are not sure what the code is supposed to do, try to simplify it and make sure that the code is reliable in its own right, not just reliable by chance.

依靠未知是非常危险的。 当您不确定代码应该做什么时，请尝试对其进行简化，并确保代码本身是可靠的，而不仅仅是偶然的可靠。

Rely only on things you are sure of. Don’t program by coincidence.

仅依靠您确定的事情。 不要巧合编程。

单元测试 (Unit test)

Testing is a hot topic these days. And yes, it was also an important topic 20 years ago (and it will always be).

最近，测试是一个热门话题。 是的，这也是20年前的一个重要主题(并且将一直如此)。

But sometimes people forget about unit tests these days. They might have just finished their code and they assumed everything was okay...until the code ended up broken in production because of edge cases.

但是有时候，人们如今忘记了单元测试。 他们可能刚刚完成了代码，并认为一切正常……直到由于边缘情况导致代码在生产中被破坏为止。

In order to maintain stability and refactor safely, we always need to keep our code protected by writing unit tests. And it’s never enough if your tests only cover the happy path. Perform ruthless testing on your code, and remember that your code is not finished until you've covered every available test.

为了保持稳定性和安全地重构，我们始终需要通过编写单元测试来保护代码。 如果您的测试仅涵盖幸福的道路，那将是远远不够的。 对您的代码执行无情的测试，并记住您的代码只有在涵盖所有可用测试后才能完成。

Unit testing will help you be confident that your piece of code is truly done.

单元测试将帮助您确信您的代码部分已经完成。

取得所有权 (Taking ownership)

There's one last thing I want to talk about. As we know, programmers like to leave ‘legacies’ behind, in the form of code. And yes, most of the time it’s bad.

我想谈的最后一件事。 众所周知，程序员喜欢以代码形式留下“遗留”。 是的，在大多数情况下都是不好的。

Being a programmer, we ought to take pride in our own work. We should be proud of the responsibility we've been given and the piece of code we have been working on.

作为程序员，我们应该为自己的工作感到自豪。 我们应该为我们所承担的责任和我们一直在努力的代码感到自豪。

When we are finally able to take pride in our code and own it, we will be able to leave a good legacy behind. And people will see our code as a signature. When they see our code, they'll know that it will be solid and well-written, by a professional.

当我们最终能够以自己的代码为荣并拥有它时，我们将可以留下良好的遗产。 人们会把我们的代码视为签名。 当他们看到我们的代码时，就会知道该代码将是可靠且由专业人员编写的。

整理起来 (Finishing up)

There are even more topics covered in this book that I haven’t discussed here, such as Requirements and Teamwork. If you are interested in exploring these topics, you should try to find and read the book!

本书中涵盖了更多我尚未讨论的主题，例如需求和团队合作。 如果您有兴趣探索这些主题，则应尝试查找并阅读本书！

Just a note, however: as much as I liked the book, some stuff just didn't seem relate-able, looking at how old the book is (20 years old). It talks about old languages such as Prolog, and speaks about OOP like it’s a really new concept - so these oddities just don't seem right.

不过，请注意：尽管我喜欢这本书，但看看这本书有多老(20岁)，似乎有些东西似乎并不相关。 它谈论诸如Prolog之类的旧语言，并像一个真正的新概念一样谈论OOP-因此这些奇怪之处似乎并不正确。

But it can’t be blamed since it's already a couple decades old.

但是不能怪它，因为它已经有几十年了。

Aside from that most of the stuff covered in the book is still quite relevant to the current age of Programming, like those topics I covered above.

除此之外，本书涵盖的大多数内容仍与当前的编程时代密切相关，例如我上面提到的那些主题。

If I was trying to sum everything up in this book, I'd say it basically covers everything I have ever read on the Web about becoming a better engineer.

如果我想总结本书中的所有内容，我会说它基本上涵盖了我在网络上阅读的有关成为一名更好的工程师的所有内容 。

Thanks for reading my article about The Pragmatic Programmer! Hopefully it has given you some insight into your journey as a Programmer or Software Engineer. And grab yourself a copy of the book if you are interested in learning more.

感谢您阅读我有关实用程序员的文章！ 希望它使您对作为程序员或软件工程师的旅程有所了解。 如果您有兴趣学习更多，请自己拿本书的副本。

P.S. I wrote this article on my own, without any means of advertising or marketing from a third party. The cover photo was taken from amazon's site.

PS：我自己写这篇文章，没有任何来自第三方的广告或营销手段。 封面照片是从亚马逊网站上拍摄的 。

翻译自: https://www.freecodecamp.org/news/thought-on-the-pragmatic-programmer/

程序员实用小程序