程序員必備的30條防御式編程思想原則

　　在分析若干線上問題之后，會發(fā)現(xiàn)很多問題并不是非常罕見的難題，而是由一個個較為明顯的小錯誤積累而來，為什么會犯小錯誤?或許是因為僥幸心理，或許是因為只看到了局部的利益。從某一個例子來看，確實會有“偶因一著錯，便為人上人”的僥幸，但是統(tǒng)計大量案例可以發(fā)現(xiàn)，大部分情況并不會有正面的結(jié)果。

　　本文匯編我在需求評審、編碼、項目上線幾個階段總結(jié)的原則，這些原則雖然不能直接解決問題，但是可以盡可能地優(yōu)化每一步行為，從防御式編程思維方式、行為習(xí)慣層面盡量避免錯誤的發(fā)生。

　　交流溝通時的原則

　　不同場景，使用不同的溝通工具

　　通過IM(即時通訊工具)打字是常見的溝通方式，成本低，適合簡單問題的溝通以及團(tuán)隊內(nèi)各種信息的通知。但如果一個復(fù)雜的問題，打字3分鐘還說不清楚、無任何進(jìn)展，應(yīng)該立刻換一種更高效的溝通方式，比如語音或面談。

　　語音溝通相比文字溝通，有了語氣，可以避免純文字語氣生硬的問題，而且在單位時間內(nèi)有更多的信息輸出量，效率更高。有時會看到兩個人在群里一人一句，討論了5分鐘，結(jié)果發(fā)現(xiàn)說的不是一件事情。如果及時換用語音，可能1分鐘就發(fā)現(xiàn)問題所在了。

　　見面溝通相比語音，增加了表情，能更好地表達(dá)強(qiáng)烈的訴求。特別是遇到非常緊急的問題時，直接見面不失為最好的方法。有時候都出線上問題了，還在等別人通過IM回復(fù)，可能會影響更優(yōu)的止損時間。

　　避免確認(rèn)偏誤，反對的觀點(diǎn)可能會帶來更多啟示

　　確認(rèn)偏誤，指的是只聽“好”消息——即能印證自己觀念的消息，而對“壞”消息趕盡殺絕——拒絕接受與自己觀念不同的消息、想法。這種現(xiàn)象會導(dǎo)致自己無法接受一個長遠(yuǎn)有益的反對意見。

　　這種情況在大數(shù)據(jù)時代看信息流的時候會更明顯，經(jīng)過精準(zhǔn)的算法，在有一個觀點(diǎn)、喜歡某類觀點(diǎn)的時候。精準(zhǔn)的推薦算法，只為持續(xù)推薦給自己認(rèn)同觀點(diǎn)的信息。不會有反面的信息來糾正錯誤的觀點(diǎn)。這樣強(qiáng)化錯誤的觀點(diǎn)，會讓自己處于信息繭房之中無法自撥。

　　這是因為大腦的結(jié)構(gòu)非常復(fù)雜，由理性的我和感性的我組成，對于別人的反對意見，感性的我會默認(rèn)把別人的反對意見當(dāng)成攻擊。

　　所以我們就要訓(xùn)練感性的我，對于別人的觀點(diǎn)，要仔細(xì)思考，再做行動。反對的觀點(diǎn)，可能道出了自己想法中潛在的風(fēng)險，甚至是一個更好方案的啟蒙。通過訓(xùn)練主動辯證思考的能力，區(qū)分“聽起來舒服的觀點(diǎn)”與”對自己長遠(yuǎn)有利的觀點(diǎn)“。

　　舉例論證，只能作為決策的參考意見

　　無論是自己思考問題，還是討論問題的時候，經(jīng)常會出現(xiàn)以下兩種觀點(diǎn)。

　　上一個項目，我使用了技術(shù)方案A，效果非常好，所以這個項目也使用技術(shù)方案A吧。

　　我有一個同學(xué)，遇到這樣的問題，他就是這樣解決的，所以我們也可以這樣做。

　　把一次偶然的成功，當(dāng)成必然的結(jié)論的現(xiàn)象。既可能出現(xiàn)在討論中，也可能出現(xiàn)在自己的經(jīng)驗中。這些經(jīng)驗可以當(dāng)成決策的一個參考案例，但不能直接當(dāng)成必然的結(jié)論�？茖W(xué)的方法應(yīng)該根據(jù)不同的場景，不同背景，做大規(guī)模的統(tǒng)計，這樣才能根據(jù)不同場景做更好的決策。

