為什麼程序員應該避免間接代碼？

本文討論被間接代碼毀掉的可閱讀性。

作者 | Matthew Rocklin

譯者 | 彎月，責編 | 郭芮

出品 | CSDN（ID：CSDNnews）

以下為譯文：

我常常看到有些代碼的作者為了抽象，而把細節放入某個外部函數中。請看下面的例子。

加入間接代碼之前：

# main.py

if x.startswith("foo"):
do_something_with(x)


加入間接代碼之後：

# main.py

if is_foolike(x):
do_something_with(x)

# utils.py

def is_foolike(x):
return x.startswith("foo")


這種做法的理由可能包括：

• 如果代碼重複多次，那麼這種抽象可以讓代碼更緊湊；

• 如果代碼重複多次，那麼就應該找一個位置集中管理這段邏輯，以便將來可以集中修改；

• 這種抽象隱藏了與功能要點無關的細節，就像散文中的腳註；

• 這種抽象通過函數名稱作為內聯文檔為一組操作命名；

• 感覺代碼更乾淨，更抽象。

學校老師就是這麼教我們的——找到一些功能，抽象出去，然後繼續。

避免間接的情況

然而，這種添加間接代碼的行為也需要付出代價。當其他人閱讀這段代碼時，他們需要在多個文件定義的多個函數之間跳轉。這種非線性的閱讀過程更加耗費閱讀者的精力。

在寫代碼的過程中，加入這種間接代碼並沒有任何問題，寫代碼的人的腦海中建立了一個抽象模型，因此將這種抽象寫入代碼是有意義的，感覺很好。但是，當其他人需要快速檢查和理解一段代碼時，就會遇到大麻煩。這發生在兩種重要的情況下：

1、在代碼審查期間。當其他人需要在代碼合併到主項目之前，檢查代碼是否合理。這些審查人員需要花費的時間大約是寫代碼的時間的十分之一。

2、將來的調試。如果代碼中存在任何問題，那麼將來完全陌生的開發人員將不得不查看這段代碼，並搞清楚代碼的內容。他們必須在幾分鐘內理解這段代碼，並確定相關的內容。他們沒有時間理解代碼背後完整的思維過程，而間接的代碼會大大減慢理解的過程。

與原來的開發過程相比，現代社區代碼中的審查和調試往往是瓶頸。因此，我經常鼓勵開發人員避免抽象，並將函數定義寫在代碼內部。

我們仍然應該使用函數

需要明確的是，我們有很多理由將複雜的邏輯分成多個函數，特別是面對重複代碼的時候，或者某些重要的政策可能會在將來發生變化時。因此，我們需要找到一個平衡點。

我希望在大多數情況下，寫代碼的人能夠意識到除了原作者之外，每個閱讀代碼的人都會感受到間接代碼帶來的附加成本。

原文：http://matthewrocklin.com/blog/work/2019/06/23/avoid-indirection

作者：Matthew Rocklin，維護與協調Python數字計算生態系統中的多個庫，特別是有關高效和可擴展的計算。

本文為 CSDN 翻譯，轉載請註明來源出處。

【END】

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！