TAT.SigmaLiu 一個有趣的內存泄漏案例
In Web開發 on 2020年12月17日 by view: 4,568
1

0. 背景

之前在這篇文章里說過做了個 SSR 《論如何像素級直出具有 14W 行代碼量的前端頁面》,本以為今天順順利利,高高興興。

e62eaf67-820c-49ee-9295-86011d7d596c

沒想到項目放到線上后,隨著請求量的增多,卻感覺到首屏速度越來越慢,并且是在持續性地變慢。而且在發布完后(也就是容器重建了),耗時又陡然降下來了。

企業微信截圖_52eb633b-73b9-4860-8033-3532e629875e

0. 前言

騰訊文檔列表頁在不久前經歷了一次完全重構后,首屏速度其實已經是不錯。但是我們仍然可以引入 SSR 來進一步加快速度。這篇文章就是用來記錄和整理我最近實現 SSR 遇到的一些問題和思考。雖然其中有一些基礎設施可能和騰訊或文檔強相關,但是作為一篇涉及 Node、React 組件、性能、網絡、docker 鏡像 、云上部署、灰度和發布等內容的文章,仍然可以小小地作為參考或者相似需求的 Checklist。

image-20201128121452829

TAT.SigmaLiu ESLint 自動修復問題之如何保留最后修改人信息
In 未分類 on 2020年03月06日 by view: 5,463
1

在推行代碼規范的時候,絕大多數情況下都會遭到不小的阻力,一來每個人的代碼習慣不一致,要人輕易改變習慣確實也不是一朝一夕的事情,二來一般都會帶來額外的開發成本和其它困擾。我們不禁在想,推行代碼規范的困難點在哪里,以及如何解決這些痛點,讓各個角色更容易接受呢?

 

歸納起來,推行規范的過程中,最常聽到的幾點擔憂有:

  1. 是否帶來額外的開發成本
  2. 規范的執行力度有強制性嗎
  3. 已經開發的分支,合入的時候遇到大量沖突誰來解決
  4. 存量代碼如何解決
  5. 被修復的代碼,后面一看最后修改人全部都是運行 eslint --fix 的那個人怎么辦