一個資深Java架構師告訴你咱們是如何將一個項目作爛的

首先我想聲明一個項目作爛不是你一我的挖坑就行的，這是一個很大的工程 須要團隊協做

既然標題都用到了」爛」這個詞，那什麼纔是爛呢？

在你的項目裏，」爛」和」好」同樣沒法準確的衡量和定義，在大多數人的職業生涯裏，你聽到」爛」項目確定比聽到」好」項目的狀況要多不少。

當你在一個維護型項目面前，一邊嘴裏跑出一萬隻草尼馬，一邊還在上面Coding，最後竟然還如期交付了維護任務，你能說那是」爛」項目嗎?

我本身也沒有遇到過真正」爛」到沒法維護的項目，由於我就是那個讓項目慢慢變爛的人。

也許，」爛」項目的罪證沒法像《如何編寫沒法維護的代碼》那樣容易羅列，因此你根本就不認爲那是爛。

意識到項目的」爛」與聞到代碼的壞味道同樣是優秀開發人員的基本素養。

不過本文說的」爛」，只是從程序員的角度去看項目，與項目自己的創意，項目在公司層面的戰略意義沒有關係。

工具

在我剛出道時（06年左右），那時候的Java生態圈其實已經很強大了，可是我剛畢業工做過的幾家公司，幾乎在項目部署上都沒有使用太多的自動化工具。

有的是直接用開發工具Eclipse打包war文件，其中一家公司，甚至是在本地編譯Java文件，而後上傳class文件到線上服務器，就算那時已經有ANT這樣的先進工具，惋惜咱們仍是類人猿，沒有進化過來, 要知道 使用製做工具是人類起源的重要標誌.

現在咱們在一個最好的時代, Maven成了Java構建的標準，Gradle成了Java構建的新秀, 請把打造高可用自動化工具鏈與開發高可用系統提高到一樣一個高度。

若是你的項目中使用到了工具，可是它卻很脆弱：過多依賴環境，依賴複雜的配置，有時候還會有BUG。

若是你的項目還不能作到一鍵命令構建，打包。

若是你的測試環境和線上環境程序部署時間不在可控範圍。

……

那麼你的項目，確定會慢慢變爛, 由於效率過低。若是想學習Java工程化、高性能及分佈式、深刻淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友能夠加個人Java進階羣：591240817，羣裏有大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給你們

框架

是的，從你找工做開始，就確定據說了這個詞，若是你在學校的時候就是一個勤奮好學的同志，那麼你早就據說過了，在Java的世界裏，你不會幾種框架，還好意思出去混嗎，因而不少招聘裏面都提到，精通Spring,Hibernate,Struts,Mybatis … 我入職的一家公司，甚至還有公司框架Demo代碼學習這個環節。

So，當你到公司第一次接觸到項目的時候，我想上面提到的這幾個框架，至少有一個出如今你的項目中，先來看看我遇到的項目中使用框架的狀況：

1. 使用了框架，可是版本已是上個世紀的了，卻依然在線上跑着

2. 依賴同一個第三方開源工具包，卻有多個版本

3. 有的地方用了框架的註解配置方式，有的地方卻用的XML配置文件

4. 一個原本只須要幾十K代碼搞定的項目，最後把框架依賴一塊兒打包，至少幾十M

5. 沒看出來爲何這個項目須要用到這個框架

6. ……

框架一詞本來來自建築學，在軟件行業裏面，本人理解框架，就是解決特殊場景問題的 抽象實現。本着娛樂的精神，這裏就不引入太書面的文字，容易引發反感。

若是你的項目和我遇到的狀況同樣，知足了上面兩點以上，我相信，只要這個項目還要繼續，就會繼續變爛，緣由大概有如下幾點：

• 你是一個有理想的男青年，你想把機械鍵盤砸在那個已經不知離職多久的前前前同事的臉上，而後大聲喊出來「老子要重構」，然而老闆說:能夠，你先把這一堆需求實現了再說。

• 最後老闆仍是贊成了，沒事兒你就重構吧，可是，你敢把一個正在好好running的線上項目框架換成最新版本嗎？（你的項目用到還不僅一個框架，有些框架之間在版本上還有依賴的，你不可能只升級其中一個）

