程序員應該知道的10大編程格言

 

每一個程序員都該知道的10大編程格言（Kevin Pang）：

編程格言1：無風不起浪 (There is no smoke without fire）

編程格言2：預防爲主，治療爲輔(An ounce of prevention is worth a pound of cure：）

編程格言3：不要把雞蛋都放在一個籃子(Don't put all your eggs in one basket)

編程格言4：種瓜得瓜,種豆得豆（As you sow,so shoul you reap）

編程格言5：欲速則不達（Great haste makes great waste）

編程格言6：三思然後行( Look before you leap。Think first, Program later)

編程格言7：當你僅有的一把工具是錘子，全部的東西看起來都像是釘子（When the only tool you have is a hammer, everything looks like a nail）

編程格言8：沉默就是贊同 （Silence is construed as approval）

編程格言9：雙鳥在林不如一鳥在手（A bird in the hand is worth two in the bush）

編程格言10：能力越大責任越大（With great power comes great responsibility）

1.無風不起浪(There is no smoke without fire)：

設計糟糕的代碼一般表現如下 的一些現象：

巨大的類或者方法

大區塊註釋的代碼

重複的邏輯

過多 if/else 層次嵌套

Poorly designed code tends to manifest itself through some common tell-tale signs. Some examples of these are:

Giant classes and/or functions

Large blocks of commented out code

Duplicated logic

Deeply nested if/else blocks

Developers often refer to these as code smells, but personally, I think the term "code smoke" or "code fumes" is more appropriate as it implies a higher sense of urgency. If you don't address the underlying problem it will come back to burn you later on.

2. 預防爲主，治療爲輔(An ounce of prevention is worth a pound of cure）磨刀不誤砍柴工

程序員常常錯誤地認爲高效率編碼就是快速編碼，不少程序員不經思索和設計就直接編寫代碼。很不幸地是，這種 Leeroy Jenkins魯莽作法將會編寫出槽糕的代碼，結果致使須要不斷維護和修改代碼，甚至有可能這些槽糕的代碼將會被替換掉。所以，編碼效率不只以編碼的時間，並且還有調試代碼的時間。

撿了芝麻丟了西瓜。磨刀不誤砍柴工。

原文：

Toyota's assembly line of the 1980s was famously efficient due to its revolutionary approach towards defect prevention. Each member of the assembly line was given the ability to halt production when they noticed a problem in their sector. The idea was that it was better to halt production and fix the problem as early on as possible than to continue producing faulty units that would be tougher and more costly to fix/replace/recall later on.

Developers often make the faulty assumption that productivity = cranking out code quickly. Many programmers dive straight into coding without a second thought towards design. Unfortunately, this Leeroy Jenkins approach towards software development tends to lead to sloppy, fragile code that will need to be constantly monitored and patched — perhaps even replaced altogether down the line. Ultimately, productivity must be measured not only in how much time is spent writing it, but also by how much time is spent debugging it. A short term gain may prove to be a long term loss if one isn't careful.

3. 不要把全部雞蛋放在一個籃子 （Don't put all your eggs in one basket)不要過分依賴某我的

一個軟件項目開發團隊的公共要素（bus factor）是指那些會影響整個項目進程的核心開發人員的總數。好比某人被車撞了或某人生孩子或某人跳槽了，項目可能就會無序，甚至會擱置。

換言之，若是團隊的關鍵成員忽然流失，項目將會怎麼辦？業務仍繼續仍是中止呢？

所以咱們在項目開發中， 每位開發人員最好能最熟悉軟件系統非本身所擅長的部分。

原文:

A software team's bus factor is defined as "the total number of key developers who would if incapacitated, as by getting hit by a bus, send the project into such disarray that it would not be able to proceed".

In other words, what happens if you suddenly lost a key member of your team? Would business continue as usual or would it grind to a halt?

Unfortunately, most software teams fall into the latter category. These are the teams that turn their programmers into "domain experts" who only deal with requests that fall into their area of expertise.. At first, this appears to be a fairly reasonable approach. It works for the automaking assembly lines, why not for software development teams? After all, it's unreasonable to expect each member of the team to be intimately familiar with each and every nuance in the application, right?

The problem is that developers cannot be easily substituted and replaced. And while the pidgeon-hole approach works fairly well when everybody is available and accounted for, it quickly falls apart when "domain experts" suddenly become unavailable due to turnover, sickness, or even freak bus accidents. It is imperative that software teams have some sort of redundancy built in. Code reviews, pair programming, and communal code go a long way to foster an environment where each developer is at least superficially familiar with parts of the system outside their comfort zone.

4.種瓜得瓜，種豆得豆 （As you sow, so shall you reap)

《注重實效的程序員》一書中有這樣一段話解釋「破窗理論」：

不要留着「破窗戶」（不良的設計、錯誤的決策或者糟糕的代碼）不修。發現一個就修一個。

若是沒有足夠的時間進行適當的修復，就先把它保留起來。或許你可 以把出問題的代碼放到註釋中，或是顯示「未實現」消息，或用虛擬數據加以替代。採起一些措施，防止進一步的惡化。這代表局勢尚在掌控之中。

咱們見過整潔良好的系統在出現「破窗」以後立馬崩潰。雖然促使軟件崩潰的緣由還有其餘因素（咱們將在其餘地方接觸到），但（對「破窗」）置之不理，確定會更快地加速系統崩潰。

簡而言之，好的代碼會促生好的代碼，糟糕的代碼也會促生糟糕的代碼。別低估了習慣的力量。沒人想去整理糟糕的代碼，一樣沒人想把完美的代碼弄得一團糟。寫好你的代碼，它才更可能經得住時間的考驗。

原文：

The Pragmatic Programmer has this to say about the Broken Window theory:

Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a "Not Implemented" message, or substitute dummy data instead. Take some action to prevent further damage and to show that you're on top of the situation.

We've seen clean, functional systems deteriorate pretty quickly once windows start breaking. There are other factors that can contribute to software rot, and we'll touch on some of them elsewhere, but neglect accelerates the rot faster than any other factor.

In short, good code begets good code and bad code begets bad code. Do not underestimate the power of inertia. No one wants to be the one who has to clean up sloppy code, but neither does anyone want to be the one that makes a mess out of beautiful code. Write it right and your code will have a far better chance at standing the test of time.

5 .欲速則不達（Great haste makes great waste)

經理、客戶和程序員正日益變得急躁。一切都須要作的事，都須要立刻就作好。正因如此，快速修復問題變得很是急迫。

沒時間對一個新功能進行適當的單元測試？好吧，你能夠先完成一次測試運行，而後你就能夠隨時回來繼續測試它。

當訪問Y屬性時，會不會碰到奇怪的對象引用錯誤？不管怎樣，把代碼放到try/catch語句塊中。咱們要釣到大魚啦！

是否是似曾相識呢？這是由於咱們在之前已經都作到了。而且在某些狀況下、它是無可非議的。畢竟，咱們有最後期限，還得知足客戶和經理。但不要過於頻繁操 做，不然你會發現你的代碼不穩定，有不少熱修復、邏輯重複、未測試的方案和錯誤處理。最後，你要麼是把事情草草作完，要麼是把事情好好作完。

原文：

Managers, clients, and programmers are getting more impatient by the day. Everything needs to be done and it needs to be done now. Because of this, the temptation to throw together hacks and quick-fixes becomes very tough to resist.

No time to properly unit test a new feature? Oh well, it works for the one test run you put it through. You can always come back to it later!

Mysterious object referencing error when you try to access property Y? Whatever, just throw a try/catch block around the code. We've got bigger fish to fry!

Sound familiar? It's because we've all done it at some point in time. And in certain instances, it is justifiable. After all, we have deadlines to meet and clients/managers to satisfy. But do it too often and you'll soon find yourself with a very unstable code base full of hotfixes, duplicated logic, untested solutions, and porous error handling. In the end, you have to strike a balance between getting things done and getting things done right.

6. 三思然後行（ Look before you leap)

「敏捷開發」這個詞最近被頻繁濫用，常常被程序員用來掩飾他們在軟件開發過程當中的糟糕規劃/設計階段。咱們是設計者，看到產品朝正當方向有實質進展，咱們理應高興。但意外的是，UML圖和用例分析彷佛並不能知足咱們的願望。因此，在不知本身作什麼的狀況下或者不知本身身處何處時，咱們開發人員常常就稀裏糊塗地寫代碼了。

這就比如你要去吃飯，但你根本沒有想好去哪裏吃。由於你太餓了，因此你火燒眉毛地找個餐館，定個桌位。而後你上車開車後沿途在想（找地方吃飯）。只是，這樣會耗費更多的時間，由於你要過較多的U型彎道，還在餐館前停車，也許最後因等待時間過長而不吃了。確切地說，你最後應該能找到地方吃飯，但你可能 吃的飯並非你想吃的，而且這樣花費的時間，可能比你直接在想去的餐館訂餐所花的時間更長。

原文：

The term "Agile Development" is used and abused frequently these days, often as a way for programmers to justify ignoring the dreaded planning/designing phase of software development. We are creators, and as such we derive pleasure from seeing actual progress made towards a finished product. Surprisingly, UML diagrams and use case analysis just don't seem to satisfy that desire. So, we developers often start off coding without any idea of what we are doing or where we are going. It's like heading out for dinner when you haven't yet decided where you want to go. You're hungry so you don't want to waste time finding a restaurant and booking a table. Instead, you just hop in your car and figure you'll think of something along the way. Only, it ends up taking you longer because you have to make a bunch of U-turns and stops at restaurants that end up having too long of a wait. True, you'll probably find your way to food eventually, but you probably didn't end up with the meal you wanted and it probably took a lot more time and hassle than it would have had you just called and booked a reservation at a restaurant you wanted to go to.

7.當你僅有的一把工具是錘子，全部的東西看起來都像是釘子（When the only tool you have is a hammer, everything looks like a nail）

看見了吧？我早就說過動態記錄在這個項目中頗有效

程序員有一種傾向，當一談到他們工具時，其視野就變狹窄了。一旦某種方法在咱們的一個項目上「行得通」，咱們就會在接下來全部的項目上都用到它。學習新東 西彷彿是一種煎熬，有時候甚至會心猿意馬。從始至終都在想「若是我用以前的方法作、這個就不會這麼麻煩了」。

必定要摒棄這種想法，按咱們所知道的去作，即便那不是最完美的解決方法。

堅持本身所知很簡單，不過從長遠的角度講，選擇一個適合這項工做的工具要容易得多。不然，就會與你的職業生涯格格不入。

原文：

See? I told you Active Record would work for this project!

Programmers have a tendency to get tunnel vision when it comes to their tools. Once something "just works" for us on one project, we tend to insist on using it for every project therafter. It can be a pain to learn something new and, at times, highly unsettling. The entire time we're thinking "it would have been easier had I just done it the old way!". Enough of these moments and we will simply go with what we know, even if it isn't a perfect fit for the task.

It's easy to stick with what you know, but in the long run it's much easier to pick the right tools for the job. Otherwise you will be fitting square pegs into round holes for the rest of your career.

8. 沉默就是贊同（Silence is construed as approval）

我什麼都沒看見！沒看見！

"破窗理論"與"變成慣性理論"有着宏觀的聯繫。

編程社區就好像一個現實社區。每一個做品都是一個開發者的縮影。糟糕的代碼發佈的越多，就越容易反映現狀。若是你不去努力編寫優秀、整潔和穩定的代碼，那你天天都將和糟糕的代碼相伴了。

一樣地，若是你看到別人寫出了糟糕的代碼，你就要跟這我的提出來。注意，這時候機智就應該用上場了。通常狀況下，程序員都願意認可他們在軟件開發中仍是有不懂的地方，而且會感謝你的好意。互相幫助對你們都有利，而對問題視而不見，只會使問題一直存在。

原文：

I see nothing! Nuh-thing!

This ties in with the theory on broken windows and programming inertia, only on a larger scale.

The programming community is just that, a community. Each programmer is a reflection on the craft. The more bad code that is released into the wild, the more it becomes the status quo. If you don't make an effort to write good, clean,SOLID code, you will find yourself having to work with it on a day-to-day basis.

Likewise, if you see poorly designed code written by someone else, you should make the effort to bring it up with the creator. I should note, however, that tact ought to be employed in such a situation. In general, programmers are willing to admit that they do not know everything there is to know about software development and will appreciate the gesture. We all benefit when we help each other out. Turning a blind eye to problems only perpetuates them.

9.雙鳥在林不如一鳥在手（A bird in the hand is worth two in the bush）

若是能夠討論系統架構和重構，那麼就差找個時間把事情作完。爲了使正常運做的東西更加簡潔而作改動，權衡改動的利弊很重要。固然了，簡潔是一個理想目標， 但總會有能夠經過重構改進的代碼。在編程世界中，爲了代碼不過期，會頻繁簡單改動代碼。但有時候你又必須保證代碼對客戶有價值。那麼，你面臨一個簡單窘 境：你不能一石二鳥。你在重構舊代碼上所發時間越多，你編寫新代碼的時間就越少。在及時改進代碼和維護程序之間，也須要找到平衡點。

原文：

There is a time and place to discuss system architecture and refactoring opportunities, and a time to just get things done. It is important to weigh the pros and cons of revamping something that already works just to make it cleaner. It's an admirable goal, of course, but there will always be code that you want to restructure. The programming world simply changes too frequently for code to not get outdated. But at some point you have to provide value to your customers. The simple fact remains: you can't do two things at once. The more time you spend refactoring old code, the less time you spend creating new code. Striking a balance is critical to enhancing as well as maintaining your application in a timely manner.

10.能力越大責任越大（With great power comes great responsibility）

毫無疑問，軟件已成爲咱們生活中一個既基本又重要的一部分。正因如此，開發優秀軟件格外重要。乒乓球遊戲中的Bug是一回事，航天飛機導向系統或者航空交通管制系統中的Bug是另一回事。Slashdot曾發表一文，講述了單單Google News的一個小失誤使一家公司股票蒸發11.4億美圓。其餘例子參見《軟件Bug引起的十次嚴重後果》。這些例子便說明了咱們正行使着多大的權利。你今天寫的代碼，不管你是否有意，說不定有朝一日在重要的應用程序中派上用場，這想一想都使人懼怕。編寫正確合格的代碼吧！

原文：

Software has undoubtedly become an integral and vital part of our lives. Because of this, practicing good software development is more crucial than ever. It's one thing to have a bug in a game of Pong, it's another to have one in the guidance system of a space shuttle or air traffic control system. Slashdot recently posted an article describing how a minor glitch in Google News singlehandedly evaporated $1.14 billion in shareholder wealth. Events such as these demonstrate how much power we wield. It's a little frightening to think that the code you write today, whether you intend it to or not, may one day be recycled and depended upon for mission-critical applications. Write accordingly.

Do you have any proverbs you feel should be added to this list? Feel free to let me know in the comments!

天天一點成長，歡迎指正！