程序員如何挽救日漸失控的項目？

01-14

接手一個新項目，面對以下情況，該如何解決:
1.代碼很臟很亂:
冗餘度高、
廢棄的太多、

編寫質量差、
技術棧陳舊鬆散、
風格百樣、
臨時性一次性的hack邏輯、
難以確認哪些代碼在生效以什麼方式生效。
2.leader們不大重視代碼質量，只重開發速度和可靠度。
程序員拿代碼質量不當回事，或者早已沒有能力寫出漂亮的代碼，各種將就、湊合。
3.架構水平不夠。很多項目拆得不合理，拆完以後，變成九龍治水的局面，一個信息，多處維護，同步負擔承重。

4.迭代速度高，核心項目每周平均4個發布。
5.各種不合理的要求。
有時候、一期工程和二期工程並行開發……
老闆為了搶佔市場，不惜一切代價提高迭代速度。
比如某個業務做壞了，有12天的壞數據，修復這個壞數據，依賴不可控的外部介面。
上面下死命令，要求在8小時內修復。
（最後也只能是一個折中方案，上面勉強接受）

6.加班嚴重，有同事連續工作38小時。
7.沒有文檔或者文檔太舊，公司沒這習慣，各種迷霧，只可意會不可言傳，老員工腦子裡的東西，信息不對稱嚴重。
8.部門壁壘嚴重，跨團隊做項目，異常低效，各種踢皮球、資源不給足、進度滯後。
9.人員流動很大，每年換掉60%的人。
10.產品巴不得大而全、又催活如催命。
公司高層在每個時間段，會提出一個主題、若干副題。

產品圍繞這些做需求，多個idea互相競爭，搶奪開發和QA資源。
過了階段，再想做這方面的idea，就難了，不會給你足夠多的資源。
所以，產品一搶到資源，就巴不得狠狠地干一票。
11.業務模型混亂、耦合度高，從來沒有整理過，綁架項目設計。
多數產品經理出需求，都只求局部最優，不考慮對整體業務結構的影響。
12.項目基本靠幾個老leader和QA扛著。
13.項目在賺大錢，對可靠性要求很高。

重構代碼，面臨巨大內部阻力，特別是QA的阻力。
總之就是:
基礎設施差、
coder懶惰且無責任心、
項目不養人（技術類員工發展慢）、
開發速度越來越慢（擴張的無底洞）、
可靠性越來越難保障（如何狂風中的蠟燭）、
監控報警晝夜響個不停，每天提心弔膽、
越來越沒有成就感，天天干爛活兒、

整個公司都疲憊不堪
公司目前的應對辦法，就是:
1.加工資
2.加人
3.加機器、降低單機利用率
4.加監控報警，人肉不分晝夜盯著，一有動靜就去查
5.產品天天去分析數據，導報表，看哪裡可能有問題
各位有什麼好建議，如何擺脫這種痛苦的局面？

以上的情況，都遇到過。

典型的一個業務導向的公司，糙猛快的開發習慣，缺乏懂技術通產品，能控場能抵抗業務壓力的技術話事人。隨著時間流逝，開發無規，代碼堆積，人員流動，能力下滑，架構腐化，逐漸走向結構性崩潰的場景：業務壓迫帶來了貼膏藥的代碼，膏藥代碼導致更大的技術壓力，人才流失，疲於奔命，然後帶來更大的業務壓力。就像飛機掉入了失速螺旋，怎麼也改不出來。

曾經花了半年時間，帶團隊花大代價改出過這樣的惡性循環，花了大幾百個人日全面重構一個有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文件都幾千行，隨隨便便展開個方法都幾百行，你跟我說推了重寫~~？！

別想了，就這套破玩意也是百多號人用了幾年才寫出來的，現在每天還在遷入大量的Code呢。實在忍不了，大不了直接走人，沒什麼大不了的事情~~

沒什麼可建議的，你能救的只有自己。

贈幾句良言與你：

1. 不在其位不謀其政，錢沒給夠別瞎找事

2. 沒break就別輕易推倒重來

3. 戒掉代碼潔癖，dirty fix也是一種方法

4. 再牛逼的架構也不能解決所有問題

5. 做事看人，成事看天

6. 對自己好點，提升自己，愛護自己

我相信你是很有理想的，我也是，但別把一腔熱血灑在垃圾堆里，不值得。

從源頭抓起，治標治本

辭職跑路，祝你早日解脫。

基本上小公司還有可能你當個技術負責人推倒重來挽救一下，大公司的話自己走人是最有效的。

少吐槽，多幹事。

看完這個之後，我覺得軟體工程課程以後要加一章：如何抵禦過度業務壓榨

