在感覺項目代碼的構架不行的時候,你們會怎麼辦?

12-29

自己的單人項目,意向客戶天天等著試用
突然覺得之前很多東西沒有設計好,越是往後寫越是覺得一種藥丸的感覺.
很多東西一開始都沒考慮到,需要擴展的地方現在完全是在硬加了.

可以去看看《重構》這本書。重構實際上就是調整代碼，在保持代碼功能不變的情況下，調整代碼，使得它更容易被修改。

有幾個要點需要注意：

重構並非重寫，不要將代碼推倒重來。
有些人口中說的重構，其實指代碼重寫。之後重寫失敗，就說重構無用，這樣就很冤枉了。重寫風險很大。舊系統無論看起來多爛，至少是可以運行的。而重寫代碼時，新系統有很長一段時間不能運行，並且需要維護舊系統。並且有可能舊系統並非真的很爛，可能只是習慣不同，可能有些特殊情況你不知道，重寫不一定可以做得更好。
儘可能保證代碼時刻可以運行，並且功能不要缺失。

做到這樣，你重構的工作就隨時可以停止。不能幾小時、幾天都停不下來。
重構和改變功能，同一時間內，只能做一樣。
在重構過程當中，就算髮現了之前錯誤，也不能修改。應該記錄下來，等做完這次重構再修改，不然很容易在修改過程中引入其它錯誤。
重構是在項目整個過程當中的一種習慣，並非是其中的一個階段。
不要定下一兩周時間，說這個工作是重構。應該在整個項目過程當中，隨時開始，隨時停止。每一次重構都是很細微。
何時開始，當你感覺添加代碼已經很勉強時，就需要重構。
何時停止，當重構之後，你當前的修改已經可以順利進行時，就立即停止。
添加修改代碼已經不勉強了，就立即停止當前重構，繼續實現新功能。剋制住看不順眼就重構的慾望，只要可以順利完成當前工作，就立即停止。項目其它地方代碼無論多爛都好，跟你今次的修改無關，就不要動它。不然你停不下來，白白浪費時間。當下一次需要添加功能時，再繼續上面步驟。或者你可以將看不順眼的地方記錄下來，等有時間或者想休息時候，就去調整一下，但需要隨時可以停止。
不要害怕修改代碼。很多人都害怕修改代碼，傾向於完全不修改代碼，就添加功能。
這樣之前的代碼就會越來越勉強，到有一天就會整個崩倒。

架構很多時候並非一開始就全部設計好的，很難一開始就可以考慮到所有可能性。一開始，只要大方向正確就行，有大方向就可以將項目砍成幾大模塊，之後再細分。細分到不確定、需要猜測時，就需要停了。某人覺得需要猜測的事，對更高水平的人來說，可能就是確定的。

細分之後，有時可以試試從下往上寫，先做些確定好，不容易變動的工作，比如編寫一些實用函數，一些小類。慢慢就可以在其中發現某種模式，將其將抽象往上層推。架構往往是進化出來，而非是設計出來的。假如已經有現成的，類似的項目，可以適當參考，也可以少走很多彎路。

《重構》這本書講述構的思想和各種具體的重構方法。一旦有了重構習慣，無論起初代碼多爛，你都可以在其中工作。但有些公司，明明代碼很爛，又不可以修改，或者每一次修改都需要填寫一大堆的報告，真是這樣的環境，工作起來就很痛苦了。

十多年的軟體研發經歷告訴我，所有的項目、系統到後期都會遇到類似的問題，其中人員變動、需求變更是最大的原因。

在日本，很多銀行的軟體系統還在使用COBOL，美國國防部核彈部隊仍在使用軟盤，估計很多年輕的程序員連軟盤什麼樣子都不知道。那麼他們為什麼不推倒重來呢？歸結起來其實就是風險和成本的問題。

一個系統在生命周期可能十年或者更多，在此期間，如果沒有完整的開發、運維和更新記錄，你甚至連一份完整的需求、設計文檔都沒有，在加上人員變動，有時候系統裡面一個看似很tricky的東西修改掉就可以造成系統的重大故障，在這種情況下重新整理需求本身已經不可能，把系統推到重來更簡直是自殺。

就風險來講，本人曾經在金融IT行業做過，參與過銀行的核心系統升級和切換工作，開發工作動輒就是上千人的開發團隊，涉及廠商上百家，預算以億計，開發完成後升級切換的過程跟衛星發射有的一比，前期演練N多次，切換現場有指揮中心、科技隊伍、廠商保障隊伍、後勤隊伍，醫務保障隊伍一應俱全，如果切換失敗影響營業，不但可能造成巨大的經濟損失，銀監、客戶也絕對不能饒了你。

