OLID 原則最初是由 Bob 在他的《敏捷軟件開發(fā)：原則、模式和實踐》一書中提出的，它們旨在使軟件設(shè)計更易于理解、靈活和可維護(hù)。它們是原則不是規(guī)則更不是完美的真理。然而它們確實是很好的建議。

原則是精神上的小房間。他們給一個概念命名，這樣你就可以談?wù)摵屯评磉@個概念。它們提供了一個地方來表達(dá)我們對好代碼和壞代碼的感受。他們試圖將這些感受歸類為具體的建議。從這個意義上說，這些原則是一種鎮(zhèn)痛劑。給定一些您感覺不好的代碼或設(shè)計，您可能能夠找到一個原則來解釋這種不好的感覺并建議您如何感覺更好。

• 單一責(zé)任原則(The Single Responsibility Principle)
• 開放封閉原則(The Open Closed Principle)
• 里氏替換原則(Liskov Substitution Principle)
• 接口分離原則(The Interface Segregation Principle)
• 依賴倒置原則(The Dependency Inversion Principle)

單一責(zé)任原則

這個原則背后的想法是我們需要將不同的職責(zé)分成不同的類，我們有下面的代碼來說明 User 類：

這個例子的問題是 User 類必須管理兩個不同的職責(zé)：

• 編輯用戶數(shù)據(jù)
• 記錄用戶數(shù)據(jù)版本

這會產(chǎn)生維持穩(wěn)定性的問題，在使用過程中，我們可能會有多種理由修改這個類，比如更換一個更換的Log方法，這樣就影響了本不應(yīng)該被改變的User類邏輯，從而產(chǎn)生了不必要的風(fēng)險。最好的方式就是，將職責(zé)分開，User類專門負(fù)責(zé)User的邏輯，Log類專門管理Log。

開放封閉原則(The Open Closed Principle)

代碼在開發(fā)過程中不會保持永久穩(wěn)定，一直都在變化，我們編寫的所有代碼都會在未來的某個時刻發(fā)生變化，因此我們需要創(chuàng)建更容易的代碼。

我們更改代碼的方式將定義代碼質(zhì)量，如果我們不斷更改當(dāng)前的類，這將在我們的代碼中產(chǎn)生錯誤，但是如果我們用新的類擴(kuò)展我們的類，這將有助于我們避免代碼中的錯誤，那就是 OCP原理的主要思想。

如果我們想添加一個新的三明治尺寸，例如巨型，我們需要編輯 Sandwich 類，并可能破壞其他東西，如果我們將此列表委托給另一個類并從 Sandwich 類加載這個類，我們將在未來進(jìn)行維護(hù) 更簡單、更安全：

現(xiàn)在我們通過 Sandwich 類中的 setSize 方法連接了 2 個不同的類，無論我們要添加多少尺寸，我們都不需要再編輯 Sandwich 類，這就是 OCP 原理的精髓。

里氏替換原則

這個定義并不能幫助我們更快地理解這個原則的含義，但是這個想法很簡單：一個父類可以被一個派生類替換而不會破壞它的行為。即：一個對象在其出現(xiàn)的任何地方，都可以用子類實例做替換，并且不會導(dǎo)致程序的錯誤。

下面的代碼是一個派生類破壞父類行為的經(jīng)典示例：

這里的問題是, 正方形不應(yīng)該是長方形的子類。原因是正方形多了一個屬性“長==寬”。這時，對正方形類設(shè)置不同的長和寬，計算面積的結(jié)果是最后設(shè)置那項的平方，而不是長*寬，從而發(fā)生了與長方形不一致的行為。如果程序依賴了長方形的面積計算方式，并使用正方形替換了長方形，實際表現(xiàn)與預(yù)期不符。所以應(yīng)該將他們寫成兩個單獨的類。

接口分離原則

接口隔離原則表明客戶端不應(yīng)該被強(qiáng)迫實現(xiàn)一些他們不會使用的接口，應(yīng)該把冗余接口中的方法分組，然后用多個接口替代它，每個接口服務(wù)于一個子模塊。簡單地說，就是使用多個專門的接口比使用單個接口要好很多。

