There are three great virtues of a programmer; Laziness, Impatience and Hubris. —— Larry Wall
好的程序員有三種美德： 懶惰、急躁和傲慢。

Laziness
The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer, Also hence, this book.

Impatience
The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to. Hence, the second great virtue of a programmer.

Hubris
Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer.

懶惰：
是這樣一種品質(zhì)，它使得你花大力氣去避免消耗過多的精力。它敦促你寫出節(jié)省體力的程序，同時別人也能利用它們。為此你會寫出完善的文檔，以免別人問你太多問題。

急躁：
是這樣一種憤怒，當你發(fā)現(xiàn)計算機懶洋洋地不給出結(jié)果。于是你寫出更優(yōu)秀的代碼，能盡快真正的解決問題。至少看上去是這樣。

傲慢：
極度的自信，使你有信心寫出（或維護）別人挑不出毛病的程序。

There is no smoke without fire.
無風不起浪

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.

設(shè)計糟糕的代碼通常表現(xiàn)以下的一些現(xiàn)象：

• 巨大的類或者方法
• 大區(qū)塊注釋的代碼
• 重復的邏輯
• 過多 if/else 層次嵌套

An ounce of prevention is worth a pound of cure.
預防為主，治療為輔

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.

程序員經(jīng)常錯誤地認為高效率編碼就是快速編碼，很多程序員不經(jīng)思索和設(shè)計就直接編寫代碼。很不幸地是，這種 Leeroy Jenkins魯莽做法將會編寫出槽糕的代碼，結(jié)果導致需要不斷維護和修改代碼，甚至有可能這些槽糕的代碼將會被替換掉。因此，編碼效率不僅以編碼的時間，而且還有調(diào)試代碼的時間。

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

Don't put all your eggs in one basket.
不要把所有雞蛋放在一個籃子

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.

一個軟件項目開發(fā)團隊的公共要素（bus factor）是指那些會影響整個項目進程的核心開發(fā)人員的總數(shù)。比如某人被車撞了或某人生孩子或某人跳槽了，項目可能就會無序，甚至會擱置。
換言之，如果團隊的關(guān)鍵成員突然流失，項目將會怎么辦？業(yè)務仍繼續(xù)還是停止呢？

因此我們在項目開發(fā)中， 每位開發(fā)人員最好能最熟悉軟件系統(tǒng)非自己所擅長的部分。

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.

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

不要留著“破窗戶”（不良的設(shè)計、錯誤的決策或者糟糕的代碼）不修。發(fā)現(xiàn)一個就修一個。如果沒有足夠的時間進行適當?shù)男迯?，就先把它保留起來?；蛟S你可 以把出問題的代碼放到注釋中，或是顯示“未實現(xiàn)”消息，或用虛擬數(shù)據(jù)加以替代。采取一些措施，防止進一步的惡化。這表明局勢尚在掌控之中。

我們見過整潔良好的系統(tǒng)在出現(xiàn)“破窗”之后立馬崩潰。雖然促使軟件崩潰的原因還有其他因素（我們將在其他地方接觸到），但（對“破窗”）置之不理，肯定會更快地加速系統(tǒng)崩潰。

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

Great haste makes great waste.
欲速則不達

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.

經(jīng)理、客戶和程序員正日益變得急躁。一切都需要做的事，都需要馬上就做好。正因如此，快速修復問題變得非常急迫。

沒時間對一個新功能進行適當?shù)膯卧獪y試？好吧，你可以先完成一次測試運行，然后你就可以隨時回來繼續(xù)測試它。

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

是不是似曾相識呢？這是因為我們在以前已經(jīng)都做到了。并且在某些情況下、它是無可非議的。畢竟，我們有最后期限，還得滿足客戶和經(jīng)理。但不要過于頻繁操 作，否則你會發(fā)現(xiàn)你的代碼不穩(wěn)定，有很多熱修復、邏輯重復、未測試的方案和錯誤處理。最后，你要么是把事情草草做完，要么是把事情好好做完。

Look before you leap
三思而后行

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.