就成本來講，一個系統到了一定年限一般來說有兩種可能，第一種是系統已經逐漸不再符合市場需求，起到的作用越來越小，那麼，花大成本對系統進行升級改造和替換都不再划算，用最小的代價保證系統可用就行。如果一個系統市場前景越來越大，原有技術架構和設計或者功能設計不滿足市場需求，那麼就有必要花成本對系統進行升級改造或者乾脆推出換代產品進行替換。

回到話題，怎麼樣才能避免項目/系統後期一團糟的情況呢：

1. 制定系統設計、開發規範和研發流程，並嚴格遵守，最大限度的避免人員變動造成的系統架構、設計和代碼風格的變動。
2. 把系統重構貫徹到每次代碼變更的過程中，不符合規範的代碼、有問題的代碼發現了就修改掉，不在系統的傷口上撒鹽。不因為時間緊迫而錯上加錯。
3. 周期性的進行代碼Review和小範圍的重構。

在敏捷開發裡面常說的一句話是：make it work, make it better, make it perfect。先把系統跑起來實現商業價值，再不間斷進行優化，把這三句話貫徹到每一個研發周期中，就能最大可能的延長產品的生命周期。

更新：
評論裡面有幾個用戶可能對醫療保障有疑問，貼個圖上來吧

各位朋友一定要注意：
1、在管理者看來，重構前輩的代碼是沒什麼績效的，而且風險還大。而救火、在臃腫老代碼上不斷加東西實現業務需求是有實實在在的績效的。
2、整天提重構還容易得罪人。你抱怨別人架構垃圾，整天嚷嚷要重構，你可知道，這個架構正是當年某位前輩設計的，這前輩現在是你領導的領導呢。

所以，職場的事情，複雜得很，不可只從技術角度看問題。

剛入職的時候，jira上被assign了上百個bug，很多bug無法解，新feature很難做。
摸清套路後，決定一邊解bug一邊重寫（不是重構，重用少部分邏輯）。
後來新版本上線，一口氣關幾十個bug。
酸爽！

複雜的系統總是源於簡單的演化。你的知識不斷進步，需求不斷變更，所以有必要的話可進行重構，在一次次的重構下，你會有意識地去做一些有拓展和可維護的行為。

不要想那麼多，先讓客戶用起來再說，確認目前的需求，確認目前的東西能用（是能用，不是好用）。
很多你擔心的問題其實根本不是問題，你擔心不好用的地方其實客戶永遠也不想去用。
重構嘛，單人做的有明確客戶的東西，基本上不可能大規模重構，不要想太多。

現在工作也是可以選擇的，老大分配任務，我會先了解這個項目目前架構如何，如果是一坨屎，我是不會接手的，非要接手就按我的架構重新來。不過如果給你得項目能夠讓你感覺到這是一個精心設計的架構，層次分明，結構清晰，擴展性和靈活性都非常好，我想你會心情很愉快的接手的。

一般只要稍稍有一點架構的項目，當覺得架構不行的時候，大多數都是業務已經發展很多了，但架構並未跟上。比如：當有一個新業務需求本質上需要調整架構才合適的，但可能因為上線時間急，只做了臨時方案（類似打個補丁），久而久之，這樣的事情多了，架構就開始亂了。
解決這個問題，沒有捷徑，只能把以前的債都還上：重新調整架構。
這種事情本身是越早成本越小。

但對你這個項目不是，你是一個人的項目，也沒個商量的人。本質上是自己水平不夠且需求不清。

上個月中旬接下了一個組的所有程序，花了三天時間看代碼，發現有的重大多線程bug，這些服務端程序隨時有生命危險！！！

呵呵的是改這個bug就要改框架，加上初代代碼很多問題是當時沒考慮倒的，遲早會雪崩的

現在只能白天上班寫老框架代碼，晚上寫新框架代碼。

首先，你這個不行是什麼樣的不行？你得先知道為什麼這個架構不行，原因無非就是實現困難和滿足不了需求，另外就是代碼上的問題了，一個好的架構不應該過多的描述代碼，除非制定架構的人有經驗，也能夠清晰的描述代碼的邏輯性和意義，不然會讓技術人員局限於某些框框內。
另外這關係到了你採用的軟體工程里的模型，對於個人開發者(我和問主一樣都是個人開發者)，我推薦使用增量模型，既你寫多少代碼，就要測試多少代碼，能看到那些效果，也能得到感覺上的反饋。好多其它模型的設計方法都是定義一個框架，規定寫什麼寫什麼，寫的時候就不管了，也不會考慮到"可見可得『』這個東西，我曾經寫過網站，就是做到了寫多少代碼就有多少的效果，那樣的好處非常多，對開發人員有激勵作用，還可以實時的找出問題和錯誤。

