編碼整潔之道：專業程序員的行為準則(英文版)（簡體書）

忍受各種不確定性及不間斷的壓力並能夠獲取成功的程序員有一個共通特徵：他們都深度關注軟件創建實踐。他們都把軟件看做一種工藝品。他們都是專家。在“鮑勃大叔”看來“專業”的程序員不僅應該具備專業的技能，更應該具備專業的態度，這也是本書闡述的核心。專業的態度包括如何用帶著榮譽感、自尊、自豪來面對進行軟件開發，如何做好並做得整潔，如何誠實地進行溝通和估算，如何透明並坦誠地面對困難做抉擇，如何理解與專業知識相伴的責任。．

作者：（美國）羅伯物?C.?馬丁（Robert C. Martin）

羅伯特?C.?馬丁（Robert C. Martin），也就是鮑勃大叔，從1970年開始就是一個程序員了。他是全球會議上的著名發言人，他的書包括：《代碼整潔之道？（Clean Code，Prentice Hall，2009）、《敏捷軟件開發：原則、模式和實踐》（Agile Software Development：Prinoples，Patterns,and Practices，Prentice Hall，1999）和《UML Java程序員指南》（UML for Java Programmers，Prentice Hall，2003）。他是一個多產的作家，已經發表和出版了數百篇文章、論文和博客。他曾經是The C++ Report雜志的主編，也是敏捷聯盟（Agile Alliance）的第一任主席。馬丁創建并領導著Object Mentor公司，擁有許多經驗豐富的軟件開發者和經理，主要業務是幫助企業完成他們的項目。

從《編碼整潔之道:專業程序員的行為準則(英文版)》中讀者可以學到：一個真的軟件專家究竟應該如何處事？如何處理沖突，安排緊張的日程，以及與不通情理的項目經理打交道？如何讀懂編碼的工作流，并了解前人的思路上的斷點？如何面對無情的壓力并避免倦怠？如何客觀地對待新的開發范式？如何管理你的時間并且避免走入死胡同，陷入泥潭？如何培育可以讓程序員個人以及團隊茁壯成長的環境？什么時候要說“不”及如何去說？什么時候說“是”及“是”究竟意味著什么？

Foreword
Preface
Acknowledgments
About the Author
On the Cover
Pre-Requisite Introduction
Chapter 1 Professionalism
Be Careful What You Ask For
Taking Responsibility
First, Do No Harm
Work Ethic
Bibliography
Chapter 2 Saying No
Adversarial Roles
High Stakes
Being a “Team Player”
The Cost of Saying Yes
Code Impossible
Chapter 3 Saying Yes
A Language of Commitment
Learning How to Say“Yes”
Conclusion
Chapter 4 Coding
Preparedness
The Flow Zone
Writer’s Block
Debugging
Pacing Yourself
Being Late
Help
Bibliography
Chapter 5 Test Driven Development
The Jury Is In
The Three Laws of TDD
What TDD Is Not
Bibliography
Chapter 6 Practicing
Some Background on Practicing
The Coding Dojo
Broadening Your Experience
Conclusion
Bibliography
Chapter 7 Acceptance Testing
Communicating Requirements
Acceptance Tests
Conclusion
Chapter 8 Testing Strategies
QA Should Find Nothing
The Test Automation Pyramid
Conclusion
Bibliography
Chapter 9 Time Management
Meetings
Focus-Manna
Time Boxing and Tomatoes
Avoidance
Blind Alleys
Marshes, Bogs, Swamps, and Other Messes
Conclusion
Chapter 10 Estimation
What Is an Estimate？
PERT
Estimating Tasks
The Law of Large Numbers
Conclusion
Bibliography
Chapter 11 Pressure
Avoiding Pressure
Handling Pressure
Conclusion
Chapter 12 Collaboration
Programmers versus People
Cerebellums
Conclusion
Chapter 13 Teams and Projects
Does It Blend？
Conclusion
Bibliography
Chapter 14 Mentoring, Apprenticeship, and Craftsmanship
Degrees of Failure
Mentoring
Apprenticeship
Craftsmanship
Conclusion
Appendix A Tooling
Tools
Source Code Control
IDE/Editor
Issue Tracking
Continuous Build
Unit Testing Tools
Component Testing Tools
Integration Testing Tools
UML/MDA
Conclusion
Index

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.I'll do a kata or two every day, often as part of settling in to work. I might do it in Java, or in Ruby, or in Clojure, or in some other language for which I want to maintain my skills. I'll use the kata to sharpen a particular skill, such as keeping my fingers used to hitting shortcut keys, or using certain refactorings.Think of the kata as a 10-minute warm-up exercise in the moming and a 10-minute cool-down in the evening.
COLLABORATION
The second best way to learn is to collaborate with other people. Professional software developers make a special effort to program together, practice together, design and plan together. By doing so they learn a lot from each other, and they get more done faster with fewer errors.This doesn't mean you have to spend 100% of your time working with others.Alone time is also very important. As much as I like to pair program with others, it makes me crazy if I can't get away by myself from time to time.
MENTORING
The best way to learn is to teach. Nothing will drive facts and values into your head faster and harder than having to communicate them to people you are responsible for. So the benefit of teaching is strongly in favor of the teacher.