　　創(chuàng)意擇優(yōu)，自己調(diào)整權(quán)重再做決策

　　無論是技術(shù)方案的討論，還是一個有爭論問題的交流，大家都會從自己的角度有不同的觀點(diǎn)。每個人都有自己更關(guān)注的點(diǎn)，所處位置不同，關(guān)注點(diǎn)則不同。如果需要自己做決策，那么在討論的過程中，要理解每一個想法背后的原因，這樣才能明白其底層邏輯，從自己的角度判斷其權(quán)重。綜合考慮不同角度的想法，這樣才能站在自己的角度，更全面地考慮、決策問題。

　　李開復(fù)在選擇畢業(yè)論文課題時，就涉及風(fēng)險與穩(wěn)定兩類課題的決擇。

　　如果選擇深度學(xué)習(xí)，可能會延期畢業(yè)，風(fēng)險高，但是如果成功了則一舉成名。

　　如果選擇普通的課題，能按時畢業(yè)，無風(fēng)險，但是不會取得非常大的成就。

　　對于不同人，承受的風(fēng)險是不同的，那么他們的選擇也會不同，當(dāng)然了，其長遠(yuǎn)收益也不同。

　　打字溝通時，重要的內(nèi)容單獨(dú)發(fā)一條消息

　　對于大段的文字內(nèi)容，對方不一定會仔細(xì)看每一句。重要的問題，單獨(dú)發(fā)一句，不和其他內(nèi)容合并在一起。

　　實例1：在排查一個問題時，一句話問了2個問題，對方回答“是”。我根據(jù)對方的結(jié)論，繼續(xù)排查問題。排查了一天，我感覺問題B的情況不應(yīng)該是B1，再次找對方確認(rèn)，結(jié)果對方說他只看到我說的前一句，并沒有看到后一句"問題B的情況是B1吧?"。

　　實例2：有一次項目上線之后，我給合作方發(fā)了一句話以表示感謝，對方回了我一句：“需要我配合排查什么問題?”

　　會議紀(jì)要，在跨團(tuán)隊合作時更能凸顯價值

　　會議主持人應(yīng)即時記錄會議結(jié)論與待辦事項，否則會出現(xiàn)幾天、幾周之后，大家印象中的結(jié)論不同而導(dǎo)致沖突，甚至出現(xiàn)遺忘重要待辦事項的情況。

　　對于內(nèi)部團(tuán)隊，出現(xiàn)這種問題并不會有太大的問題，畢竟大家長期合作，一點(diǎn)點(diǎn)失誤也會被包容，但不能因為經(jīng)常被包容而沒有這個習(xí)慣。因為在更大的共同體，公司橫向團(tuán)隊的合作，甚至與外部公司合作的時候，這個問題帶來的負(fù)面影響就會成倍地放大。

　　對于一些定制化功能的三方供應(yīng)商來說，他們會對接很多團(tuán)隊，他們對外部溝通時，并不是研發(fā)，而是其他崗位的同學(xué)，比如銷售或商務(wù)。他們在對接時難免會因為理解偏差而作出錯誤的回答，如果根據(jù)錯誤的結(jié)論，設(shè)計出一個不合理的技術(shù)方案，等到項目上線前期才發(fā)現(xiàn)問題，在沒有會議紀(jì)要的情況下，很難證明是對方說錯了，還是自己理解錯了。

　　需求評審與排期階段的原則

　　人人都是產(chǎn)品經(jīng)理，需求決定方向

　　軟件開發(fā)，是為了滿足用戶的需求，解決實際問題，創(chuàng)造價值，并不僅僅是為了被安排的一個個需求任務(wù)。研發(fā)不僅要按照產(chǎn)品經(jīng)理的需求寫代碼，也要思考與批判其合理性。只有身處一名用戶的角度，仔細(xì)分析產(chǎn)品的合理性，才能寫出更有價值的代碼，而不僅僅是把寫代碼當(dāng)成一種體力勞動的交換。

　　技術(shù)是手段，而非目的

　　需求分析與系統(tǒng)設(shè)計是兩個遞進(jìn)的步驟。

