整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
OLID 原則最初是由 Bob 在他的《敏捷軟件開發：原則、模式和實踐》一書中提出的，它們旨在使軟件設計更易于理解、靈活和可維護。它們是原則不是規則更不是完美的真理。然而它們確實是很好的建議。
原則是精神上的小房間。他們給一個概念命名，這樣你就可以談論和推理這個概念。它們提供了一個地方來表達我們對好代碼和壞代碼的感受。他們試圖將這些感受歸類為具體的建議。從這個意義上說，這些原則是一種鎮痛劑。給定一些您感覺不好的代碼或設計，您可能能夠找到一個原則來解釋這種不好的感覺并建議您如何感覺更好。
單一責任原則
這個原則背后的想法是我們需要將不同的職責分成不同的類，我們有下面的代碼來說明 User 類：
這個例子的問題是 User 類必須管理兩個不同的職責：
這會產生維持穩定性的問題，在使用過程中，我們可能會有多種理由修改這個類，比如更換一個更換的Log方法，這樣就影響了本不應該被改變的User類邏輯，從而產生了不必要的風險。最好的方式就是，將職責分開，User類專門負責User的邏輯，Log類專門管理Log。
開放封閉原則(The Open Closed Principle)
代碼在開發過程中不會保持永久穩定，一直都在變化，我們編寫的所有代碼都會在未來的某個時刻發生變化，因此我們需要創建更容易的代碼。
我們更改代碼的方式將定義代碼質量，如果我們不斷更改當前的類，這將在我們的代碼中產生錯誤，但是如果我們用新的類擴展我們的類，這將有助于我們避免代碼中的錯誤，那就是 OCP原理的主要思想。
如果我們想添加一個新的三明治尺寸，例如巨型，我們需要編輯 Sandwich 類，并可能破壞其他東西，如果我們將此列表委托給另一個類并從 Sandwich 類加載這個類，我們將在未來進行維護 更簡單、更安全：
現在我們通過 Sandwich 類中的 setSize 方法連接了 2 個不同的類，無論我們要添加多少尺寸，我們都不需要再編輯 Sandwich 類，這就是 OCP 原理的精髓。
里氏替換原則
這個定義并不能幫助我們更快地理解這個原則的含義，但是這個想法很簡單：一個父類可以被一個派生類替換而不會破壞它的行為。即：一個對象在其出現的任何地方，都可以用子類實例做替換，并且不會導致程序的錯誤。
下面的代碼是一個派生類破壞父類行為的經典示例：
這里的問題是, 正方形不應該是長方形的子類。原因是正方形多了一個屬性“長==寬”。這時，對正方形類設置不同的長和寬，計算面積的結果是最后設置那項的平方，而不是長*寬，從而發生了與長方形不一致的行為。如果程序依賴了長方形的面積計算方式，并使用正方形替換了長方形，實際表現與預期不符。所以應該將他們寫成兩個單獨的類。
接口分離原則
接口隔離原則表明客戶端不應該被強迫實現一些他們不會使用的接口，應該把冗余接口中的方法分組，然后用多個接口替代它，每個接口服務于一個子模塊。簡單地說，就是使用多個專門的接口比使用單個接口要好很多。
看下面的例子：
在這個例子中，Product 類中的方法 setName 總是要求用戶發送 onFinish 函數，即使用戶不需要調用這個函數，這樣實現更好：
依賴倒置原則
這個原則有兩點：
這里的想法是創建一種方法來減少我們的類對其他類的依賴，從而更容易替換對其他類的依賴。讓我們分析下面的代碼：
在此示例中，我們將 Client 類與 ValidateEmailSimple 緊密耦合，每次調用 setEmail 時，我們都會從 ValidateEmailSimple 創建一個新實例，這里的問題是，當您決定將此驗證更改為另一個更復雜的驗證（ValidateEmailAdvanced）時，您將需要更改客戶端類中所有出現的舊驗證系統，這可能會在我們的應用程序中產生新的錯誤和不一致。
解決這個問題的方案就是把這種緊耦合的依賴轉化為松耦合的依賴，怎么做呢？ 很簡單，讓我們在 Client 類中創建一個名為 _emailValidationService 的 var，并調用它來驗證我們的電子郵件，而不是直接調用我們需要的驗證類：
使用這種方法，當我們決定放置一個更高級的驗證電子郵件系統時，我們不需要更改 Client 類，很酷吧？
歡迎轉發，感謝閱讀！
年以來，隨著疫情方面的數據逐漸增多，一些互聯網公司也紛紛發布一些可視化的數據產品服務，讓用戶可以實時并直觀了解最新情況，可謂一個便民利器。而本文，則通過丁香醫生、以及騰訊新聞推出的“疫情實時動態”可視化服務，總結分享其中運用到的一些常見的數據可視化經驗。
閱讀指南：
（1）受眾人群：初級產品經理
（2）閱讀收獲
首先，需要先簡單澄清下數據可視化的基本概念。數據可視化，實質上是把一些概要信息（數據、關鍵內容），并結合動靜態的圖像視頻等形式進行展示，從而清晰傳遞核心信息。較為注重視覺層面的觸達。
所以我們需要在數據之中挖掘一些重要的價值信息，并以一個可觀的方式呈現。而“重要”的定義是十分明顯的，核心數據、用戶感興趣、有決策意義，都可稱之為重要。
根據馬斯洛五層次需求理論，那么數據可視化在其中屬于什么層次的需求？
受疫情影響，生命安全成了最重要的社會需求。那么滿足大眾對這方面的廣泛需求，推出這樣的數據可視化產品是十分有必要，滿足用戶對疫情情況、資訊信息、醫療信息等方面的獲取，從而保障自己基本的需求。
（1）脈絡
初始，丁香醫生率先推出一個H5的可視化頁面，匯總披露病例數據。隨后，一些大廠也開始陸續推出，包括頭條、騰訊等等。
而為什么大家都紛紛推出這樣的數據服務，從戰略層來說：一是做好企業責任，滿足用戶的知情需求；其二是滿足自己的平臺用戶，并吸引流量，這都是拉新、促活的寶貴方式。
而展示的信息，主要包括每日的新增、累計病例數，各地區的病例分布，以及疫情新聞、醫學知識等方面的內容。
（2）價值
而接下來，也將依據用戶體驗五要素中的范圍層、框架層、表現層，分別對這個疫情數據可視化的產品服務進行分析。
范圍層的定義是決定這樣的產品服務需要提供什么范圍內的功能服務，什么是不做的。以及要做的數據指標，哪些是關鍵的，哪些是次要的。所以我們可以羅列一下這樣數據可視化產品，基于用戶的需求是需要準備什么樣的數據指標。
上圖摘自國家衛健委某日的全日數據，在制作可視化的時候，需要考慮數據源的出處以及能提供什么樣的指標及口徑。
從中可以看出，大致可以劃分兩類關鍵數據：一個是病例的數據，一個是輔助性的數據。我們需要從中挑出其適合展示同時也是用戶需要關心的數據。
通常做這種可視化產品，總結性的數據是十分關鍵的。而基于用戶的關注點，每日新增、累計，就是其中的關鍵。
另外，基于“時間”和“地區”，代表了數據的“屬性”。而屬性則反應了這個數據可以以什么樣的特點進行展現。而“時間”和“地區”是，最適合以數據趨勢和數據分布的兩種主要數據可視化表達形式。
從下表可以看出，3家平臺的數據指標在展示上是比較一致的，核心指標都一一羅列展示。
其中在時間的“小時”級別，以及“解除醫學觀察”等細分指標都不做展示，我認為主要出于以下目的：
框架層的定義是指根據要做的功能范圍，應該確定如何正確布局和設計，可以簡單理解為PPT的排版一樣，以什么樣的方式來排列展現這些元素。
首先，我們需要先看看上文提及到的幾類數據指標，重新分類一下,并標記相應的優先級。
顯然按照合理的布局應該是：
大致的布局是已經清晰了，那么接下來就需要基于數據類型采用合理的可視化展示形式。
前面也提過，由于是時間和地區下的各類數據，基于這樣的屬性，是可以做趨勢、地域、列表等分布的展示方式。支持趨勢的圖形則主要為折線、柱狀圖，支持地域分布類型則為地圖，而列表則為常規的類報表方式等。
其中，由于時間跨度較長和地區明細較多，如果使用柱狀圖，則會顯得橫軸較長，所以在有限的手機屏幕尺寸下，是不適宜展示的。
（Echarts部分地圖特性截圖）
所以在這里，更傾向于采用粗一些的2D省級行政地圖形式，開發周期短，且滿足最基本需求。
（1）匯總數據
相同點：
差異點：
評價：正常應遵循“標題+具體數值+較昨日變化”這樣的排列比較合適，上下順序先從標題了解該指標的含義，居中放大具體數值，突出關鍵信息，其次顯示較昨日變化對比，感知變化情況。
（2）各指標趨勢
相同點：
差異點：
（3）國內各省市分布
相同點：統一以常規列表分布展示國內各省市的疫情數據情況，并集中以地區、確診、死亡、治愈等字段。
差異點：
評價：
（4）海外各國分布
展示方式如國內疫情一致，這里不多說。而唯一不同的是，丁香醫生在全球各國的基礎做了“洲”單位的分類。這樣的好處是，分類顯得更有層次性，了解某個范圍內的地區更有顯著性。
表現層所關注的，是頁面各個元素組件的形狀、色彩和大小比例搭配。同時數據可視化十分重視圖形色彩的表達，一個好的視覺設計，能夠為數據的信息傳遞起到十分重要的作用。
從上圖可以看出，3家平臺都展示了4個關鍵指標“確診”、“疑似”、“死亡”和“治愈”，以及在色彩選擇上，盡管有具體色值的差別，但是理念是都較為接近的。
地圖分布通常是以顏色深淺代表數據的“密集程度”，那么就要確定2個關鍵的地方，1個是色系，另外1個是合理的刻度比例。前者根據數據內涵確定合適的色系進行表達，后者是做色系的層次區分。
以上就是此次疫情數據下，在可視化應用上的一些體驗總結，3家都遵循了一些基本原則，同時也有各自的一些風格。而數據可視化的應用需要兼顧不同的因素，達到最佳效果。
一個理想的可視化設計流程，需要經歷“數據指標的范圍篩選、頁面的布局抉擇、可視化的視覺設計“等關鍵步驟。
3家平臺地址：
丁香醫生：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，數據產品一枚；公眾號：吾某
本文由 @A.D. 原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
器之心報道
編輯：力元、蛋醬
不要對 Python 4.0 抱有希望，可能不會有的。——Python 之父 Guido van Rossum
2020 年 1 月 1 日，Python 官方結束了對 Python 2 的維護，意味著 Python 2 完全退休，進入 Python 3 時代。之后，關于 Python 4 的發布排期也成為了社區的熱門議題。
去年，Python 之父 Van Rossum 在推特上表示，假如會有 Python 4，從 3 到 4 的版本過渡會更像從 1 到 2 的過渡，而不會像從 2 到 3 的過渡。
但在最近接受 Microsoft Reactor 采訪時，Van Rossum 被問及 Python 的未來，以及什么時候會出 Python 4.0。他卻表示，可能不會有 Python 4 了。
Van Rossum 回答說：「我和 Python 核心開發團隊的成員對 Python 4.0 沒什么想法，提不起興趣，估計至少會一直編號到 3.33。」
視頻地址：https://www.youtube.com/watch?v=aYbNh3NS7jA
在從 Python 2 過渡到 Python 3 時已經被上了一課的 Van Rossum 表示，在內部的嚴肅場合，談論 Python 4 是個禁忌，大家只會在飲茶時把 Python 4 當玩笑開。
2020 年 4 月，Python 2.7 生命周期中的最后一個版本 - Python 2.7.18 發布了。彼時 Van Rossum 警告過開發人員 Python 3 與 Python 2 不兼容，因此基于 Python 2 的軟件庫依賴項將不能升級至版本 3.0。
那是一個延續了數年之久，緩慢而又痛苦的遷移期。Van Rossum 說：「實際上，Python 比核心開發人員意識到的要成功得多，因此我們應該對從 Python 2 過渡到 Python3 更加了解和支持。但當時我們錯誤地認為過渡會很簡單，因為我們都像 Python 編程中的愛因斯坦一樣，可以在睡眠中將代碼從 Python 2 轉換為 Python3。」
不過，Van Rossum 并沒有完全排除 Python 4.0 的可能性，他暗示道，當 Python 與 C 的兼容性發生重大變化時，可能會改變目前的想法。Van Rossum 表示：「如果不更改語言就會與 C 擴展存在嚴重的不兼容，或者我們能夠擺脫全局解釋器鎖（GIL），這樣的情況下我們可能被迫升級至 Python4.0。」
然而，關于預計在 10 月發布的 Python 3.10，以及將實現一些重大速度提升的版本 3.11，Van Rossum 強調，重點依舊是盡可能長時間地漸進式的更新編程語言。
兩年前，Guido van Rossum 從 Dropbox 離職，宣布退休，但又在 2020 年 11 月加入了微軟，主動結束了自己的退休生活。當時他表示，將致力于「使用戶更好地使用 Python（并且不僅僅是在 Windows 系統上）」。
「現在，我們有一個嚴格的年度發布時間表，Python 3.10 之后是 3.11，之后是 3.12，依此類推。（在 Python 4 之前）我們必須先發布 3.9，每次添加另一個數字并不是容易的事，但仍然比從 3 到 4 輕松得多。」
「Python 的加速是漸進式的，3.11 版本會有新的速度提升，我們會在 3.12 和 3.13 中將其進一步提高。」
接下來，讓 Python 更快是 Python 核心開發團隊的工作重點。在近日的 PyCon Language Summit 上，Van Rossum 宣布目標是在 3.11 版本中將 CPython 的性能提高一倍。
Van Rossum 還介紹了通過外部項目（比如 Pyston）來加速語言的努力，Pyston 項目是 Python 3.8.8 的實現，該實現最初發布在 Dropbox，后來開源。其創建者最近發布了 Pyston 2.2，相比 CPython 3.8.8 的性能提高了 30％。
「現在，我覺得大約有一年時間來證明我們在 Python 性能上取得了進步，3.11 會比 3.10 快得多。」
同時，Van Rossum 也分享了自己對其他編程語言的看法，他欣賞 Rust 改進 C++ 代碼的能力，并且 Go 是「比較 Python」的語言中最有趣的。
「你可能注意到，在過去的六七年里，我們一直在 Python 中添加可選的靜態類型，也叫漸進類型。」Python 之父也介紹了 Python 近年來對 TypeScript 的重視程度。
「當開始項目時，我實際上并不了解 TypeScript，所以我不能說最初是受到了 TypeScript 的啟發…… 如今，我們肯定是以 TypeScript 為樣板，有時我們發布了新功能，因為某些功能相對 Typescript 是缺失的，然后我們根據用戶需求將其進行添加，非常成功。」
Van Rossum 說，Python 仍然在努力尋找重獲成功的方法。在他看來，Hejlsberg 是一個非常聰明的人，TypeScript 正在做的一些事情，是 Python 未來需要弄清楚的。實際上 TypeScript 也在向 Python 學習，就像 JavaScript 在一些領域從 Python 那里學習一樣。
參考鏈接：https://www.tectalk.co/why-python-4-0-might-never-arrive-according-to-its-creator/
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