看下面的例子：

在這個例子中，Product 類中的方法 setName 總是要求用戶發(fā)送 onFinish 函數(shù)，即使用戶不需要調(diào)用這個函數(shù)，這樣實現(xiàn)更好：

依賴倒置原則

這個原則有兩點：

1. 高層模塊不應(yīng)該依賴低層模塊。 兩者都應(yīng)該依賴于抽象。
2. 抽象不應(yīng)該依賴于細(xì)節(jié)。 細(xì)節(jié)應(yīng)該取決于抽象。

這里的想法是創(chuàng)建一種方法來減少我們的類對其他類的依賴，從而更容易替換對其他類的依賴。讓我們分析下面的代碼：

在此示例中，我們將 Client 類與 ValidateEmailSimple 緊密耦合，每次調(diào)用 setEmail 時，我們都會從 ValidateEmailSimple 創(chuàng)建一個新實例，這里的問題是，當(dāng)您決定將此驗證更改為另一個更復(fù)雜的驗證（ValidateEmailAdvanced）時，您將需要更改客戶端類中所有出現(xiàn)的舊驗證系統(tǒng)，這可能會在我們的應(yīng)用程序中產(chǎn)生新的錯誤和不一致。

解決這個問題的方案就是把這種緊耦合的依賴轉(zhuǎn)化為松耦合的依賴，怎么做呢？ 很簡單，讓我們在 Client 類中創(chuàng)建一個名為 _emailValidationService 的 var，并調(diào)用它來驗證我們的電子郵件，而不是直接調(diào)用我們需要的驗證類：

使用這種方法，當(dāng)我們決定放置一個更高級的驗證電子郵件系統(tǒng)時，我們不需要更改 Client 類，很酷吧？

歡迎轉(zhuǎn)發(fā)，感謝閱讀！

年以來，隨著疫情方面的數(shù)據(jù)逐漸增多，一些互聯(lián)網(wǎng)公司也紛紛發(fā)布一些可視化的數(shù)據(jù)產(chǎn)品服務(wù)，讓用戶可以實時并直觀了解最新情況，可謂一個便民利器。而本文，則通過丁香醫(yī)生、以及騰訊新聞推出的“疫情實時動態(tài)”可視化服務(wù)，總結(jié)分享其中運(yùn)用到的一些常見的數(shù)據(jù)可視化經(jīng)驗。

閱讀指南：

（1）受眾人群：初級產(chǎn)品經(jīng)理

（2）閱讀收獲

• 產(chǎn)品分析的方法論實例，包括用戶體驗五要素、馬斯洛需求理論等；
• 數(shù)據(jù)可視化的基本技巧和遵循原則。

一、前言

1.1 概念

首先，需要先簡單澄清下數(shù)據(jù)可視化的基本概念。數(shù)據(jù)可視化，實質(zhì)上是把一些概要信息（數(shù)據(jù)、關(guān)鍵內(nèi)容），并結(jié)合動靜態(tài)的圖像視頻等形式進(jìn)行展示，從而清晰傳遞核心信息。較為注重視覺層面的觸達(dá)。

所以我們需要在數(shù)據(jù)之中挖掘一些重要的價值信息，并以一個可觀的方式呈現(xiàn)。而“重要”的定義是十分明顯的，核心數(shù)據(jù)、用戶感興趣、有決策意義，都可稱之為重要。

1.2 動因

根據(jù)馬斯洛五層次需求理論，那么數(shù)據(jù)可視化在其中屬于什么層次的需求？

受疫情影響，生命安全成了最重要的社會需求。那么滿足大眾對這方面的廣泛需求，推出這樣的數(shù)據(jù)可視化產(chǎn)品是十分有必要，滿足用戶對疫情情況、資訊信息、醫(yī)療信息等方面的獲取，從而保障自己基本的需求。

1.3 基本情況

（1）脈絡(luò)

初始，丁香醫(yī)生率先推出一個H5的可視化頁面，匯總披露病例數(shù)據(jù)。隨后，一些大廠也開始陸續(xù)推出，包括頭條、騰訊等等。