• 想到這裏，再擡頭看看周圍Coding的同事，有的是已經工做了數年的老臘肉，還有一波剛入職的小鮮肉，他們是否和你同樣有理想，有追求呢

• ……

若是你學過PMP，那麼上面這些問題能夠歸納爲風險和成本。

引入了框架, 那麼項目成員是否在框架上作足了技術儲備? 若是僅僅是達到使用的地步,那麼因爲框架引起的問題,你是否可以在最短的時間內解決?

否則框架就成了項目的枷鎖，即便不會讓項目慢慢變爛，也不會讓項目慢慢變好。

領域模型

對啊，沒問題，咱們項目裏面的使用Spring，爽得不要不要的，Spring不是提倡面向接口編程嗎，咱們有完善的Service接口層。

是的，就像上面提到的，我曾經學習過公司的框架Demo代碼，裏面把Module都分好了，Domain, Dao，Manager（用於管理DAO層的事務），Service，Web。 真實的狀況倒是，Service裏面，一個Service接口對應了一個Dao（大部分狀況是這樣的），你有幾個數據表，大概就有多少個Service接口，若是有個新業務來了，添加了一張表，就再搞一個Service接口,Service，Dao基本都是在爲數據庫CRUD服務。

一個接口類從項目產生就沒有出現過多個實現, 當時定義接口僅僅是爲了遵循面向接口編程。

在充滿疑惑的歲月裏，我找到了真相，原來我把名詞理解錯了，「DDD」的含義有兩種，一個是Data-Driven Design，一個是Domain-Driven Design

一個沒有領域模型抽象的項目，早晚要慢慢變爛。

代碼

框架和模型是讓你站得更高的角度來看項目,最後仍是得回到代碼上,好的項目(應該說團隊)必定可以找到一套規範(當前流行叫」軍規」), 每一個團隊制定的規範可能有些不一樣,但仍是能找到不少共性.

• 代碼規範(Checkstyle, 方法名,類名規範,註釋規範,代碼格式規範……)

• 工程規範(構建流程,版本發佈……)

• 設計規範(設計複雜度控制,模塊依賴……)

• 數據庫表設計規範, SQL規範

• ……

通過我多年的經驗,制定規範這事兒,其實重點在如何讓項目成員理解和認同,最後纔是執行,不少項目成員對規範的抵觸源自浮淺地認爲規範只能讓他們將時間消耗在非功能性需求上.

規範是一種認同感, 但要想讓項目成員創建更好的認同感, 有時候你必須利用人格魅力(若是你有的話),或者慘痛的經驗(老司機確定有的).

擡頭看看你的項目, 能不能找到一條硬性要求的規範, 若是找不到, 能夠直接跳出該文.

若是你有所覺悟,而後只是到網上處處借鑑各類軍規堆砌在項目裏, 那麼依然沒什麼卵用.

規範並不能讓你的代碼變得多優秀. 規範只是防止代碼裏處處瀰漫着單身屌絲程序員(猿)的我的感情色彩,規避一些顯而易見的錯誤.

有了規範, 你有沒有代碼審查?

你在網絡上處處都能搜索到」 XX團隊如何看重代碼審查,XX團隊爲了代碼質量開發了一個代碼審查工具」, 但是你很難找到XX團隊是如何作代碼審查的,因此搞清楚如何讓代碼審查起到做用 比代碼審查自己更重要.

總之,在代碼審查以外,你還須要權衡,要不要把代碼審查搞成政治任務,要不要搞成批鬥大會, 若是你在代碼審查的氣氛裏面聞到了壞味道, 那就應該停下來.

一個作好了代碼規範和代碼審查的項目,想變爛都沒那麼容易.

測試

我在大學裏面學編程的時候，彷佛老師都沒教過什麼是測試，當時寫TC的時候，老師只是說上機執行，如今回想起來，好像當時的教材也沒有專門講測試。（也許我就沒有好好學過）

從項目代碼來看，最基本的就是單元測試。

你的項目雖然有單元測試，可是他們要麼過期（沒有和被測試代碼一塊兒演化），要麼根本就沒有達到覆蓋率要求。

當你想給一個功能補寫單元測試的時候，發現編寫單元測試的難度比從新實現這個功能的難度還要大，結果你就真那樣作了。

測試的目的就是爲了發現儘量多的缺陷， 儘可能 保證質量。

