軟體開發防錯指南
英文原文：The Pokayoke Guide to Developing Software
标簽： <無> 121人收藏此文章, 我要收藏 楊康 推薦于 1個月前 (共 31 段, 翻譯完成于 02-19) ( 8評) 參與翻譯(12人)： JeremyCooper, 鉑金小狼, daxiaoming200, Khiyuan, 我隻有這一個名字, LeeFly, greyCode, FGQ, 何傳友, 賈俊俊, suyor, 沙灘哥 僅中文 | 中英文對照 | 列印此文章
需求一個好的項目是從需求開始的。一個成功漂亮的需求分析-會讓你擁有更多的潛在使用者-但更重要的是緊急需求， 使用者迫切需要你解決的實際問題-讓他們知道你的産品能做到這些，他們才會不得不使用他。如果你能滿足一個人的緊急需求，你最少也能得到一個固定客戶；如果你能解決更多需求，那更沒的說了。對于大多數人來說，優先解決一個人的需求（平常）再去解決更多需求，會更容易達成目标。 |  賈俊俊 翻譯于 1個月前 1人頂 頂 翻譯的不錯哦! |
| 其它翻譯版本(1) |
| 你能自我了解這個需求是很重要的。理想地，它是你在自己的經曆上産生的需求。比如說，你可能會不顧一切地尋找另一個人去和你約會。次好的是，如果你能外出和嘗試過一種會激發那種需求的生活方式。比如說，如果你很幸福地已婚了，你可能會嘗試征詢你的配偶的允許，是以你可以外出和不顧一切地尋找另一個人去和你約會。這不是完全一樣，但至少有共同點。最起碼，你應該坐下來看看那些有這個需求的人們并能夠了解他們。去當你的單身朋友的照看者同時看着他們設法找個人。 |  JeremyCooper 翻譯于 1個月前 0人頂 頂 翻譯的不錯哦! |
| 當然，你的需求很古怪是可能的。有時候人們會很熱衷于一個想法以至于他們将假裝有對它的需求。你想去确認你在滿足的是一個真實的需求。一個好的做法是確定你能找到至少一個陌生人，他和你一樣強烈地感受到這個需求。 | JeremyCooper 翻譯于 1個月前 0人頂 頂 翻譯的不錯哦! |
| 其它翻譯版本(1) |
| 例子時間：我從事于一個給人們提供一系列有意思和有趣的東西去觀看的網站。對于大多數辦公室工作者，這是一個相當強烈的需求——辦公室很無聊而且你真正能做的隻是坐在電腦前看，是以你極度渴望觀看有趣的事物來解悶。相比之下，我的朋友從事于一個允許你查閱各種正在發生在你周圍的政府事物（新酒許可獲得準許，人們被拘留，汽車被拖曳等等）。你可以想出許多關于為什麼這是有趣的或者為什麼人們可能想知道這類事的理由，不過這個網站沒有滿足真正強烈的需求。盡管我的朋友做得比我更好，但是我從事的這個網站變得比他的更受到廣泛的歡迎。 | JeremyCooper 翻譯于 1個月前 0人頂 頂 翻譯的不錯哦! |
想法但是一個需求是不夠的，你也需要一個想法去滿足需求。客觀地看一秒你的想法。它是否看起來像是真正滿足需求？大多數糟糕的想法是差的是因為它們不真正滿足需求。你想把需求進一步轉換為想法，而不是從想法退化到某種理由。我提及的政府資料就遭受到這個問題，政府資料真的是很酷和提供了一些簡單的搜尋方法給人們，這讓它看起來像一個真正好的想法。而且一旦你迷上了那個想法，就很容易提出它可能滿足的需求。不過你隻是在提出理由。這不是一個直接找出任何一個需求的方法。而且抓住一個需求總是比去滿足兩個的好。 這不是說一個想法不能解決多種需求。偉大的想法确實可以。他們能真正地解決多種需求。他們是對問題直接和明智的對策，而不僅僅是把不同需求硬塞去實作一個你已經喜歡的想法。 | JeremyCooper 翻譯于 1個月前 0人頂 頂 翻譯的不錯哦! |
| 拿iPhone當例子吧。你可能會說“iPhone解決了什麼需求？史蒂夫 喬布斯隻是提出了一個真的很好和通用的想法，然後它正好有效地滿足了各種需求”。不過那不是事實。當iPhone釋出時，喬布斯宣傳它滿足了三個需求：它是一個寬頻視訊iPod，一個有活力的網絡通訊器，和一個好玩的手機。拿這些其中似乎最不像iPhone的一條來說。什麼會讓你就需要去做一個偉大的寬屏視訊iPod？哦，你會需要一個大的，寬的，占據整個裝置的螢幕和一塊能長久持續的電池。你也會需要某種輸入機制，不過當螢幕占據了整個裝置時你會怎麼做呢？好吧，你不得不把螢幕做成輸入裝置。但是現在你有一塊和你口袋裡放着的電話差不多大小的磚塊。你真的應該把它們結合起來。是以為什麼不用觸屏來為好玩的手機提供接口。而且既然你有了一個大的觸屏和一個無線連接配接，不能用它來連接配接網絡似乎顯得很傻...然後你就回到了iPhone。即使史蒂夫 喬布斯不夠優秀去推銷一個不能滿足真正需求的好想法。 | JeremyCooper 翻譯于 1個月前 0人頂 頂 翻譯的不錯哦! |
| 一旦你有了一個基本的想法，你不需要去探究其中大量的細節。不過既然你是那種喜歡提出想法的有創意的人，不管這樣你将會。你将會不斷地提出各種酷的特性或者擴充或者用途和擺設。這些不是重要的，這意味着他們會使你分心除非你對它們做些什麼。是以把他們放到一個Lenin Document。一個Lenin Document就僅僅是關于你大多數想法的樣子的描述，從主要的特性（它能夠打電話）開始和進而完成更模糊的部分（它會有一個應用程式，讓你從床上就可以控制烤箱）。 你可能将不再看這個文檔，不過你和你的同僚提出的好想法不會再困擾你，一旦你有一個安全的地方去把它們寫下來。 | JeremyCooper 翻譯于 1個月前 0人頂 頂 翻譯的不錯哦! |
招聘哦，等一下，什麼同僚？你也會需要組一個隊。當雇用某人時，你想去問三個關鍵問題：
| JeremyCooper 翻譯于 1個月前 0人頂 頂 翻譯的不錯哦! |
| 傳統的程式員招聘過程包括：a)閱讀履歷，b)在電話上問一些難題，還有c)當面給他們出程式題。我認為這是一個糟糕的招聘體制。你從履歷隻能了解非常少而且在面試中當你問應試者難題時，他們真的很緊張。程式設計不是一類在壓力下的工作，是以觀察應試者緊張時的表現是相當沒用的。而且被問的面試問題似乎是專挑那些令人抓狂的。有多少問這些問題的人真的能在他們第一次聽到的時候回答上來呢？ | JeremyCooper 翻譯于 1個月前 0人頂 頂 翻譯的不錯哦! |
| 相反地，僅僅試着去回答上面的三個問題。去找出是否他們能把事情做好，問他們做了什麼。如果某人真的能做好事情，他們到現在應該做了一些事。如果某人真的擅長做事，他們不會一直避開它。沒有先前的經驗是很難當一個好的程式員而且現在任何人可以通過發起或參與一個自由軟體項目的方式來獲得一些經驗。是以隻要要求一些代碼例子和一個示範，看看它是否看起來優秀。你真的很快地了解了許多，因為你不是看着他們回答一個不自然的面試問題，你看的是他們實際的作品代碼。是否簡潔，整齊，講究的，有用的？有沒有你的産品要的東西？ | JeremyCooper 翻譯于 1個月前 0人頂 頂 翻譯的不錯哦! |
| 去考察一個人是否聰明，隻需和他閑談一下。盡你所能去消除壓力：在咖啡館見面，表明這不是一個面試，盡量顯得自然和友善。任何情況下你都不應該問他們任何标準的“面試問題”—僅僅是像你在聚會上和某人談話那樣和他們交流。（如果你在聚會上讓人們說出他們的優缺點或者去評估在芝加哥的鋼琴調音師的數量，你會有更大的麻煩。）在閑談中很容易看出一個人是否聰明。我們經常對我們遇到的人是否聰明做決定，就像我們經常能判斷我們看到的人是否有吸引力。 | JeremyCooper 翻譯于 1個月前 0人頂 頂 翻譯的不錯哦! |
| 不過如果你仍然不是很确定，就看三個方面。首先，他們懂嗎？問他們思考過什麼并對此探查他們。他們顯得在細節上了解嗎？他們能清楚地解釋它嗎？（清楚的解釋是真正了解的一個特征）他們知道些關于項目的你所不知道的東西嗎？其次，他們是否有求知欲？他們通過問些關于你的問題來回應你嗎？他們真的感興趣或者僅僅出于禮貌？他們問了關于你所說的進一步的問題嗎？他們的問題讓你思考嗎？第三，他們是否學習？在對話的有些時候，你可能會給他們解釋一些東西。他們真的了解它了嗎或者他們僅僅是點頭和微笑呢？有些人懂一些小領域的事物但不關心其它的。而且有些人有求知欲但不肯學習，他們問了很多問題但沒有用心聽。你需要能滿足以上所有三點的人。 | JeremyCooper 翻譯于 1個月前 1人頂 頂 翻譯的不錯哦! |
| 最後，你可以跟他們出去聚聚來斷定你是否可以跟他們共事。許多聰明人可以再一個小時的交談裡表現的很愉快，但是幾個小時以後，他們的一些怪癖就會被放大。是以，在你們聊完天以後，你可以邀請他們和團隊裡的其他人一起吃個飯或者在辦公室裡打個遊戲。再說一次，盡可能的自然随便一點。關鍵就是看他們是否會讓你心煩。 如果他們都看起來不錯，而你隻打算雇傭其中幾個，做最後一輪檢測確定你沒有被忽悠：讓他們做一部分工作。通常這意味着拿一些你需要的小的并且獨立的部分讓他們寫。（如果你堅持要看别人頂着壓力工作，那就給他們一個最後期限）。如果需要，你可以給他們提供一點酬勞，但是絕大多數的程式員并不介意被給予像這樣的小任務，隻要他們做的這些東西是開源的就行。這個測試本身并不起作用，但是如果有些人通過了前三個部分，那麼這個測試就足以用來證明他們沒有忽悠你，他們真的可以做他們所說的工作。 | 我隻有這一個名字 翻譯于 1個月前 1人頂 頂 翻譯的不錯哦! |
| 現在更傾向于說“好的，我們何不試着讓你來做一個月看看怎麼樣呢”，其實這并沒有用。首先，這會使你的雇員如履薄冰，總是想着去提高自己，這很殘忍并且達不到理想效果（壓力和恐懼會讓他們更低産）。其次，如果在一個小項目結束後你不能保證說不，那麼一個月後你同樣做不到，結果你就招了個不夠理想的人。還不如直接說不好招更好的人。 | 我隻有這一個名字 翻譯于 1個月前 0人頂 頂 翻譯的不錯哦! |
假定現在，你有一個團隊，是時候做點實事了。雖然立即俯下身來建設夢想（包括你所自豪的事情）的想法的确誘人。但那是一種巨大的浪費。沒人喜歡在多餘的事情上浪費時間，你會想要做的更少些。現在有了。 工作中的每一個創意都依賴于對世界的某種假定；如果假定不正确，創意就不會成功。譬如你在航空公司工作，你知道人們讨厭排隊登機。你的解決方法是：我們可以在檢票時出售一份價值 5 美元的“提前登機”票，以便他們提前登機。這個創意依賴于下面幾個假定：
| Khiyuan 翻譯于 1個月前 0人頂 頂 翻譯的不錯哦! |
| 你會想寫出這些假設，并挑選出最重要的。比如說，“客戶希望盡早登機”是最重要的。現在請牢記，如果這個假設是錯誤的，我們之前做的所有工作将會是徒勞。是以，在假設被證明之前，不要投入太多精力。 那麼，檢驗的最低限度是什麼呢？對此的原生術語，即最小可行量或MVP，然而它已經成為了一個時髦詞，被不真正了解它的人所曲解。大多數人會說這一想法的最小可行量是一個切實的主幹系統，隻需讓你在檢查時多付5美元，或許會在你的登記證上标記一下，然後通知檢票員讓有标記的乘客先登機。很簡單，不是嗎？ | 沙灘哥 翻譯于 1個月前 0人頂 頂 翻譯的不錯哦! |
| 也許是，但還有比它更簡單的方法。檢測這個假定最精确簡單的方法就是支付頁面增加一個“點選這裡提前登機”的按鈕。當有人點選時，彈出一條“對不起，該‘提前登機’的程式無法使用”的錯誤提示。之後你就可以測算有多少人點選了該按鈕。如果有很多人點選它，那麼就知道人們是希望提前登機的。如果沒有人點選它，那麼說明人們對這個産品沒有需求。 但是多少點選量算多呢？可以拿出實際的資料作為參考。“哇，有一千人點選了該按鈕”，你說。“真多啊！這是使用豪華包監測服務人數的十倍！” | FGQ 翻譯于 1個月前 0人頂 頂 翻譯的不錯哦! |
| “不，不是的”，跟你擡杠的同僚反駁道，“太少人用了，使用終端機服務的人比這個還要多一倍。” 為了避免這種争論，你可以事先從那個同僚認可的數字裡選一個來作衡量。你們兩個必須統一商量好，如果結果數字比標明數字大，那麼之前的假設成立；否則不成立。 但是，你應該怎麼來作統計呢？總不能真的去地數點選按鈕的次數吧。這種情況下可以使用虛榮(虛假?)度量。假設實際上100人中隻有1個人想提前登機。大家都知道，聖誕節的時候，坐飛機的人是平時的3倍。如果你選擇在這時進行測試，那麼你的按鈕點選次數可以輕易地達到2000人次的目标。這不是由于這個按鈕真的很有用，隻是由于聖誕節前後太多人坐飛機而已。 | daxiaoming200 翻譯于 1個月前 0人頂 頂 翻譯的不錯哦! |
| 其實，你真正應該采用的是，創新度量。這種統計得出的數字，隻與你感興趣的方面有關，其它的東西都不會對結果有影響。就上面所說的例子，我們隻統計點選按鈕的人數的百分比。假設有3%的人點選了按鈕。這個百分比不會因為旅客突然大量增加而改變。 當然，這個百分比反而有可能下降。因為聖誕節的旅客比較匆忙，無暇顧及其他。是以你要相應地調整你的預期目标為：3%正常旅客會點選按鈕。這樣，即使旅客突然激增，這個統計也比較穩定。 | daxiaoming200 翻譯于 1個月前 0人頂 頂 翻譯的不錯哦! |
| 你甚至可以圈定群體來幫助統計。一個群體是指一組事先標明的人。例如，你可以事先標明一組正常旅客，隻有他們可以看到按鈕。這樣的話，突然激增的旅客就不會影響你的統計了，他們都看不到按鈕，因為他們并不是你圈定的群體。 另外，你也可以進行類比統計。可能多加一個按鈕會使人們更加不想購買升艙服務（可能很貴）。将你事先圈定的群體随機分成人數相等的兩份。其中一份可以看到按鈕，另一份看不到。對比這兩份人的統計，你就可以看到添加按鈕是否有影響。如果實驗中隻有4%旅客購買升艙服務，但是你圈定的群體中有8%購買了，那麼你就要考慮将這個差異納入到将來的計劃了。 | daxiaoming200 翻譯于 1個月前 0人頂 頂 翻譯的不錯哦! |
團隊一旦你确立了一個假設，并用最小可行的方法來驗證它，一套明确的度量标準類證明它，是時候去實際踐行它的時候了。應該從一名産品負責人開始。他們是你的産品的“喬布斯”-他們會為了保證整個産品的完整性而重新對每一個細節進行授權并簽發許可。 你最好寫一張卡片（3X5大小或者像Asana這樣的清單式任務管理系統），用來描述你的目的與你将用來證明它的度量。 “挑選一幫經常訪港的家夥，将他們分為實驗組和對照組”。 當我準備登機檢票的時候，我能看到這樣一個按鈕，能提供給我一次讓我盡早登機機會的按鈕，如果我點選了它，我就會收到一條表明該服務目前無法使用的錯誤提示資訊。 這證明了我們的顧客想盡早登機的假設。我們認為該假設表明實驗組有超過2%的人點選了有可能能讓自己盡早登機的按鈕。我們同時也監測了他們購買的其他更新，他們為了保證推廣該功能而不會引起嚴重的廣告效應的登機完成率。 | LeeFly 翻譯于 1個月前 0人頂 頂 翻譯的不錯哦! |
| 第一段提到了被實驗的對象。第二段講述了一個關于改變使用者生活經曆的故事。第三段解釋了我們為什麼進行實驗以及我們尋找的尺度是什麼。 這些都涉及到一堆（或者是線上To List）按照優先級排序的卡片，并把最重要的需要驗證的假設放在最前面。你的設計師們，當他們在做他們目前的任務的時候，将從一堆卡片中摘取最靠前的卡片。他們将與産品負責人一起設計，看起來就像（按鈕放在哪？到底要要怎麼表達？）。一旦産品負責人認可了相關設計并簽了字，設計師們将會親自把卡片交給程式設計人員，同時和他們一起工作以實作該設計。 從實施或實際使用的經驗所帶來的實際問題，一旦實施完成，就會導緻花費大量的時間進行重新設計，或許這樣反複修改能給産品負責人帶來更多的回報建議。 | LeeFly 翻譯于 1個月前 0人頂 頂 翻譯的不錯哦! |
開發當你着手開發的時候為你的軟體編寫自動化測試是一項很好的實踐，這樣在之後未通過（部分測試）時就很容易知道（是哪裡出的問題）。你覺得自己搞定的時候就可以運作測試以確定它們全部通過，當然，你得保證測試能同時覆寫到那些有把握的和所有實驗性的功能點。 編碼是一項費神的活兒，是以找個人來做結對程式設計通常更加有效：一個碼代碼，一個邊看變指點（一個人寫測試然後把鍵盤甩給另一個人寫代碼讓測試通過有時也蠻有趣的）。 如果你一直找不到人跟你結對，那麼至少得保證你能拉一個人過來評估下你做的變更。在往工程裡送出代碼之前，你應該 總是 看看diff (比如說運作 git diff HEAD)。 | greyCode 翻譯于 1個月前 0人頂 頂 翻譯的不錯哦! |
架構如果你正在開發一項網絡服務（比如Web應用），就應該按照應用開發十二要素來設計。滿足這十二要素的應用程式遵循以下12條原則：
| greyCode 翻譯于 1個月前 0人頂 頂 翻譯的不錯哦! |
| 您還應該 引入"Chaos Monkey"來 進一步確定 您的系統 的 穩健性，"Chaos Monkey"是一個自動化的過程，去激活一個系統的不同元素，以確定它們是健壯的響應中斷。例如：程序的是一次性的，"Chaos Monkey"會自動殺死一個随機的生産過程，這能避免開發人員依賴持續性的程序，如果他們犯了一個錯誤，并且一直沒有發現，早期捕捉這個錯誤則能避免這個錯誤以及錯誤引發的其他衍生物最終導緻的災難性的結果 | 鉑金小狼 翻譯于 28天前 0人頂 頂 翻譯的不錯哦! |
部署軟體設計師一旦送出他們的代碼到版本控制庫中，那麼他們所有的測試都将順利通過。 如果他們要求改變後端服務的代碼(如資料庫模式更改)，這可以通過遷移做到。一個遷移能改變它如何制作和復原。當部署一個新的軟體版本時，運作任一未運作的遷移模式。同步的代碼版本依賴于其後備服務。在復原之上，遷移同時又被復原。這意味着後備服務與代碼總是同步的。 | 何傳友 翻譯于 11天前 0人頂 頂 翻譯的不錯哦! |
| 幾乎所有的新代碼都是緻力于開發的主線的（又名主幹或HEAD）。這就避免了不同的開發分支合并後的痛苦。因為任何大的變化都應作為一個實驗來實作，如果一個變化沒有完成或者沒有準備好，就很容易被大多數實驗外的使用者關閉。如果代碼準備好了，則更多的人可以加入到實驗組而這種拴牢最終将被删除。 一旦 送出 到版本庫，版本 庫就會 自動 建立 ， 釋放， 并 在一個新的 測試環境 中 運作這些 代碼并 自動測試它們 。 然後，就應該 嘗試 運作代碼，并 遷移 對 生産 支援 服務 的完整副本 （read： 資料庫） ， 嘗試通過運用 和復原 的遷移這兩種方式確定測試通過 | 鉑金小狼 翻譯于 9天前 0人頂 頂 翻譯的不錯哦! |
| 如果它們全部都通過了，它就應該釋出出來。為了確定一些莫名其妙地通過了測試的斷碼不釋出出來，你應該有一個免疫系統去監控部署。系統會檢視你的主要創新名額（尋找新的收益，新的使用者等等），以確定他們沒有受到不利影響的部署。如果是這樣，它會自動復原，并提醒團隊。 為了確定 還沒有被産品所有者 審查的代碼不釋出 出來 ，你應該給它們着手 控制 實驗 。 新功能應該在 最初時沒有任何人的實驗中 投入生産 。 産品所有者 可以 添加 自己 的實驗 ， 或 把 實驗放在預覽伺服器讓 每個人 來測試 它 。 QAs 也可以測試 。 當所有人都 快樂了 ，就會有越來越多的人 加入到 實驗中 。 如果 名額看起來很棒 ，甚至 可以 增加更多 ，直到 最終 100 ％的使用者都參與到 實驗裡來 和有控制 可以 從 代碼庫 中 删除的力量 。 | 鉑金小狼 翻譯于 8天前 0人頂 頂 翻譯的不錯哦! |
釋出有些人會鼓勵你舉行一個大的如同好萊塢式的釋出會，在軟體推出的幾個月前就開始大肆宣傳釋出日期。 這種方式也許在好萊塢很好用——如果你的電影在首映周票房高唱，影院心甘情願的多放映幾周，且你的電影被譽為“本周最佳影片”。但對于軟體開發者，這是極其荒謬的。你的軟體并非在影院釋出，它釋出在網際網路上。你的軟體不比擔心被影院展示一周就下架。你可以年年推送，培養使用者群。 | Khiyuan 翻譯于 1個月前 0人頂 頂 翻譯的不錯哦! |
| 一場盛大釋出會的問題在于，除非你是完美的，釋出當天總會出現一些你忽視掉的 BUGs 和概念錯誤。現在，數以百萬計的人正在通路你的産品，體驗這些錯誤。（也許你的錯誤時沒有适時的加載和測試伺服器，導緻網站當機。） 相反的，你應該視你的釋出會為另一場實驗，并在表現良好的時候緩慢增加允許通路的使用者數量。學習 Gmail 的例子：邀請極少的人，針對他們的使用和回報測試你的設定，當他們開始喜歡上的時候，允許他們邀請另一些人加入。慢慢增加人數，直到所有期待邀請的人都已被邀請，整個世界都将是你的試驗場。 祝你好運！ | Khiyuan 翻譯于 1個月前 0人頂 頂 翻譯的不錯哦! |
| 緻謝 此文 最初是由Aaron Swartz寫的，是他和其他人 很多不同的想法的組合 。 需求和想法的讨論可能受到Paul Graham 的影響 。招聘 是改編自Aaron 的我如何雇傭程式員，這涉及到 Joel Spolsky的 作品 （ 他的書 被稱為聰明地把事情辦好 ） 。 假定是 改編自精益創業 和豐田 生産系統 。 團隊和開發 是基于 極限程式設計 的 想法 。 架構 明顯是基于 12-要素的應用 。The Chaos Monkey 是來自于Netflix 。 從Rails 遷移 是一個長期的過程 。 部署 通過 蒂莫西· 菲茨來自IMVU的 連續性 免疫系統 。 釋出的部分 是改編自如何啟動軟體 。 | 鉑金小狼 翻譯于 7天前 0人頂 頂 翻譯的不錯哦! |
本文中的所有譯文僅用于學習和交流目的，轉載請務必注明文章譯者、出處、和本文連結
我們的翻譯工作遵照 CC 協定，如果我們的工作有侵犯到您的權益，請及時聯系我們 (源自：http://www.oschina.net/translate/pokayoke-guid-to-developing-software?from=20130224)