　　在需求分析階段，不應(yīng)該考慮詳細(xì)的技術(shù)細(xì)節(jié)，否則就會出現(xiàn)“因為技術(shù)太困難，所以這個需求做不了”或“這個工作量太大了，改一下需求吧，這樣工作量就減少很多”的現(xiàn)象，導(dǎo)致一個優(yōu)秀想法的流產(chǎn)。剛開始就從技術(shù)的角度，而不是從用戶真實需求的角度來實現(xiàn)一個更有價值的產(chǎn)品。產(chǎn)品的價值應(yīng)該根據(jù)用戶的需求來決定，而不是技術(shù)的難易。當(dāng)然并不是不考慮技術(shù)實現(xiàn)的成本，而是應(yīng)該有先后順序，確定需求之后再確認(rèn)技術(shù)實現(xiàn)的成本，畢竟即使技術(shù)成本很高，其ROI也可能更高。

　　雖然有些需求，用某些技術(shù)方案，成本非常低。幾個小時就做完一個需求，但如果是無意義的需求與無意義的技術(shù)方案，做再多又有什么用呢?

　　簡化步驟的產(chǎn)品，有更大價值

　　對于需要用戶交互的產(chǎn)品，用戶操作成本越低，時間成本越低，價值越高。這就需要在考慮產(chǎn)品的時候能在保證功能不變的前提下，盡量多的刪除冗余功能，而不是增加功能，雖然增加功能更容易。

　　跨團(tuán)隊合作，內(nèi)部排期全部對齊之后再與外部溝通

　　從個人，到團(tuán)隊，到整個公司，再到外部公司，共同體逐漸增大，溝通成本也會逐漸增加。對于一些需要統(tǒng)一結(jié)論的問題，比如項目的排期，應(yīng)該根據(jù)共同體的規(guī)模從小到大逐步確定。避免和外部團(tuán)隊確定了一個項目上線的日期，結(jié)果發(fā)現(xiàn)內(nèi)部時間無法匹配，后續(xù)再與外部團(tuán)隊調(diào)整。一方面溝通成本會很大，另一方面也暴露了內(nèi)部流程的混亂。

　　倒排排期需求，注意節(jié)假日，并保證聯(lián)調(diào)時間

　　有時候難免會遇到非常緊急的需求，需要倒排排期。如果一定要壓縮時間，那就壓縮開發(fā)時間，要保證聯(lián)調(diào)時間足夠。因為聯(lián)調(diào)才能更快地暴露問題。提前暴露問題，才能盡早地協(xié)調(diào)資源，解決問題。

　　開始聯(lián)調(diào)的日期盡量不要定在大型節(jié)假日前1天，特別是涉及多團(tuán)隊的大項目，因為一個人休假導(dǎo)致無法聯(lián)調(diào)，最終導(dǎo)致整個流程都無法及時開始聯(lián)調(diào)。

　　不要給合作方評估工作量

　　有涉及和兄弟團(tuán)隊，甚至外部公司合作的時候，可能會遇到需要對方增加或修改一個功能的情況。從自己的角度看，這個功能只需要幾分鐘就能完成，但只要自己沒有改代碼的權(quán)限，就不要從自己的視角給對方評估工作量。

　　一方面每個人對每個功能的熟悉程度不同，對方可能剛接手代碼，也不是非常熟悉。另一方面每個團(tuán)隊都有自己的流程，完成整個功能的修改，邊際成本并不低。因為不僅僅需要研發(fā)修改代碼，滿足當(dāng)前功能，還要考慮拓展性與穩(wěn)定性，甚至測試等團(tuán)隊的協(xié)作。

　　開發(fā)階段的原則

　　完善的文檔，是擁有長遠(yuǎn)戰(zhàn)略眼光的表現(xiàn)

　　把可能涉及項目的整個團(tuán)隊當(dāng)成一個共同體，而不僅僅是自己一個人。相比于自己寫一次文檔的局部視野，可以從更全局的視野來看長遠(yuǎn)收益。對于多團(tuán)隊合作的需求，如果不記錄，看似一個不重要的參數(shù)，可能會涉及大量團(tuán)隊的溝通與協(xié)作的成本。雖然在維護(hù)他人項目的時候，可以看代碼或注釋來了解整個項目。但是一些復(fù)雜的項目，較復(fù)雜的邏輯，很難從代碼中看出來整體結(jié)構(gòu)，這時候文檔的重要性就顯示出來了。