估計大部分創業型公司初中期都會遇到這些問題吧。

我們公司開始，也遇到了類似的問題，然後現在的解決方法是自己開發了一套基於SOA的開發平台，然後配合公司管理制度來解決：

1、基於平台開發的話，開發人員用構件進行邏輯的拖拉拽，然後計算機根據構件轉譯成代碼。機器寫的代碼，連注釋都是自動生成的規範化注釋，所以基本上解決代碼髒亂和質量差的問題。ps：系統里沒有能完成需要功能的構件，可以自定義構件。我們公司強調盡量不要直接寫代碼實現，哪怕很簡單的功能也封裝一下，便於管控。

2、代碼質量控制，我們公司現在採用的設計評審。一般是兩級評審，公司層做需求向設計過渡的整體性設計評審。項目組，自己做不同功能模塊的設計評審。項目組的評審很細，設計用到的構件都要評審，後面構件升級了，所有涉及到的模塊都能快速定位。

3、架構問題，我們是統一架構了就不再提了。

4、我們公司分成研發部和開發部，研發部負責平台的迭代，開發部負責項目的迭代。一般項目更新，每天都有。平台的迭代，一周一到兩次。而且，平台還分成了開發版和穩定版。項目組，一般都是用穩定版的，穩定版更新頻率更低。

5、項目並行，這種也有遇到。我們是採用績效控制+內不立項的模式。對外的合同和對內的立項是不同的，比如我們一個合同一期是200萬，然後客戶在內部提了很多不在範圍內的問題。但是老闆感覺客戶很重要，就響應了人家的要求。這個時候，我們內部就會產生立項，老闆答應人家的額外功能，就當成公司內部的成本。不能強加給項目組。

6、加班的問題，項目式的公司都有吧。關鍵是績效控制好，比如項目合同周期3個月，那麼里程碑節點順利執行，就發100%的績效。節點比計劃還順利，2個月你就可以拿到3個月的績效。如果計劃延後，整個項目組的績效就會逐漸降低。

7.我們公司做到現在都還有文檔積累的問題，這個是公司發展的必然現象。對新人的學習不利，對公司知識儲備也不夠。

現在我們採取的措施是，項目結束後做項目總結，把項目關鍵點的資料形成文檔，統一入庫。

8.部門間踢皮球的問題，屬於項目初期計劃和責任分工不明確，而且估計你們公司沒有成型的仲裁體系。該是誰的問題，分工和績效掛鉤的，推不掉的。

9.人員流動很大的問題，不是很好解決。良性循環的公司，基本上很少遇到。我們公司是統一平台開發、統一入職培訓，而且和幾所高校有人才輸送協議。如果感興趣，可以聯繫我，我可以提供部分我們平台的資料。在統一架構下，人才的流動不是很大，因為脫離平台之後，他的舞台沒有想像的那麼大。

10.大而全不是不可以，但是要有階段性的目標。搶佔資源的時候，你要給我立項報告，用多少人產生多少產值，完不成要背鍋的。

11.業務模型和整體設計對項目經理要求很高。這個是整體培訓體系的問題，要讓新人能夠起來，走到項目經理的地步上周期很長，甚至項目經理本身的能力儲備和個人知識體系都要更新。建議也可以學一下我們公司的設計評審模式，讓有經驗的人集體評審，做知識匯總。

12.公司是老員工打的天下，幾個老leader和QA扛著是必然的啊。創業者和就業者心態都不同好吧。關鍵是培養體系要建設上來，學會新人培養。我們公司採用的是以師帶徒，我們平台有分級考核，學生考到了更高級別的平台認證，老師都有獎勵的。

13.「項目在賺大錢，對可靠性要求很高。」這一條，打個廣告。推薦用我們公司的平台，一百多個項目驗證，足夠穩定可靠，系統架構給一個專業的公司來做，比請一兩個架構師靠譜的多。

人生有幾件事不可挽回：

1：潑出去的水

2：逝去的青春

3：複雜而失控的項目

現實是，如果你向老闆說這個項目要推倒重寫，甚至僅僅是說要大改，就足以把領導嚇得一身冷汗。領導很可能只是希望你在保持現有框架的基礎上修修補補，發揮大神之力力挽狂瀾。可是一旦你真的鼓起勇氣準備動手，你一定會在某個時刻望著一堆莫名其妙的bug發獃，絕望，然後在心底把原作者詛咒千遍。前團隊欠下的技術債必須還清，只是恐怕老闆不會給你這個時間。

