這篇文章的內容其實是我一直想說的，郭昂寫的即全又現實。領導都怕重構的，其實也沒並要一開始就大刀闊斧的重構，一般來說可以在實現新功能時就一邊重構一邊做新的功能。慢慢的，那些舊的過時的**自然也會被淘汰的。
郭昂在前後兩家公司的工作中，主持和經歷十餘次重構，涉及**和架構。在他看來，如果不做重構，任**隨意膨脹，就會產生糟糕的架構，其惡劣影響包括：
首先是開發效率的降低，在糟糕架構下加進新功能，會受之前**的影響，可能存在意想不到的改動點和問題點，開發和除錯時間都會大大增加；其次是故障率的提公升，在質量低下的**中，總是容易藏著很多不易發現的坑，這些都會成為故障的隱患；同時，架構也會使得需求的完成大打折扣，使得設計好的目標，因為架構限制或者效能等原因，只能完成80%甚至更低。接下來，他列出了重構要解決的各種問題：
接下來，他總結了自己重構經歷的經驗和感受，指出「第一道難關是如何過領導這道關」：
很多領導都要揹著產品指標和任務，重構這種事情，在很多時候，有可能是「費力不討好」的代名詞，因為在大多情況，無法幫助領導完成指標。他的建議是：
讓重構與某些技術或產品指標掛鉤，例如完成新產品、改進效果、提高效能等，相當於是重構伴隨著其他改進搭幫上線，那麼這種情況可以比較順利的完成重構。在團隊規模***的前提下，郭昂建議可以分工，一部分開發新架構，另一部分進行架構改進，保證長期目標和短期目標都可以落實：而如果單純為了架構的合理性而去重構的話，就需要去說服領導，為什麼原來的架構會降低開發效率，新做的架構能帶來哪方面的提公升。一定要讓領導明白，這個能帶來實實在在的長期收益，不管效能、效率、安全等都可以，而並非只是「看著不爽」而進行的重構。
值得注意的就是，不管從**還是設計角度上來看，都要讓現有做的事情能夠復用，而不是新架構上線之後就會被廢掉。對於漸進式重構，郭昂建議：
以月為單位，快速的迭代，能夠很快的看到效果，並且小規模投入使用。對於重構中新架構的設計，郭昂指出：前瞻性、復用性、避免技術完美主義、避免使用過多未經廣泛使用的前沿技術，這都應該注意。
他認為：重構的負責人非常重要。
作為重構時的負責人，一定要緊跟**開發的過程，並隨時進行指導，一般情況下，不要相信寫出糟糕**的人，經過略加指導就能寫出漂亮**了。……重構的工作一定要做細，迭代中的**檢查也是必不可少的。
大多數的重構都是可以避免的，這需要從以下幾個方面去提高。郭昂文中有一句話可作總結：
不管怎樣，重構，一定不能是為了重構而重構，……最重要是找準其要解決的實際問題。
大多數演算法及其推廣
有一種演算法叫大多數演算法，大多數意思是給定乙個陣列，已知裡面有乙個數的統計個數超過了總數的一半。比如1，2，3，1，1，1 那麼1就是大多數。有乙個簡單的演算法就是排序，然後取中位數。時間複雜度為o nlogn 那麼有沒有更快速的演算法呢，這裡介紹一種o n 的演算法。其原理就是開乙個臨時變數，和...
摩爾投票法和大多數
摩爾投票演算法 假設有這樣乙個場景 票選村長，每人可投一票，我們將候選村長從1開始編號，村民們在票上寫上候選村長的編號即可完成投票。那麼最後統計的票可形成乙個整型陣列。那麼誰是村長呢？票數過半的那個人。摩爾投票演算法可以快速的計算出乙個陣列 現次數過半的數即大多數 majority 演算法核心思想是...
寫給大多數早期創業者
最近看了一些專案，基本上看了都不敢投，自己想了想，原因就是6個字 太簡單，太複雜？簡單的其實還好，因為一般來講，都是由於是沒經驗的小伙，覺得暴富就在身邊，想個點子就是別人沒想過的，看見塊肥肉就覺得是自己的。這種基本上 就不投。怕的是複雜的，因為發現創業者智商實在是高，首先是賺錢兜的圈子大，搞乙個很複...