　　文檔的維護(hù)確實需要成本，但這是一個短期的成本。長期來看，有了文檔，可以避免以后更多的溝通交流成本，避免花更多時間看一個陌生的邏輯的時間。相比編碼完成之后推倒重來，文檔的修改成本并不高。

　　面對短期與長期的天平的兩端，你愿意把砝碼放在哪一端?人生是一場馬拉松，雖然不寫文檔會有短期內(nèi)的輕松。但是從長遠(yuǎn)角度來說，目光長遠(yuǎn)，從更寬廣的視角，擁有長遠(yuǎn)戰(zhàn)略眼光，其實更重要。

　　另外，有人認(rèn)為文檔確實應(yīng)該寫，但是僅限于復(fù)雜的項目，簡單的項目沒必要寫，其實簡單的項目正是訓(xùn)練習(xí)慣的一個好機(jī)會。如果從來沒有寫文檔的習(xí)慣，那么在Own大型項目的時候，就會發(fā)現(xiàn)非常不習(xí)慣寫文檔，在時間緊張，功能復(fù)雜，涉及團(tuán)隊非常多的項目時，重壓之下，動作就容易變形。想要保證動作連貫行云流水，就要在平時養(yǎng)成好習(xí)慣。

　　維護(hù)文檔的同時，也要維護(hù)文檔索引

　　如果是單獨(dú)一個項目的文檔，其結(jié)構(gòu)比較單一，即使迭代多個版本，其整體結(jié)構(gòu)也比較清晰。但如果是一個團(tuán)隊大家一起記錄，對于一個新主題頁面的添加，不同的人會添加到不同的層級，下次在查找的時候非常困難。此時索引的重要性就很明顯了，即文檔的添加，不僅僅是單獨(dú)一篇文檔的添加，還需要有相應(yīng)索引的維護(hù)。

　　這其實涉及到現(xiàn)代電子文檔存儲的一個問題，種類多，分類靈活，層級變幻無窮。隨著團(tuán)隊規(guī)模的擴(kuò)大，項目的增加，無序狀態(tài)會持續(xù)導(dǎo)致熵加。想要更整潔，索引必不可少。

　　編碼時間占比應(yīng)低于30%

　　一個項目從需求評審、技術(shù)方案調(diào)研、書寫文檔、編寫代碼、測試、上線。純粹編碼的時間占比并不大。特別是在設(shè)計完美，一氣呵成寫完代碼的情況下。如果編碼時間占比很大，大概率是因為在編碼的過程中寫了一半、突然不知道后面怎么寫了，或者寫完之后，才發(fā)現(xiàn)設(shè)計有嚴(yán)重缺陷，需要推倒重來。

　　代碼需要別人能看懂，而不僅僅能正常運(yùn)行

　　上學(xué)時期，一個課程設(shè)計的項目，只要能正常運(yùn)行即可。至于老師能不能看懂我們變量命名是什么意思，并不重要。因為這個項目，以后再也不會有人關(guān)注了。但是在企業(yè)項目中，一個項目不僅僅是要自己維護(hù)，還涉及到團(tuán)隊內(nèi)其他同學(xué)來維護(hù)。因此代碼的要求就不僅僅是能運(yùn)行了，還要能讓別人看懂。

　　先寫注釋，再寫代碼

　　注釋不是補(bǔ)出來的，而是在編碼的時候就應(yīng)該寫好的。

　　代碼和注釋是密不可分的統(tǒng)一體，類似知行合一的思想，知和行是密切結(jié)合在一起的，兩者不可分割。幾秒鐘打幾個字寫一些注釋，會為以后查看節(jié)省更多的時間。有人可能說我能看懂就行，以后看不懂也是別人看不懂，和我沒關(guān)系。即使只從自己的角度來看，這個還真不一定，不信可以看看自己2個月之前寫的代碼。況且從更大的共同體利益來看，寫注釋并不是為了自己，而是為了整體團(tuán)體的利益。如果剛開始不習(xí)慣寫代碼的同時寫注釋，可以在寫代碼之前先寫注釋。

　　外交無小事，對外的接口，變量的更改，要盡早同步

　　對外的接口協(xié)議，要慎重，確定之后不應(yīng)該修改了。但是如果因為早期考慮不全面，必須修改，那就盡早修改。雖然自己全局搜索替換成本很低，但是如果涉及合作方的修改，特別是在測試后期，溝通成本可能要再高一個量級。周知上下游，越早改，大家的相對成本越低。

