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

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

 

啓示錄

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

心中有原則

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

 

好比我作過的一個項目是須要依賴數十個系統，那麼以前的作法是讓全部我依賴的系統在變動時調用個人同步接口把數據同步過來，此處存在這麼幾個問題： 假設IP或域名變了，須要通知全部依賴方；假設咱們出問題了，各個依賴方須要本身進行重試；假設數據出問題了，須要通知依賴方再同步一下數據；這種方式產 生了嚴重的耦合。所以在設計新架構時咱們要徹底摒棄這種方法，改用異步通知+拉取依賴數據的方式，如經過MQ通知咱們數據變動了，而後經過依賴方提供的接 口拉取數據；這種方式的好處：和依賴方鬆耦合；假設數據有問題再調用下依賴方接口拉取下數據修復便可。所以這個項目的原則就是異步通知+拉取數據。而若是 依賴方不提供這種接口咱們就沒法知足他們的需求。還有一種特例就是有些依賴方的數據能夠一天全量同步一次，那麼可使用定時任務天天跑一次；即定時任務+ 拉取數據。也就是說最糟糕的狀況就是使用定時任務+拉取數據機制。

 

好比咱們接到一個需求說須要在大家頁面上加一個數據來展現，此時要咱們在展現頁面時調用他們的接口拿到數據而後展現，此處存在的問題是：咱們若是強 依賴他們，那麼他們的抖動將影響咱們頁面的體驗，雖然能夠降級，可是咱們也不能容忍一點點抖動；所以咱們提供的方案仍是異步通知+拉取數據，將數據存儲到 咱們本身這邊；或者前端異步加載。

 

心中有原則，即必須有一個或幾個中心原則指導咱們的架構不偏離航線，不然項目將朝着腐朽的方向發展，越作越爛，最後沒有幾我的能維護這個項目。也不能由於圖一時之省事，而爲將來埋坑。

 

代碼規範化

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

一、不必一上來就抽象什麼DAO、Service的接口，個人原則就是就一個實現類，由於我項目90%以上狀況不須要接口這個東西，爲了接口而接口只能使類的數量暴增；

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

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

四、好比spring bean的名字能夠帶上後綴， **Service、**Dao、**RpcService、**HttpService、**DataSource，見到名字後綴就知道這個功能是什麼實現的。

 

不一樣公司的規範化可能不同，遵循本身公司的一套規範化讓代碼朝着好的方向發展。

 

代碼審查

代碼審查對於一些新人我我的以爲是有必要的，由於新人來了不瞭解咱們的原則、不熟悉咱們的代碼規範；此時應該經過代碼審查機制來糾正或着帶領着他們 朝着咱們一個共同的方向發展。經過代碼審查能夠糾正一些錯誤的或者很差的實現，找出一種當前最優的方案；還可讓新人意識到一些他以爲無所謂的問題。

 

代碼重構

發現很差的或者壞掉的代碼必須重構，由於若是以爲這段代碼有問題，只要這個項目活着，將來的某一天確定會出問題。一個沒事或之後改吧可能致使一個重大的線上事故。所以發現很差的代碼應該找時間當即重構。重構的目標也是架構原則指導的，不符合原則的就應該重構掉。

 

代碼註釋

不少人可能不屑於寫註釋，以爲代碼就是註釋；那我以爲多是他沒見過變態的業務需求，在咱們項目中老是存在一些很是變態或着說是魔法代碼，這些代碼 只有當時寫的人理解，若是沒有註釋，你是不瞭解他那麼作的意圖的，會以爲很難以想象，可是實際上那就是業務需求。還有一些是咱們依賴別人的接口，而這個接 口也是很是不可接受的，可是已經有很是多的部門依賴不可能改的，此時也只能默默接受。對於這些變態的需求或者不可理解的需求寫註釋吧。

 

代碼邏輯抽象

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

 

工具類

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

 

項目閉環

咱們在作項目時發現有人把一個大項目分拆爲多個子系統，而後這些子系統做爲獨立項目，而後當新人來的時候總摸不着頭腦。所以個人作法是使用如Maven構建一個大項目，而後拆成各類子模塊，整個項目都在一塊兒的。

 

持續改進

技術天天都在發生變化，所以咱們要持續學習，瞭解目前對於項目來講最優的解決方案，而後適當的應用到項目中，進行項目的持續改進，有時候就是須要革本身命，持續發展；可是必定要有好的回滾策略，任何改進不能犧牲穩定性或增長事故率爲前提，這個風險要有很好的把控。

 

自動化

對於一些運維或者業務相關的功能咱們須要自動化完成；若是咱們常常處理一些問題，那麼能夠考慮爲這些問題構建一個自動化工具，減小咱們的重複勞動。

 

 

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

 

摘自張開濤的博客：http://jinnianshilongnian.iteye.com/blog/2232357