“敏捷開發(fā)”這個詞最近被頻繁濫用，經(jīng)常被程序員用來掩飾他們在軟件開發(fā)過程中的糟糕規(guī)劃/設(shè)計階段。我們是設(shè)計者，看到產(chǎn)品朝正當方向有實質(zhì)進展，我們理應高興。但意外的是，UML圖和用例分析似乎并不能滿足我們的愿望。所以，在不知自己做什么的情況下或者不知自己身處何處時，我們開發(fā)人員經(jīng)常就稀里糊涂地寫代碼了。

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

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

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.

程序員有一種傾向，當一談到他們工具時，其視野就變狹窄了。一旦某種方法在我們的一個項目上“行得通”，我們就會在接下來所有的項目上都用到它。學習新東 西仿佛是一種煎熬，有時候甚至會心神不定。從始至終都在想“如果我用之前的方法做、這個就不會這么麻煩了”。一定要摒棄這種想法，按我們所知道的去做，即使那不是最完美的解決方法。
堅持自己所知很簡單，不過從長遠的角度講，選擇一個適合這項工作的工具要容易得多。否則，就會與你的職業(yè)生涯格格不入。

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.

我什么都沒看見！沒看見！

"破窗理論"與"變成慣性理論"有著宏觀的聯(lián)系。

編程社區(qū)就好像一個現(xiàn)實社區(qū)。每個作品都是一個開發(fā)者的縮影。糟糕的代碼發(fā)布的越多，就越容易反映現(xiàn)狀。如果你不去努力編寫優(yōu)秀、整潔和穩(wěn)定的代碼，那你每天都將和糟糕的代碼相伴了。

同樣地，如果你看到別人寫出了糟糕的代碼，你就要跟這個人提出來。注意，這時候機智就應該用上場了。一般情況下，程序員都愿意承認他們在軟件開發(fā)中還是有不懂的地方，并且會感謝你的好意。互相幫助對大家都有利，而對問題視而不見，只會使問題一直存在。

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.

如果可以討論系統(tǒng)架構(gòu)和重構(gòu)，那么就差找個時間把事情做完。為了使正常運作的東西更加簡潔而做改動，權(quán)衡改動的利弊很重要。當然了，簡潔是一個理想目標， 但總會有可以通過重構(gòu)改進的代碼。在編程世界中，為了代碼不過時，會頻繁簡單改動代碼。但有時候你又必須保證代碼對客戶有價值。那么，你面臨一個簡單窘 境：你不能一石二鳥。你在重構(gòu)舊代碼上所發(fā)時間越多，你編寫新代碼的時間就越少。在及時改進代碼和維護程序之間，也需要找到平衡點。

With great power comes great responsibility
能力越大責任就越大

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.

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

Stay hungry , Stay foolish. —— Steve Jobs

喬幫主在2005年給斯坦福大學做畢業(yè)演講中提到過的他最喜歡的一句話。
原文來自《Whole Earth Catalog》

Talk is cheap. Show me the code. —— Linus Torvalds
能說算不上什么，有本事就把你的代碼給我看看。

Linux的創(chuàng)始人Linus Torvalds在2000-08-25給linux-kernel 郵件列表的一封郵件提到的

You build it, You run it. —— Werner Vogels

Amazon的CTO：Werner Vogels的名言。是相對傳統(tǒng)應用開發(fā)模式提出來的，在微服務架構(gòu)里頭特別受歡迎。

傳統(tǒng)的單體應用是基于項目模式的，且多數(shù)的項目都采用瀑布模型進行開發(fā)，開發(fā)團隊根據(jù)客戶的業(yè)務需求及功能設(shè)計，開發(fā)出軟件系統(tǒng)并交付給客戶，自此，該系統(tǒng)將由運維團隊接手，進入系統(tǒng)運維階段。

而在微服務架構(gòu)體系中，更傾向于讓開發(fā)團隊負責應用系統(tǒng)的全部生命周期，應用系統(tǒng)的開發(fā)是基于快速迭代方式來實現(xiàn)的，這是一個地地道道的產(chǎn)品研發(fā)思路，讓服務的開發(fā)者與服務的使用者（客戶）形成每日的交流反饋，來自直接客戶的反饋有助于開發(fā)者提升服務的品質(zhì)。