　　模塊、函數(shù)遵循單一目的的原則

　　每個函數(shù)只做一件事，每個模塊功能盡量單一。每個模塊對外暴露相應(yīng)的接口，做到“高內(nèi)聚，低耦合”。說起來似乎很簡單，但是如果在需求第一個版本就寫出高耦合的代碼，就會導(dǎo)致后續(xù)維護(hù)不可控，出現(xiàn)一個類上千行的現(xiàn)象。后期想要再改，成本呈指數(shù)級上升。每個函數(shù)，盡量不超過30行。每個類，盡量不超過900行。

　　命名要表里如一，見名知意

　　變量是代碼中最小的單位，命名的好壞與可讀性好壞有較大關(guān)系。比如命名是keyString，看意思應(yīng)該是key值的字符串，如果在使用的時候用的是value，這會給別人閱讀造成很大的障礙。

　　編碼：不要使用特殊技巧

　　非常復(fù)雜的炫技代碼，其價值在可讀性面前不值一提。如果能開源，那也算是秀出風(fēng)采，否則就是自嗨。

　　Commit message 雖不起眼，但蘊(yùn)藏大信息

　　Commit message可以當(dāng)成一個索引，不僅方便回顧迭代的流程，還方便回滾。每一個commit message，都應(yīng)該和模塊、函數(shù)的單一目的類似，盡量只有一個功能的修改。并且commit message最好有固定的格式，比如[分支名][修改的內(nèi)容]。想要更詳細(xì)的話，可以再加上[代碼類型]，區(qū)分是功能，還是bug的修復(fù)。甚至可以再加上[bugId]，可以鏈接到相應(yīng)的bug空間。這種習(xí)慣在集成，回滾時就體會到價值。

　　代碼評審，是輸入、輸出之后的反饋，是進(jìn)步最快的方式之一

　　代碼評審：別人發(fā)現(xiàn)我的錯誤時，應(yīng)該心存感激，而不是試圖辯解。正如同健身的時候，先看書中的理論，再實踐，最后找教練反饋。有時候我們認(rèn)為自己做的動作是對的，但是在輸出之后找教練反饋，可以糾正很多不注意的細(xì)節(jié)導(dǎo)致的錯誤。代碼評審也是如此，有時候認(rèn)為自己寫得完美無缺，但實際可能漏洞百出。

　　If else平衡，失敗的數(shù)據(jù)也需要

　　對于一些邏輯的處理，輸出成功結(jié)果進(jìn)行透傳。雖然只需要處理成功的情況，但是失敗的情況也要處理。失敗的數(shù)據(jù)雖然暫時沒用，但可以統(tǒng)計失敗率，以及分析問題。

　　測試階段的原則

　　涉及用戶操作的產(chǎn)品功能，交叉測試更容易發(fā)現(xiàn)問題

　　每個用戶都有不同的操作習(xí)慣，對于涉及用戶操作的產(chǎn)品功能，如果一直是同一名QA測試，可能因為其固定的操作習(xí)慣，導(dǎo)致不容易發(fā)現(xiàn)一些隱藏的bug。這個時候盡可量多的“用戶”操作，從不同的操作習(xí)慣來體驗，則更容易發(fā)現(xiàn)問題。如果能進(jìn)一步擴(kuò)大范圍，不同崗位的同學(xué)一起使用、體驗、吐槽，則能更早地發(fā)現(xiàn)真實用戶的體驗問題。

　　無法解決的困難問題，試試研究的思路

　　有時候會遇到一個很困難的問題，一天都解決不了。主要是兩種情況：

　　思路錯了。

　　未知的知識太多了。

　　如果是思路錯了，這個時候不妨以退為退，想一想為什么要開發(fā)這個功能，甚至退回到需求層面，是不是可以有其他更簡單的解決思路。從更高的視野來看，可以避免陷入局部細(xì)節(jié)而無法自撥。

　　如果是未知的知識太多，可以不直接解決這個問題，而是帶著研究的想法，把相關(guān)的知識全部學(xué)一遍，有可能這個困難就迎刃而解了。如果時間有限，可以問別人，并做好記錄，后續(xù)再親自總結(jié)，抓住解決問題所帶來的成長機(jī)會。

　　上線之后的原則

　　以正合，以奇勝

