熟悉公司技術(shù)棧。一個公司應(yīng)該有自己固定的技術(shù)棧。這套技術(shù)棧會應(yīng)對公司具體的業(yè)務(wù)需求。當(dāng)然，創(chuàng)業(yè)公司的技術(shù)資源是比較少的，需要招聘人員從上一家公司帶來一些。詢問需求。需求先跟產(chǎn)品溝通討論需求，了解客戶有哪些需求信息。整理需求。以文檔的方式把跟產(chǎn)品溝通后的需求，按照功能模塊逐一進(jìn)行梳理整理，需要寫得盡可能詳細(xì)。討論需求。就是需求評審，確認(rèn)哪些需求是合理的，哪些需求是不合理的。進(jìn)行有意義的需求評審，這個特別重要。確認(rèn)需求。再次跟產(chǎn)品確認(rèn)需求，一方面是確認(rèn)就是要做文檔中呈現(xiàn)的需求，另一個方面也是檢驗開發(fā)者是否對需求理解到位了。如果發(fā)現(xiàn)開發(fā)者跟產(chǎn)品理解不一致，是需要作出修改。這個時候產(chǎn)品也需要跟客戶再次溝通，確認(rèn)需求是否是客戶真實需要的。整理文檔。把項目的時間周期呈現(xiàn)在文檔中。把項目中所有需要的功能模塊，都需要用文檔進(jìn)行詳細(xì)說明。設(shè)計表結(jié)構(gòu)。根據(jù)產(chǎn)品畫的原型，抽象成軟件設(shè)計的概念，現(xiàn)在大都是抽象面向?qū)ο蟾拍睢．媽嶓w流程圖。用實體流程圖來說明項目的核心流程和數(shù)據(jù)流程。因為一個系統(tǒng)其實就是實體來描述的，而實體數(shù)據(jù)的流動其實就是核心流程邏輯了。畫必要的UML圖。加強(qiáng)實體間相互關(guān)系理解，這樣可以搭建一個好的類關(guān)系組織圖。這里沒有好或者不好，只是如果把這些需求當(dāng)成工程技術(shù)那樣嚴(yán)謹(jǐn)?shù)乃伎?，這些步驟還是可以做的。根據(jù)自己需要，靈活應(yīng)對，如果自己理解力夠好，經(jīng)驗夠了，這些步驟可以直接在腦子里做。如果理解力不夠好，還是該畫就畫。畫項目核心功能邏輯圖。把項目中比較復(fù)雜的和非常重要的功能邏輯，畫成圖，目的：輔助自己理解。用漢語把功能寫出來。其實寫代碼就是寫故事，用漢語可以先把故事寫一寫，然后用編程語言把故事在描述一次。做兩次是非常好的，第一次會考慮到一些細(xì)節(jié)，因為當(dāng)接觸一個新的功能邏輯，其實是陌生的。用熟悉的漢語寫成一個故事，是可以輔助理解的。其實，橡皮鴨的調(diào)試法就是這樣的。用自己的話，用自己的理解把整個過程說出來。編碼。把前面的工作都踏實做好了，編碼就是一件非常簡單的事情。單元測試。需要注意一下，哪些是必須測試的，哪些內(nèi)容根本無需測試。bug修復(fù)。上線?？偨Y(jié)。一個項目做完后，把重要的bug，進(jìn)行整理和學(xué)習(xí)。把做得不好地方進(jìn)行梳理，下次需要改善。學(xué)習(xí)新技術(shù)。這個也是工作的一部分，而且特別重要。