總是看到有人說,動(dòng)態(tài)一時(shí)爽,重構(gòu)火葬場(chǎng)。
然而這世界上有的是著名的開源項(xiàng)目,也有像 Github、Instagram 這樣流量巨大的知名網(wǎng)站是基于動(dòng)態(tài)語言開發(fā)的,經(jīng)過了這么多年重構(gòu),也未聽說哪個(gè)作者進(jìn)了火葬場(chǎng)的,不明白這些人是真的不知道還是裝作看不見呢?不過他們說動(dòng)態(tài)語言大到一定程度就無法維護(hù),雖然這話也同樣不值一駁,不過也提醒了我,我也很好奇用動(dòng)態(tài)語言開發(fā)的項(xiàng)目規(guī)模能大到什么程度。
從我知道的信息看,用動(dòng)態(tài)語言開發(fā)的最大規(guī)模的項(xiàng)目可能要算是OpenStack,據(jù)說代碼總量已經(jīng)達(dá)到數(shù)百萬行,并且還在持續(xù)增加中。這當(dāng)然是一個(gè)說明動(dòng)態(tài)語言能力的好例子。不過像這樣巨大的項(xiàng)目,要分析起來也并不容易(好吧,真正的原因是我懶得下載那么龐大的代碼庫)。我選擇了 Python 社區(qū)中比較知名的一些項(xiàng)目來分析,主要是來自 Github ,也有個(gè)別來自其他倉庫。這個(gè)選擇可能包含了一定的主觀因素在內(nèi),不過我相信大多數(shù)項(xiàng)目還是非常有代表性的。
計(jì)算代碼數(shù)量的工具是cloc。所有項(xiàng)目均選擇截止到 2018 年 1 月 3 日的主干代碼,統(tǒng)計(jì)中僅包含 Python 文件,排除了其他文件類型。值得說明的一點(diǎn)是, 通過 Ubuntu APT 默認(rèn)安裝的 cloc 版本 1.60 在統(tǒng)計(jì)部分項(xiàng)目的時(shí)候存在問題,該問題在最新的版本中已經(jīng)得到解決,因此本文中所有統(tǒng)計(jì)均使用從官網(wǎng)下載的 cloc v1.72。
上表已經(jīng)按代碼行數(shù)排了序。有意思的一點(diǎn)是, 代碼規(guī)模最大的前4名中除了 CPython 之外其他三個(gè)全部是運(yùn)維性質(zhì)的項(xiàng)目,本來我猜測(cè)代碼應(yīng)該比較多的項(xiàng)目比如 Odoo 排名反而很靠后。我對(duì)運(yùn)維項(xiàng)目了解有限,不太清楚為什么這些項(xiàng)目的代碼規(guī)模會(huì)名列前茅,或許是因?yàn)橐С值膬?nèi)容比較多而雜?
本次統(tǒng)計(jì)中純 Python 代碼量最大的 Sentry 幾乎達(dá)到了 70W 行,這是相當(dāng)有規(guī)模的項(xiàng)目了。30W~50W 行代碼的項(xiàng)目有三個(gè),包括基礎(chǔ)項(xiàng)目 CPython 在內(nèi)。20W 和 10W 行代碼規(guī)模的分別有三個(gè),剩下 7 個(gè)則在 10W 行以內(nèi)。看過這個(gè)列表你應(yīng)當(dāng)相信,動(dòng)態(tài)語言至少在幾十W行代碼的項(xiàng)目上是完全沒有問題的。這也是絕大多數(shù)普通應(yīng)用的上限了,如果代碼真的達(dá)到數(shù)百萬行規(guī)模的話,那么無論用什么語言,都勢(shì)必面臨著拆分項(xiàng)目的問題。
上表將代碼量指標(biāo)按照代碼/空白/注釋進(jìn)行了分類,也在一定程度上反應(yīng)了項(xiàng)目的代碼風(fēng)格。Sentry 是本次統(tǒng)計(jì)中代碼量最多的項(xiàng)目,然而從表中可以看到,項(xiàng)目中的注釋和其他項(xiàng)目相比,少得有點(diǎn)不成比例,說明 Sentry 的作者非常不注重注釋。
同學(xué)們一定發(fā)現(xiàn)了,我在列表中除了代碼行相關(guān)的指標(biāo)之外還增加了幾個(gè)其他內(nèi)容,這也是我個(gè)人比較感興趣的方面。
第一個(gè)指標(biāo)是每個(gè)文件的平均代碼行數(shù)。按照模塊化的觀點(diǎn),單個(gè)文件中堆砌太多內(nèi)容顯然是不合理的,這通常意味著耦合太多、難于理解和修改。然而到底多少算是合適,并沒有一個(gè)明確的標(biāo)準(zhǔn)。我希望通過這些項(xiàng)目的分析,了解一下開源作者們?cè)趯?shí)踐中做出的選擇。
統(tǒng)計(jì)的結(jié)果分布比較平均,從 100~600行/文件的都存在,并不存在明顯的集中點(diǎn)。有趣的是,頭兩名(Pandas, NumPy)有著緊密的聯(lián)系,都是和數(shù)學(xué)統(tǒng)計(jì)相關(guān)的。這可能是因?yàn)閿?shù)學(xué)庫的特點(diǎn)比較純粹而單一,不像其他類庫那樣容易劃分。末尾的項(xiàng)目(Pillow, youtube-dl, Odoo, Scrapy)可以從側(cè)面印證這種猜想:它們都是面向特定領(lǐng)域的,所以更加容易模塊化。
第二個(gè)指標(biāo)是注釋和代碼的比例,這個(gè)問題也有著類似的情況。注釋并非越詳盡越好,但總是需要一定量的注釋來解釋 Why 的問題。注釋太少,說明項(xiàng)目的作者沒有給后來的維護(hù)人員留下足夠的線索,可能會(huì)造成維護(hù)上的問題。另一方面,我們考察的全部是開源項(xiàng)目,沒有公司考核或者 KPI 的約束,所以我們可以放心的相信不會(huì)存在作者故意多寫注釋的問題。前面提到的 Sentry 毫無爭(zhēng)議的因?yàn)樽⑨屘倥诺搅俗詈螅@未必說明這個(gè)項(xiàng)目很差,但至少是一個(gè)信號(hào),說明該項(xiàng)目在維護(hù)方面可能是存在問題的。而對(duì)于那些作者愿意投入精力來寫注釋的項(xiàng)目(Ansible, NumPy, Fabric, Salt 等),足以反映作者在項(xiàng)目上投入了相當(dāng)大的心力,這是一個(gè)好的信號(hào),說明這些項(xiàng)目是值得信賴的。
有一點(diǎn)是出乎我意料的,那就是作為所有項(xiàng)目之母的 CPython 排名比較靠后,按照道理這個(gè)基礎(chǔ)項(xiàng)目應(yīng)該有更多的注釋才對(duì)。不過再想一想又覺得可以理解,因?yàn)?CPython 有單獨(dú)發(fā)布的、非常詳盡的文檔,這是其他大多數(shù)項(xiàng)目都沒有的,那么代碼中的注釋少一些也是情有可原的。
最后一項(xiàng)統(tǒng)計(jì)是關(guān)于文件類型的。Python 項(xiàng)目中絕大多數(shù)應(yīng)該是 Python 代碼,這點(diǎn)沒有什么疑問,但同時(shí)我也想看看除了 Python 代碼之外,一個(gè)項(xiàng)目還包括哪些主要文件。C/HTML/Javascipt 的上榜是毫不意外的,但有一種文件我事先沒有想到,那就是 .PO(開源項(xiàng)目常用的語言資源文件)。對(duì)于 Django 和 Django-CMS 這兩個(gè)項(xiàng)目, PO 代碼數(shù)量甚至比 Python 代碼還要多。
大概看了一下,Django 支持 90 種以上的語言,這也無怪乎語言文件的數(shù)量如此之多了。這個(gè)結(jié)果也可以提醒我們,有些同學(xué)——不僅是程序員,也包括大多數(shù)經(jīng)驗(yàn)不足的老板、客戶、產(chǎn)品經(jīng)理等——會(huì)下意識(shí)的認(rèn)為程序開發(fā)無非是寫代碼,對(duì)于代碼之外的其他工作,在估算的時(shí)候往往只拍腦袋式的定下一個(gè)極短的時(shí)間。但對(duì)于實(shí)際的項(xiàng)目來說,代碼僅僅是其中的一部分,"其他工作"有時(shí)候——應(yīng)該說是經(jīng)?!獣?huì)占用你大部分的的時(shí)間和精力。
這些工作往往并不有趣,但對(duì)于項(xiàng)目來說又是必不可少的組成部分,希望同學(xué)們予以足夠的重視。
-
代碼
+關(guān)注
關(guān)注
30文章
4671瀏覽量
67770 -
python
+關(guān)注
關(guān)注
53文章
4753瀏覽量
84081
原文標(biāo)題:代碼行數(shù)最多的 Python 項(xiàng)目是?
文章出處:【微信號(hào):magedu-Linux,微信公眾號(hào):馬哥Linux運(yùn)維】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論