QQ空間技術水平如何？
1. 06年，還是壹個前端技術萌芽的年代，雖然04年google把ajax概念讓更多人看到了前端的重要性，但是前端技術還是非常沒有標準化的年頭。剛接手空間的前端代碼，前輩們為了極致的體驗，十幾號開發（前端，後臺，甚至運營開發都有）都在同時改壹個文件G4.js，文件數量可達200k（自己腦補有多少行）。當時沒有像現在那麽多框架，那麽多解決方案，更加沒有node.js，妳從何下手？ 如果妳們都覺得文件請求合並為基本原則，那麽這個做法是不是就是對的？2. 對於那麽大的文件，代碼本身的問題就非常多。所以接下來的事情，我想的方式是拆開，模塊化。做這個事情，後來就到了07年，為了讓模塊化開發方式簡單，自己寫了壓縮合並工具，自己定義模塊加載的方式。然而當時能想到最簡單的優化就是，把首頁用戶不需要的內容盡量異步加載。如果回想起來，當時最遺憾的是，並沒有把模塊化的工作方式，抽象成設計模式。後來做DO分離的時候，我們把前端的工具也慢慢推動形成了公司級的工具，包括發布和壓縮，其實也是最早期的前端工程化雛形。當然工程化還包括了最早的公司web端性能的測速平臺3. 抓包中妳們還能看到qzfl，這個是最早期為了解決開發規範，解決瀏覽器兼容的產物。這個框架為空間做了非常多的深度定制，同時也從整個團隊來說，讓前端開發在生產環節獲得效率的提升（當然始終沒有提升效率到，我們有時間去做開源，這個深表遺憾）。當然到現在同時看到多個基礎庫，其實是讓我覺得非常痛心的壹點，在現在提倡去框架的時代，在空間依舊看到了很多基礎庫。這個確實需要後輩們想辦法，qzfl已經發揮了它最大的價值，是否還能帶來更大的價值？4. 前端優化，這個很古老又很贊新的問題。怎麽做都沒有對錯，雖然前端優化也能有壹些常規的設計模式去驅動，但是設計模式不見得都是全對的。空間的優化原則是基於數據分析的基礎去做的，所以我們會去關註真實用戶端的使用情況。空間多首屏加載做了非常多調整，以及對10%的用戶，在網絡接入，運營商，使用習慣上做更多的分析。所以我們並不會說直接套用xxx優化原則就認為我們做了優化，優化隨著時間推移，隨著用戶硬件的升級，也在不斷調整著策略。當然以上這些優化其實只解決了用戶訪問的速度問題，並沒有解決卡頓的問題。所以我在12年的velocity china上提出了前端的渲染性能優化的分析方法(有興趣可以百度搜索16毫秒的優化)，希望前端開發通過渲染問題的分析，去優化空間的卡頓。因為空間長期都在和網絡較量，對於復雜前端性能，確實看得不夠多，特別是運行時的性能。空間的前端技術，也許在現在很多人看起來技術很古老。但是它已經是壹個大象級別的項目。另外在業務面前，壹個理性的程序員會考慮，我的重構是否對現在的優化還有價值？ 空間當年從10萬到百萬，到千萬訪問量的提升的時間段內，各種優化都是值得的。然而到了現在頂峰階段，去做天翻地覆的改動價值是否得以放大？所以，也建議大家不要以新技術的運用作為判斷前端技術是否NB的唯壹標準。回想04年ajax誕生，算是新技術？其實只是壹個新的設計模式。最後空間前端團隊，雖然在開源上沒有太多的貢獻，但是在騰訊內，給大家創造了非常大的成長空間，創建了騰訊的web前端通道，讓前端技術真正在公司內受到重視，做到這點已經足夠。心存感激。