初創的技術團隊，一切從0開始，一切看似那麼美好，前景如此令人嚮往。市場不等人，需要快速的搶佔先機，所以產品如果能夠早點面市，就比別人多了一絲活下去的希望。但是磨刀不誤砍柴工，如果不做好基礎的技術準備工作，就一頭扎進業務程式碼中，看似如火如荼，實際會帶來各種各樣的隱患（當初創團隊的團隊成員並非是那種並肩在其他平臺很長時間形成默契的戰友的話，問題會更多）。在此，把我們的經驗總結一下，避免踩坑。總結下來，一個團隊的建設要包括以下幾個大的方面：

• 在團隊協作方面，要搭建或者使用一些有利於團隊協作的業務平臺，減少大家之間溝通等帶來的成本。
• 建立一系列良好的規範和制度並保證執行下去，包括編碼規範、命名規範、晨會制度、週報制度等。
• 建立一套良好的研發流程
• 搭建一些基礎的研發平臺，以保證快速迭代，持續交付
• 如果不是土豪和專家，我們的建議是都用雲服務，比如阿里雲的ECS，RDS，開放搜尋，Quick BI，redis，OSS，SLS等。

下面會從協作，規範，流程以及持續交付這四個方面來講講，我們在動手開幹之前，技術團隊要做好哪些準備。

搭建團隊協作基礎設施

開篇提到團隊協作的基礎設施能夠減少團隊協作間溝通等成本，下面從一些我們認為必須要有的基礎設施來講講他們的用處。

私有gitlab的搭建

現在有很多的免費或者收費的平臺能夠提供相關的程式碼託管服務，那為什麼一定要自己來搭建呢？最早，我們團隊使用過一家雲程式碼託管服務，一週內好幾次無法提交或者拉取程式碼，導致大家工作受到了影響。GITHUB也老不穩定，說不定哪天就被牆。再加上自己搭一個Gitlab並不麻煩，所以就自己搭建了。

maven私庫的搭建

團隊很大程度上會沉澱一些公用的jar，加上採用微服務架構，每個服務定義的介面都以jar包的形式給到呼叫方。這些jar包放置在團隊私有的maven庫上再合適不過。

共享文件庫

大家可以把一些需求的理解以及設計方案放在這個地方，以便於其他人快速瞭解，也為了沉澱知識，比如團隊擴張或者新人進來之後，能有地方讓他們快速的學習和上手。在這裡推薦一款SaaS產品，叫語雀。目前是免費使用階段，支援markdown，寫起文件來感覺很爽。

專案、測試用例、缺陷管理工具

現在大多數初創團隊都會採用敏捷的開發模式，以MVP的思路，快速迭代，不斷完善產品。在一個迭代中，需要能夠清晰的看到每天每個人有什麼任務，每個任務處於什麼階段，是需求階段，開發階段，測試階段還是已完成？類似Scrum中的看板的那種。還有測試的用例和缺陷也需要有一個系統能夠進行維護和管理。目前我們團隊正在用雲效。當然雲效能做的不只是這些，但是我們只是用了雲效最基礎的專案管理和缺陷以及用例管理的功能。

建立規範

一個團隊如果沒有規範，大家按照各自的習慣寫程式碼，那麼相互之間理解對方的程式碼的成本就會變高。規範就是為了把這種大家溝通，理解上的門檻和成本降低。讓研發的同學關注在開心的寫業務程式碼上。

編碼規範

後端編碼規範

幸運的是我們用的是java，我們完全按照阿里巴巴的規範進行後臺程式碼的編寫。也不用費勁腦子和嘴皮子來統一大家的語言規範了。按照阿里巴巴的規範來就好。

前端編碼規範

命名規範

變數

表結構

表字段

資料庫相關的規範，可以看看58沈劍的58的資料庫軍規

專案結構規範

