當前位置:  首頁  >  PHP資訊  >  大話程序猿

程序員開發者應該負責多少代碼行數?

當我在越來越多的組織中工作之后,我編譯時候遇到的有趣問題也越來越多。嚴格來說,我也有了很多待辦事宜。而此處的有趣并不是諷刺。這種有趣就像是你聽見一個醉漢夸夸其談他的政治觀點,然后回答說“哦,那……很有趣”。

當我在越來越多的組織中工作之后,我編譯時候遇到的有趣問題也越來越多。嚴格來說, 我也有了很多待辦事宜。而此處的有趣并不是諷刺。這種有趣就像是你聽見一個醉漢夸夸其談他的政治觀點,然后回答說“哦,那……很有趣”。

程序員應該負責多少行代碼.jpg

把這些問題放在哲學層面上真的讓我很感興趣。它們讓我想去了解我從來沒有想過的事情。今天我從眾多問題中選出一個,然后搞清楚。這個問題是一個客戶在不久之前問過我的:“開發者應該對多少代碼負責呢?”

為什么要問這個呢? 好吧。是因為他們有一個值得稱贊的目標。 他們有一個相當龐大的遺留代碼庫,并且不想那些在其上工作的人負擔過重。 “我們知道我們的代碼庫有X行代碼,所以多少開發人員可以組成一個完美的開發團隊?

他們以數據驅動的方式問了一個很好的問題。然而,由于缺乏更仔細的檢查,所有理由都不成立。 我今天會說出為什么會如此。下面是一些關于這個想法的問題列表。

集體代碼所有權

首先,此處不談針對集體代碼所有權的異議。歷史上,應用程序開發的經理出于特殊的目的往往將軟件工作和體力勞動做對比。

有一堆需要挖的洞? 分配給每個團隊成員一些挖洞的任務。有一堆需要編寫的代碼? 分配給每個團隊成員需要編寫的代碼段。

當你意識到代碼與挖洞是不同的,代碼塊不是商品的時候,你就要準備好應對麻煩事了。也就是說,你不能拿它們做互換交易。所以當你對代碼進行了劃分,剛好碰上編寫 X 模塊的人輕量兩個星期假,那你只是把任務擱置,直到那個人回來。

個人代碼所有權也會帶來其他問題,但往往是對業務影響最大的。有人稱之為“公共要素”。但是無論你叫它什么,當你開始談論團隊成員對現有代碼的“負責”時,你應該鼓勵此類行為。 因團隊本應該對代碼庫負責。 僅此而已。

代碼量意味著什么呢? 無所謂?

對于那些年紀比較大的.NET開發者來說, 你可能會把你的編程歷史分為"BL"和"AL". 即"Linq前"和"Linq后"。

在 Linq 出現之前, 你寫了大量的指令性的代碼,,遍歷嵌套循環直到找到你想要的對象。而Linq一經問世, 所有這些都變成了聲明式的代碼。但它不是通過一對一的智能海量映射做到的。它是將你的冗長的就像快要爆炸了的中子星一樣的指令性代碼,分割成一系列更小的部分。

通過這些,我們知道了代碼量在不同的語言、開發者甚至語言的不同版本之間,都會有巨大的差異。因此,"How Much" 作為一個數值指標變得相當不穩定,以至于有很少的可度量的值.

從商業的觀點看, 代碼就像庫存, 它提供了商業可能性, 但是它放在那兒,就是你的負債。你希望開發者用盡可能少的代碼完成一個功能。而比較諷刺的是,有些開發者們更趨向于為每一個功能寫盡可能多的代碼,他們就應該為"最少代碼"負全責。畢竟有時候, 多不一定更好。

代碼的不確定性

我提出的第三個也是最后一個反對意見是關于代碼不確定性的。這里,我指的是給定文件或代碼段的更改頻率。

要理解代碼的不確定性會在哪產生分歧,請考慮兩個極端。首先,考慮一個穩定的、被充分考慮的模塊,它包含了一百萬行代碼。每隔34年,就會出現一些新的政府監管規定,需要對這里或那里進行一些細微的調整,但除此之外,它如產品鏈上的夢幻一般運行良好。

另一方面,考慮一個10,000行應用程序。但是這個應用程序有各種各樣的運行時問題。這里,為了更說明問題,假定持股人在不斷改變著他們對軟件行為的想法,導致大量粗制濫造。

對于這兩個代碼庫,您完全可能將100萬行的代碼庫交予1個開發人員維護,而你需要一整個團隊來為第二個代碼庫工作也是完全可能的。盡管后者的代碼庫的大小是前者的1%,這依舊是有理可據的。

我提供這個例子來說明一個重要的觀點。光用代碼的行數來作為維護的依據是欠妥的。因此,僅僅使用代碼行數來評估維護計劃會成為悲傷的故事。

根據代碼庫對團隊進行評估

那么,你如何根據代碼庫來劃分一個團隊大小?如果不可行,那么開發人員應該負責多少代碼,或者說“開發人員應該承擔多少責任?”

我將給出一個既簡單又難以衡量的方案:開發人員應該承擔多大的責任?基于這點考慮,可以讓代碼變得更加規范。

在敏捷(Agile)開發的世界里,這一思路產生了故事地圖(story mapping)和計劃活動(planning activities)。將軟件的目標劃分為待辦事項列表中的特性,然后讓團隊對這些特性進行分析處理。如果團隊在業務上進展過慢,則表示你的團隊需要壯大。如果人們無所事事,說明你的團隊人員冗余。

在自頂向下計劃/瀑布模型的世界中,會呈現出一種類似的動態現象,而你所能做的就只是算算會在什么時候先于計劃完成(哈,就是這樣)或是開始落后于計劃。先于計劃,那就是團隊人數太多了,落后于計劃,就是人數還不夠。

誠然,你得通過計算和觀察軟件所實現的功能是否能跟上業務需求的演進步伐,才能估量出開發人員所要承擔的責任范圍。

吐了個 "CAO" !
  • 專業文章代寫   2017-11-08 22:41:46
    666
掃碼關注 PHP1 官方微信號
PHP1.CN | 中國最專業的PHP中文社區 | PHP資訊 | PHP教程 | 數據庫技術 | 服務器技術 | 前端開發技術 | PHP框架 | 開發工具 | PHP問答
Copyright ? 1998 - 2020 PHP1.CN. All Rights Reserved PHP1.CN 第一PHP社區 版權所有
     
28玩法