　　幾乎沒有靠運(yùn)氣的出奇制勝，只有以擁有足夠正面實力為前提，并且有一些額外的力量，才能取得最終的勝利，在做項目時也是如此。

　　要想更快，更高效地完成一個項目，離不開日常的積累。項目上線不是結(jié)束，而是成長的開始。一個項目可以提供很多經(jīng)驗與素材，當(dāng)成自己輸入、輸出的一種反饋，找到不足之處，避免下次犯同樣的錯誤。

　　在公司光環(huán)之下成長，而不是單打獨(dú)斗

　　閑暇時間干什么，找個副業(yè)?短期來看，確實能有一些額外的收入，但長遠(yuǎn)來看，即使多出來30%的收入，并不會有本質(zhì)的變化，無非是能更換一些更高檔的電子產(chǎn)品、服飾、日用品。個人的力量太弱小，單打獨(dú)斗不如在公司的光環(huán)下，更高效完成項目的前提下獲得個人的成長。

　　一方面是因為公司的平臺有更多資源，另外基于公司項目的成長，邊際交付成本較低。基于現(xiàn)有的項目，深挖與之相關(guān)的底層原理，這樣才能更快的積累與成長。在做簡單項目的時候，底層原理的作用不明顯，但對于非常復(fù)雜的項目，需要底層原理支撐的時候，自己積累沉淀的技術(shù)就會發(fā)揮出明顯的效果。

　　面對線上問題，焦慮毫無意義，重要的是尋找當(dāng)下解決方案

　　面對線上問題，擔(dān)憂過去或焦慮未來都沒有用。關(guān)注當(dāng)下，冷靜積極地尋求解決方案。失敗既能化為動力，驅(qū)動個人成長，也能毀掉自己，這取決于我們?nèi)绾螒?yīng)對失敗。能打敗自己的不是任何人與事，而是自己。出了線上問題，有兩件事情要做：

　　針對現(xiàn)狀，如何解決。

　　復(fù)盤分析原因，避免下次犯同樣的錯誤。

　　針對"線上已出現(xiàn)了事故"的現(xiàn)狀，需要立即尋找解決方案，這是遇到線上事故時優(yōu)先級最高的事情。止損非常重要，特別是損失在不停的擴(kuò)大時，此時每一步操作都非常重要，如果問題非常復(fù)雜，記得多喊人。把老板、經(jīng)驗豐富的同學(xué)都拉到群里，畢竟在慌忙之中，自己考慮的可能不全面。如果大家有事都沒看到消息，就直接打電話。

　　分析原因的時候，如果是復(fù)雜、涉及非常多團(tuán)隊合作的項目，其實有非常多的原因，從不同的角度分析會有不同的結(jié)果。在復(fù)盤會上，要盡量多的表達(dá)客觀的實際情況，而不是害怕，特別是對于內(nèi)向的同學(xué)。避免在會上不說話，會后又感到后悔，該表達(dá)的時候不要吝嗇表達(dá)。

　　從自己的角度來說，并不是“只要這個線上問題，和我無關(guān)”，我就不用關(guān)注了。這類問題正是非常好的反面教材，即使和自己無關(guān)，也可以成為避免下次自己犯錯的素材。

　　比如本文的各個原則，有些和我沒有關(guān)系，但是在見到這些問題的時候，我做了總結(jié)，避免自己也犯同樣的錯誤。最壞的情況是自己犯了嚴(yán)重的錯誤，導(dǎo)致較大的損失。面對痛苦的經(jīng)驗，是逃避，還是積極應(yīng)對，取決于自己的態(tài)度。不要被痛苦所擊敗，而要將痛苦作為反思的素材。痛苦+反思 = 成長。

　　謀事在人，成事在天

　　將付出的努力與結(jié)果進(jìn)行課題分離，它們之間的關(guān)系類似追求的目標(biāo)與附屬品。有時候我們付出了很多，但是結(jié)果卻非常悲傷，這個時候就要用上阿德勒的課題分離了。付出是我們能掌控的，但結(jié)果不是，所以要把付出的努力與結(jié)果分離。

　　從另一個角度，也可以從目標(biāo)與附屬品的角度來考慮。如果我們追求的是結(jié)果，那一旦失敗確實會非常悲傷。但如果結(jié)果是附屬品，而過程是追求的目標(biāo)，那其實結(jié)果如何已經(jīng)不重要了。