背景
百科V5版重構孩擂，實際上是百科有史以來（06年4月20日上線，產(chǎn)品發(fā)展的第9個年頭）第四次整體性的重構熟史，重構共耗時兩年馁害，按先后次序從展現(xiàn)，底層存儲到核心提交依次重寫并分步接入蹂匹，替換原有核心碘菜。在這個過程中，新老系統(tǒng)并行運行限寞，在不斷的迭代過程中下線老的子系統(tǒng)忍啸。
至于為什么在九年時間內(nèi)進行四次重構，原因很直接履植，就是之前重構中沒有解決系統(tǒng)狀態(tài)不佳的根本問題——過度復雜计雌，第三次重構甚至還加劇了這個問題。
V5版重構耗時兩年玫霎，其中核心系統(tǒng)（詞條的展現(xiàn)凿滤，編審提交，存儲）共耗時一年庶近，周邊子系統(tǒng)遷移耗時一年翁脆。重構完成后系統(tǒng)狀況提升明顯，核心系統(tǒng)代碼量僅有原來的20%鼻种，瀏覽及提交性能都有數(shù)十倍甚至幾十倍的提升反番。
一點點討論
1. 參與此次重構最深的感觸是什么
看到這個問題，竟一時不知從何說起叉钥，感覺此時像極了很多電影中罢缸，回憶畫面開始前的橋段，男主沉默半晌投队，深深的吸了一口祖能，又慢慢的吐出，伴隨著煙霧的繚繞蛾洛，時間又飛回到了兩年前……
- 『臥槽代碼寫的這么爛濒旦，都特么干不下去跑路了傻咖，把哥拉過來給他們擦屁股……居然還有加薪升職的，應該拖出門外痛打！哩簿！』
- 『對同義詞重定向的問題舆绎，我能想起的最適合它的畫面：「孔乙己顯出極高興的樣子兽叮，將兩個指頭的長指甲敲著柜臺累盗，點頭說，“對呀對呀蟆淀！……回字有四樣寫法拯啦，你知道么澡匪？”」，究竟是用戶真正的需求褒链，還是特么你自己所謂的需求唁情？』
- 『在一片和樂的氛圍中，眾人親手掐死了這個產(chǎn)品甫匹，卻還在四處尋找劊子手』
- 『都二十七八歲甸鸟，誰不愿意享受大好時光，良辰美景兵迅，花前月下抢韭，誰特么愿意天天加班看這坨**一樣的代碼』
- ……
（壓迫至極吐槽，不代表本人主流價值觀）
我也驚訝回想起這段時間恍箭，不那么愉快的時光占據(jù)了絕大多數(shù)刻恭，甚至自己失眠在床上輾轉(zhuǎn)反側的時候，腦子里揮之不去的就是這些念頭扯夭。而與之相對的是吠各，重構上線的成功，各項技術指標的大幅提升勉抓，以及自身技術上的成長，并沒有帶來巨大的成就感候学，持續(xù)的喜悅藕筋，以及額外的回報∈崧耄快樂的時間和那些煎熬的時光相比隐圾，總是短暫的，甚至感覺掰茶，不那么值得一提暇藏。
但是，這和我在知道做過的重構濒蒋，感覺完全不一樣盐碱！為什么同樣歷盡艱辛，克服重重障礙完成了重構沪伙，回想起來感覺完全不一樣瓮顽？
我想，這應該就是上面這個問題的答案：
『粗糙技術/需求的巨大破壞性』
（用粗糙是為了盡量中性客觀一點的描述围橡，避免強烈的主觀色彩暖混，私下介紹這里會用一個「爛」字）
其破壞性體現(xiàn)在幾個方面:
- 其一，對人/團隊態(tài)度的消極影響：相信從上面的描述可以感覺出多么負面的感情翁授，當然以自己的感覺作評價有自說自話的嫌疑拣播，不妨看下研發(fā)人員的流動性晾咪，待接盤后的那個年關，老研發(fā)相繼離職（用爭先恐后可能也不為過）贮配，走的時候都有一種解脫的感覺谍倦，團隊瀕臨斷層，老系統(tǒng)只有一個老QA了解一些牧嫉。
- 其二剂跟，對新人成長的影響：觀察同時期兄弟產(chǎn)品線的新人，可以明顯發(fā)現(xiàn)兩邊成長的差異酣藻。zhidao的重構和baike V3重構在差不多相近的時間段啟動曹洽，zhidao早已完成預期目標，系統(tǒng)調(diào)理清晰辽剧，同時培養(yǎng)了不少新人送淆，大多都成了獨當一面的靠譜工程師，而baike這邊則陷入了過度復雜的泥沼怕轿，不得已再次展開又一次的重構偷崩。同時期入職的新人在編碼習慣，系統(tǒng)模型撞羽，一些基本概念的理解上都不甚理想阐斜。
- 其三，對產(chǎn)品的影響：重構開始前與PM的通氣會上诀紊，PM舉雙手贊成谒出，原因很直接，就是因為做什么都做不了邻奠，做什么都很慢笤喳，一做活動就崩潰，用戶天天有投訴碌宴，bug提也提不完杀狡。這種環(huán)境下，PM即便有好的idea贰镣，運營有再強的推廣能力呜象，也沒有什么卵用。
- 其四碑隆，對公司的影響：極大的增加了成本董朝，包括人員，機器干跛，時間等各方面子姜。以機器為例，老baike前端上百臺機器僅勉強能支撐每天的訪問量，同時期訪問量差不多的知道哥捕，同樣也使用PHP牧抽，前端僅有寥寥二十余臺機器，即便baike屬于重前端遥赚，這個數(shù)量也決不至于4倍于zhidao扬舒，baike畢竟還有頁面緩存扛著流量呢。按兩倍算凫佛，也多用了30多臺機器讲坎，每年至少因為粗糙的技術多花100多萬（估算），多花的這些錢愧薛，用來改善待遇/福利可好晨炕？
最嚴重的后果就是導致這個產(chǎn)品死掉，散落一地雞毛毫炉∥屠酰『眾人親手掐死了這個產(chǎn)品，卻還在四處尋找劊子手』
2. 這次重構成功嗎瞄勾，為什么费奸？
從技術的角度看，這次重構是非常成功的进陡。暫且不論上線后各項技術指標的成倍提升（詳見PPT）愿阐，從兩件具體實例看，一是open-bugs郵件組趾疚，從最開始每天爆滿缨历，到現(xiàn)在一個月也沒幾封，沒有產(chǎn)品或研發(fā)同學每天的時間都耗在修不完的bug上盗蟆，能集中精力去做業(yè)務開發(fā)，這就是一個非常好的轉(zhuǎn)變舒裤。二是編輯大賽的運營活動上看喳资，老系統(tǒng)一天提交上限也就<10W，超過系統(tǒng)就開始延遲腾供，體驗極為惡劣仆邓，新系統(tǒng)支持百萬量級的提交，后面運營活動的數(shù)字都非常漂亮伴鳖，是由審核系統(tǒng)的重構來提供保證的节值。
此次重構，讓瀕臨崩潰的系統(tǒng)重新回歸正常的狀態(tài)榜聂。
猶如大病初愈的病人一樣搞疗，有沒有問題呢，還是有的须肆，此次重構基本重寫了一個百科匿乃，但之前的底子太差桩皿，數(shù)據(jù)層面的混亂完全修復幾無可能，例如模塊的數(shù)據(jù)幢炸，仍然是一個復雜的數(shù)據(jù)包泄隔。這是后續(xù)系統(tǒng)發(fā)展的一個風險，但凡涉及到這里的變動宛徊，還是會很復雜佛嬉。例如編輯器，前端系統(tǒng)的一個風險點闸天。
其它方面暖呕，看法可能就各有不同了，對于我來說号枕，最恰當?shù)谋硎隹赡芫褪恰褐貥嫸嗌偈络志荆几缎φ勚小涣?/p>
3. 理想的架構是什么樣子？
加個前綴葱淳，我眼中钝腺，理想的架構用一個詞描述就是『簡單』，兩句話描述就是『主干清晰赞厕，結構簡單』艳狐。
為什么說理想的架構最典型的特征是簡單，舉個例子皿桑，IPhone毫目，大街上隨處可見，為什么這么貴大家都還愿意買诲侮，就是因為簡單镀虐，或者另一個詞，好用沟绪，即便是老人或者小孩兒刮便，都不用學，拿著就會操作绽慈，基本上直覺上的反應恨旱，就該是這個樣子的。如果把一個系統(tǒng)也做到這個程度坝疼，隨便讓個人來看搜贤，稍微說兩句就能明白，讓他也覺得這件事就應該是這個樣子的钝凶，那差不多就做到了簡單的程度仪芒。
但要做到這個簡單確不是件容易的事，《黑客與畫家》里面給了很好的解釋，當想把一個事情做簡單的時候桌硫，就不得不觸及這件事的本質(zhì)夭咬，而探索一件事的本質(zhì)，是很難的事情铆隘。
『主干清晰卓舵，結構簡單』是自己總結的兩句話，對于業(yè)務系統(tǒng)膀钠，新上手的人掏湾，最迫切的想抓住兩條線：
- 控制流：這個系統(tǒng)主要做了什么，都包含哪幾步肿嘲，每步大概做了什么事情融击，畫出來就是系統(tǒng)/模塊的流程圖。即便需要了解細節(jié)雳窟，也能很快定位到相應的代碼塊尊浪。理想的控制流，要足夠的清晰簡單封救，讓人憑借相關的注釋和名稱拇涤，就大概能了解到相應的功能。不拖泥帶水誉结，不陰暗晦澀鹅士。
- 數(shù)據(jù)流：了解了功能接下來就需要掌握數(shù)據(jù)從何而來，需要做怎樣的加工才能完成我想要的任務惩坑。數(shù)據(jù)的結構和變換應盡可能的簡單清晰易擴展掉盅。杜絕復雜的數(shù)據(jù)封裝，百科的系統(tǒng)復雜以舒，很大程度上就是因為復雜的數(shù)據(jù)構成趾痘，不得不寫大量晦澀難懂的代碼塊去加工數(shù)據(jù)成各自想要的格式，毫無邏輯可言蔓钟。
當你想簡化上面兩條線的時候永票，軟件工程上常常講的兩個高內(nèi)聚/低耦合也就會逐漸進入你的意識中了。一個好的系統(tǒng)藍圖就會慢慢構建出來奋刽。
4. 如何做一個好的研發(fā)工程師
字如其人瓦侮，碼亦如其人艰赞，編程語言作為另一類語言佣谐，很多時候也能反映出coding的人當時的心態(tài)和態(tài)度，設計優(yōu)美方妖，代碼寫的工整狭魂，細節(jié)處理的漂亮，于人于己都是一件好事，常常說有些工程師值得尊敬雌澄，有些工程師不值得尊敬斋泄，大多數(shù)判斷來源于此。
相信能堅持做到這一點镐牺，對于設計炫掐，開發(fā)以及交付的各個環(huán)節(jié)，心中都會有個高那么一點點的追求睬涧，努力把事情做到能讓自己覺得滿意募胃，而不是僅僅實現(xiàn)了這個功能，完成了這個任務而已畦浓。
