週末重溫了一遍阿圖·葛文德的《清單革命》，其副標題「如何持續、正確、安全地把事情做好」是各行各業都想實現的夢想。而對應到具體行業時，各類從業者的「清單革命」又各有不同。書中大部分描寫的是醫療、建築、餐飲、零售等傳統行業上的例子。通過清單的規範，能有效地降低從業者失誤從而提高效率。
對於程式開發，經歷了從《人月神話》中「沒有銀彈」的尷尬境地，到如今行業漸入正軌：流程規範化、功能模組化、引數配置化。程式開發的過程中各道「工序」也日漸明確。以下是《清單革命》給我帶來的一些啟示。
無知之錯，在程式開發早期有很多案例，如著名的「千年蟲」，第乙個蠕蟲病毒、intel奔騰浮點指數除法等等。在這些都是在探尋未知里程時開拓者們遇到的坑。如今大資料時代或許還會出現前所未聞的bug，但相比前人這種機率勢必小得多。
無能之錯：犯錯是因為未能正確使用知識，不能被原諒
程式開發中的「無能之錯」為qa部門提供了主要的工作內容。
無論是小到文案拼寫錯誤，還是大到死迴圈宕機，這些bug都是像抗日神劇中翻來覆去出現的場景。
或許是趕工期無法面面俱到，但一些常識和關鍵點對於程式開發來說也是必須要卡好的，如字段長度確認、日期格式轉換、介面字段對齊、sql索引命中、邏輯判斷分路完備、頁面正常渲染、避免死迴圈等等。不同程式設計師或許側重點不同，前端同學側重於ui互動，後端同學側重於介面事務。
但和醫療行業相似的是，程式開發也是乙個「我們所掌握的知識數量和複雜程度，已經超出了個人正確、安全和穩定地發揮出其功效的能力範圍「的行業。
「在重壓之下，人們特別容易忽視一些單調的例行事項」 和 「人們會麻痺大意，會故意跳過一些明明記得的步驟」。
這兩句或許就是程式設計師日常犯錯的縮影。書中的例子是將通過將消毒皂的使用寫入清單，大大降低感染率。顯然徹底地做好消毒工作在此之前沒有被重視，也是醫護人員容易忽略的環節。
對照程式設計師呢？或許正確理解使用者需求也是極易被忽略的環節。沒有理解好使用者需求的細節直接開工的情況比比皆是。測試或上線後才反饋出來。當然這塊也因人而異，每個人在回顧自己的bug列表時都能大致發現自己開發過程中容易忽略的關鍵點。
個人總結的一些關鍵點：
**審查
程式開發早已過了金山軟體求伯君當年那種孤膽英雄的時代。絕大多數程式設計師不是獨行俠，通常都是團隊。團隊中的**review能大大避免錯誤的發生。這點相比其他行業算是一大優勢吧。提倡團隊**審查，加上sonar**掃瞄，保障團隊**質量。團隊**審查也能出個清單：
方案決策
書中建築團隊在進行方案決策時會找來很多行業專家開會決定。「無論在設計時有多麼困難，都沒有犯錯的餘地。因為錯誤意味著送命和巨大的經濟損失」。開發團隊在遇到方案決策時，需要每個人用自己的專業知識來評估方案。也就是用每個人認知中的知識清單來判斷方案的優劣，用團隊的認知網路來避免個體的認知偏差。程式開發方案也需要由系統架構、安全審計、網路部署、產品開發、qa測試等部門敲定。
書中的例子是沃爾瑪在「卡特里娜」颶風中救災的例子。不是簡單地分權就行，更關鍵地是讓每個人都能擔負起自己的責任。程式開發過程也是一樣，個體要向團隊負責，可以通過清單來確保充分溝通、互相協調、承擔責任、明確自己的權力和責任。
我也列了個清單：
綜上，《清單革命》或許不能解決「沒有銀彈」的難題，但至少能讓程式開發過程中程式化、規範化不至於「腹背受敵」。文中所列舉的清單純粹是根據個人開發經驗推導所得，參考意義不大。每個人、每個團隊根據自身情況歸納出自己的清單，才能更好地完成「清單革命」。
對程式開發的一些理解
有一句流行語 10 的 是處理正常流程的，90 是用於進行異常處理的 這是許多擁有大量通訊開發經驗教訓的專家們掛在嘴邊的話。在通訊界中，經常是各家的裝置互相聯絡，它們之間通過各種標準化的通訊協議來互相握手互相理解，雖說是 智慧型裝置 但終究是沒有思維的，不具有模糊推理之類的能力 所以，什麼話都說的毫...
阿里培訓的一些啟示
啟示1 心態。拓展訓練的時候，有乙個專案是高空抓竿，我認為這很簡單，從地面上看，這個動作很並不難。但是當我爬上8公尺高的桿子，站在晃動的桿子上看到下面的風景的時候，我心裡卻充滿了恐懼，我一度覺得我沒辦法再成功，我沒多想幾乎是逼著眼睛跳出去的，最後抓住了桿子，挑戰成功。事後，我想起了列禦寇學射的故事，...
對測試轉開發的一些想法
首先需要引兩個外鏈 其實我這兩天，重新審視了一下我的內心，我想從乙個測試轉開發的真實動機到底是什麼？那絕對不是因為我愛開發技術愛的痴狂，雖然我確實適合做技術。根本原因就是，我受夠了做乙個功能測試。功能測試對乙個人的成長沒有任何幫助。產品經理去了解業務，設計系統流程，然後與開發討論實現的問題，然後開發...