基本上我要告訴你的是你寫多少代碼就要有多少的效果，沒有效果寫的代碼也要是圍繞著效果，這樣你會發現許多不開明的東西變得豁然開朗了，組織結構也變得有靈性了，假如有bug，你也知道在哪。其實我更好的建議是，在你懂得一個軟體如何實現時，最好是寫一份文檔描述一些東西，這樣會更加清晰一些東西。

至於架構，我覺得一個個人開發者你能弄什麼架構？不需要，你只要按照一些模型如增量模型，瀑布模型，螺旋模型等等寫代碼就可以了，可以根據個人的思維選擇。

一個好的架構師不僅要考慮的是代碼，他考慮的東西很多，可能也會決定團體採用什麼模型，但是更多的時候是靠個人發揮，與其抱怨不如接受。

你要知道的是一個架構師比你普通程序員的水平要高出許多許多，他思考的也更多，不是你嘴頭說說不都是搞開發嗎那樣的。

所以他的選擇也是比你要高明許多，選擇重構代碼是笨人的選擇，要麼就是心浮氣躁的人乾的事，代碼的重構一般只有某些特殊情景才會發生，所採用的軟體版本跟不上時代潮流，即新軟體的功能更加安全穩定，需要更新，等等。

如果有人開口就說重構代碼，我只會對他說呵呵，更有甚者要重構全部代碼，那如果不是特別需要，基本上就是那些菜鳥乾的事。這種人在公司很招人厭惡，就好像你玩lol，玩了一會隊友突然說英雄沒選好，重玩吧。哎呀，我符文選錯了，重玩吧，么么噠。哎呦，我天賦選錯了，重玩吧，重玩肯定能贏。

這種人不是傻是什麼？

以前是不能忍直接拍案而起直接重構搞起，

現在是先等等，想好了再做。

先理解運行原理，確認理解了才有資格去評論思考。

充分尊重作者，想他為什麼會這樣寫，時間，態度，能力，需求變化。。很多其實都是事後諸葛亮，當時自己寫未必更好。

還會看這個代碼解決什麼問題，是否是關鍵，值不值得花費很多時間優化的收益。

也需要思考，是不是真的有問題，還是僅僅自己的視角技術閱歷上看覺得有問題。

是不是本身需要重構，還是僅僅自己覺得牛逼想表現自己才去做。

做的時候也要考慮，重構是按自己的路子寫了一遍，還是站在程序功能維護角度寫了一遍。

力度也要考慮，殺雞牛刀，殺牛雞刀都不可取，難得的是恰到好處又適當有餘地。

以前總想著「我能，我可以，我認為」去思考做事凸顯自己能力來做事，程序是表達自己能力的手段，可能多是為了證明自己。

如今是開始尊重程序，好比自己是監護人帶著一個孩子，想「如何能讓它更成為它自己，關注它的能力充分發揮，和成長軌跡和空間」。

首先你不能說現在的架構不行，你得說現在的架構隨著時間的推移和業務的變化，已經不能完全滿足現在快速變化的需求。這樣之前做這個架構的人聽了，也能明白你的意思是業務的變化讓架構不能滿足需求，而不是做架構的人做的太水。
沒有一蹴而就的完美架構，只有不斷重構的完善過程。

試圖理解作者的思路有時候會發現並不亂

/*日碼千行一時爽，代碼重構火葬場*/
/*重構!=重寫全部代碼*/
以下情況可以選擇重構:

不重構整個程序已經不能再繼續擴展
程序出現了致命的Bug，不重構無法修復
架構已經被證實有問題，未來一定會出現問題

有些程序經過多人的接手，離職，經過數次的擴充，早先的需求文檔和架構已經找不到了，裡面存在著各種各樣黑魔法，有各種非致命或極難出現的Bug。
這種代碼，我的建議是，能再活幾年，就活幾年，該送進棺材的時候，就別猶豫了。
理清楚黑魔法比重構難多了

要麼辭職要麼重構推薦看軟體隨想錄

自己挖的坑，含淚也得跳，慢慢填或者忍！

你可以學習編寫單元測試，實行測試驅動開發，會逼著你寫出設計良好的代碼，架構設計不好的代碼不易於測試。有了單元測試，以後如果因為需求變更再重構代碼時也有了信心。

ctrl+a del

這個要看項目的大小了，如果是大型項目，估計是不會輕易修改的，成本太大，小項目就看CTO了，想改的話，花點時間還是可以的。其實修改項目架構這種情況還是很少的，畢竟改架構和重新建個項目沒太大區別。

架構能力，從側面反?了你的客戶溝通能力、多事務協調能力、組織能力和風險評估能力。簡單原型模擬系統，是有用的。