而為什么大家都紛紛推出這樣的數(shù)據(jù)服務(wù)，從戰(zhàn)略層來說：一是做好企業(yè)責(zé)任，滿足用戶的知情需求；其二是滿足自己的平臺用戶，并吸引流量，這都是拉新、促活的寶貴方式。

而展示的信息，主要包括每日的新增、累計病例數(shù)，各地區(qū)的病例分布，以及疫情新聞、醫(yī)學(xué)知識等方面的內(nèi)容。

（2）價值

• 用戶：主要滿足3類用戶：大眾用戶、政企用戶和患者用戶。其中主要是前2者。大眾用戶是指像我們普遍受此前疫情影響生活、工作等方面的大眾群體。政企用戶是指政府和企業(yè)機(jī)構(gòu)，同樣受此次疫情影響，對機(jī)構(gòu)的運(yùn)作肯定也是有影響的，他們需要基于此做合適的決策，保障企業(yè)和員工的安全。患者用戶是指受此次疫情傳播切身影響到的用戶，包括確診、疑似、接觸、被動隔離等，這類用戶對醫(yī)學(xué)信息的獲取會更為迫切。
• 需求：面對3類不同的用戶，主要是滿足2大類需求，分布是資訊信息和醫(yī)療信息的獲取。其中資訊信息包括疫情信息、政府信息、權(quán)威報道等。醫(yī)療信息包括醫(yī)學(xué)知識、醫(yī)院信息、醫(yī)學(xué)服務(wù)等。

而接下來，也將依據(jù)用戶體驗五要素中的范圍層、框架層、表現(xiàn)層，分別對這個疫情數(shù)據(jù)可視化的產(chǎn)品服務(wù)進(jìn)行分析。

二、范圍層

范圍層的定義是決定這樣的產(chǎn)品服務(wù)需要提供什么范圍內(nèi)的功能服務(wù)，什么是不做的。以及要做的數(shù)據(jù)指標(biāo)，哪些是關(guān)鍵的，哪些是次要的。所以我們可以羅列一下這樣數(shù)據(jù)可視化產(chǎn)品，基于用戶的需求是需要準(zhǔn)備什么樣的數(shù)據(jù)指標(biāo)。

2.1 范圍確認(rèn)

上圖摘自國家衛(wèi)健委某日的全日數(shù)據(jù)，在制作可視化的時候，需要考慮數(shù)據(jù)源的出處以及能提供什么樣的指標(biāo)及口徑。

從中可以看出，大致可以劃分兩類關(guān)鍵數(shù)據(jù)：一個是病例的數(shù)據(jù)，一個是輔助性的數(shù)據(jù)。我們需要從中挑出其適合展示同時也是用戶需要關(guān)心的數(shù)據(jù)。

通常做這種可視化產(chǎn)品，總結(jié)性的數(shù)據(jù)是十分關(guān)鍵的。而基于用戶的關(guān)注點，每日新增、累計，就是其中的關(guān)鍵。

另外，基于“時間”和“地區(qū)”，代表了數(shù)據(jù)的“屬性”。而屬性則反應(yīng)了這個數(shù)據(jù)可以以什么樣的特點進(jìn)行展現(xiàn)。而“時間”和“地區(qū)”是，最適合以數(shù)據(jù)趨勢和數(shù)據(jù)分布的兩種主要數(shù)據(jù)可視化表達(dá)形式。

2.2 主次確認(rèn)

從下表可以看出，3家平臺的數(shù)據(jù)指標(biāo)在展示上是比較一致的，核心指標(biāo)都一一羅列展示。

其中在時間的“小時”級別，以及“解除醫(yī)學(xué)觀察”等細(xì)分指標(biāo)都不做展示，我認(rèn)為主要出于以下目的：

• 小時：各地數(shù)據(jù)更新時間不一致，無法保證的小時級別的統(tǒng)一更新。所以在時效性無法保障的前提下，不做過于實時的展示是合理的；
• 解除醫(yī)學(xué)觀察：類似追蹤到密切接觸者、解除醫(yī)學(xué)觀察這樣的指標(biāo)太大，且邊界有不確定性，用戶對其感知不會太深，所以不展示存在較大不確定性的指標(biāo)同樣也是相對合理的；

