關注細節但不陷入細節

2021-09-07 22:32:28 字數 1025 閱讀 5163

我們經常說要關注細節,這個從大的方向上來說,是沒有問題的。以前有一本書《細節決定成敗》講的這一方面。在對於某些領域,細節是需要關注的,但是不能陷入細節。換個說法,如果你一直糾結與細節的上的問題,就很難突破自己,把握全域性,畢竟人的時間是有限的,能夠把握整體,抓住重點細節,關注核心領域所處的細節才是王道。

以前做過很多專案,在專案整體業務確定之後,就陷入到細節的討論之中,當一群人坐在一起,你說一句,我說一句,把大家都能想到的各種可能性都拿出來,然後你針對各種可能性找出相應的解決方案。這些細節中,有一部分是針對某一特例的,有一些是業務異常規則引起的,有一些是互動方面的,而有一些是具有抽象的,公共性質的。

在這些細節中,最有價值的就是具有抽象的,通用領域的細節,這些能夠幫助你把具體的細節抽象出共同的特性,並且可以把這些抽象細節應用於其他領域,從而能夠達到舉一反三的效果。舉個例子,在專案,我們經常會用到定時機制,乙個關注的細節問題是,如果系統在維護,定時任務沒有執行,那麼如何進行重試。對於某乙個特定的場景,可以寫乙個人工觸發按鈕。這個細節就可以進行抽象,就是如何補償由於定時機制機制異常而導致任務沒有執行這種場景,有多重方案,甚至可以開發乙個專門的任務管理平台來做這個事情。類似這種可以通用和抽象出來的細節,比如業務併發控制解決方案 等,是非常值得關注和深度挖掘的。

對於某些特定場景的細節,比如我們和外部合作,定製了協議,但是對於極少數情況,不符合這個協議等,這種都是普片情況下的特例考慮,很難對這些問題進行抽象,因為這些都是對於特定領域和場景的。值能夠針對特定的細節具體分析,這一部分的價值相對比較低。只能夠加強你對某一領域了解的深度。

還有一類純粹是浪費時間的討論,這些完全是無意義的或者說沒有太多可行性的參考價值。比如頁面文字框的長度要多大,業務失敗要不要傳送郵件給使用者,以及許多裝逼問題:「對於乙個可有可無的功能,考慮機器斷電,磁碟寫滿等細節。

如果經常關注的第三類細節問題,就相當的無聊和無趣了,而最耗費和讓人陷入的就是第二類或者第三類細節問題的討論,這類細節問題很難幫助你或者讓你站在更高的角度去考慮問題,可以了解這一部分細節,但是沒有必要陷入這一部分細節,應該去專注細節問題的共同點,從著一些共同點中找出共性的問題並提出這一類問題的通用解決方案。

關注C 細節 抽象的理解

include using namespace std class a int main 該程式輸出func a,試分析其背後的原理 這主要涉及的是c 的記憶體模型問題,其實就是c 的抽象機制 c 物件雖然封裝了成員函式 成員變數 屬性 但成員函式和成員變數的處理方法是完全不同的,成員函式是整個類公...

程式設計師應知 關注細節

曾經有一句話,叫做 細節決定成敗 充分說明了細節對於成功的作用。如果我們注意一下,就會發現很多因為注重細節而獲得成功的案例。產品的細節 蘋果的系列產品我們都已經非常熟悉了,各種各樣i打頭的產品,對於細節已經給予了非常大的關注。尤其體現明顯的就是在對使用者使用的友好度和便利性方面的細節。ipad ip...

關注C 細節 標準庫string型別

一.首先作為一種標準庫型別,string存在四種基本的建構函式。如下 string s 預設建構函式,s為空串 string s s1 用s1來初始化s string s my blog 將s初始化為乙個字串字面值 string s n,c 將s初始化為n個 c 的副本 二.對於輸入主要就是cin ...