原文出處：?等你歸去來

雖說工作就是簡單的事情重復做，但不是所有簡單的事你都能有機會做的刺彩。

我們平日工作里钓丰，大部分時候都是在做修修補補的工作躯砰，而這也是非常重要的。做好修補工作携丁，做好優(yōu)化工作琢歇，足夠讓你升職加薪！

但是如果有機會梦鉴，去嘗試些自己平日里少做的事李茫，我覺得是一件值得慶幸的事。

前段時間肥橙，接了個新項目魄宏。只有一些idea在業(yè)務需求方腦海里，然后就開始需求討論存筏，然后就開始做事了宠互。項目不復雜，但是由于是用JAVA語言實現(xiàn)（這相對來說是我的薄弱點）椭坚，對我個人顯得比較有意義予跌。

總結下來，其實也就是一個項目清單善茎。個人覺得還是有點意義吧券册，給沒有一定全面實踐的同學參考吧！

1. 項目規(guī)劃

1.1 首先垂涯，你得徹底明白到底要做什么烁焙？

這個過程，可能是你要讀需求一遍集币、兩遍考阱、三遍。鞠苟。。 然后假設秽之，你已經在使用這個產品了当娱。

1.2 其次，明白需求后考榨，就要進行整體框架的構思跨细！

比如用什么呈現(xiàn)給用戶，用什么來存儲數(shù)據(jù)河质，需要些什么樣的系統(tǒng)等冀惭。

在這個層次上震叙，一般都會遵循公司的規(guī)定，然后再根據(jù)項目本身需求散休，做些相應的調整媒楼。

我們在這個項目里的整體框架為：前端使用 APP(ios&android)、H5進行用戶界面呈現(xiàn) ===>> 接入網關進行數(shù)據(jù)加解密戚丸，流控轉發(fā)等 ===>> 第一層API服務划址，接受客戶端請求，做簡單業(yè)務檢驗組裝 ===>> 第二層核心業(yè)務SERVICE服務限府，進行核心業(yè)務處理夺颤，如寫庫、調用第三方接口等 ===>> 最下層基礎服務胁勺，提供單一的功能服務世澜，如消息服務，訂單服務署穗。

前期只提供APP寥裂，因此不存在單獨H5調用API服務的情況，但是H5的應用場景仍然存在蛇捌，此時的H5地址抚恒，由服務接口提供地址返回到APP進行webview加載。

1.3 人員規(guī)劃

項目整體框架出來后络拌，得要有人去實施才行俭驮。

這里一般需要遵循一個最小原則，即劃分出的人員春贸，盡量做到能夠獨立完成自有的模塊混萝，而不是一定要依賴于另一方的實現(xiàn)才能進一步。比如 android,ios各一人萍恕，API與SERVICE可以多個人逸嘀，但是都要讓其有全部權限，因為API與SERVICE有強依賴允粤，脫離一方崭倘，將無法獨立完成±嗟妫基礎服務各自安排相關人員實現(xiàn)司光。最后進行聯(lián)調即可。

1.4 時間規(guī)劃

有了人員之后悉患，也不能無限時間的去做事残家。肯定是要規(guī)劃的售躁，否則沒有壓力也沒有動力坞淮。項目不知何時才能結束茴晋。訂時間計劃一定要去詢問當事人，要多少時間回窘，盡量站在專業(yè)的角度給出合理的建議和評估诺擅。促進項目的完成。

2. 框架規(guī)劃及搭建

2.1 有了整體框架的構思后毫玖，就要細節(jié)到每個層次的實踐了

因為都是應用的分層掀虎，所以，不可能有統(tǒng)一的描述付枫，只能是針對每個應用層烹玉。做自己該做的事。如 android/ios 有自己的開發(fā)框架阐滩；h5有自己的開發(fā)框架(因為很多應用場景可能涉及到h5與app原生的交互二打，所以即使功能簡單，也盡量利用一些已有的框架進行開發(fā))掂榔。

而服務端继效，雖分為多層應用，但是應盡量使用同一門語言装获，利用同一套開發(fā)框架瑞信，自己公司有研發(fā)框架自然最好，沒有也盡量利用統(tǒng)一的開源框架穴豫。這樣做的好處是凡简，當有人員變動時，可以立即熟悉其代碼及應用場景精肃，從而增加適應性和管理性秤涩。

針對服務端的框架，我覺得有必要多說點司抱。因為整個應用運行的流暢性筐眷，可靠性，準確性习柠，都是由服務端來決定的匀谣。雖然用戶看到的是APP或者H5，但是可以說资溃，服務端才是應用的核心振定。所以，服務端要做的事情自然很多了肉拓。