三、框架層

框架層的定義是指根據(jù)要做的功能范圍，應(yīng)該確定如何正確布局和設(shè)計，可以簡單理解為PPT的排版一樣，以什么樣的方式來排列展現(xiàn)這些元素。

3.1 布局

首先，我們需要先看看上文提及到的幾類數(shù)據(jù)指標(biāo)，重新分類一下,并標(biāo)記相應(yīng)的優(yōu)先級。

顯然按照合理的布局應(yīng)該是：

1. 從數(shù)據(jù)指標(biāo)來看，確診、疑似、治愈、死亡這4個是關(guān)鍵指標(biāo)，而累計要較新增重要些。
2. 從時間和地域上看，中國整體數(shù)據(jù)、各省市數(shù)據(jù)、全球各國數(shù)據(jù)這3類為關(guān)鍵指標(biāo)。而由于目標(biāo)用戶主要為國內(nèi)廣大用戶，那么按照優(yōu)先級排序應(yīng)以全國到各省市，再到全球各國，這樣的順序排列。

3.2 可視化方案

大致的布局是已經(jīng)清晰了，那么接下來就需要基于數(shù)據(jù)類型采用合理的可視化展示形式。

前面也提過，由于是時間和地區(qū)下的各類數(shù)據(jù)，基于這樣的屬性，是可以做趨勢、地域、列表等分布的展示方式。支持趨勢的圖形則主要為折線、柱狀圖，支持地域分布類型則為地圖，而列表則為常規(guī)的類報表方式等。

其中，由于時間跨度較長和地區(qū)明細(xì)較多，如果使用柱狀圖，則會顯得橫軸較長，所以在有限的手機(jī)屏幕尺寸下，是不適宜展示的。

1. 趨勢：由于時間跨度較長和地區(qū)明細(xì)較多，如果使用柱狀圖，則會顯得橫軸較長，所以在有限的手機(jī)屏幕尺寸下，是不適宜展示的。
2. 地圖：地圖的可視化有很多，比如像基礎(chǔ)的echats組件，就支持各類2D、3D圖形。但是在這里我們需要考慮的是，用戶主要打開的應(yīng)用設(shè)備是手機(jī)。那么手機(jī)的設(shè)備性能一定程度上限制了可視化的效果呈現(xiàn)。先忽略開發(fā)成本，過于酷炫的效果，會導(dǎo)致頁面加載、渲染十分久，這在體驗上十分不劃算的。

（Echarts部分地圖特性截圖）

所以在這里，更傾向于采用粗一些的2D省級行政地圖形式，開發(fā)周期短，且滿足最基本需求。

3.3 平臺分析

（1）匯總數(shù)據(jù)

相同點：

• 從布局上，3家都采用“整體數(shù)據(jù)+地圖分布”的結(jié)合布局，清晰傳達(dá)全國一天的整體數(shù)據(jù)；
• 從數(shù)據(jù)時效性上，都清晰明確數(shù)據(jù)的更新時間，從而保證與官方的一致性；
• 從整體數(shù)據(jù)上，都以“標(biāo)題、人數(shù)、較昨日”3個字段，展示整體數(shù)據(jù)的主要信息；
• 統(tǒng)一以地圖分布展示全國各省的分布，并以同一色系的深淺表達(dá)各省的數(shù)據(jù)發(fā)展情況，而圖標(biāo)的比例尺隨著數(shù)據(jù)的增加也會發(fā)生變化。

差異點：

• 丁香醫(yī)生在匯總數(shù)據(jù)中間穿插了此次疫情的一些基本信息，占據(jù)了一些空間。對于前期疫情爆發(fā)，有利于做信息普及，但到了中、后期，用戶已經(jīng)十分感知這方面的信息，優(yōu)先級已經(jīng)沒有那么重要，其實完全可以作為一個hover進(jìn)行信息展示。
• 整體數(shù)據(jù)上，基本展示4、5個核心指標(biāo)，但在“標(biāo)題”、“較昨日XX”和“具體數(shù)值”的排版上有所不同，而更是把標(biāo)題放在2個指標(biāo)之間。

