初創(chuàng)的技術(shù)團隊，一切從0開始，一切看似那么美好，前景如此令人向往。市場不等人，需要快速的搶占先機，所以產(chǎn)品如果能夠早點面市，就比別人多了一絲活下去的希望。但是磨刀不誤砍柴工，如果不做好基礎(chǔ)的技術(shù)準備工作，就一頭扎進業(yè)務(wù)代碼中，看似如火如荼，實際會帶來各種各樣的隱患（當初創(chuàng)團隊的團隊成員并非是那種并肩在其他平臺很長時間形成默契的戰(zhàn)友的話，問題會更多）。在此，把我們的經(jīng)驗總結(jié)一下，避免踩坑。
總結(jié)下來，一個團隊的建設(shè)要包括以下幾個大的方面：
在團隊協(xié)作方面，要搭建或者使用一些有利于團隊協(xié)作的業(yè)務(wù)平臺，減少大家之間溝通等帶來的成本。
建立一系列良好的規(guī)范和制度并保證執(zhí)行下去，包括編碼規(guī)范、命名規(guī)范、晨會制度、周報制度等。
建立一套良好的研發(fā)流程
搭建一些基礎(chǔ)的研發(fā)平臺，以保證快速迭代，持續(xù)交付
如果不是土豪和專家，我們的建議是都用云服務(wù)，比如阿里云的ECS，RDS，開放搜索，Quick BI，redis，OSS，SLS等。
下面會從協(xié)作，規(guī)范，流程以及持續(xù)交付這四個方面來講講，我們在動手開干之前，技術(shù)團隊要做好哪些準備。
搭建團隊協(xié)作基礎(chǔ)設(shè)施
開篇提到團隊協(xié)作的基礎(chǔ)設(shè)施能夠減少團隊協(xié)作間溝通等成本，下面從一些我們認為必須要有的基礎(chǔ)設(shè)施來講講他們的用處。
私有g(shù)itlab的搭建
現(xiàn)在有很多的免費或者收費的平臺能夠提供相關(guān)的代碼托管服務(wù)，那為什么一定要自己來搭建呢？
最早，我們團隊使用過一家云代碼托管服務(wù)，一周內(nèi)好幾次無法提交或者拉取代碼，導致大家工作受到了影響。GITHUB也老不穩(wěn)定，說不定哪天就被墻。再加上自己搭一個Gitlab并不麻煩，所以就自己搭建了。
maven私庫的搭建
團隊很大程度上會沉淀一些公用的jar，加上采用微服務(wù)架構(gòu)，每個服務(wù)定義的接口都以jar包的形式給到調(diào)用方。這些jar包放置在團隊私有的maven庫上再合適不過。
共享文檔庫
大家可以把一些需求的理解以及設(shè)計方案放在這個地方，以便于其他人快速了解，也為了沉淀知識，比如團隊擴張或者新人進來之后，能有地方讓他們快速的學習和上手。
在這里推薦一款SaaS產(chǎn)品，叫語雀。目前是免費使用階段，支持markdown，寫起文檔來感覺很爽。
項目、測試用例、缺陷管理工具
現(xiàn)在大多數(shù)初創(chuàng)團隊都會采用敏捷的開發(fā)模式，以MVP的思路，快速迭代，不斷完善產(chǎn)品。在一個迭代中，需要能夠清晰的看到每天每個人有什么任務(wù)，每個任務(wù)處于什么階段，是需求階段，開發(fā)階段，測試階段還是已完成？類似Scrum中的看板的那種。還有測試的用例和缺陷也需要有一個系統(tǒng)能夠進行維護和管理。目前我們團隊正在用云效。當然云效能做的不只是這些，但是我們只是用了云效最基礎(chǔ)的項目管理和缺陷以及用例管理的功能。
建立規(guī)范
一個團隊如果沒有規(guī)范，大家按照各自的習慣寫代碼，那么相互之間理解對方的代碼的成本就會變高。規(guī)范就是為了把這種大家溝通，理解上的門檻和成本降低。讓研發(fā)的同學關(guān)注在開心的寫業(yè)務(wù)代碼上。
編碼規(guī)范
后端編碼規(guī)范
幸運的是我們用的是java，我們完全按照阿里巴巴的規(guī)范進行后臺代碼的編寫。也不用費勁腦子和嘴皮子來統(tǒng)一大家的語言規(guī)范了。按照阿里巴巴的規(guī)范來就好。
IDEA插件下載：https://github.com/alibaba/p3c
前端編碼規(guī)范
命名規(guī)范
變量
表結(jié)構(gòu)
表字段
數(shù)據(jù)庫相關(guān)的規(guī)范，可以看看58沈劍的58的數(shù)據(jù)庫軍規(guī)
項目結(jié)構(gòu)規(guī)范
在之前，都是單體應(yīng)用，大家定義好包的層級結(jié)構(gòu)就好了。比如我們經(jīng)常用的
Controller
Service
Dao
Model
Common
這種分package的模式，后來演進成采用不同的module來表達不同的職責。
隨著服務(wù)化的思路，我們的項目數(shù)量增多。那么每個項目要是有不同的這種結(jié)構(gòu)，其實大家理解起來還是比較費勁的。所以，我們對每個項目的module都有約定（比如在哪寫倉儲代碼，哪里寫DAO代碼各個層是如何依賴的），我們定義了一套自己的maven骨架，大家都用它來生成服務(wù)項目。這些大家在相互了解別人的代碼的時候，即使不知道業(yè)務(wù)，也能很清晰的知道比如它定義的接口應(yīng)該在哪個module里面，它引用別人的服務(wù)是在哪個module中定義的。
統(tǒng)一開發(fā)工具
團隊最好是用一種開發(fā)工具，但是不強求。
建立研發(fā)流程
一套好的研發(fā)流程，能夠讓研發(fā)的效率以及質(zhì)量提升數(shù)倍。雖然看起來，好像不是那么回事兒。但是經(jīng)過實踐對比后，有流程控制的項目確實從進度和質(zhì)量上要超出沒有流程的項目好幾倍。
我們團隊流程如下：
需求和設(shè)計評審
需求由PD產(chǎn)出后，一定要經(jīng)過幾輪的討論（包括跟業(yè)務(wù)方，UED等），需要最終定稿，確定范圍，并且研發(fā)的同學已經(jīng)充分的理解要做什么。
在需求評審完成后，需要進行設(shè)計評審。主要是設(shè)計上是否邏輯完成，滿足交互需求，并且定義好交互頁面的規(guī)范和樣式。
這兩個評審是必須要有且不能隨便的。
我們經(jīng)歷過開發(fā)到一半，需求推翻重來的情況，也經(jīng)歷過開發(fā)某個流程，發(fā)現(xiàn)PRD上遺漏了一種場景，又需要跟PD，業(yè)務(wù)方進行溝通，而且有些時候，這種未考慮到的場景在重新進行設(shè)計思考的時候還影響到了之前的代碼架構(gòu)設(shè)計，不得不修改之前的架構(gòu)設(shè)計或者表結(jié)構(gòu)等，造成大量的人力浪費。
我們也經(jīng)歷過前端的同學按照原型開發(fā)出來的頁面，卻并非是了產(chǎn)品和設(shè)計的想要的界面。很多原型工具并不是那么完整的表達出PD和UED腦子里的東西。 那么需要把這些規(guī)范，比如字體，字號，邊距等都進行標注，來減少大家對同一個事物的理解不一致的情況發(fā)生。
系統(tǒng)設(shè)計
需求和設(shè)計確定后，基本上整個產(chǎn)品的形態(tài)都已經(jīng)出現(xiàn)在我們研發(fā)的腦子中了。
系統(tǒng)設(shè)計階段，需要研發(fā)對用例進行分析，確定自己腦子中的那個理解與定稿的需求是一致的。同時，研發(fā)還需要花點時間在對domain以及流程的設(shè)計上，盡可能的把一個業(yè)務(wù)場景考慮得周全。
系統(tǒng)設(shè)計階段，就是讓研發(fā)盡可能的推遲寫代碼的沖動，先把一個需求一個功能如何用代碼實現(xiàn)，思考得深刻一點，把各種情況思考得全面一些，避免來回來去的返工。
我自己曾經(jīng)也經(jīng)歷過，不做設(shè)計直接寫代碼。當初認為這個需求簡單，所以就沒有設(shè)計。后來代碼寫著寫著，發(fā)現(xiàn)需求沒有想象的簡單，還要考慮一些場景，于是把寫好的代碼刪了重寫，反復好幾次，每次都是發(fā)現(xiàn)了新的需要考慮的場景導致設(shè)計推倒重來。 后來索性，停下來，利用半天的時間，把問題思考全面了，再開始寫代碼，后面就是一氣呵成了。
系統(tǒng)設(shè)計中，需要定義好兩種接口。
與前端的接口 （包括入?yún)?，返回值，錯誤碼）
與其他服務(wù)系統(tǒng)的接口（包括入?yún)?，返回值，錯誤碼）
編碼
按照規(guī)范編碼，不要施展奇技淫巧。盡可能的抽象和收斂。
CR
CR一定要做，CR是團隊成員之間相互了解對方的編碼習慣和思路的一個很好的過程。
單元測試
利用mockito來進行單元測試的編寫。研發(fā)的同學要考慮一個功能的正常和異常場景。 異常場景又需要根據(jù)各種情景來編寫不同的測試用例。比如DB異常，RPC超時，下游返回調(diào)用錯誤等等。
為持續(xù)交付搭建基礎(chǔ)設(shè)施
服務(wù)化之后，系統(tǒng)拆分得很小。每個系統(tǒng)上線需要能做到隨時隨地且自動化。借助之前的經(jīng)驗，我們搭建了一套基于JENKINS + MESOS+MARATHON+DOCKER的持續(xù)交付的基礎(chǔ)設(shè)施，來保證我們的系統(tǒng)能夠快速上線。研發(fā)只需要點擊一下按鈕即可實現(xiàn)從編譯到部署的過程。
后續(xù)我們會針對如何搭建持續(xù)交付的基礎(chǔ)設(shè)施，如何使用阿里云的服務(wù)等等進行專題分享。
