標籤:style http color strong 檔案 問題
第3部分 軟體研發工作總結
完成第一個新需求
在入職後不久,我得到了第一個新任務:完成某個版本的一個新需求。所謂的“需求”,就是用文檔的形式告訴我們要做什麼,要實現什麼功能。
在得到需求文檔之後,我仔仔細細地閱讀了好幾遍,發現有些地方自己並不是很明白。如果在自己都不是很確定的情況下修改代碼,其後果是很嚴重的,專案經理曾經這樣告誡我。我把自己的疑惑以郵件的形式發給了SE(系統工程師),讓他把需求講明白。在我們公司,SE負責寫需求,他們要把使用者想要實現的功能寫成文檔,然後讓軟體開發工程師來實現,可以說是起到了“橋樑”的作用。
很快,SE便回了郵件,一一為我答疑解惑。在明確了自己到底要做什麼之後,我便著手修改代碼了。一般說來,作為新人,不太可能一開始便做很複雜的東西,都是從最簡單的開始的。也就是說,先是要在別人的基礎之上修改代碼。
對照著“需求文檔”和“詳細設計文檔”,我很快便找到了要進行修改的地方。接下來是不是應該馬上就寫代碼呢?還不是。接下來要做的是找出“編程規範”,按照上面寫的來辦事,包括:如何命名變數?如果寫注釋?如何添加或刪除代碼?“沒有規矩,不成方圓”,我們做任何事情都要遵守一定的“遊戲規則”。
一切準備工作都做好了之後,就可以動手編代碼了。在此過程中,我總是小心翼翼的,生怕出錯。完成一定的代碼量之後,我回過頭去檢查幾遍,再接著做下去。如此反覆,直到完成該需求。
我本以為編好代碼便萬事大吉了,但事實並非如此。導師告訴我,編完代碼之後要進行自測,在自測無誤之後才能提交。這也糾正了我之前的一個想法:代碼測試是測試人員的事情。在我們公司,大部分的測試工作都是開發工程師在做。在自測多次之後才能將代碼提交到指定的地方。
我總結了一下,一般說來,在整個研發項目中,除了編碼之外,我們還需要做以下事情:
第一,自測
所謂的“自測”,與測試人員做的測試有區別。我們自測的目的是驗證自己編寫的代碼的正確性,要確保讓別人發現的錯誤盡量少。
如果要完成多個功能,我的做法是在完成一個功能之後,便對其進行測試。
第二,編寫文檔
一般說來,涉及到的文檔的種類繁多,包括:單元測試文檔、整合測試文檔、詳細設計文檔、使用者文檔、協議文檔等。如果涉及到升級,那麼還有升級文檔。
對於單元測試文檔的編寫,是要對自己編寫的單個函數功能進行驗證,要在文檔中寫出自己設計了哪些用例,達到的效果是什麼,以及測試過程中出現了什麼問題。
對於整合測試文檔的編寫,重在對介面進行測試。“整合”的目的就是將不同功能的模組組合起來,要看它們是否能夠協同工作。編寫的方法和單元測試文檔差不多。
對於詳細設計文檔的編寫,要體現出自己設計的整個過程。也就是說,自己的思路是什麼,為什麼要這麼做,哪些模組最重要,哪些函數是關鍵函數。詳細設計文檔是非常重要的,我們以此來編寫代碼。
對於使用者文檔的編寫,要謹慎。使用者文檔一般是拿給使用者和現場的工程人員看的,如果寫得不好,那麼對於現場版本的安裝是很不利的。
其它協議文檔或者由使用者提供,或者由業務規劃部門提供,我們可以參考。
第三,走同行評審流程
我們做出來了東西,要想得到別人的認可,就需要同行評審。“同行評審”顧名思義,就是讓專家或同事來看一下我們做的東西怎麼樣,有哪些不足,如何改進等。
這個流程比較重要,通過它,我們可以發現自己想法的不足、自己思維的漏洞,並加以改正。
第四,提交並構建版本
這裡的提交版本,不是像我們在學校那樣把文檔或代碼一放就了事了,而是要按照規格來辦事。哪裡放代碼,哪裡放文檔,檔案結構如何組織,都是有嚴格規定的。一切都要遵循規範和做事流程,這是公司和學校的區別。
在版本提交過後,下一步工作就是構建一個版本,表示我們開發人員的工作到此已經告一段落了,接下來該測試人員“粉墨登場”了。
回首自己完成需求的過程,有這幾點體會:
第一,做任何事情都要積極主動,不懂就要問。
第二,開發人員做事要認真仔細,要確保自己編寫的代碼的正確性,為自己的工作負責。
第三,凡事都要遵守規範,不能憑自己的想法辦事情。
經驗是一點點積累起來的,完成第一個需求的經曆讓我學到了很多東西,它為我之後的工作打下了基礎。
(本人微博:http://weibo.com/zhouzxi?topnav=1&wvr=5,號:245924426,歡迎關注!)