評價：正常應(yīng)遵循“標(biāo)題+具體數(shù)值+較昨日變化”這樣的排列比較合適，上下順序先從標(biāo)題了解該指標(biāo)的含義，居中放大具體數(shù)值，突出關(guān)鍵信息，其次顯示較昨日變化對比，感知變化情況。

（2）各指標(biāo)趨勢

相同點：

• 基于新增和累計兩個維度，都展示了確診、疑似、死亡和治愈等指標(biāo)的數(shù)據(jù)趨勢；
• 數(shù)據(jù)內(nèi)涵和數(shù)值接近的指標(biāo)，都做合并在同一折線圖中，這樣使得頁面簡潔，且便于數(shù)據(jù)之間做比對、關(guān)聯(lián)。比如新增確診和新增疑似，2者的數(shù)據(jù)內(nèi)涵相對接近，且數(shù)值是比較接近，都是千級單位。那么這樣的折線展示兩者關(guān)聯(lián)關(guān)系，又不會因為展示其他不相關(guān)又懸殊的指標(biāo)造成誤解。

差異點：

• 丁香醫(yī)生在展示的指標(biāo)較多一些，且增加了死亡率和治愈率等百分比類型的指標(biāo)。
• 和騰訊新聞的版式比較接近，且使用了不同的色系進(jìn)行分類表達(dá)。而丁香醫(yī)生主要以左右滑動的交互收縮形式展示。減少空間，但降低了其他圖表的漏出。
• 丁香醫(yī)生突出了湖北和非湖北的數(shù)據(jù)，這樣的好處可以比較全國和非湖北，側(cè)面表達(dá)目前的疫情傳播困難程度主要在湖北，其他地區(qū)相較輕一些，實際比全國的平均值更低，緩輕心理壓力（這就是可視化的魅力）。

（3）國內(nèi)各省市分布

相同點：統(tǒng)一以常規(guī)列表分布展示國內(nèi)各省市的疫情數(shù)據(jù)情況，并集中以地區(qū)、確診、死亡、治愈等字段。

差異點：

• 和騰訊新聞有明確的標(biāo)題進(jìn)行布局區(qū)分，顯示國內(nèi)疫情數(shù)據(jù)。而丁香醫(yī)生沒有明確展示，與上面版塊的邊界過于混淆。
• 和騰訊新聞較丁香醫(yī)生額外增加“新增確診”指標(biāo)，并且以差異色值顯示。
• 列表默認(rèn)展開當(dāng)前省份的各市數(shù)據(jù)，而和騰訊新聞伸縮展開按鈕默認(rèn)統(tǒng)一在右側(cè)，與丁香醫(yī)生顯示左側(cè)不同，較為符合移動端產(chǎn)品交互習(xí)慣。
• 有趣的是，優(yōu)先展示當(dāng)前用戶地理位置所在省份的數(shù)據(jù)展示，再以累計確診人數(shù)進(jìn)行順序排列。而騰訊新聞和丁香新聞統(tǒng)一以累計確診人數(shù)多少排列。

評價：

1. 考慮排序、篩選的展示邏輯，一般從大到小。
2. 移動端頁面因為便于依據(jù)當(dāng)前用戶的地理位置，可以采用個性化的手段做一些差異顯示，這樣在保證整體數(shù)據(jù)展示的過程也優(yōu)先展示用戶接近的數(shù)據(jù)信息，體驗更佳。

（4）海外各國分布

展示方式如國內(nèi)疫情一致，這里不多說。而唯一不同的是，丁香醫(yī)生在全球各國的基礎(chǔ)做了“洲”單位的分類。這樣的好處是，分類顯得更有層次性，了解某個范圍內(nèi)的地區(qū)更有顯著性。

四、表現(xiàn)層