然而不少項目根本就沒有清晰定義出 質量 的邊界，甚至只完成了功能測試。

羅列你項目中的測試項，將他們分類列舉，若是測試項用一張紙都能寫完， 那麼這個項目自己就是爛的，根本不須要慢慢變爛。

再強調一下，若是沒有充分測試（怎樣纔是充分測試？）的項目，其實已經爛了。

需求

全部的業務需求你都應該去知足

業務是項目的基本驅動力，能夠說沒有需求就沒有項目存在。

然而對於一個發展中的項目，有可能正是需求在讓它慢慢變爛.

由於我見過太多的需求來至項目控制人員(簡稱領導),而不是來至於真正用戶,這些項目控制人員還會振振有詞地說:」我也是用戶中的一員」,大部分開發人員基本上又都處於食物鏈的最低端, 因此遇到上面這種狀況,基本是無解的(排除那些真正執行工程師文化的公司).

大部分項目的需求，都會對應到一個系統功能，系統功能都會有生命週期，可是項目中的代碼卻每每隨需求一塊兒增加，對於過期的功能代碼，沒人敢隨便刪除，而後就變得臃腫。

另一種狀況就是需求超越了領域模型，例如：ATM取款機，讓你植入視頻播放功能（現實生活中卻真有的）,你有時候沒法分辨出這類需求，而後卻漂亮地實現了它。

恭喜你，你的項目正在面臨慢慢變爛的風險。

負面情緒

負面情緒讓項目慢慢變爛，聽起來有點牽強，其實負面情緒與項目中的」爛」有點像雞與蛋的關係，但這也只是其中一方面，放眼望去，項目中的負面情緒來自於方方面面。

部分開發人員若是遇到《如何編寫沒法維護的代碼》 中提到的問題會讓他們大怒，而後抱怨沒有統一的代碼格式化工具，沒有規範的目錄結構，甚至日誌輸出格式也是五花八門……

若是你在項目中常常聽到這種罵街的聲音，那麼你所在的項目還不至於那麼快變爛。

不滿現實，並動手去改變它，這也是優秀程序員的基本素養，但你必須停下來思索一下，你周圍的人是不滿的多，仍是動手去改變的人多。

我本身就很是願意和不滿現實而且情緒化的開發人員一塊兒工做，很是害怕那些只是抱怨，說到動手去改變的時候又保持沉默的人。

情緒會傳染，有些情緒在團隊中會產生負面的效果，有些卻能成爲動力，這取決於團隊的自我認知能力。

如何識別項目中遇到的負面情緒呢？

• 小A最近常常一邊寫代碼，一邊上逛招聘網站

• 小B常常給你說，某某公司的工資更高，全員MAC環境開發，23寸顯示器…

• 小C給你講，小A和小B的代碼寫得真爛

• 小D抱怨技術上得不到提升

• ……

放心，若是你在項目中是個領導角色，上面這些抱怨列表你基本上是不會聽到的，若是你只是一個普通的開發人員，那麼就去購買一本《程序員自我修養》，將負面情緒轉化爲正能量。

保持現狀

有一個老程序員自豪地告訴我，他寫的一個程序已經在線上跑了快10年了，歷來沒動過。

我只是笑了笑，說了一句：牛逼

若是我寫一個打印Hello world的程序，部署在一臺太陽能Linux機器上，而後把它放到外太空,誰知道能運行多久呢。

我作的部分項目裏面，用到的第三方工具距離最新版發佈時間有的至少快5年了。

同事告訴我，用着這麼穩定，幹嗎要升級。

你要知道，JDK如今多久發佈一次？每次都有哪些BUG修復？有哪些性能提高？你用的這個第三方包，但是在5年前那個版本的JDK下開發完成的，並且那個開發第三方工具包的人有可能還死了。

請注意,咱們不是在討論升級的問題,咱們是在討論 變化 的問題.

保持現狀是一種惰性思惟，它已經麻痹了開發人員對項目變化帶來的風險評估。

若是將項目比作一輛汽車，它只是在不停地行駛，卻沒有按期保養。（重點是你不知道應該保養哪些部件）

不要讓保持現狀的思惟腐蝕了項目，讓項目慢慢變爛。

最後記住:

在一個團隊協做的時代，你不是一我的在挖坑。

也能夠關注咱們的微信公衆號