go big or go home —— Facebook Office Slogan
要么牛逼，要么滾蛋

Done is better than perfect. —— Facebook Office Slogan
完成比完美更好

Eating our own dog food. —— Microsoft

據(jù)說，在狗糧生產(chǎn)基地，新配制出的狗糧都是要經(jīng)過好多人品嘗并通過后才會上市的。

而在IT界，微軟公司也采用這一做法來檢測他們自己研發(fā)的軟件，他們管這叫做eat our own dog food。Dog food指軟件公司開發(fā)出新的軟件程序后，在發(fā)布之前先在公司內(nèi)部使用，即“內(nèi)部試用”，或者做名詞指“內(nèi)部試用的軟件”。

微軟公司讓“吃我們自己的狗食”這句話變得人盡皆知，這句話的意思是：每天研發(fā)工作的一部分就是使用自己正在開發(fā)的軟件。這種做法傳達的理念是，研發(fā)人員在使用自己的軟件時能夠很快發(fā)現(xiàn)漏洞或者不對的地方。

UNIX很簡單。但需要有一定天賦的人才能理解這種簡單。——Dennis Ritchie

軟件在能夠復用前必須先能用?！猂alph Johnson

優(yōu)秀的判斷力來自經(jīng)驗，但經(jīng)驗來自于錯誤的判斷。——Fred Brooks

‘理論’是你知道是這樣，但它卻不好用?！畬嵺`’是它很好用，但你不知道是為什么。程序員將理論和實踐結(jié)合到一起：既不好用，也不知道是為什么。——佚名

當你想在你的代碼中找到一個錯誤時，這很難；當你認為你的代碼是不會有錯誤時，這就更難了。——Steve McConnell 《代碼大全》

如果建筑工人蓋房子的方式跟程序員寫程序一樣，那第一只飛來的啄木鳥就將毀掉人類文明。——Gerald Weinberg

項目開發(fā)的六個階段：1. 充滿熱情 2. 醒悟 3. 痛苦 4. 找出罪魁禍首 5. 懲罰無辜 6. 褒獎閑人——佚名

優(yōu)秀的代碼是它自己最好的文檔。當你考慮要添加一個注釋時，問問自己，“如何能改進這段代碼，以讓它不需要注釋？”——Steve McConnell 《代碼大全》

我們這個世界的一個問題是，蠢人信誓旦旦，智人滿腹狐疑?！狟ertrand Russell

無論在排練中演示是如何的順利(高效)，當面對真正的現(xiàn)場觀眾時，出現(xiàn)錯誤的可能性跟在場觀看的人數(shù)成正比?！?/p>

羅馬帝國崩潰的一個主要原因是，沒有0，他們沒有有效的方法表示他們的C程序成功的終止?！猂obert Firth

C程序員永遠不會滅亡。他們只是cast成了void?！?/p>

如果debugging是一種消滅bug的過程，那編程就一定是把bug放進去的過程?！狤dsger Dijkstra

你要么要軟件質(zhì)量，要么要指針算法；兩者不可兼得?！?Bertrand Meyer)

有兩種方法能寫出沒有錯誤的程序；但只有第三種好用?！狝lan J. Perlis

用代碼行數(shù)來測評軟件開發(fā)進度，就相對于用重量來計算飛機建造進度?！葼枴どw茨

最初的90%的代碼用去了最初10%的開發(fā)時間。余下的10%的代碼用掉另外90%的開發(fā)時間?！猅om Cargill

程序員和上帝打賭要開發(fā)出更大更好——傻瓜都會用的軟件。而上帝卻總能創(chuàng)造出更大更傻的傻瓜。所以，上帝總能贏?！狝non

參考：
送給程序員：最好的編程名言
IT界的一些朗朗上口的名言
有關(guān)程序員的經(jīng)典名言都有哪些？
每個程序員都該知道的10大編程格言
quotes about coding
Programming quotes by 37Signals