在之前，都是單體應用，大家定義好包的層級結構就好了。比如我們經常用的-Controller - Service - Dao - Model - Common 這種分package的模式，後來演進成採用不同的module來表達不同的職責。隨著服務化的思路，我們的專案數量增多。那麼每個專案要是有不同的這種結構，其實大家理解起來還是比較費勁的。所以，我們對每個專案的module都有約定（比如在哪寫倉儲程式碼，哪裡寫DAO程式碼各個層是如何依賴的），我們定義了一套自己的maven骨架，大家都用它來生成服務專案。這些大家在相互瞭解別人的程式碼的時候，即使不知道業務，也能很清晰的知道比如它定義的介面應該在哪個module裡面，它引用別人的服務是在哪個module中定義的。

統一開發工具

團隊最好是用一種開發工具，但是不強求。

建立研發流程

一套好的研發流程，能夠讓研發的效率以及質量提升數倍。雖然看起來，好像不是那麼回事兒。但是經過實踐對比後，有流程控制的專案確實從進度和質量上要超出沒有流程的專案好幾倍。我們團隊流程如下：

需求和設計評審

需求由PD產出後，一定要經過幾輪的討論（包括跟業務方，UED等），需要最終定稿，確定範圍，並且研發的同學已經充分的理解要做什麼。在需求評審完成後，需要進行設計評審。主要是設計上是否邏輯完成，滿足互動需求，並且定義好互動頁面的規範和樣式。這兩個評審是必須要有且不能隨便的。我們經歷過開發到一半，需求推翻重來的情況，也經歷過開發某個流程，發現PRD上遺漏了一種場景，又需要跟PD，業務方進行溝通，而且有些時候，這種未考慮到的場景在重新進行設計思考的時候還影響到了之前的程式碼架構設計，不得不修改之前的架構設計或者表結構等，造成大量的人力浪費。我們也經歷過前端的同學按照原型開發出來的頁面，卻並非是了產品和設計的想要的介面。很多原型工具並不是那麼完整的表達出PD和UED腦子裡的東西。 那麼需要把這些規範，比如字型，字號，邊距等都進行標註，來減少大家對同一個事物的理解不一致的情況發生。

系統設計

需求和設計確定後，基本上整個產品的形態都已經出現在我們研發的腦子中了。系統設計階段，需要研發對用例進行分析，確定自己腦子中的那個理解與定稿的需求是一致的。同時，研發還需要花點時間在對domain以及流程的設計上，儘可能的把一個業務場景考慮得周全。系統設計階段，就是讓研發儘可能的推遲寫程式碼的衝動，先把一個需求一個功能如何用程式碼實現，思考得深刻一點，把各種情況思考得全面一些，避免來回來去的返工。我自己曾經也經歷過，不做設計直接寫程式碼。當初認為這個需求簡單，所以就沒有設計。後來程式碼寫著寫著，發現需求沒有想象的簡單，還要考慮一些場景，於是把寫好的程式碼刪了重寫，反覆好幾次，每次都是發現了新的需要考慮的場景導致設計推倒重來。 後來索性，停下來，利用半天的時間，把問題思考全面了，再開始寫程式碼，後面就是一氣呵成了。系統設計中，需要定義好兩種介面。

1. 與前端的介面 （包括入參，返回值，錯誤碼）
2. 與其他服務系統的介面（包括入參，返回值，錯誤碼）

編碼

按照規範編碼，不要施展奇技淫巧。儘可能的抽象和收斂。

CR

CR一定要做，CR是團隊成員之間相互瞭解對方的編碼習慣和思路的一個很好的過程。

單元測試

利用mockito來進行單元測試的編寫。研發的同學要考慮一個功能的正常和異常場景。 異常場景又需要根據各種情景來編寫不同的測試用例。比如DB異常，RPC超時，下游返回呼叫錯誤等等。

為持續交付搭建基礎設施

服務化之後，系統拆分得很小。每個系統上線需要能做到，隨時隨地，自動化。藉助之前的經驗，我們搭建了一套如下的環境JENKINS + MESOS+MARATHON+DOCKER，來保證我們的系統能夠快速上線，研發只需要點選下一個按鈕即可。後續我們會針對如何搭建持續交付的基礎設施，如何使用阿里雲的服務等等進行專題分享。