2.2 怎樣搭建好一些服務端的框架呢？

首先梳庆，框架類的東西暖途，自然是要提前學習的卑惜。但是，就目前市場行情來說驻售，要想利用框架應該都是比較簡單的露久，尤其是公司內部提供的框架，一定要有demo欺栗。這樣毫痕，照著demo，一步步調試迟几，直到整個應用接通消请；

刪除不需要的模塊，添加特別需要的模塊类腮，保證在具體開發(fā)過程中臊泰，能夠想利用啥就有啥可利用；

充分了解框架需要的一些配置參數(shù)蚜枢，知道事務從哪里來缸逃，到哪里去？這里厂抽，應有一個配置中心與之對應需频，但是自己得清楚。

使用一個順手的IDE工具筷凤，不是說你技術不夠牛逼昭殉，而是一個好的工具，能夠讓你事半功倍嵌施。（其實能夠多背點套路饲化，也不一定非要體現(xiàn)在正式項目上）

寫出第一個可供使用的接口服務，可以說吗伤，第一個永遠是比較重要的吃靠。因為，第一個的思路足淆，就是你后續(xù)所有功能的方向巢块，因此，寫好第一個”hello, world.”巧号；

3. 開發(fā)環(huán)境的搭建(服務端)

3.1 其實這項工作是及其重要的族奢，之所以把它放在第三點，是因為丹鸿，沒有代碼作鋪墊越走，開發(fā)環(huán)境搭了也沒用。

3.2 開發(fā)環(huán)境的搭建，主要也是服從于整體框架的構思廊敌。

主要包括铜跑，需要多少個服務，需要多少臺服務器骡澈，需要多少個基礎應用锅纺，需要多少個基礎配置等等。

當然肋殴，開發(fā)環(huán)境本身就是一個很大的難題囤锉，一般還是交給專業(yè)運維幾十年的老司機來完成了。自己就當作了解得了护锤。

目前的項目開發(fā)官地，除一些小規(guī)模公司還在利用一套服務端代碼，干完所有的事外蔽豺，大部分應該都是多個應用的配合完成区丑。而測試環(huán)境，不太可能利用多個服務器提供服務修陡。因此沧侥，使用docker進行測試環(huán)境搭建尤佳。建立多個docker進行多個服務器模擬魄鸦，也算是和線上環(huán)境保持一致了宴杀。

目前的主流技術得用上（當然關鍵還得看你的框架規(guī)劃），zookeeper, dubbo, redis, mongo, mq, …

3.3 只有開發(fā)環(huán)境搭建好了拾因，才能讓后面的流程無憂旺罢。搭建的過程一定是，又搭建绢记，又改代碼扁达，又排錯…

4. 進度的同步

4.1 及時向領導同步項目進度

對于一個新項目，有些地方行動緩慢是很正常的蠢熄。而部分開發(fā)同學（比如我自己）跪解，就喜歡沉浸在自己的小世界里糾結，走不出來签孔，從而忘卻向領導匯報工作叉讥。而作為一個有點同理心的領導來說，他又不愿意實時都來盯著你做事饥追，因為也怕你遇到困難图仓，想多給你點時間解決。但是但绕，這種情況救崔，開發(fā)同學自己其實是要吃虧的，因為，給外人的感覺就是帚豪，你啥都沒做碳竟。所以，解決問題的同時狸臣，也不忘向領導匯報。

4.2 有處理不了的問題昌执，及時向大牛們或者領導請教

獨立解決問題是好事烛亦，但是千萬別過了頭，實在解決不了懂拾，就要及時請教煤禽。否則，浪費的是時間岖赋。進步最快的方式檬果，莫過于向比自己牛逼的人請教。知之為知之唐断，不知為不知选脊！

4.3 盡量將問題分攤下去

問題肯定是有的，而且會很多脸甘。千萬不要把所有的事情都壓在自己這兒恳啥，那樣自己會累死的，而且項目進度也會因此變得緩慢丹诀。要多利用小組成員的各自優(yōu)點钝的，適當多讓其搞點事情。

工作永遠都不是單一的一件事铆遭，肯定還會有其他的事情插入進來硝桩，觀察事情的重要性解決。如果能夠讓其他同學解決的枚荣，盡量讓其他同學處理碗脊，這點也得與領導同步。否則分心過于利害棍弄，受阻的只有項目進度望薄，延期可不是自己一人的事情了。

