編碼整潔之道

前言

　　1986年1月28日東部時間上午11：39，“挑戰(zhàn)者”號航天飛機發(fā)射73.124秒后由于右側(cè)固態(tài)火箭助推器（SRB）的故障，在48000英尺的高空被撕成碎片。7名英勇的宇航員，其中包括高中教師克里斯塔·麥考利芙，因此而離開了我們。麥考利芙的母親眼看著自己女兒在9英里的高空離她而去時所流露出來的表情直到今天仍然讓我無法釋懷?！　　疤魬?zhàn)者“號失事的主因是出了故障的右側(cè)固態(tài)火箭助推器中的高熱廢氣泄漏后穿過船體的各段最終飛濺到外部燃料箱上。接下來，主液氫燃料箱的底部爆炸，燃料被點燃后把箱體推入上面的液氧箱體內(nèi)。與此同時，右側(cè)固態(tài)火箭助推器脫離其尾部支撐柱并開始圍繞其前方支撐柱進行旋轉(zhuǎn)。而后它的凸起部分刺穿了液氧箱體。這些異常的力量導(dǎo)致飛行器為了逆氣流而旋轉(zhuǎn)　　需以遠超1.5馬赫的速度進行移動，最終空氣動力把一切都撕成了碎片?！　≡谟覀?cè)固態(tài)火箭助推器的環(huán)形段之間有兩個橡膠的O形環(huán)密封圈。當飛行器的各段被拴在一起時，O形環(huán)密封圈將被壓縮，并形成嚴密的密封腔，廢氣無法穿過。　　但是在發(fā)射的前一晚，發(fā)射臺的溫度低至17℉，比O形環(huán)密封圈的最低臨界溫度低23°，比任何之前的發(fā)射低33°。因此，O形環(huán)密封圈變得非常硬以致無法密封住高熱氣體。在右側(cè)固態(tài)火箭助推器被點燃后，高熱氣體迅速聚積形成壓力脈沖。而后，助推器的各段向外膨脹并向O形環(huán)密封圈釋放壓力。O形環(huán)密封圈的硬度使它們無法保持密封狀態(tài)，因此部分高熱氣體從O形環(huán)密封圈的70°弧內(nèi)漏出和蒸發(fā)?！　∧D·塞奧科公司中設(shè)計了右側(cè)固態(tài)火箭助推器的工程師們其實已經(jīng)知道O形環(huán)密封圈存在這個問題，7年前他們就向莫頓·塞奧科的經(jīng)理們以及NASA進行過相關(guān)報告。實際上，O形環(huán)密封圈在上次發(fā)射中已經(jīng)因為類似的原因被損壞，盡管還不是災(zāi)難性的損毀。結(jié)果，最寒冷的發(fā)射終于使最嚴重的傷害成為現(xiàn)實。雖然工程師們已經(jīng)為此設(shè)計了修復(fù)方案，但是修復(fù)本身卻被一直拖延下來?！　」こ處焸冊?jīng)懷疑O形環(huán)密封圈會在寒冷中變硬。他們也知道“挑戰(zhàn)者”號的發(fā)射溫度比以往任何一次都低，并且遠低于紅線。也就是說，工程師們已經(jīng)知道風險非常高。工程師們根據(jù)自己對這些情況的了解而采取行動，他們寫下提出警報信號的備忘錄。他們向塞奧科和NASA強烈呼吁不要進行發(fā)射。在一個直到發(fā)射前數(shù)小時還在持續(xù)進行的開了11個小時的會議上，這些工程師展示了最重要的數(shù)據(jù)。他們炸開了鍋，軟磨硬泡，反對發(fā)射。但最終經(jīng)理們忽略了他們的聲音?！　‘敯l(fā)射時間來臨時，一些工程師拒絕觀看直播，他們害怕看到發(fā)射臺上的爆炸。但是當“挑戰(zhàn)者”號優(yōu)美升空時他們開始放松。在飛行器解體前，當看到飛行器速度超過1馬赫時，他們中有人說：躲過一劫。盡管有各種抗議和備忘錄，以及工程師們的呼吁，經(jīng)理們?nèi)匀幌嘈潘麄兏私馇闆r。他們認為工程師們反應(yīng)過度了，不相信工程師們的數(shù)據(jù)和推論?！　√幵诰薮蟮慕?jīng)濟和政治壓力之下，他們進行了發(fā)射，期盼一切都會順利。　　這些經(jīng)理并不僅是愚蠢，他們是在犯罪。7位優(yōu)秀的先生和女士的生命、一代人期待太空旅行的希望，在那個寒冷的早晨皆因那些經(jīng)理們把自己的恐懼、希望和直覺凌駕于專家意見之上而破滅。他們做了一個他們并沒有權(quán)利來做的決定。他們篡奪了真正了解狀況的人——工程師們的權(quán)利。　　但是該如何評價工程師們呢？當然，工程師們做了他們應(yīng)該做的事情?！　∷麄兺ㄖ私?jīng)理并為自己的責任而進行了斗爭。他們使用了各種合適的渠道和各種權(quán)利協(xié)議。他們做了他們所能做的——在特定的系統(tǒng)之下，但最終經(jīng)理們踐踏了這些努力。因此工程師們或許可以免受責難，而若無其事地走開?！　〉袝r候我很想知道，他們之中是否有人會在夜里因為克里斯塔·麥考利芙母親的神情而輾轉(zhuǎn)難眠，后悔自己當年沒去找過丹·拉瑟。　　關(guān)于本書　　這是一本關(guān)于軟件專業(yè)主義的書。本書給出了許多務(wù)實的建議，并試圖回答如下這些問題也：　　●究竟什么樣的人才是軟件專家？　　●一名專家究竟應(yīng)該如何處事？　　●專家應(yīng)該如何處理并應(yīng)對沖突、緊張的日程以及蠻不講理的經(jīng)理？　　●專家應(yīng)該在什么時候，用什么樣的方式說“不”？　　●專家會如何面對壓力？　　但是你會發(fā)現(xiàn)書里面隱藏在務(wù)實建議背后的是一種斗爭并取得突破的態(tài)度。這是一種誠實，珍視榮譽，自尊并自豪的態(tài)度。這是一種愿意接受作為專家和工程師所系重大責任的意愿。這種責任意味著要把活兒“做好”且“干凈利落”。它意味著有效溝通，據(jù)實評估。它也意味著管理好自己的時間，在風險與回報之間做出審慎的決定。　　但是這種責任之中還包含了一些其他的東西——一個可怕的東西。作為一名工程師，你對你的系統(tǒng)和項目所了解的深度是經(jīng)理們不可能企及的。與這種了解相對應(yīng)，你就也有責任在必要時采取行動。

內(nèi)容概要

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

作者簡介

作者:(美)Martin

書籍目錄

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

章節(jié)摘錄

版權(quán)頁：   插圖：   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.

編輯推薦

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

圖書封面

圖書標簽Tags

無

評論、評分、閱讀與下載

---

    編碼整潔之道 PDF格式下載

---