IT職場：職場小白如何順利完成一個新項目

我們的學(xué)員經(jīng)常留言說剛接手了一個新項目，感覺手忙腳亂的，不知道從何下手，針對這點小編準(zhǔn)備羅列了一套職場小白如何順利完成一個新項目的流程，步驟和項目規(guī)劃書，歡迎圍觀。

一、項目規(guī)劃

1.1 首先，你得徹底明白到底要做什么?

這個過程，可能是你要讀需求一遍、兩遍、三遍。。。 然后假設(shè)，你已經(jīng)在使用這個產(chǎn)品了。

1.2 其次，明白需求后，就要進行整體框架的構(gòu)思!

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

在這個層次上，一般都會遵循公司的規(guī)定，然后再根據(jù)項目本身需求，做些相應(yīng)的調(diào)整。

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

前期只提供APP，因此不存在單獨H5調(diào)用API服務(wù)的情況，但是H5的應(yīng)用場景仍然存在，此時的H5地址，由服務(wù)接口提供地址返回到APP進行webview加載。

1.3 人員規(guī)劃

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

這里一般需要遵循一個最小原則，即劃分出的人員，盡量做到能夠獨立完成自有的模塊，而不是一定要依賴于另一方的實現(xiàn)才能進一步。比如 android,ios各一人，API與SERVICE可以多個人，但是都要讓其有全部權(quán)限，因為API與SERVICE有強依賴，脫離一方，將無法獨立完成?；A(chǔ)服務(wù)各自安排相關(guān)人員實現(xiàn)。最后進行聯(lián)調(diào)即可。

1.4 時間規(guī)劃

有了人員之后，也不能無限時間的去做事?？隙ㄊ且?guī)劃的，否則沒有壓力也沒有動力。項目不知何時才能結(jié)束。訂時間計劃一定要去詢問當(dāng)事人，要多少時間，盡量站在專業(yè)的角度給出合理的建議和評估。促進項目的完成。

二、框架規(guī)劃及搭建

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

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

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

針對服務(wù)端的框架，我覺得有必要多說點。因為整個應(yīng)用運行的流暢性，可靠性，準(zhǔn)確性，都是由服務(wù)端來決定的。雖然用戶看到的是APP或者H5，但是可以說，服務(wù)端才是應(yīng)用的核心。所以，服務(wù)端要做的事情自然很多了。

2.2 怎樣搭建好一些服務(wù)端的框架呢?

首先，框架類的東西，自然是要提前學(xué)習(xí)的。但是，就目前市場行情來說，要想利用框架應(yīng)該都是比較簡單的，尤其是公司內(nèi)部提供的框架，一定要有demo。這樣，照著demo，一步步調(diào)試，直到整個應(yīng)用接通;

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

充分了解框架需要的一些配置參數(shù)，知道事務(wù)從哪里來，到哪里去?這里，應(yīng)有一個配置中心與之對應(yīng)，但是自己得清楚。

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

寫出第一個可供使用的接口服務(wù)，可以說，第一個永遠是比較重要的。因為，第一個的思路，就是你后續(xù)所有功能的方向，因此，寫好第一個”hello, world.”;

三、開發(fā)環(huán)境的搭建(服務(wù)端)

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

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

主要包括，需要多少個服務(wù)，需要多少臺服務(wù)器，需要多少個基礎(chǔ)應(yīng)用，需要多少個基礎(chǔ)配置等等。

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

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

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

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

四、進度的同步

4.1 及時向領(lǐng)導(dǎo)同步項目進度

對于一個新項目，有些地方行動緩慢是很正常的。而部分開發(fā)同學(xué)(比如我自己)，就喜歡沉浸在自己的小世界里糾結(jié)，走不出來，從而忘卻向領(lǐng)導(dǎo)匯報工作。而作為一個有點同理心的領(lǐng)導(dǎo)來說，他又不愿意實時都來盯著你做事，因為也怕你遇到困難，想多給你點時間解決。