需求也不可能一下就是完善的呼畸，在做的過程中痕支，才可能發(fā)現(xiàn)一些潛在的問題，這時及時與需求方溝通蛮原，保持高效的狀態(tài)卧须。當然，后期的跟進，也是盡量做到不要一人大包大攬花嘶，而是相應的人就去負責相應事情的跟進笋籽。其他人只要知道結果就行。

5. 功能模塊的完成

5.1 說到具體的業(yè)務實現(xiàn)椭员，個人覺得车海，已經不那么難了。不過就是隘击，先盡力提出的一個初稿侍芝，然后發(fā)現(xiàn)問題解決問題，發(fā)現(xiàn)問題埋同，解決問題的過程州叠。

5.2 各自系統(tǒng)能做的事情完成后，就是聯(lián)調各系統(tǒng)間的調用關系凶赁，保持高效的溝通咧栗，讓問題在短時間內解決，尤為重要虱肄。在這種時候致板，我覺得，一個小黑屋也許也是個不錯的選擇浩峡。

5.3 聯(lián)調的過程可岂，其實就是一個自測的過程，應把盡可能多情況給考慮到位翰灾。

5.4 代碼檢查缕粹，自己開發(fā)的代碼，基本上很難發(fā)現(xiàn)其中的問題纸淮，即時找到相應人幫忙檢查代碼平斩，是比較好的解決代碼問題的方案。其實咽块，在給別人檢查的時候绘面，也是自己檢查的時候，相當于自己再一次的開發(fā)侈沪，也能及時發(fā)現(xiàn)問題揭璃。

6. 多輪的測試驗證

6.1 測試同學，其實在開發(fā)快結束的時候亭罪，已經把測試用例給到大家瘦馍。這也是另一個角度的開發(fā)，因此应役，參考測試用例進行相應開發(fā)修改也是很有必要的情组。

6.2 第一輪測試燥筷，可能主要是大功能的驗證，小功能的檢查院崇，擋板環(huán)境即可肆氓，無需真實環(huán)境。

6.3 第二輪測試底瓣，則是要把之前的測試及各種配置谢揪，全部清空，以一個全新的項目來對待濒持，重新進行相應環(huán)境搭建键耕，代碼部署，然后再進行測試柑营，確保問題解決后，做好了相應的處理方案備份村视。這時官套，就需要用到真實的應用環(huán)境了。對之前一些暫未解決的問題進行重新測試蚁孔。確保無問題奶赔。

6.4 第三輪測試，應該是一個灰度發(fā)布的環(huán)境杠氢，也可以認為是預上線站刑。將所有環(huán)境當作是線上來處理，如果運行ok,即可準備發(fā)布上線了鼻百。

6.5 在測試過程中绞旅，因測試人員只是人工的處理，有時不一定能捕獲所有的問題温艇，開發(fā)在這時因悲，也應站在測試的角度，發(fā)現(xiàn)問題勺爱，即時監(jiān)控晃琳，即時處理。

6.6 自動化測試琐鲁，這個其實應該是靠后的處理卫旱，但是如果能做到這些的話，也能夠快速的重現(xiàn)問題围段。

6.7 壓力測試顾翼，應對線上環(huán)境，需有一定的能力評估蒜撮，不然暴构，只瞎猜跪呈，恐怕也不是好事。隨時準備橫向擴展取逾，也只是出現(xiàn)問題后的解決方案耗绿。做好壓測，發(fā)現(xiàn)代碼中存在的問題砾隅，即時處理掉误阻。

7. 外圍處理(上線前)

7.1 上線前，肯定是有很多事務要處理的晴埂。

測試環(huán)境中的各種基礎數(shù)據(jù)究反，隨時導出備份，到線上時儒洛，直接插入使用精耐；

服務器，在架構評審過程中進行數(shù)量評估琅锻；

域名卦停，對外網提供服務一定是要域名的；

權限恼蓬，比如上線后惊完，出現(xiàn)了問題，誰有權限來處理問題处硬，一定提前給到小槐；

驗收，這是關鍵的一點荷辕，功能完成后凿跳，及時驗收，如果上線有些小問題桐腌，盡量協(xié)商拄显，不要在線上頻繁改動。

如此案站！

整個項目就完工了躬审。

其實發(fā)現(xiàn)，一個項目真正的功能實現(xiàn)蟆盐，并沒有占多大的比例承边，而是一些前期的準備及后續(xù)的處理，反而占了更多的時間石挂。

第一個版本上線后博助，可能接著就是迅速迭代了。（如果運營還可以的話１杂蕖）

以上富岳，就是一整個項目的流程清單蛔糯，以一步一個腳印的經歷總結，不涉及具體語言代碼窖式，但是思路都是相通的蚁飒，希望對你有幫助！