你需要的不是重構,而是理清業務邏輯

2021-06-13 15:43:13 字數 1021 閱讀 3761

看到一篇好文章,深有體會。我就是業務能力不行,**能力也咋滴,純屬半吊子。幸好有顆上進行

中文:

最近我遇到了一位以前公司的同事。他提到了數年前我在那個公司曾經開發過的專案。他說這個專案現在已經變成了「職業殺手」。基本上,任何接觸過這個 「職業殺手」專案的人最終都會離開這個公司。如果公司想讓名下的程式設計師人數》0,唯一的辦法就是花數月時間完全重構這個系統。

對於這事我有兩點要說。首先,在我離開這個公司前,這個系統的單元測試覆蓋率已經達到了85%,所以,不要責備我。第二,這麼大規模的重構?肯定會出問題。

每 乙個系統裡都至少有乙個成為人民公敵、讓所有人害怕的元件。它承載了太多的任務,它擁有太多狀態,太多的其它元件呼叫它。當時間到了償還技術債務的時候, 人人都會把目光投向這個元件。然而,如果你對這個元件只有乙個不全面的理解,你放下所有工作來完全重構它,那你成功的機率會很小。這個元件,就就它表現出 來的令人恐怖的程度和複雜相比,它的實際情況會比你想象更複雜,更恐怖。

你認為這個元件是如何發展成這樣乙個不幸的狀態的?是因為公司雇用 了乙個笨蛋,讓他肆無忌憚的往系統裡增加複雜度?或是因為這個元件最初設計的太抽象,由於多年來需求的變更,它的責任範圍不斷的擴大?(出於個人的自尊, 我寧願相信這個「職業殺手」屬於後者)。十有**,這個元件變成如今這個恐怖的狀態,都有由「聰明人」的一些「好意」造成的。如果你決定做一次大的重構, 你實際是欠下了另一筆技術債務留給後人。

為了能真正的徹底償還這筆債務,你需要去分解這個系統的複雜度。你需要花時間尋找所有呼叫這個元件 的客戶端。你需要花時間跟你的同事交流,了解這個這個元件的歷史和它是如何被使用的。你需要簡化這個元件的周邊環境,看看它是如何運作的。每週,你都需要 花更多的時間來更清楚的了解這個元件的業務。只要有足夠長的時間跨度,你最終能理清所有複雜的問題。

從實際方法上說,這個問題應該怎麼辦?與其現在花3個整月的時間做一次完全的重構,不如先用乙個季度的時間做清理工作。最後還是要重寫,但有了3個月的計畫準備,你有了時間去分析和設計。你有了時間來理清業務。

你需要的不是大資料 而是正確的資料

本文講的是你需要的不是大資料 而是正確的資料 it168 編譯 大資料 這個術語是無處不在的。無論是大企業還是小企業,新興企業抑或是傳統企業,都正在參與著這個 遊戲 海量的使用者資料正在被各個 大規模收集利用,有的公司為了能與客戶交流,甚至不惜利用龐大的文字交流資料建立演算法。但實際上,我們對大資料...

你需要的不是大資料 而是正確的資料

大資料 這個術語是無處不在的。無論是大企業還是小企業,新興企業抑或是傳統企業,都正在參與著這個 遊戲 海量的使用者資料正在被各個 大規模收集利用,有的公司為了能與客戶交流,甚至不惜利用龐大的文字交流資料建立演算法。但實際上,我們對大資料的痴迷,往往也會產生誤導。是的,在某些情況下,從資料中確實能夠獲...

團隊往往需要的不是人才,而是化繁為簡的能力

怎樣才是好的管理?我們來看看蓋房子。你找20個工人來,說,這是圖紙,這是錢。你們必須有化繁為簡的能力,把房子在20天內蓋好。這是不現實的。作為管理者,我們懂得如何化繁為簡。我們要先把工種先分為木工 水電工 瓦工等等,再把工序分為一二三四五。然後,重要的部分來了,你要給每個工人下達乙個 簡單 的指令,...