但是，這種情況，開發(fā)同學(xué)自己其實是要吃虧的，因為，給外人的感覺就是，你啥都沒做。所以，解決問題的同時，也不忘向領(lǐng)導(dǎo)匯報。

4.2 有處理不了的問題，及時向大牛們或者領(lǐng)導(dǎo)請教

獨立解決問題是好事，但是千萬別過了頭，實在解決不了，就要及時請教。否則，浪費的是時間。進步最快的方式，莫過于向比自己牛逼的人請教。知之為知之，不知為不知!

4.3 盡量將問題分攤下去

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

工作永遠都不是單一的一件事，肯定還會有其他的事情插入進來，觀察事情的重要性解決。如果能夠讓其他同學(xué)解決的，盡量讓其他同學(xué)處理，這點也得與領(lǐng)導(dǎo)同步。否則分心過于利害，受阻的只有項目進度，延期可不是自己一人的事情了。

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

五、功能模塊的完成

5.1 說到具體的業(yè)務(wù)實現(xiàn)，個人覺得，已經(jīng)不那么難了。不過就是，先盡力提出的一個初稿，然后發(fā)現(xiàn)問題解決問題，發(fā)現(xiàn)問題，解決問題的過程。

5.2 各自系統(tǒng)能做的事情完成后，就是聯(lián)調(diào)各系統(tǒng)間的調(diào)用關(guān)系，保持高效的溝通，讓問題在短時間內(nèi)解決，尤為重要。在這種時候，我覺得，一個小黑屋也許也是個不錯的選擇。

5.3 聯(lián)調(diào)的過程，其實就是一個自測的過程，應(yīng)把盡可能多情況給考慮到位。

5.4 代碼檢查，自己開發(fā)的代碼，基本上很難發(fā)現(xiàn)其中的問題，即時找到相應(yīng)人幫忙檢查代碼，是比較好的解決代碼問題的方案。其實，在給別人檢查的時候，也是自己檢查的時候，相當(dāng)于自己再一次的開發(fā)，也能及時發(fā)現(xiàn)問題。

六、多輪的測試驗證

6.1 測試同學(xué)，其實在開發(fā)快結(jié)束的時候，已經(jīng)把測試用例給到大家。這也是另一個角度的開發(fā)，因此，參考測試用例進行相應(yīng)開發(fā)修改也是很有必要的。

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

6.3 第二輪測試，則是要把之前的測試及各種配置，全部清空，以一個全新的項目來對待，重新進行相應(yīng)環(huán)境搭建，代碼部署，然后再進行測試，確保問題解決后，做好了相應(yīng)的處理方案備份。這時，就需要用到真實的應(yīng)用環(huán)境了。對之前一些暫未解決的問題進行重新測試。確保無問題。

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

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

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

6.7 壓力測試，應(yīng)對線上環(huán)境，需有一定的能力評估，不然，只瞎猜，恐怕也不是好事。隨時準(zhǔn)備橫向擴展，也只是出現(xiàn)問題后的解決方案。做好壓測，發(fā)現(xiàn)代碼中存在的問題，即時處理掉。

七、外圍處理(上線前)

7.1 上線前，肯定是有很多事務(wù)要處理的。

測試環(huán)境中的各種基礎(chǔ)數(shù)據(jù)，隨時導(dǎo)出備份，到線上時，直接插入使用;

服務(wù)器，在架構(gòu)評審過程中進行數(shù)量評估;

域名，對外網(wǎng)提供服務(wù)一定是要域名的;

權(quán)限，比如上線后，出現(xiàn)了問題，誰有權(quán)限來處理問題，一定提前給到;

驗收，這是關(guān)鍵的一點，功能完成后，及時驗收，如果上線有些小問題，盡量協(xié)商，不要在線上頻繁改動。

如此!

整個項目就完工了。

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

第一個版本上線后，可能接著就是迅速迭代了。(如果運營還可以的話!)

以上，就是一整個項目的流程清單，以一步一個腳印的經(jīng)歷總結(jié)，不涉及具體語言代碼，但是思路都是相通的，希望對你有幫助!