曾接手過一個項目，那個項目真的讓我大開眼界。原來代碼可以這麼寫的，各種耦合，各種直接寫在代碼里的常量（你可以體會這邊改了一個數值在另一個文件里也要相應修改的感受嗎），還有各種相同函數的拷貝，更讓人崩潰的是連環bug，修復一個bug誕生更多bugs！是的，加s表示複數。。。折騰一圈受不了了，最終還是重構代碼了，加班了數月。

祝題主好運哈哈。

據我多年從業經驗，能加薪的項目都不是爛項目。

只能盡量去做到最好，我目前也在做一個項目，隊友有兩個坑貨，寫著很差的代碼，我只能每天review，不好的刪掉並加註釋給他們看。這樣或多或少會帶來點成效。不過最主要還是要制定規範吧，我之所以那樣做是因為我的話沒有分量，他們不會在意，我建議和項目經理商量制定好規範會好很多。如果你說話有分量，最好的建議是把坑貨開除掉，那樣最好不過～

過去不必思量，現在不必緊張，未來不必恐慌，念佛自然安詳，南無阿彌陀佛，阿彌陀佛，阿彌陀佛，阿彌陀佛，阿彌陀佛，阿彌陀佛。

近的因緣可以自己改變，遠的因緣鞭長莫及，豈能盡如人意，但求無愧我心。

此事尚可改云何不歡喜，此事不可改憂惱有何益？這件事還有迴旋餘地，那為什不歡喜呢？這件事已經沒有任何其他可能了，憂惱有什麼好處嗎？

劃分成模塊，混成一團就劃分一個大模塊，只對公共介面寫好文檔，這樣即使裡面一坨屎，也沒用辦法修改，但是還可以繼續用，修改就新建一個模塊實現新的功能。這樣就把那坨屎個從今後的開發中隔離了出去

從一個純架構設計方面給一點建議.

看所有人的回答並沒有真正講到架構設計方面的內容，我就漏個短。隨便給一點建議。

如果哪裡有問題歡迎提問。

另外我的習慣以及做法就是下述的內容了。

哦，使用這種方式熱替換過一個彩票項目，該項目已經跑2年了。

其實核心就差不多類似灰度發布一樣。「灰度開發」哈哈哈，瞎扯的。。不存在這破概念。。。

但是這個建議有一個前提.你們公司有一個聽的明白下面處理方式的原因以及有足夠大的膽子.

我這裡的建議是建立在你的項目真的有你說的那麼糟糕的情況下哦~~~~~~

另外你也要有足夠的能力去做下面的建議.

1.從你開始.所有功能使用適配器或橋接或其他任何結構型的設計開始.

脫離原本代碼,從你開始=全新的開始.

2.你的文中提到了修復舊BUG.舊內容跳到什麼新內容或舊的功能要修復.不修改舊代碼.使用職責鏈跳過來,跳轉到你的新代碼中.做注入處理.

3.實在無法注入或代價太高.抽象舊的代碼(照著舊的業務邏輯主類完整不變整一個抽象基類很容易對吧,,複製粘貼即可.把函數改成抽象函數),然後做個抽象工廠,每個函數打上BUG或版本標記屬性.通過屬性調用或跳轉新代碼.

為什麼這麼做?看你的描述..大家都挺忙.這樣不影響大家的工作唄.他們愛按原來的寫就按原來的寫.無屬性配置默認調用原本函數.

4.保證上述3條做到了的情況下，開始讓大家往你這邊轉。然後逆襲整個公司，恭喜！你做老大了。

對了，寫完看了看。你這公司還能接受不斷添加新機器啊。。這還不好辦？加個mq隔離整個業務，新業務拿你的mq處理去做完全可以脫離舊的內容。

什麼？有人再說我這麼整舊的業務或功能集成不到一塊去？難改的反射載入他們dll進來，好改的直接自己寫。

當然如果你還糾結說我靠，自己寫model自己寫組裝什麼的好煩？這都做不到反射封裝估計第3點你也做不到了。。

什麼？你們公司對於運行速度有要求？反射效率低？緩存所有反射入口。都單機單幹了，這個就可以無視了嘛。。。dll只載入一次。相信我，除了海量級的訪問外，還真的看不大出來。你可以跑的試試。。

不知道題主是目標做啥。。如果是架構師，恩...這種破事就是我的日常生活啦...

不過你得小心...可不能像你原來拿到東西就做啦...推薦我的日常...早上思考人生,下午3點前思考人生.

下午2小時產出100行有效核心代碼..真的就夠了- -其他的.扔給碼農吧!

活臟點沒關係，只要錢夠就行。代碼這麼亂，流失率這麼高，項目這麼掙錢，你要是能扛下來，工資不是隨便開嗎？