《5分鐘從學生到程序員》第11課。
終于開始要做功能了,我相信新手都會有些興奮和緊張,我們就帶著這種美妙的感覺開始代碼之旅。很多新手拿到功能,就開始復制代碼,樂其不疲的當個代碼搬運工,這種開局方式是不妥的,我們先來看下新手常犯的錯誤。
1)當個快樂的代碼搬運工
這種是最常見的。一般新手的功能都比較簡單,都會是顯示類、列表類的功能,最多有一點簡單的交互。像這種功能在項目中很多,工程師就會去找類似的功能,然后整篇整篇的復制代碼過來,改點界面上的顯示元素,基本上功能開發就差不多了,自己看看沒問題,就丟給測試工程師。
初級工程師是代碼搬運工沒錯,但這種操作是有問題的,他沒有理解功能和代碼,代碼復制過來,感覺差不多就不管了,反正是把開發交給感覺。
分享個案例:之前有做一個項目,在發迭代版本的時候,我試用了一下,就發現一個功能不對,H5上顯示的文字內容不對,我就知道,這位老兄復制代碼搞錯了,我就故意去問他業務流程,他講了半天講不清楚,最后他告訴我代碼是他復制過來的,他也搞不懂,再問他調用關系也搞不清楚,我看復制過來的代碼里面,有很多是垃圾代碼,是前個功能的業務流程,這里用不到。我就讓他師傅花半天時間重新教一遍。
2)先鋪界面,再找接口,拼出個功能交給測試
很多新手看到功能,他也不懂得去理解功能,就看到有界面設計,其它也不管,就開始寫界面,寫完界面,再到處問接口,調個半天接口流程還走不通,終于調通了,還發現跟界面對不上,又鬧騰個半天,終于把數據對上了。不錯,界面有了,數據也有了,功能開發完了,就丟給測試。然后,測試就來投訴:“那個某某,功能開發一半就提交測試,簡直是開玩笑。”
這種開發方式,不僅新手喜歡用,我見過很多工作多年的工程師也喜歡用。
分享個案例:一個有四年經驗的H5工程師特別離譜,他做功能是分三步的,先按產品原型把所有的界面都鋪出來,然后對接接口,把數據調通,最后根據UI交互設計圖,再重新調整界面。我估算過他的開發速度,比正常的多出30%,而且bug率也特別高,關鍵還天天加班。
3)理解個大概就開始動手,然后打補丁,把功能完整性交給測試
這種也比較常見,不過犯這種錯誤的,都是新手中的高手,普通的還犯不上。一個功能比如有十個點,他懂得去分析,得出來五六個點,然后就開始開發,開發出來之后跟產品原型一比對,發現少東西了,就開始加,加了一兩個點,然后感覺好,就提交測試。
這種是有一定的產品理解能力,但是理解不到位,所以功能的完整性是沒有保證的。
我們分析了常見的錯誤方式,接下來我們看正常的要怎么做。
我們都用過微信,那現在給你分配的功能就是聊天時發文字這個功能,那要怎么做?
1)步驟一:知道功能做什么
首先,知道功能做什么?發文字功能,是給好友發送中英文、數字、符號等信息。
其次,誰會用,怎么用?發文字功能,每個人都會用,可以給好友發,可以在群里發。
最后,功能跟其它功能有沒有關系?暫時這個功能跟其它功能沒關系。
通過前面的這些分析,我們就知道功能大概做什么了。接下來,就要看怎么做。
2)步驟二:知道功能實現的流程、步驟
簡單的講就是整理功能的實現思路,它大概有哪些主要的步驟。把這些步驟列出來,這個功能要實現的目標能達到了。
APP端:
* 聊天界面有個 輸入框,用戶點輸入框可以輸入文字,發送;
* 如果沒有網絡,提示用戶沒有網絡;
* 如果連接正常,就把文字內容異步發給服務器;
* 收到服務器返回,成功:把菊花去掉,不成功:顯示個紅色“!”。
后臺接口:
我們再來看后臺java端,同樣的功能,后臺思考的就跟前端不一樣。后臺大概是:
* 消息發送方告訴服務器有新消息
* 服務器方接收發送消息方數據
* 服務器告訴消息接收方有新數據要接收
* 接收方取得數據器端數據
* 接收方告訴服務器數據已經拿到,消息可以作廢
像這樣基本上就把一種事講通了。
3)步驟三:問師傅或領導
像前面這樣想一想,把它寫下來,可以用思維導圖,可以用文字,也可以用UML圖,或大學時學的流程圖。你確定對功能的理解和實現思路的理解都是對的嗎?我相信你不敢確定。所以,整理完思路,不是直接開發,要先問下師傅,讓他看你的理解對不對。師傅以他的經驗,如果有問題,他能幫你指出來,你再把思路修改一下。兩人再切磋一下,基本上就把功能點都找出來。
實際上,我前面講的這三部分,分別是需求分析、概要設計和設計評審。如果你是在大企業或有流程的企業,都有專門的流程節點和編寫要求,正常是用UML圖來畫分析設計圖,評審有專門的分析設計評審會,就按公司的要求來做就是了。如果是在專業性要求不高的公司,可以采用這種簡化的分析、設計和評審方法,至少自己的專業水平不會太差。
我這種簡化了的分享,主要是用來幫助理解分析和設計的原理。通過這種簡化了的分享,應該感覺分析、設計很簡單吧!不然很多人認為分析、設計是很高大上的,很難的事,就很抗拒去做,結果專業能力一直提升不上去。
實際上,分析、設計還是比較簡單的,難的是UML圖不懂得畫,而往往把分析、設計理解成畫UML圖和寫文檔。分析、設計是用來整理思路、輔助理解需求,UML圖是用來輔助分析、設計的,而現在UML圖把分析、設計難住了。《大學》里有句話:“物有本末,事有始終。” 而把分析、設計理解成畫UML圖,就是本末倒置。
4)步驟四:寫代碼 (做個快樂的代碼搬運工)
到前面這個階段,基本上就很清楚功能做什么,怎么做了。那就可以當個快樂的代碼搬運工,找到每個步驟的實現代碼,把它搬過來,所有的步驟和功能點都實現到了,那這個功能就開發完了。
5) 步驟五:測試
代碼開發完,不要認為就結束了,丟給測試就可以了。一般初級工程師都不會做測試和跑測試用例,所以公司沒有要求,我們也不做。但是,我們要自己去用下這個功能,如果自己開發出來的功能,自己都不會用,你覺得用戶會懂得用嗎?
自己試用的過程中,如果有用的不流暢的,用戶也會用的不流暢;如果你覺得做的功能看起來看丑,那客戶也是這種感覺。所以交出去的功能,是自己滿意的功能。那測試的時候,基本上是很少BUG了。
【準時完成】
前面講了這么多,通過分析、設計、評審,讓你對功能需求有充分的理解,這樣寫出來的功能的完整性才有保證,自己試用功能,才能減少bug,所有的這些操作,都是讓你做的功能,減少bug率和返工,確保開發進度。
做開發有個至關重要的原則,就是“準時完成”。我帶團隊,硬性要求就是項目必須準時上線,不能有任何的延期。如果你能做到準時完成,比看十本執行力的書都來的有效果。
這節課我們分享了做功能開發常見的錯誤方式,大家盡量避免犯這些錯誤。簡單分享了分析、設計、設計評審的原理和操作步驟,打消程序員對分析、設計的抗拒心理,提升程序員的專業性,也讓大家掌握做功能比較好的方法和習慣,確保功能開發能準時完成。
新聞標題:寫代碼的五個步驟,你會幾個?
本文路徑:http://m.newbst.com/news28/104278.html
成都網站建設公司_創新互聯,為您提供品牌網站建設、網站制作、搜索引擎優化、網站導航、外貿建站、全網營銷推廣
廣告
聲明:本網站發布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源:
創新互聯