表現(xiàn)層所關(guān)注的，是頁面各個元素組件的形狀、色彩和大小比例搭配。同時數(shù)據(jù)可視化十分重視圖形色彩的表達(dá)，一個好的視覺設(shè)計，能夠為數(shù)據(jù)的信息傳遞起到十分重要的作用。

4.1 匯總數(shù)據(jù)

從上圖可以看出，3家平臺都展示了4個關(guān)鍵指標(biāo)“確診”、“疑似”、“死亡”和“治愈”，以及在色彩選擇上，盡管有具體色值的差別，但是理念是都較為接近的。

• 確診：首先疫情確診人數(shù)，本身是一個起提醒警示作用的數(shù)據(jù)含義，所以采用偏紅色的表達(dá)是合理的，而丁香醫(yī)生和騰訊新聞則保持了這個理念。
• 疑似：疑似的指標(biāo)內(nèi)涵也是有一定的警醒作用，但是由于較“確診”的程度輕些，那么采用黃粽色系，可以相對和緩一些，而這3家在這方面是保持一致的；
• 死亡：這個指標(biāo)內(nèi)涵本質(zhì)上是一個嚴(yán)肅悲傷的事情，大家可以留意在一些關(guān)于“死亡”的場合，都會著裝嚴(yán)肅內(nèi)斂，甚至幾乎統(tǒng)一黑色色系。所以，這樣的指標(biāo)在色彩上選擇偏暗深色系是比較合理的；
• 治愈：治愈本身代表由壞轉(zhuǎn)向好的意義，那么用一種代表陽光、希望的色彩是恰到好處的，所以采用偏綠色的色彩；

4.2 地圖分布

地圖分布通常是以顏色深淺代表數(shù)據(jù)的“密集程度”，那么就要確定2個關(guān)鍵的地方，1個是色系，另外1個是合理的刻度比例。前者根據(jù)數(shù)據(jù)內(nèi)涵確定合適的色系進(jìn)行表達(dá)，后者是做色系的層次區(qū)分。

• 丁香醫(yī)生：相對開放一些，采用深紅色系，直面表達(dá)此次傳播疫情的危險程度；
• ：3者中相對更為克制一些，采用和緩一點的黃棕色，同時刻度較多，所以會顯得深色區(qū)不多，這樣在展示哪些地區(qū)更嚴(yán)重一些會顯得沒那么突出；
• 騰訊新聞：偏淡紅色系，表達(dá)的危險信息要弱一些，處于3家平臺的中間，既不“激進(jìn)”也不過于“保守”。

4.3 折線趨勢

• 對比色：折線圖通常最多展示4種數(shù)據(jù)，但大多數(shù)只會展示2-3種，極少放4種。而折線圖有2種以上的時候，就需要采用2種以上的獨立色系來展示，這樣的好處是比較好區(qū)分。但有些產(chǎn)品會采用同樣的色系下2種深淺顏色，在屏幕十分大的情況下是合適的，但是在手機(jī)端有限的空間情況下，還是建議使用2種不同色系。從上圖可以看出，除外，其余兩家基本是采用了明顯的區(qū)分。
• 數(shù)據(jù)節(jié)點：很多時候為了便于用戶知道每個橫軸刻度對應(yīng)的節(jié)點位置，都會標(biāo)記一個“圓點”在上面，這樣好處是便于較快對應(yīng)上位置。但是，當(dāng)橫軸的刻度過于密集的時候，這種展示是不適合的，因為過于密集顯得頁面不夠簡潔，且沒有重點。顯然這3家平臺都是有這樣的問題。而最好的方式，只需要在當(dāng)前一天顯示節(jié)點及顯示具體數(shù)值，這樣會更清晰可觀，也便于輔助閱讀。

以上就是此次疫情數(shù)據(jù)下，在可視化應(yīng)用上的一些體驗總結(jié)，3家都遵循了一些基本原則，同時也有各自的一些風(fēng)格。而數(shù)據(jù)可視化的應(yīng)用需要兼顧不同的因素，達(dá)到最佳效果。

一個理想的可視化設(shè)計流程，需要經(jīng)歷“數(shù)據(jù)指標(biāo)的范圍篩選、頁面的布局抉擇、可視化的視覺設(shè)計“等關(guān)鍵步驟。

