回複內容：
以上的情況，都遇到過。
典型的一個業務導向的公司，糙猛快的開發習慣，缺乏懂技術通產品，能控場能抵抗業務壓力的技術話事人。隨著時間流逝，開發無規，代碼堆積，人員流動，能力下滑，架構腐化，逐漸走向結構性崩潰的情境：業務壓迫帶來了貼膏藥的代碼，膏藥代碼導致更大的技術壓力，人才流失，疲於奔命，然後帶來更大的業務壓力。就像飛機掉入了失速螺旋，怎麼也改不出來。
曾經花了半年時間，帶團隊花大代價改出過這樣的惡性迴圈，花了大幾百個人日全面重構一個有7、8年歷史的老系統，代價是自己的當時績效對外不好看。
所謂善戰者無赫赫之功，此之謂也。
前人栽樹，後人乘涼。 幹這種活，沒有識貨的老闆，是吃力不討好。
千言萬語，凝聚成一句話：全公司要有靠譜的技術管理和技術文化。這是CTO的職責。
給你歸納翻譯一下，問題簡化為這些：
- 如何提高代碼品質？【開發能力】
- 如何提高架構水平？【架構能力】
- 如何控制產品需求的合理性和迭代節奏？【專案管理-需求分析/專案規劃】
- 如何降低加班強度？【專案管理-資源管理】
- 如何積累知識庫，降低口傳心授的依賴？【團隊建設-知識庫建設】
- 如何提倡團隊合作文化？【團隊建設-價值觀建設/績效設計】
- 如何培養團隊技術梯隊，不強依賴幾個核心員工？【團隊建設-梯隊培養】
- 如何避免自有通過QA才能保障產品品質的困境？【開發能力-品質保障】
- 如何提升系統穩定性和可用性？【架構能力】
- 如何通過產品大圖整理出清晰的業務模型？【架構能力-產品規劃】
- 如何拒絕業務方的不合理需求？【專案管理-需求管理】
- 如何降低人員流失率【團隊建設-可惜離職率】
- 如何在飛速發展的業務環境下回答以上問題？【可落地方案】
自頂向下，依次需要解決的點是：
- 價值觀建設
- 提倡團隊合作。提倡合作？然並卵，誰鳥你，一句現在很忙就把你憋死。作為leader，還是要搞好人際關係，靠刷臉去推合作。
- 提倡敬業和激情。自己先要成為榜樣，不過重要的還是看激勵政策。
- 績效設計原則
- 重視拿結果，更重視執行過程。發現、表揚、提拔代碼寫得好，業務也玩的溜的人。管理不能停留在表面上，要到代碼裡去。
- 重視個人技術能力，更重視技術傳承、培養人。誒，說你呢，沒帶過人的同學別想加工資，想晉陞給我先帶3個徒弟出來。
- 重視技術創新。天天重複自己的人，再老資格也要給他敲警鐘，該fire就fire。擠出項目的時間餘量給有想法的人做點不一樣的事；必須要有一支發明家隊伍，而不是碼農隊伍，所以，搞條鯰魚進去動動風水，會有好處的。
- 產品研發流程
- 流程保護。和產品團隊、業務團隊磨合出固定的迭代流程和節奏，並能堅持下來，堅決抵抗不合理的需求和節奏，有理有據地向上反饋。
- 產品話語權。一個產品設一個技術owner，要具有對該產品的需求評審，設計評審權，開發人員要參與業務調研/業務分析，影響產品設計，爭取產品規劃和業務模型的話語權。避免成為單純的技術資源，疲於奔命。
- 跨部門溝通。提前和產品部門溝通雙方的預期和能力，將產品規劃和技術規劃結合起來考慮，3個月協調一次。
- 團隊建設
- 人才梯隊建設。高手不能太多，也不能太少。微妙，自己意會，橄欖形社會最有活力。
- hire and fire。60%流失率，這窟窿！還是先加工資要緊，狠狠加，先把隊伍拉起來，才有餘力做重構的活。
- 團隊文化建設。不管是美國還是中國，哪個總統/主席，都得有個施政口號，讓人知道你要幹什麼，分清敵我。
- 團隊技術能力發展。先把人找齊了。。。
- 專案管理
- 敏捷也好，瀑布也要，反正要找個合適自己的項目流程，並嚴格靈活地執行下去。
- 加強項目複盤環節，code review。
- 維持一個合適的工作鬆緊度。
- 專案管理的精髓是什麼》》》我個人認為是制度化，制度化的壞處其實非常多，但有一條好處，就值得我們採用：那就是有強大的理由能按我安排的時間、我安排的地點來打仗。優秀的pm無一不是時間管理的高手，敢於向試圖越過制度胡亂插手的領導說不，這就是項目團隊的福音。
- 系統架構
- 與實際需求相關，無非就是提升穩定性，可用性、可維護性、安全性的那些架構招數，譬如SOA、服務治理、中介軟體、負載平衡、降級等等。一個簡單清晰可靠、可快速橫向擴充的系統架構是基石。
- 業務架構
- 業務模型重構
- 模組化，外掛程式化設計
- 平台化架構
- 產品品質
- 編程規範
- 設計模式
- 單元測試和自測
- QA 和 code review
- 故障複盤
- 組織發展
- 知識傳承
- 挖掘技術深度和創新意識
- 內部培訓和外部培訓
- 鼓勵創新的機制
寫完回顧一下，自己都覺得好笑，有點空列大綱無法落地的感覺，呵呵，實際的困難肯定遠遠超出預期。要想改變一條船的航向，首先你得有舵手的影響力（成功資曆，直接管理技術團隊），其次擷取船長（老闆）的支援，再次你得真的知道正確的航向（怎麼做），接著得到船員的支援（公司其他團隊的理解），最佳化調動自己的力量（所有開發都認同你的理念，招聘合適的人才），然後還要避開暗礁（別讓項目失敗），通過一次次的勝利來鞏固你的正義。
太他媽的難了，所以很多人都勸你開溜，他們是對的，因為99%的老闆都看不懂以上這些文字和它們的價值，但老闆還知道加人加工資，說明有希望。~~
問問自己，有這個實力嗎，確信，撲上去。這就是所謂的“技術債務”。
就跟公司債務不能全靠會計解決一樣，程式員能發揮的作用有限。
當然，作為一個程式員，職業道德裡確實應該包含《Clean Code》裡說的"童子軍規則"：以當童子軍為榮，以有女朋友為恥！（錯了，錯了，不是這個，是 當你離開一個地方的時候，要讓它比你來的時候更整潔乾淨。）
不要重構！不要重構！不要重構！（三體人從半人馬座發來遙遠的問候～～）題主接觸這個項目多久了？是空降進來的還是一直在做的？
如果是空降來的。依個人經驗，越是複雜的項目，不同的人對項目的判斷就越容易產生偏差。尤其是之前有一些品質相對高些的項目的經驗的人，反而可能會先入為主的對舊項目的表面品質產生要求，但實際並不一定能夠找到癥結所在，找到了也不一定能制定出周全的方案。
如果是一直在做成長到負責人的，項目做砸有你一份：）那麼之前的做法肯定有不合理的地方。這時候可能已經知道項目有諸多問題，但受人在此山中思維定勢的影響，已經撞到了手段的天花板了。不接受新方法新思路的熏陶，只能一籌莫展。
個人建議是，起兩個團隊：一批外部調任招聘為主，技術水平要高，主做支援系統；一批項目內抽調為主，業務理解要精深透徹，主做核心業務重構。兩個團隊要保持高度溝通隨時交換經驗，同時要頂住壓力不被抽掉去攻堅新業務（苦了剩下的人了：P）。節奏上建議選擇有代表性的核心模組，一直做到藕合度滿意為止。
通常第一步是最難的，第一個業務拆分結束後，成本投入和實施步驟都有譜了，業務架構的方法論也有了，後面第 N 個依法泡製就行了。與大多數人相反，我認為這反而是大展身手的時候。
首先，難道你們都沒發現“項目在賺大錢”這一點嗎？面對一座金礦，難道你一定要買來全世界最好的鎬頭才能開始挖？你就不怕被別人挖光了？
第二，沒有多少公司有google那麼牛逼可以只招全世界最頂尖的人才。幾個牛人帶著一堆普通人才是業界常態。這種情況下，代碼品質不可避免的會有所降低。講句不好聽的，就算是google，隨著時間的推移，也會有一堆不知所云的垃圾代碼和冗餘架構。各位鼓勵跳槽的，難道就不擔心下一個公司的代碼也是如此爛嗎？在國內，就算是bat這個層級的公司，爛代碼也是不少見的。到時候難道又跳槽嗎？
難道你就這麼自信一輩子唯寫好代碼不寫爛代碼？只與頂尖高手合作不搭理剛畢業的菜鳥？
所以，必須學會在高速行駛的汽車上換車胎（以下只關注技術部分，至於跨部門合作／與產品 扯皮之類經驗，美女rd可以靠姿色，土豪rd可以靠請客，屌絲rd可以靠同為屌絲的同情心，總之，各村有各村的高招，只可意會不可言傳）。
具體來講，無非就是幾個方面：
1. 深刻理解業務。這是一切的前提，這一點決定了你“能不能成為一個架構師”。在理解業務的基礎上，你才能進行架構，才知道哪些模組是可以熱替換的。事實上，很多龐大的系統其實真正不可熱替換的部分只有那麼一小點兒，其他東西都是可以通過熱替換逐步改善的。當80%的東西都改善以後，剩下的20%也就不難處理了。
2. 打好技術基礎。如果說第一點決定了你“能不能成為一個架構師”，那麼這一點就決定了你“能不能成為一個好架構師”。有足夠的技術基礎，你精心refine的架構才不至於又變成別人口中的垃圾，你的繼任和屬下才不會發出跟你一樣的感歎。
3. 代碼很髒很亂這一點，是最不重要的點。在有了良好的架構的情況下，代碼不管多髒多亂，其影響範圍也只有自己模組那一小部分。如果代碼已經爛到會影響整個架構的情況，那有以下幾點可供參考：a. 你的架構是否藕合度仍然太高？b. 你是否派不夠資深的人承當了非常重要的任務？
事實上我認為真正的架構師是絕不會脫離代碼一線的。一個系統中最難最有挑戰性的部分，正應當是架構師親自coding的部分。如果你親自coding的結果都不夠滿意，那你應當考慮的是，你所擁有的資源是否足夠搞定這個項目？是否應當降低項目追求的目標？
4. 架構是一個trade off的過程，過於追求低冗餘度和過於追求效能都會導致很高的實現與維護成本。成本是架構師第一該考慮的東西。
5. 可能你並不是架構師。完全沒有關係，人人都應當站在架構師的角度去考慮問題。當你站在架構師的角度考慮問題的時候，“代碼髒亂”，“架構冗餘”，這些問題看上去又會有更深一個層次的感受。你也就不至於在面對龐大而表面上無序的系統的時候，感覺看不到方向，而無從下手了。
總之，還是那句話，放著金礦不挖天理不容。有金礦的前提下，架構亂你才有機會。這麼亂的架構都能掙大錢，你把架構隨便改善一些，豈不是更能掙大錢？像這種系統，我們TFS上面一大堆（十來個吧？！反正絕對超過十個）
大部分都是純手寫的哦（當然不是我寫的，我是專門來擦屁股和最佳化的）。大部分都是純手寫的哦（當然不是我寫的，我是專門來擦屁股和最佳化的）。
隨隨便便開一個aspx都千把行JS，隨隨便便開個js檔案都3K+行JS，隨隨便便開個.cs檔案都幾千行，隨隨便便展開個方法都幾百行，你跟我說推了重寫~~？！隨隨便便開一個aspx都千把行JS，隨隨便便開個js檔案都3K+行JS，隨隨便便開個.cs檔案都幾千行，隨隨便便展開個方法都幾百行，你跟我說推了重寫~~？！
別想了，就這套破玩意也是百多號人用了幾年才寫出來的，現在每天還在遷入大量的Code呢。別想了，就這套破玩意也是百多號人用了幾年才寫出來的，現在每天還在遷入大量的Code呢。
實在忍不了，大不了直接走人，沒什麼大不了的事情~~少吐槽，多幹事。劃分成模組，混成一團就劃分一個大模組，只對公用介面寫好文檔，這樣即使裡面一坨屎，也沒用辦法修改，但是還可以繼續用，修改就建立一個模組實現新的功能。這樣就把那坨屎個從今後的開發中隔離了出去辭職跑路，祝你早日解脫。沒什麼可建議的，你能救的只有自己。
贈幾句良言與你：
1. 不在其位不謀其政，錢沒給夠別瞎找事
2. 沒break就別輕易推倒重來
3. 戒掉代碼潔癖，dirty fix也是一種方法
4. 再牛逼的架構也不能解決所有問題
5. 做事看人，成事看天
6. 對自己好點，提升自己，愛護自己
我相信你是很有理想的，我也是，但別把一腔熱血灑在垃圾堆裡，不值得。跳槽吧
