程序員實用小程序

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/

程序員實用小程序