五、總結(jié)

1. 選擇數(shù)據(jù)，需確保數(shù)據(jù)的準(zhǔn)確性、穩(wěn)定性和易讀性；
2. 進(jìn)行可視化設(shè)計前，需要了解主要用戶使用的設(shè)備類型，以及開發(fā)的主程序，切勿過于追求視覺效果，畢竟設(shè)備性能之間、APP和手機(jī)網(wǎng)頁之間，都是有較大的性能差別的；
3. 數(shù)據(jù)的內(nèi)涵和屬性確定了可適用的展示方式，比如地理信息適用使用地圖，占比分布適宜使用餅狀圖等；
4. 數(shù)據(jù)可視化的核心，是需要明確展示的目的和主題，同時需要分清主要和次要關(guān)鍵信息；
5. 數(shù)據(jù)可視化的布局本質(zhì)上就是講好一個“故事”，所以是故事就要有先后順序、遞進(jìn)關(guān)系；
6. 每個元素組件，兼顧數(shù)據(jù)及數(shù)據(jù)之間背后的邏輯、關(guān)聯(lián)關(guān)系；
7. 數(shù)據(jù)的羅列展示要整齊劃一，一般遵循從大到小、從外到里的原則。
8. 視覺是數(shù)據(jù)可視化的一大利器，善用有利于合理化的展示，其中圖表的設(shè)計、色彩的搭配至關(guān)重要。

3家平臺地址：

丁香醫(yī)生：https://ncov.dxy.cn/ncovh5/view/pneumonia

：https://i.snssdk.com/ugc/hotboard_fe/hot_list/template/hot_list/forum_tab.html?activeWidget=1&city_code=440300&city_name=%E6%B7%B1%E5%9C%B3&tt_from=weixin&utm_source=weixin&utm_medium=toutiao_ios&utm_campaign=client_share&wxshare_count=1

騰訊新聞：https://news.qq.com/zt2020/page/feiyan.htm?devid=EB886059-83CA-4F1F-AB3A-B64FCD87D7F7&qimei=eb886059-83ca-4f1f-ab3a-b64fcd87d7f7

作者：A.D，數(shù)據(jù)產(chǎn)品一枚；公眾號：吾某

本文由 @A.D. 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。

器之心報道

編輯：力元、蛋醬

不要對 Python 4.0 抱有希望，可能不會有的。——Python 之父 Guido van Rossum

2020 年 1 月 1 日，Python 官方結(jié)束了對 Python 2 的維護(hù)，意味著 Python 2 完全退休，進(jìn)入 Python 3 時代。之后，關(guān)于 Python 4 的發(fā)布排期也成為了社區(qū)的熱門議題。

去年，Python 之父 Van Rossum 在推特上表示，假如會有 Python 4，從 3 到 4 的版本過渡會更像從 1 到 2 的過渡，而不會像從 2 到 3 的過渡。

但在最近接受 Microsoft Reactor 采訪時，Van Rossum 被問及 Python 的未來，以及什么時候會出 Python 4.0。他卻表示，可能不會有 Python 4 了。

Van Rossum 回答說：「我和 Python 核心開發(fā)團(tuán)隊的成員對 Python 4.0 沒什么想法，提不起興趣，估計至少會一直編號到 3.33。」

視頻地址：https://www.youtube.com/watch?v=aYbNh3NS7jA

在從 Python 2 過渡到 Python 3 時已經(jīng)被上了一課的 Van Rossum 表示，在內(nèi)部的嚴(yán)肅場合，談?wù)?Python 4 是個禁忌，大家只會在飲茶時把 Python 4 當(dāng)玩笑開。

2020 年 4 月，Python 2.7 生命周期中的最后一個版本 - Python 2.7.18 發(fā)布了。彼時 Van Rossum 警告過開發(fā)人員 Python 3 與 Python 2 不兼容，因此基于 Python 2 的軟件庫依賴項將不能升級至版本 3.0。

