我是如何構建一個持續發展的項目

說起項目，每個程序員都應該搭建過自己的項目，而我也搭建過數十個企業級或互聯網級項目；在做企業級項目時也抽象了一套通過的開發腳手架 ES 方便開發，也做過一些通用的代碼生成工具來生成通用項目架子或一些CRUD的代碼。做這些平臺或項目的時候或多或少給我一些啟示和原則，而這些啟示和原則一直指導著我內心方向，時刻指導我不偏離航線。

啟示錄

• 心中有原則
• 代碼規范化
• 代碼審查
• 代碼重構
• 代碼注釋
• 代碼邏輯抽象
• 工具類
• 項目閉環
• 持續改進
• 自動化

心中有原則

我認為這是搭建和維護項目的靈魂，失去了靈魂，項目雖然能運行，但是未來是沒有方向的。來了需求就接，最后就是修修補補。其實我個人認為心中有原則就是有未來預見性，能根據現有需求預見到未來的需求發展。

比如我做過的一個項目是需要依賴數十個系統，那么之前的做法是讓所有我依賴的系統在變更時調用我的同步接口把數據同步過來，此處存在這么幾個問 題：假設IP或域名變了，需要通知所有依賴方；假設我們出問題了，各個依賴方需要自己進行重試；假設數據出問題了，需要通知依賴方再同步一下數據；這種方 式產生了嚴重的耦合。因此在設計新架構時我們要完全摒棄這種方法，改用異步通知+拉取依賴數據的方式，如通過MQ通知我們數據變更了，然后通過依賴方提供 的接口拉取數據；這種方式的好處：和依賴方松耦合；假設數據有問題再調用下依賴方接口拉取下數據修復即可。因此這個項目的原則就是異步通知+拉取數據。而 如果依賴方不提供這種接口我們就無法滿足他們的需求。還有一種特例就是有些依賴方的數據可以一天全量同步一次，那么可以使用定時任務每天跑一次；即定時任 務+拉取數據。也就是說最糟糕的情況就是使用定時任務+拉取數據機制。

比如我們接到一個需求說需要在你們頁面上加一個數據來展示，此時要我們在展示頁面時調用他們的接口拿到數據然后展示，此處存在的問題是：我們如 果強依賴他們，那么他們的抖動將影響我們頁面的體驗，雖然可以降級，但是我們也不能容忍一點點抖動；因此我們提供的方案還是異步通知+拉取數據，將數據存 儲到我們自己這邊；或者前端異步加載。

心中有原則，即必須有一個或幾個中心原則指導我們的架構不偏離航線，否則項目將朝著腐朽的方向發展，越做越爛，最后沒有幾個人能維護這個項目。也不能因為圖一時之省事，而為未來埋坑。

代碼規范化

在寫代碼時也要有一些原則或規范化的東西來指導。比如我們的項目也分了什么DAO、Service、Controller；而每個人可能叫的名字/開發時思路不一樣，那么我們必須統一起來，如：

1、沒必要一上來就抽象什么DAO、Service的接口，我的原則就是就一個實現類，因為我項目90%以上情況不需要接口這個東西，為了接口而接口只能使類的數量暴增；

2、所有類名必須見名知意，不能表達含義的全部重構；

3、配置文件的規范化，其實就是分類，按照功能分類配置；

4、比如spring bean的名字可以帶上后綴， **Service、**Dao、**RpcService、**HttpService、**DataSource，見到名字后綴就知道這個功能是什么實現的。

不同公司的規范化可能不一樣，遵循自己公司的一套規范化讓代碼朝著好的方向發展。

代碼審查

代碼審查對于一些新人我個人覺得是有必要的，因為新人來了不了解我們的原則、不熟悉我們的代碼規范；此時應該通過代碼審查機制來糾正或著帶領著 他們朝著我們一個共同的方向發展。通過代碼審查可以糾正一些錯誤的或者不好的實現，找出一種當前最優的方案；還可以讓新人意識到一些他覺得無所謂的問題。

代碼重構

發現不好的或者壞掉的代碼必須重構，因為如果覺得這段代碼有問題，只要這個項目活著，未來的某一天肯定會出問題。一個沒事或以后改吧可能導致一個重大的線上事故。因此發現不好的代碼應該找時間立即重構。重構的目標也是架構原則指導的，不符合原則的就應該重構掉。

代碼注釋

很多人可能不屑于寫注釋，覺得代碼就是注釋；那我覺得可能是他沒見過變態的業務需求，在我們項目中總是存在一些非常變態或著說是魔法代碼，這些 代碼只有當時寫的人理解，如果沒有注釋，你是不了解他那么做的意圖的，會覺得很不可思議，但是實際上那就是業務需求。還有一些是我們依賴別人的接口，而這 個接口也是非常不可接受的，但是已經有非常多的部門依賴不可能改的，此時也只能默默接受。對于這些變態的需求或者不可理解的需求寫注釋吧。

代碼邏輯抽象

抽象是非常重要的一個過程，把項目中一些共性、經常用到的功能做抽象，抽象成公共代碼或基礎組件，這樣對于這些功能就可以反復使用，這個過程是 持續的，發現到共性就考慮重構抽象。這種方式可以提升我們的開發效率，簡化業務邏輯實現。比如我們做的消息處理系統，只需要簡單配置下就可以工作了。

工具類

在項目開發過程中，要帶領團隊成員使用常見的工具類，如apache commons、google guava等。使用這些工具類可以使得代碼bug更少（最常見的如空指針異常）、代碼更短、更易懂。

項目閉環

我們在做項目時發現有人把一個大項目分拆為多個子系統，然后這些子系統作為獨立項目，然后當新人來的時候總摸不著頭腦。因此我的做法是使用如Maven構建一個大項目，然后拆成各種子模塊，整個項目都在一起的。

持續改進

技術每天都在發生變化，因此我們要持續學習，了解目前對于項目來說最優的解決方案，然后適當的應用到項目中，進行項目的持續改進，有時候就是需要革自己命，持續發展；但是一定要有好的回滾策略，任何改進不能犧牲穩定性或增加事故率為前提，這個風險要有很好的把控。

自動化

對于一些運維或者業務相關的功能我們需要自動化完成；如果我們經常處理一些問題，那么可以考慮為這些問題構建一個自動化工具，減少我們的重復勞動。

我個人認為要搭建一個好的項目，就是要有好的價值觀，不打破自己設立的原則，自覺自律朝著好的方向發展，不偷懶；任何人破壞我的代碼我都要想辦法糾正過來。