amazon的參考
程序員的職業素養/圖靈程序設計叢書
作者：(美)馬丁|譯者:章顯洲//余晟
出版社：人民郵電
ISBN：9787115291578
出版日期：2012/09/01
頁數：178
人民幣：RMB 49 元
P.8(原文P.15)
這一策略有時也叫"無情重構"，我把它叫作"童子軍訓練守則"：對每個模塊，每檢入一次代碼，就要讓它比上次檢出時變得更為簡潔。每次讀代碼，都別忘了進行點滴的改善。
This philosophy is sometimes called merciless refactoring. I call it “the Boy Scout rule”: Always check in a module cleaner than when you checked it out. Always make some random act of kindness to the code whenever you see it.
P.8(原文P.16)
職業發展是你自已的事。雇主沒有義務確保你在職場能夠立於不敗之地，也沒義務培訓你，送你參加各種會議或給你買各種書籍充電。這些都是你自已的事。將自已的職業發展寄希望於雇主的軟件開發人員將會很慘。
Your career is your responsibility. It is not your employer’s responsibility to make sure you are marketable. It is not your employer’s responsibility to train you, or to send you to conferences, or to buy you books. These things are your responsibility. Woe to the software developer who entrusts his career to his employer.
P.9(原文P.16)
另外，雇主也沒義務給你留學習時間。有些雇主會這麼做，有些甚至要求你這麼做。但是還是那句話，他們待你不薄，你應該適當表示感激。因為這些優待不是你理所當然就該享有的。
It is also not your employer’s responsibility to give you the time you need to learn. Some employers may provide that time. Some employers may even demand that you take the time. But again, they are doing you a favor, and you should be appropriately appreciative. Such favors are not something you should expect.
P.10-11(原文P.18-19)
別忘了桑塔納的咀咒："不能銘記過去的人，注定重蹈先人的覆轍"。
下面列出了每個專業軟件開發人員必須精通的事項：
1.設計模式。必須能描述COF書中的全部24種模式，同時還有POSA書中的多數模式的實戰經驗。
2.設計原則。必須了解SOLID原則，而且要深刻理解組件設計原則。
3.方法。必須理解XP、Scrum、精益、看板、瀑布、結構化分析及結構化設計等。
4.實踐。必須掌握測試驅動開發、面向對向設計、結構化編程、持續集成和結對編程。
5.工作。必須了解如何使用UML圖、DFD圖、結構圖、Petri網絡圖、狀態遷移圖表、流程圖和決策表。
Remember Santayana’s curse: “Those who cannot remember the past are condemned to repeat it.”
Here is a minimal list of the things that every software professional should be conversant with:
1. Design patterns. You ought to be able to describe all 24 patterns in the GOF book and have a working knowledge of many of the patterns in the POSA books.
2. Design principles. You should know the SOLID principles and have a good understanding of the component principles.
3. Methods. You should understand XP, Scrum, Lean, Kanban, Waterfall, Structured Analysis, and Structured Design.
4. Disciplines. You should practice TDD, Object-Oriented design, Structured Programming, Continuous Integration, and Pair Programming.
5. Artifacts: You should know how to use: UML, DFDs, Structure Charts, Petri Nets, State Transition Diagrams and Tables, flow charts, and decision tables.
P.11(原文P.19)
業精於勤。真正的專業人士往往勤學苦幹，以求得自身技能的純熟精煉。只完成日常工作是不足以稱為練習的，那只能算是種執行性質的操作，而不是練習。練習，指的是在日常工作之餘專門練習技能，以期自我提升。
Professionals practice. True professionals work hard to keep their skills sharp and ready. It is not enough to simply do your daily job and call that practice. Doing your daily job is performance, not practice. Practice is when you specifically exercise your skills outside of the performance of your job for the sole purpose of refining and enhancing those skills.
P.12(原文P.20)
簡單說，我常用的一個技巧是重覆做一些簡單的練習，如"保齡球游戲"或"素數篩選"，我把這些練習叫作"卡塔"(kata)。卡塔有很多類型。
So what could software developers do to practice? There’s a whole chapter in this book dedicated to different practice techniques, so I won’t go into much detail here. One technique I use frequently is the repetition of simple exercises such as the Bowling Game or Prime Factors. I call these exercises kata. There are many such kata to choose from.
卡塔的形式是一個有待解決的簡單編程問題，比如編寫計算拆分某個整數的素數因子等。做卡塔的目的不是找出解決方法(你已經知道方法了)，而是訓練你的手指和大腦。
A kata usually comes in the form of a simple programming problem to solve, such as writing the function that calculates the prime factors of an integer. The point of doing the kata is not to figure out how to solve the problem; you know how to do that already. The point of the kata is to train your fingers and your brain.
P.13(原文P.21)
雇主的問題就是你的問題。你必須弄明白這些問題，並尋求最佳解決方案。每次開發系統，都應站在雇主的角度來思考，確保開發的功能真正能滿足雇主的需要。
Your employer’s problems are your problems. You need to understand what those problems are and work toward the best solutions. As you develop a system you need to put yourself in your employer’s shoes and make sure that the features you are developing are really going to address your employer’s needs.
P.15(原文P.23)
能就是能，不能就是不能，不要說試試看。(尤達大師)
“Do; or do not. There is no trying.”— Yoda
P.20(原文P.29)
我的經驗是，"為什麼"遠不如"事實"重要。事實是，"登錄頁面"還需要兩個星期才能完成。而為什麼需要兩個星期，則只是個細節。
Perhaps you think that Paula should have explained why the login page was going to take so much longer. My experience is that the why is a lot less important than the fact. That fact is that the login page will require two weeks. Why it will take two weeks is just a detail.
P.20(原文P.29)
最要說"不"的是那些高風險的關鍵時刻。愈是關鍵時刻，"不"字就愈具價值。
The most important time to say no is when the stakes are highest. The higher the stakes, the more valuable no becomes.
P.21(原文P.)
Don:炒了我也沒法改變進度預估, Charles.
Don: “ Firing me isn’t going to change the estimate, Charles.”
P.39(原文P.47)
口頭上說，心裡認真，付諸行動。
做出承諾，包含三個步驟：
1.口頭上說自已將會去做。
2.心裡認真對待做出的承諾。
3.真正付諸行動。
Say. Mean. Do.
There are three parts to making a commitment.
1. You say you’ll do it.
2. You mean it.
3. You actually do it.
P.40(原文P.48-49)
以下示例中包含的幾個用詞和短語，會透露"缺乏承諾"的蛛絲馬跡，要注意搜尋。
1.需要/應當。"我們要把這活做完"。"我需要減肥"。"有人應當負責去推動這件事"。
2.希望/但願。"希望明天我能完成這個任務"。"希望改天我們能再見面"。"但願我有時間做這件事"。"但願電腦能快點"。
3.讓我們(而不是"讓我")。"讓我們回頭再見"。"讓我們把這事做完"。
你會發現，我們有極力逃避承擔責任的傾向。
Here are some examples of words and phrases to look for that are telltale signs of noncommitment:
1. Need\should. “We need to get this done.” “I need to lose weight.” “Someone should make that happen.”
2. Hope\wish. “I hope to get this done by tomorrow.” “I hope we can meet again some day.” “I wish I had time for that.” “I wish this computer was faster.”
3. Let’s. (not followed by “I . . .”) “Let’s meet sometime.” “Let’s finish this thing.”
As you start to look for these words you’ll see that you start spotting them almost everywhere around you, and even in things you say to others.
You’ll find we tend to be very busy not taking responsibility for things.
P.41(原文P.49)
這句話的關鍵在哪裡？你對自已將會做某件事做了清晰的事實陳述，而且還明確說明了完成期限。那不是指別人，而是說的自已。你談的是自已會去做的一項行動，而且，你不是可能去做，或是可能做到，而是會做到。
What’s important about this sentence? You’re stating a fact about something YOU will do with a clear end time. You’re not talking about anyone else but yourself. You’re talking about an action that you will take. You won’t “possibly” take it, or “might get to it”; you will achieve it.
P.42-43(原文P.)
這樣的事情時有發生。有些事情先前你可能沒預料到，這很現實。但如果你仍然希望自已能夠不負眾望，那就趕緊去調整別人對你的預期，愈快愈好。
如果你無法兌現承諾，那麼最重要的就是盡早向你的承諾對象發出預警，愈快愈好，愈早愈好。
你愈早向各利益相關方發出預警信號，整個團隊就愈有可能抓住機會，中止並重新評估當前的活動，並決定是否採取些措施或做出些改變(比如調整優先級等)。這麼一來，你仍有可能達成之前的承諾，用另一個承諾來代替先前的承諾。
It wouldn’t work because sometimes I just won’t make it.
That happens. Something unexpected might happen, and that’s life. But you still want to live up to expectations. In that case, it’s time to change the expectations, as soon as possible.
If you can’t make your commitment, the most important thing is to raise a red flag as soon as possible to whoever you committed to.
The earlier you raise the flag to all stakeholders, the more likely there will be time for the team to stop, reassess the current actions being taken, and decide if something can be done or changed (in terms of priorities, for example). By doing this, your commitment can still be fulfilled, or you can change to a different commitment.
P.43(原文P.52)
在此，有一點相當重要：如果你不盡早告訴他人可能的問題，就錯失了讓他們幫助你達成目標、兌現承諾的機會。
One important point here is: If you don’t tell anyone about the potential problem as soon as possible, you’re not giving anyone a chance to help you follow through on your commitment.
P.46(原文P.56)
專業人士對自已的能力極限了如指掌。他們十分清楚自已還能保持效率加班多長時間，也非常明白要付出的代價。
Professionals know their limits. They know how much overtime they can effectively apply, and they know what the cost will be.
P.47(原文P.56)
專業人士不需要對所有請求都回答"是"。不過，他們應該努力尋找創新的方法，盡可能做到有求必應。掌專業人士給出肯定回答時，他們會使用承諾用語，以確保各方能明白無誤地理解承諾內容。
Professionals are not required to say yes to everything that is asked of them. However, they should work hard to find creative ways to make “yes” possible. When professionals say yes, they use the language of commitment so that there is no doubt about what they’ve promised.
P.49(原文P.58)
在那個深夜，我忽然領悟到，盲打的全部秘訣便是"信心"。我的手指知道按鍵在哪個位置，我只需要確信自已沒有敲錯鍵即可。而我之所以有這麼充足的信心，原因之一是敲錯鍵時我自已能夠感覺得到。
At first I typed quite a few in error. By the end of the evening I was typing them all with near perfection. I realized, during that long night, that typing blind is all about confidence. My fingers knew where the keys were, I just had to gain the confidence that I wasn’t making a mistake. One of the things that helped with that confidence is that I could feel when I was making an error. By the end of the evening, if I made a mistake, I knew it almost instantly and simply ejected the card without looking at it.
具備"出錯感知能力"，說明你已經能夠非常迅速地獲得反饋，能夠更為快速地從錯誤中學習。
Being able to sense your errors is really important. Not just in typing, but in everything. Having error-sense means that you very rapidly close the feedback loop and learn from your errors all the more quickly. I’ve studied, and mastered, several disciplines since that day on the 029. I’ve found that in each case that the key to mastery is confidence and error-sense.
本章將介紹我個人關於編碼的一套規則與原則。這些規則與原則並非關於代碼本身，而是描述我在編理時的行為、情緒與態度。它們所描述的是我在編碼時的心理、精神和情緒，而這些是"信心"和"出錯感知"的源泉。
This chapter describes my personal set of rules and principles for coding. These rules and principles are not about my code itself; they are about my behavior, mood, and attitude while writing code. They describe my own mental, moral, and emotional context for writing code. These are the roots of my confidence and error-sense.
P.50(原文P.59)
如果感到疲勞或者心煩意亂，千萬不要編碼。強而為之，最終只能再回頭返工。相反，要找到一種方法來消除干擾，讓心緒平靜下來。
If you are tired or distracted, do not code. You’ll only wind up redoing what you did. Instead, find a way to eliminate the distractions and settle your mind.
P.51(原文P.)
這個故事給我們的教訓是：疲勞的時候，千萬不要寫代碼。奉獻精神和職業素養，更多意義上指要遵循紀律原則而非成為長時間工作的工作狂。
The moral of this story is: Don’t write code when you are tired. Dedication and professionalism are more about discipline than hours. Make sure that your sleep, health, and lifestyle are tuned so that you can put in eight good hours per day.
P.61(原文P.71)
要根據目標定期衡量進度，使用三個考慮到多種因素的期限：樂觀預估、標稱預估、悲觀預估。盡量嚴守這三個時間點。不要把預估和期望混淆在一起！
The trick to managing lateness is early detection and transparency. The worst case scenario occurs when you continue to tell everyone, up to the very end, that you will be on time—and then let them all down. Don’t do this. Instead, regularly measure your progress against your goal, and come up with three fact-based end dates: best case, nominal case, and worst case. Be as honest as you can about all three dates. Do not incorporate hope into your estimates! Present all three numbers to your team and stakeholders. Update these numbers daily.
P.63(原文P.72)
因此，不應該采用額外加班加點工作的方案，除非以下三個條件都能滿足：
1.你個人能擠出這些時間；2.短期加班，最多加班兩週；3.你的老板要有後備預案，以防萬一加班措施失敗了。
最後一條至為關鍵。如果老板無法向你清楚說明加班方案的後備預案，那麼你就不該同意接受加班方案。
Therefore you should not agree to work overtime unless (1) you can personally afford it, (2) it is short term, two weeks or less, and (3) your boss has a fall-back plan in case the overtime effort fails.
That last criterion is a deal breaker. If your boss cannot articulate to you what he’s going to do if the overtime effort fails, then you should not agree to work overtime.
P.69(原文P.79-80)
1.在編好失敗單元測試之前，不要編寫任何產品代碼。
2.只要有一個單元測試失敗了，就不要再寫測試代碼；無法通過編譯也是一種失敗情況。
3.產品代碼恰好能夠讓當前失敗的單元測試成功通過即可，不要多寫。
1. You are not allowed to write any production code until you have first written a failing unit test.
2. You are not allowed to write more of a unit test than is sufficient to fail—and not compiling is failing.
3. You are not allowed to write more production code that is sufficient to pass the currently failing unit test.
P.80(原文P.90)
在武術裡，卡塔是一套設計好的、用來模擬搏門一方的招式。目標則是要逐步把整套招式練習到純熟。習武者努力訓練自已的身體來熟悉每一招，把它們連貫成流暢的套路。
In martial arts, a kata is a precise set of choreographed movements that simulates one side of a combat. The goal, which is asymptotically approached, is perfection. The artist strives to teach his body to make each movement perfectly and to assemble those movements into fluid enactment. Well-executed kata are beautiful to watch.
P.107(原文P.122)
關於會議，有兩條真理：
1.會議是必需的；
2.會議浪費了大量的時間。
There are two truths about meeting.
1. Meetings are necessary.
2. Meetings are huge time wasters.
P.107(原文P.123)
所以，如果會議沒有現實且顯著的成效，他們會主動拒絕。
Professionals are aware of the high cost of meetings. They are also aware that their own time is precious; they have code to write and schedules to meet. Therefore, they actively resist attending meetings that don’t have an immediate and significant benefit.
P.107(原文P.123)
邀請你參加會議的人並不負責管理你的時間，為時間負責的只有你。
The person inviting you to a meeting is not responsible for managing your time. Only you can do that. So when you receive a meeting invitation, don’t accept unless it is a meeting for which your participation is immediately and significantly necessary to the job you are doing now.
P.108(原文P.124)
這些年來，我學到了一條簡單規則：如果會議讓人厭煩，就離席。
Meetings don’t always go as planned. Sometimes you find yourself sitting in a meeting that you would have declined had you known more. Sometimes new topics get added, or somebody’s pet peeve dominates the discussion. Over the years I’ve developed a simple rule: When the meeting gets boring, leave.
再說一次，仔細管理自已的時間是你的責任。如果你發現參加某個會議是在浪費時間，就應當想個禮貌的辦法退出來。
Again, you have an obligation to manage your time well. If you find yourself stuck in a meeting that is not a good use of your time, you need to find a way to politely exit that meeting.
P.109(原文P.)
到場的人依次回答以下的3個問題：
1.我昨天幹了什麼？
2.我今天打算幹什麼？
3.我遇到了什麼問題？
These meetings are part of the Agile cannon. Their name comes from the factthat the participants are expected to stand while the meeting is in session. Each participant takes a turn to answer three questions:
1. What did I do yesterday?
2. What am I going to do today?
3. What’s in my way?
P.111(原文P.127)
如果問題解決了，這個選擇就是對的。如果遇到了麻煩，你可以退回來選擇另一條路。明智的做法是，選定一個時間點或設定一系列標準，來決定什麼時候放棄。
If things work out, then that path was workable. If you get into trouble, you can back out and go down the other path. It would be wise to agree on a time as well as a set of criteria to help determine when the chosen path should be abandoned.
要小心這類會議：它們的目的是發泄情緒，或者讓大家站隊。如果會議上只有一面之辭，就要避免參加。
Beware of meetings that are really just a venue to vent a disagreement and to gather support for one side or the other. And avoid those where only one of the arguers is presenting.
P.115(原文P.131)
慎重的態度和積累的經驗可以幫你避免某些死胡同，但是沒法完全避免所有的。所以你真正需要的是，在走入死胡同時可以迅速意識到，並有足夠的勇氣走回頭路。這就是所謂的坑法則(The Rule of Holes)：如果你掉進了坑里，別挖。
Prudence and experience will help you avoid certain blind alleys, but you’ll never avoid them all. So the real skill you need is to quickly realize when you are in one, and have the courage to back out. This is sometimes called The Rule of Holes: When you are in one, stop digging.
P.119(原文P.138)
問題在於，不同的人對預估有不同的看法。業務方覺得預估就是承諾。開發方認為預估就是猜測。兩者相差迥異。
The problem is that we view estimates in different ways. Business likes to view estimates as commitments. Developers like to view estimates as guesses. The difference is profound.
P.130(原文P.150)
即使有壓力，專業開發人員也會冷靜果斷。盡管壓力不斷增大，他仍然會堅守所受的訓練和紀律，他知道這些是他戰勝由最後期限和承諾所帶來的壓力感的最好方法。
The professional developer is calm and decisive under pressure. As the pressure grows he adheres to his training and disciplines, knowing that they are the best way to meet the deadlines and commitments that are pressing on him.
P.131(原文P.151)
在壓力下保持冷靜的最好方式，便是規避會導致壓力的處境。規避的方式也許無法完全減除壓力，但是可以大大降低壓力並縮短高壓力期的時間。
The best way to stay calm under pressure is to avoid the situations that cause pressure. That avoidance may not eliminate the pressure completely, but it can go a long way towards minimizing and shortening the high-pressure periods.
P.134(原文P.154)
戰勝壓力煎熬的唯一方法，便是依靠那些你已經知道切實有效的東西～你平時遵守的紀律。
Instead of looking around in a panic for something, anything, that will help you get done faster, become more deliberate and dedicated to following your chosen disciplines. If you follow TDD, then write even more tests than usual. If you are a merciless refactorer, then refactor even more. If you keep your functions small, then keep them even smaller. The only way through the pressure cooker is to rely on what you already know works—your disciplines.
P.140(原文P.163)
不正常的團隊最糟糕的症狀是，每個程序員在自已的代碼周邊築起一道高牆，拒絕讓其他程序員接觸到這些代碼。我曾在許多地方看到過，不少程序員甚至不願意讓其他程序員看見他們的代碼。這是招致災難的"最佳秘訣"。
One of the worst symptoms of a dysfunctional team is when each programmer builds a wall around his code and refuses to let other programmers touch it. I have been to places where the programmers wouldn’t even let other programmers see their code. This is a recipe for disaster.
