對一些關於編碼格式方面的老生長談做乙個重新的思考

2021-10-24 17:36:24 字數 2431 閱讀 9678

這個建議的原始意義在於使乙個函式能夠在顯示器上完全顯示。而多數的顯示器大約就只能顯示30行原始碼。

遵循這一建議後,我們將會發現乙個問題,雖然單個函式的可讀性提高了,但是代價是為了分散原始碼而不得不產生大量的一次性的函式。這些一次性的函式不光使程式整體變得凌亂,在ide中還會占用掉大綱空間。總體上看,提高單個函式的可讀性而使工程更混亂並不可取。最初提出此建議的人,在當時的歷史背景下,他所看到的工程是結構簡單、功能單一的程式,甚至於乙個程序只是為了進行乙個數**算。然而軟體技術發展至今,乙個工程往往帶有非常多功能、大量的執行緒、詳細的層次關係、各種第三方程式包。這一建議顯然不能適用於所有的情況。

乙個工程中可見的**可以分為工具、平台、架構、業務四個層次。

工具層提供基礎的驅動、演算法、容器、資源管理,只要所用的程式語言不過時,工具層可以永久使用,另外,相關程式語言的第三方元件和api都屬於工具層。

平台層提供前後端引擎,支撐起乙個事件空間,提供原始的人機介面支援,將網路計算機進行關聯。tomcat、mfc、qt都屬於平台層。mfc本身也有提供幾種原始架構。

架構層用於定義業務流程和人機介面的形態,定義乙個軟體所支援的業務方向。架構層與業務方向有較強的關聯,細節上常常需要定製,這也就是為什麼已經有了mcv的思路還是需要大量的架構師去參加工程的原因。因為mcv只是一種理論,每一套業務都需要對應的例項。這就導致了架構師有做不完的工作。

業務層用於定義業務流程中每乙個環節的功能、與其他環節的關係。對於商務辦公方向的業務層,**常常是非常相近,但又有少量變更,商務辦公的主要難點在於大量的畫面需要定製和大資料響應性太慢。對於工業自動化方向的業務層,定製程度較高,需要結合聲/光/熱/電/氣/液/剛/柔聯合傳動進行定製,工業自動化的主要難點在於抵禦系統外的干擾和零部件損耗補償。

其中的工具、平台兩個層次需要長期整體維護,對於這些需要長期整體維護的**,整體結構的清晰度要比區域性結構的清晰度更重要。工具和平台層的細節往往不需要持久的維護,一套區域性**通常在兩年內可以達到最終版本。因此,在工具和平台兩個層次上,建議盡可能減少檔案、類、函式的個數。盡可能地使用內部類、匿名類、匿名函式、**塊、區域性巨集以減少可見標籤的數量和作用域。

架構層是為了某些業務定製流程規範的**、生命週期相對較短,整體尺度不大,為了良好地支援業務層的發展,可以考慮對區域性進行優化。業務層本身不具有整體性,也就不需要考慮減小可見標籤的問題,只需要做好細節的處理就夠了。在架構層和業務層上,可以考慮用函式名來代替注釋的可能性,以減小工作量。因此,建議使架構層和業務層的粒度稍小一點,大約30行是乙個不錯的選擇。

關於注釋應該詳細還是簡約是乙個無理取鬧的問題。事實上,不論注釋得多麼詳細,別人也一樣看不懂你的**。注釋主要還是為了自己。

乙個推薦的方法是當你覺得需要有注釋的時候才去寫注釋。這樣可以避免大量的無用注釋。當你發現曾經的**開始看不懂了的時候,就可以去加注釋了。

注釋是乙個筆記,你可以記錄乙個演算法的理論依據、參考文獻、要感謝的人、操作步驟分解等你覺得有用的東西。就算是乙個不起眼的感謝注釋,也許在將來的某一天,你需要求助的時候也會派上大用場。而操作步驟也許並不重要,因為就算看了操作步驟也同樣有可能無法理解為什麼非得要按這個步驟。

這一規定通常是用於乙個檔案有多人修改的情況下,如果沒有統一的格式,檔案就會看起來很混亂。

進一步地,它的目的在於對不合理的事件合理化。不知道是誰引發的多人修改同乙個檔案的思想。試想,某一天軟體出現問題的時候,這個部分是誰負責的?這一天操作過這一部分**的人有三個,操作過這一檔案但沒有操作過這部分**的人有六個,但他們同樣有嫌疑。於是就要清查修改記錄來定罪。清查後發現是同步伺服器的同步過程發生衝突造成的,誰都沒有錯。

安全的做法是責任要明確,你在工廠裡面絕對看不到乙個零件會有兩套班組進行安裝的。這是誰的工單就由誰去完成,不然工資的分配就會失去依據。同理,軟體開發的過程中,乙個塊只能有乙個負責人。他只需要按呼叫者的規範定義介面,被介面封裝過的內部構造完全沒有必要統一。另外,每個型別都應該有單一的檔案、每個型別中的成員都應該有唯一的維護人員進行管理,以避免**同步衝突。

更進一步地,層次、業務的職責應該分離,避免由於乙個業務模組變更導致另乙個業務模組的程式設計師也要配合做調整。底層的介面應避免在工程中變更。技術開發與業務開發應是非同步進行的。新介面不可以用到已在進行中的專案上,也要避免對底層進行更新,否則由於技術開發導致的變更會使整個工程都要大規模地調整。

頂層優化與底層優化的重要性取決於乙個軟體的設計是面向業務還是面向技術的。

面向業務的軟體設計會採用自頂向下的設計模式,這種情況下,底層**的價值就相對較低,甚至為了保持架構容許出現一定量的重複**。所有的底層實現都是為了特定的架構而定製的,可以使工程達到理想的狀態,但是對技術的積累沒有多大的貢獻。這種情況下,頂層優化決定著巨集觀的效能,需要更好的優化,而底層**沒有很高的價值,不宜多做優化。

面向技術的軟體設計採用自底向上的設計模式,這種情況下,底層**的價值很高,是無法估計的。所有的底層**都是為了應對豐富的需求而設計的,具有很高的技術價值,而頂層**只不過是臨時性的一種裝配。這種情況下,頂層優化決定了乙個工程的效能,沒有必要進行深入的優化,而底層**決定了無數個工程的效能,需要精心設計,以保證效能和穩定性。

Vue關於元件方面的一些總結

新舊虛擬dom經過diff比對,形成乙個補丁 patch s 區域性更新真實dom 按dom樹的層級分解比較 嚴格的資料結構劃分 同key值對比 v for寫key,其他的元素會預設分配key 注意 在v for對乙個陣列迴圈渲染的時候千萬別用索引值當做key值。因為在是涉及陣列的增刪時候,索引值每...

AIX方面的一些資源

常用aix論壇位址介紹 aix論壇 http loveunix.style images 1 logo4.gif img url 愛u家園 是大家的快樂空間 aix使用者論壇 chinaunix的aix論壇 aix中國論壇 思達奇公司的aix 技術區 itpub的unix論壇 銀信公司 aix練習 ...

一些語言方面的技巧

1.數字轉string int x string id stringstream ss ss id 2.字串轉數字 int num string s stringstream ss s ss num char str sscanf str,d num 將字串轉換成整數 sscanf str,f fl...