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