程序員應(yīng)該知道的10大編程格言
作者 | BarryWang
每個程序員都該知道的10大編程格言（Kevin Pang）：
編程格言1：無風(fēng)不起浪 (There is no smoke without fire）
編程格言2：預(yù)防為主，治療為輔(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：欲速則不達(dá)（Great haste makes great waste）
編程格言6：三思而后行( Look before you leap。Think first, Program later)
編程格言7：當(dāng)你僅有的一把工具是錘子，所有的東西看起來都像是釘子（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：能力越大責(zé)任越大（With great power comes great responsibility）
1.無風(fēng)不起浪(There is no smoke without fire)：
設(shè)計糟糕的代碼通常表現(xiàn)以下 的一些現(xiàn)象：
巨大的類或者方法
大區(qū)塊注釋的代碼
重復(fù)的邏輯
過多 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. 預(yù)防為主，治療為輔(An ounce of prevention is worth a pound of cure）磨刀不誤砍柴工
程序員經(jīng)常錯誤地認(rèn)為高效率編碼就是快速編碼，很多程序員不經(jīng)思索和設(shè)計就直接編寫代碼。很不幸地是，這種 Leeroy Jenkins魯莽做法將會編寫出槽糕的代碼，結(jié)果導(dǎo)致需要不斷維護(hù)和修改代碼，甚至有可能這些槽糕的代碼將會被替換掉。因此，編碼效率不僅以編碼的時間，而且還有調(diào)試代碼的時間。
撿了芝麻丟了西瓜。磨刀不誤砍柴工。
原文：
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)不要過度依賴某個人
一個軟件項目開發(fā)團(tuán)隊的公共要素（bus factor）是指那些會影響整個項目進(jìn)程的核心開發(fā)人員的總數(shù)。比如某人被車撞了或某人生孩子或某人跳槽了，項目可能就會無序，甚至?xí)R置。
換言之，如果團(tuán)隊的關(guān)鍵成員突然流失，項目將會怎么辦？業(yè)務(wù)仍繼續(xù)還是停止呢？
因此我們在項目開發(fā)中， 每位開發(fā)人員最好能最熟悉軟件系統(tǒng)非自己所擅長的部分。
原文:
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)
《注重實效的程序員》一書中有這樣一段話解釋“破窗理論”：
不要留著“破窗戶”（不良的設(shè)計、錯誤的決策或者糟糕的代碼）不修。發(fā)現(xiàn)一個就修一個。
如果沒有足夠的時間進(jìn)行適當(dāng)?shù)男迯?fù)，就先把它保留起來?；蛟S你可 以把出問題的代碼放到注釋中，或是顯示“未實現(xiàn)”消息，或用虛擬數(shù)據(jù)加以替代。采取一些措施，防止進(jìn)一步的惡化。這表明局勢尚在掌控之中。
我們見過整潔良好的系統(tǒng)在出現(xiàn)“破窗”之后立馬崩潰。雖然促使軟件崩潰的原因還有其他因素（我們將在其他地方接觸到），但（對“破窗”）置之不理，肯定會更快地加速系統(tǒng)崩潰。
簡而言之，好的代碼會促生好的代碼，糟糕的代碼也會促生糟糕的代碼。別低估了習(xí)慣的力量。沒人想去整理糟糕的代碼，同樣沒人想把完美的代碼弄得一團(tuán)糟。寫好你的代碼，它才更可能經(jīng)得住時間的考驗。
原文：
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 .欲速則不達(dá)（Great haste makes great waste)
經(jīng)理、客戶和程序員正日益變得急躁。一切都需要做的事，都需要馬上就做好。正因如此，快速修復(fù)問題變得非常急迫。
沒時間對一個新功能進(jìn)行適當(dāng)?shù)膯卧獪y試？好吧，你可以先完成一次測試運行，然后你就可以隨時回來繼續(xù)測試它。
當(dāng)訪問Y屬性時，會不會碰到奇怪的對象引用錯誤？無論怎樣，把代碼放到try/catch語句塊中。我們要釣到大魚啦！
是不是似曾相識呢？這是因為我們在以前已經(jīng)都做到了。并且在某些情況下、它是無可非議的。畢竟，我們有最后期限，還得滿足客戶和經(jīng)理。但不要過于頻繁操 作，否則你會發(fā)現(xiàn)你的代碼不穩(wěn)定，有很多熱修復(fù)、邏輯重復(fù)、未測試的方案和錯誤處理。最后，你要么是把事情草草做完，要么是把事情好好做完。
原文：
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)
“敏捷開發(fā)”這個詞最近被頻繁濫用，經(jīng)常被程序員用來掩飾他們在軟件開發(fā)過程中的糟糕規(guī)劃/設(shè)計階段。我們是設(shè)計者，看到產(chǎn)品朝正當(dāng)方向有實質(zhì)進(jìn)展，我們理應(yīng)高興。但意外的是，UML圖和用例分析似乎并不能滿足我們的愿望。所以，在不知自己做什么的情況下或者不知自己身處何處時，我們開發(fā)人員經(jīng)常就稀里糊涂地寫代碼了。
這就好比你要去吃飯，但你根本沒有想好去哪里吃。因為你太餓了，所以你迫不及待地找個餐館，定個桌位。然后你上車開車后沿途在想（找地方吃飯）。只是，這樣會耗費更多的時間，因為你要過較多的U型彎道，還在餐館前停車，也許最后因等待時間過長而不吃了。確切地說，你最后應(yīng)該能找到地方吃飯，但你可能 吃的飯并不是你想吃的，并且這樣花費的時間，可能比你直接在想去的餐館訂餐所花的時間更長。
原文：
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.當(dāng)你僅有的一把工具是錘子，所有的東西看起來都像是釘子（When the only tool you have is a hammer, everything looks like a nail）
看見了吧？我早就說過動態(tài)記錄在這個項目中很有效
程序員有一種傾向，當(dāng)一談到他們工具時，其視野就變狹窄了。一旦某種方法在我們的一個項目上“行得通”，我們就會在接下來所有的項目上都用到它。學(xué)習(xí)新東 西仿佛是一種煎熬，有時候甚至?xí)纳癫欢ā氖贾两K都在想“如果我用之前的方法做、這個就不會這么麻煩了”。
一定要摒棄這種想法，按我們所知道的去做，即使那不是最完美的解決方法。
堅持自己所知很簡單，不過從長遠(yuǎn)的角度講，選擇一個適合這項工作的工具要容易得多。否則，就會與你的職業(yè)生涯格格不入。
原文：
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）
我什么都沒看見！沒看見！
"破窗理論"與"變成慣性理論"有著宏觀的聯(lián)系。
編程社區(qū)就好像一個現(xiàn)實社區(qū)。每個作品都是一個開發(fā)者的縮影。糟糕的代碼發(fā)布的越多，就越容易反映現(xiàn)狀。如果你不去努力編寫優(yōu)秀、整潔和穩(wěn)定的代碼，那你每天都將和糟糕的代碼相伴了。
同樣地，如果你看到別人寫出了糟糕的代碼，你就要跟這個人提出來。注意，這時候機(jī)智就應(yīng)該用上場了。一般情況下，程序員都愿意承認(rèn)他們在軟件開發(fā)中還是有不懂的地方，并且會感謝你的好意。互相幫助對大家都有利，而對問題視而不見，只會使問題一直存在。
原文：
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）
如果可以討論系統(tǒng)架構(gòu)和重構(gòu)，那么就差找個時間把事情做完。為了使正常運作的東西更加簡潔而做改動，權(quán)衡改動的利弊很重要。當(dāng)然了，簡潔是一個理想目標(biāo)， 但總會有可以通過重構(gòu)改進(jìn)的代碼。在編程世界中，為了代碼不過時，會頻繁簡單改動代碼。但有時候你又必須保證代碼對客戶有價值。那么，你面臨一個簡單窘 境：你不能一石二鳥。你在重構(gòu)舊代碼上所發(fā)時間越多，你編寫新代碼的時間就越少。在及時改進(jìn)代碼和維護(hù)程序之間，也需要找到平衡點。
原文：
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.能力越大責(zé)任越大（With great power comes great responsibility）
毫無疑問，軟件已成為我們生活中一個既基本又重要的一部分。正因如此，開發(fā)優(yōu)秀軟件格外重要。乒乓球游戲中的Bug是一回事，航天飛機(jī)導(dǎo)向系統(tǒng)或者航空交通管制系統(tǒng)中的Bug是另外一回事。Slashdot曾發(fā)表一文，講述了單單Google News的一個小失誤使一家公司股票蒸發(fā)11.4億美元。其他例子參見《軟件Bug引發(fā)的十次嚴(yán)重后果》。這些例子便說明了我們正行使著多大的權(quán)利。你今天寫的代碼，無論你是否有意，說不定有朝一日在重要的應(yīng)用程序中派上用場，這想想都令人害怕。編寫正確合格的代碼吧！
原文：
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!
每天一點成長，歡迎指正！
往期推薦
喜歡的這里報道
↘↘↘