如何避免程序員的大腦超載？

長沙7喜 2019-08-16

展開全文

富含邏輯與計算的程序員職業(yè)，并非任何人都可以勝任，那么對于身處其中的開發(fā)者，該怎么做，才能減輕自己腦部的壓力？

作者 | Javier Casas Velasco

譯者 | 彎月，責(zé)編 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下為譯文：

心理學(xué)中有一篇古老但非常重要的論文《神奇的數(shù)字：7±2：我們信息加工能力的局限》（The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information）。作者對大腦處理信息的極限進(jìn)行了定量研究：人腦可以同時處理5-9個概念。這其中有許多有趣的含義，但對于我們這些軟件開發(fā)人員來說，有兩個含義非常重要：

構(gòu)造（模型、實現(xiàn)、設(shè)計、模式等等）越簡單越好，因為你可以用更少的概念來描述它們。
良好的抽象自帶的特殊規(guī)則越少越好，而且最好沒有驚喜和意外，因為同樣你只需用更少的概念來描述它們。

說到底，這是一場努力讓占據(jù)大腦空間的概念趨近最少的戰(zhàn)斗，因為大腦空間非常稀缺。

簡單的構(gòu)造

查爾斯·霍爾曾說：

構(gòu)建一項軟件設(shè)計有兩種方式：一種是將軟件設(shè)計得足夠簡單以至于明顯找不到缺陷；另一種是軟件設(shè)計得足夠復(fù)雜以至于找不到明顯的缺陷。

不幸的是，他還補(bǔ)充了一句：

第一種方法要困難得多。

在軟件開發(fā)中，添加一個模塊、一個類非常容易，代碼也會越來越多。這固然可以解決大多數(shù)軟件的需求，但需要的代碼越來越多，獲得的結(jié)果卻越來越少。Jamie Zawinski曾說：

每個程序都會嘗試擴(kuò)展，直到能夠閱讀郵件。無法進(jìn)行這種擴(kuò)展的程序都將被它們所取代。

本質(zhì)上，我們擴(kuò)展程序是為了提供越來越多的功能。我們添加更多模塊、更多類和更多的代碼，而且添加的每一段代碼都需要與之前的代碼協(xié)同工作，故而隨著各段代碼之間的交互無限擴(kuò)展，程序的復(fù)雜性也呈指數(shù)激增。我們這么做是因為這種做法很簡單，至少在剛開始的時候很簡單。

另一方面，制作盡可能簡單的東西實際上非常困難。你需要尋找潛在的模式和行為，還需要去除不適合的東西。但是，最終這種方式制作的東西更好，因為你使用的概念較少，也無需浪費過多腦細(xì)胞就可以描述這些模式和行為，這意味著你可以專注于整體，而不必在意太多細(xì)節(jié)。

檢測過于復(fù)雜的構(gòu)造

實際上，檢測過于復(fù)雜和臃腫的構(gòu)造也并非難事。你只需查看一下手冊。如果手冊用大量文字描述了構(gòu)造的上下文，則表示這個構(gòu)造可能過于復(fù)雜。

讓我們來看一個例子：AbstractFactory模式。為了描述該模式的工作方式，我們需要描述很多名稱：

AbstractFactory：接口
<<creates>>：操作
Factory1（ConcreteFactory）
ProductA、ProductB：接口
ProductA1、ProductB1：類
new：關(guān)鍵字
抽象工廠類圖
:Client、factory:Factory1：序列圖

所有這些名稱和圖表之所以存在是因為制造復(fù)雜度比減少復(fù)雜度更容易。同時，它還會迫使程序員為創(chuàng)建這些對象而制定出過于特定化的解決方案，而忽略其他解決方案——例如重用存儲在某處的對象等。實際上，我們可以降低復(fù)雜度：

從整個模式中刪除“Factory”名稱。
刪除關(guān)鍵字new和<< creates >>操作。

現(xiàn)在，這個模式只有一個返回ProductA或ProductB實例的對象。它可以實例化類，從數(shù)據(jù)結(jié)構(gòu)中獲取預(yù)先構(gòu)建的對象或從不明區(qū)域獲得對象，這都無所謂，因為我們所關(guān)心的是開始的時候我們沒有對象，結(jié)束的時候卻有一個對象。現(xiàn)在，上述列表變成了：

兩個操作：

第一個操作：通過接口ProductA獲取對象
第二個操作：通過接口ProductB獲取對象

你可以將操作放在一個類、一個結(jié)構(gòu)或指針中，放在哪兒都行（甚至是你家客廳）。使用的時候，可以通過任何參數(shù)調(diào)用其中一個操作，然后它們會為你提供相應(yīng)的對象。設(shè)置的時候，可以將第一個操作設(shè)置為生成ProductA的操作，將第二個操作設(shè)置為生成ProductB的操作。沒有類圖，沒有序列圖，沒有額外的類，沒有額外的詞語。沒有歧義，因為你可以執(zhí)行的操作無非是調(diào)用它，將它作為參數(shù)傳遞，返回它并存儲它。因為函數(shù)和操作只不過是帶參數(shù)的值。那么如何通過ProductA接口獲得對象呢？ProductA能返回怎樣的對象呢？只能是第一個操作，因此你只能使用它。

構(gòu)造良好的抽象能很好地組合

上述我們通過修改AbstractFactory描述了一個構(gòu)造良好的抽象。構(gòu)造良好的抽象能很好地組合，這句話包含兩部分：

構(gòu)造良好的抽象

AbstractFactory模式是一個糟糕的抽象，因為它暴露了我們不關(guān)心的細(xì)枝末節(jié)，例如它是抽象，它必須創(chuàng)建對象，以及它使用new關(guān)鍵字。作為用戶，我們并不關(guān)心這些細(xì)節(jié)，但所有這些都出現(xiàn)在我眼前時，就必須處理。

相反，我只想要“一個操作，一個能夠讓我通過ProductA接口獲取對象的操作?！蔽艺{(diào)用這個操作，而它則返回一個ProductA。我不知道，也不在乎它獲取對象的過程。

很好地組合

AbstractFactory模式是一個糟糕的抽象（再說一次），因為它沒有進(jìn)行組合。它有兩個對象：一個創(chuàng)建ProductA，另一個創(chuàng)建ProductB。為什么我必須把它們放在同一個Factory里？為什么我不能分開這兩個操作？如果有人想合并在一起，則可以將它們放在同一個元組中。即便它們在同一個類中，也沒有良好地組合。我該如何合并它們？如果我在某處需要ProductA的其他操作該怎么辦？該操作是否需要了解AbstractFactory的錯誤鏈？

AbstractFactory myFactory = new Factory1();
ProductA myProduct = myFactory.createProductA();
AbstractFactory somethingDifferent = new SomethingDifferentFactory();
SomethingDifferent result = somethingDifferent.fabricate(myProduct);
return result

相反，如果我有“一個能夠讓我通過ProductA接口獲取對象的操作”，以及另一個通過ProductA構(gòu)造不同東西的操作，那么我就可以先調(diào)用第一個操作來獲取ProductA，然后再調(diào)用第二個操作。類型定義如下：