再論“邊界”問題

       維特根斯坦說“凡是能夠說的,都能說清楚;凡是不能說的,就應保持沉默。”

      在我看來,這仍然是一個“邊界”問題。之於軟件工程,Team Leader經常教導我們一句話“編碼是個次要問題”(興許援引自《人月神話》)。當我們想要實現一個用例,一個功能時,我們的確不急於着手碼代碼,而是應該自問:你能否用自然語言,把這件事情(需求)有條理有邏輯的表述出來,尤其對於核心業務內涵和外延的描述,包括措辭力求嚴謹,這就是劃清邊界。而程序語言是比自然語言更嚴謹、更富邏輯性的表達工具,如果用簡單的自然語言都不能清晰的把業務各個層面的邊界釐清,那就更不用指望寫出整潔的代碼了。

        當然,要做到“不畏浮雲遮望眼”是很難的,因爲大多時候我們不是“只緣身在最高層”,而是“不識廬山真面目,只緣身在此山中。”我在我的短博文“什麼是架構”裏也提及過,架構是不斷否定之否定,逐漸劃清邊界的動態演進過程,“架構演進即架構”這個講法也不是我甚至也不是我們的Leader提出的,類似思想大牛們早有提及。然而它的確是站在認識論高度的恰當總結。回到維特根斯坦那句名言,再去審視“編碼是個次要問題”這個觀點就不難理解了。在動筆之前,很大程度上應該有這樣一個盡最大努力去釐清當前問題邊界的一個過程,如果能有個清晰的視圖在心中,那寫起代碼來就是“胸有成竹”、“下筆如有神”的酣暢淋漓了,因爲能把它說清楚;反之,如果腦中一團亂麻,疑雲團團,根本沒個頭緒,那就是基礎工作還沒有做到位,該做的調研、溝通、查閱資料、整理思路等工作還是欠缺的,此時應該“保持沉默”。凡事都有個度,有些問題光想也是想不開的,以上所說的prepare工作,就像微分學中的線性主部,是要解決大方向問題,解決矛盾的主要方面。如果努力把以上問題克服,此時可以動筆編碼了,儘管此時還是謹小慎微探路前行,但輪廓是清晰的,意識的能動作用會牽引着你逐漸撥開雲霧見青天。

        之所以說,這個認識過程是一個劃清邊界的過程,是因爲當我們去認識、定義一個實體是什麼時,一定是有其他參照系,知道它不是什麼的,就像擇青菜時,我們知道我們要食用的菜不是混在其中的雜草、爛菜葉並將其剔除。回過頭來,當我們編碼建模時,比如使用java中的class時,你會怎樣理解它呢?我們可以說一個class是具有共性的一系列對象的模板,從文件/資源組織的角度也可以說它是一個命名空間,用於標識資源的位置,也可以說它是一個容器,用於盛放數據和函數等,不管怎樣理解它,但我們自問,有多少人真正的從邊界劃分的角度去理解類這個東東呢?事實上,以上提及的幾種對於類的理解,邊界仍在其中。隨意的創建類文件,隨意的分包,隨意的使用限定關鍵字public、protected、private、default,雖然使用着OO語言但卻充斥着大量的貧血域模型——僅把一個類退化成數據對象(相當於一個Map,那置基礎引用類型以及集合框架於何地?),甚至lombok的出現使get/set方法都“省去”了等現象很常見(這裏並不是說這樣做不對)。“其大無外,其小無內”,在系統的各個層面上,當我們不去仔細的審視問題邊界時,大到架構、小到一個函數的邏輯,盲目就開始編碼時,也就是混亂的開始。因此,“凡是不能說,就應該保持沉默。”

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章