那是一個延續(xù)了數(shù)年之久，緩慢而又痛苦的遷移期。Van Rossum 說：「實際上，Python 比核心開發(fā)人員意識到的要成功得多，因此我們應(yīng)該對從 Python 2 過渡到 Python3 更加了解和支持。但當(dāng)時我們錯誤地認(rèn)為過渡會很簡單，因為我們都像 Python 編程中的愛因斯坦一樣，可以在睡眠中將代碼從 Python 2 轉(zhuǎn)換為 Python3。」

不過，Van Rossum 并沒有完全排除 Python 4.0 的可能性，他暗示道，當(dāng) Python 與 C 的兼容性發(fā)生重大變化時，可能會改變目前的想法。Van Rossum 表示：「如果不更改語言就會與 C 擴(kuò)展存在嚴(yán)重的不兼容，或者我們能夠擺脫全局解釋器鎖（GIL），這樣的情況下我們可能被迫升級至 Python4.0。」

然而，關(guān)于預(yù)計在 10 月發(fā)布的 Python 3.10，以及將實現(xiàn)一些重大速度提升的版本 3.11，Van Rossum 強(qiáng)調(diào)，重點依舊是盡可能長時間地漸進(jìn)式的更新編程語言。

兩年前，Guido van Rossum 從 Dropbox 離職，宣布退休，但又在 2020 年 11 月加入了微軟，主動結(jié)束了自己的退休生活。當(dāng)時他表示，將致力于「使用戶更好地使用 Python（并且不僅僅是在 Windows 系統(tǒng)上）」。

「現(xiàn)在，我們有一個嚴(yán)格的年度發(fā)布時間表，Python 3.10 之后是 3.11，之后是 3.12，依此類推。（在 Python 4 之前）我們必須先發(fā)布 3.9，每次添加另一個數(shù)字并不是容易的事，但仍然比從 3 到 4 輕松得多。」

「Python 的加速是漸進(jìn)式的，3.11 版本會有新的速度提升，我們會在 3.12 和 3.13 中將其進(jìn)一步提高。」

接下來，讓 Python 更快是 Python 核心開發(fā)團(tuán)隊的工作重點。在近日的 PyCon Language Summit 上，Van Rossum 宣布目標(biāo)是在 3.11 版本中將 CPython 的性能提高一倍。

Van Rossum 還介紹了通過外部項目（比如 Pyston）來加速語言的努力，Pyston 項目是 Python 3.8.8 的實現(xiàn)，該實現(xiàn)最初發(fā)布在 Dropbox，后來開源。其創(chuàng)建者最近發(fā)布了 Pyston 2.2，相比 CPython 3.8.8 的性能提高了 30％。

「現(xiàn)在，我覺得大約有一年時間來證明我們在 Python 性能上取得了進(jìn)步，3.11 會比 3.10 快得多。」

同時，Van Rossum 也分享了自己對其他編程語言的看法，他欣賞 Rust 改進(jìn) C++ 代碼的能力，并且 Go 是「比較 Python」的語言中最有趣的。

「你可能注意到，在過去的六七年里，我們一直在 Python 中添加可選的靜態(tài)類型，也叫漸進(jìn)類型。」Python 之父也介紹了 Python 近年來對 TypeScript 的重視程度。

「當(dāng)開始項目時，我實際上并不了解 TypeScript，所以我不能說最初是受到了 TypeScript 的啟發(fā)…… 如今，我們肯定是以 TypeScript 為樣板，有時我們發(fā)布了新功能，因為某些功能相對 Typescript 是缺失的，然后我們根據(jù)用戶需求將其進(jìn)行添加，非常成功。」

Van Rossum 說，Python 仍然在努力尋找重獲成功的方法。在他看來，Hejlsberg 是一個非常聰明的人，TypeScript 正在做的一些事情，是 Python 未來需要弄清楚的。實際上 TypeScript 也在向 Python 學(xué)習(xí)，就像 JavaScript 在一些領(lǐng)域從 Python 那里學(xué)習(xí)一樣。

參考鏈接：https://www.tectalk.co/why-python-4-0-might-never-arrive-according-to-its-creator/