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

　　在分析若干線上問題之后，會發(fā)現(xiàn)很多問題并不是非常罕見的難題，而是由一個(gè)個(gè)較為明顯的小錯(cuò)誤積累而來，為什么會犯小錯(cuò)誤?或許是因?yàn)閮e幸心理，或許是因?yàn)橹豢吹搅司植康睦�益。從某一個(gè)例子來看，確實(shí)會有“偶因一著錯(cuò)，便為人上人”的僥幸，但是統(tǒng)計(jì)大量案例可以發(fā)現(xiàn)，大部分情況并不會有正面的結(jié)果。

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

　　交流溝通時(shí)的原則

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　不要給合作方評估工作量

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

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

　　開發(fā)階段的原則

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

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

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

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

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

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

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

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

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

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

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

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

　　先寫注釋，再寫代碼

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

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

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

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

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

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

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

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

　　編碼：不要使用特殊技巧

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

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

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

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

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

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

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

　　測試階段的原則

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

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

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

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

　　思路錯(cuò)了。

　　未知的知識太多了。

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

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

　　上線之后的原則

　　以正合，以奇勝

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

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

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

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

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

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

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

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

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

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

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

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

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

　　謀事在人，成事在天

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

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