這篇blog算是之前關於重構的乙個總結，導火索是上週花了不少時間把前一段寫的乙個功能模組做的乙個重構。
事實
沒做之前，功能什麼的基本都對，有一些小bug和效率不是很好，問題最大的是我感覺這部分有點失控，心裡一種亂的不安全感，這個感覺很差。
另外就是在處理bug，增加新的功能和用其他方案做優化的時候，可以說是舉步維艱，不僅是效率很慢，情緒上很牴觸。
花了大約3到4個工作日做的重構，完成之後前面列的問題蕩然無存，還順便修了很多bug和效能問題，更重要的是這幾天在做更清晰的設計和簡潔的程式設計，除了很享受的感覺外，還得到了不少的思考和提高。
後續開發的速度，源自結構的優化和情緒的變好，提公升大約有%50--%80（原來是%30到%50，但我實際測下來是這個數字）。
「重構是有好處的」這是廢話，關鍵是重構的意義到底多重要。是不那麼重要的，有時間才能做（實際是專案忙起來，這種認識下的重構就永遠不會有時間做），還是會非常重要，必須成為乙個task的必然組成部分？
做到現在，我的觀點是：重構是僅次於實現前的設計的乙個階段，必須成為每乙個task的必要組成部分，做到90分在收場。
重構如同覆盤
玩rts和棋類遊戲的人都知道覆盤的重要性，那是一段純粹的，安靜的思考總結的時間，也是一段自我提高非常快速的時間。
重構也是如此，是一段可以好好思考和沉澱合理的設計和簡潔的coding的時期，同時可以好好指導自己下一次的task的完成。
在實際專案中，重構過程一般發生在功能都完成的差不多，有零星bug和performance問題的情況下，心情也相對放鬆平靜，客觀上，重構階段也適合思考和沉澱。
所以在長期看來，在重構的過程好好思考，總結以及二次設計和實現，會受益很多。
(2011.8.10)
實際上我對只設計不編碼的人也感到頗為奇怪，或許我的境界沒到，但是這樣真的可以麼？編碼結束之後才能進一步去覆盤，去提公升設計和程式設計能力，單純的設計也就是設計了，如何去檢驗呢？等待程式設計人員的反饋麼？
優雅設計與實現比率最高的階段
無論是讀大師的事蹟也好，還是自己的實踐，所謂優雅的設計和實現是可以達到的，但是根據資質，需要不同程度的練習。
這裡的練習就是指，你需要去實際的做出很多優雅的設計和實現，以至於習慣於此，那麼也就是乙個程式設計師擁有了這樣的能力。
而在限時探索性模組實現過程中，做到優雅設計與實現的確是比較難的，但是在重構時候就自然而然了，這個可以說是乙個**的做優雅設計和實現的階段。
這個就像星際2中大規模部隊交鋒，奮戰了20分鐘之後，終於迎來了20秒的決戰時間，可以好好鍛鍊對抗性大規模部隊交鋒，怎可不好好珍惜？
cleancode rocks
最終寫出很簡潔的**就像打籃球時候灌籃，投了3分，漂亮的過人，蓋了個大帽。。。
這種樂趣大於取勝，是我們的原動力。
clean code也是一樣，那是一種讓你全身欣喜的事情，讓你更愛程式設計的事情，回家的路上，回想一天的工作，會跟自己說，這***才是我想做的。
重構會大幅度加速後續開發速度，提公升開發質量，降低消耗
這個是實際程式設計的時候才會切實感受到的東西， 實際程式設計中，後續開發中面對乙份簡潔的**和亂的**乙個最大區別是，簡潔**下無需費多餘力氣，很自然的就寫的簡潔清晰，人也處於乙個非常舒服的狀態，一天程式設計下來是欣喜的感覺，這像是在重構過程中建立的優雅規則和心態的延續。
而面對糟糕**時候，心裡就很亂，腦力勞動受心情影響非常大，這一點就差狠多了。而且你完全無法寫的簡潔優雅，因為**中已經是缺乏了頭緒，在大面上已經亂的前提下，後續的開發就是沒法做到這一點。而且進一步如果大家開始習慣這樣，這個是非常危險的，就像公司裡出現了不好的習氣，凌亂開始蔓延，熵是預設增加的，需要額外的力量來對抗它。從之前的專案來看，這種凌亂會像慢性疾病一樣，逐漸積累，可能殺掉乙個專案，可能只是讓專案受傷，最後只是剩下「如果我們當初***x，就***「的哀嘆了。
我認為生產力的提公升有%50到%80。
當然，道理也是有條件才成立的，
在後續開發還有比較長的時期的情況下，就毫不猶豫的去做這個事情。
如果已經後期了，那麼就值得商榷了。
做到90分收場
這裡想說這麼幾個意思：
1，90分：60分可以說是功能可以用，時不時的crash，出點bug，效率不太好，80分是當下crash，bug，效能問題都沒有了，外在來看是可以支援遊戲上市的程度，90分是在這個階段上在進一步，結構更加合理，實現更加簡潔，文件也比較齊全，成為後續開發的標準與強心劑，而不是反例和絆腳石。
2，收場：也就是在完成進入下乙個task之前，要把重構工作做好，因為這是最佳做重構的時間，所有東西都在腦袋裡，做起來效率高，不會遺漏。完成的模組堅實，自己心裡也踏實和清爽。這裡有踏踏實實一步乙個腳印的意思，也有get things done以解放自己腦力和精神力的意思。
而之前的經驗是，雖然說完成到差不多那裡，感覺好像是做了很明智的決定，不多不少，但是實際下來，隱藏的問題總是會暴露出來，使你付出比乾脆弄好大得多的代價。
具體問題具體分析+盡量不妥協
是的，這都太理想化了，實際有挑戰的開發經歷過會知道，任務列表都快拉到下輩子了，這時候很多人的壓力也比較大。
衝刺型的開發模式，減免了很多包括重構的科學的開發方式，就如同星際二兵臨城下時候，為了緩解壓力拉了農民去迎戰，短時間的壓力得到解決，長期則給自己帶來了很**煩。
當然兵力相差很大的極限情況，必須如此。
需要做的是拼命壓低自己的妥協底線，當然這個也不是隨便說說的，需要更集中的精力以提高效率，更多的加班以延長時間，但這個是值得的。
覆盤 8月 第4周工作覆盤
本次覆盤任務大於意義 7月第3周目標 目的 智慧型運營平台開發工作 目標 1 智慧型運營平台開發 完成累計資料 web開發 7月第4周覆盤 目標完成進度檢查 1.智慧型運營平台工作發現的問題修復 完成 2.跟蹤處理kafka生產問題 完成 3.視客相伴預約導航協助終端聯調測試 完成 達成亮點分析 1...
2020商業風口覆盤 巨變下的重構與新生
轉眼間，2020就落下了帷幕。雖說大環境談不上理想，但商業世界也在巨變中不斷迭代向前，舊的商業模式正在被打破，新的商業正規化正在被構建。行至2021伊始，讓我們在過往一整年商業變革的回顧中，鋪陳出對未來的啟發與期待。與此同時，直播帶貨的翻車頻率也在逐步上公升，繁榮背後的泡沫開始被消費者戳破。辛巴假燕...
覆盤知識6
1 什麼情況下使用collections.defaultdict?當定義乙個字典時，某個鍵值不存在時會報錯，但是用collections.defaultdict初始化不會報錯，引數可以是int，表示value值是int型別，引數如果是list，表示value值是list列表。2 爬蟲內容 reque...