說起項目，每個程序員都應該搭建過自己的項目，而我也搭建過數十個企業級或互聯網級項目；在做企業級項目時也抽象了一套通過的開發腳手架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構建一個大項目，然後拆成各種子模塊，整個項目都在一起的。
持續改進
技術每天都在發生變化，因此我們要持續學習，瞭解目前對於項目來說最優的解決方案，然後適當的應用到項目中，進行項目的持續改進，有時候就是需要革自己命，持續發展；但是一定要有好的回滾策略，任何改進不能犧牲穩定性或增加事故率爲前提，這個風險要有很好的把控。
自動化
對於一些運維或者業務相關的功能我們需要自動化完成；如果我們經常處理一些問題，那麼可以考慮爲這些問題構建一個自動化工具，減少我們的重複勞動。
我個人認爲要搭建一個好的項目，就是要有好的價值觀，不打破自己設立的原則，自覺自律朝着好的方向發展，不偷懶；任何人破壞我的代碼我都要想辦法糾正過來。
原文鏈接 http://jinnianshilongnian.iteye.com/blog/2232357