程式設計師進階之路—如何獨當一面

王磊的部落格發表於2017-02-21

今天和大家分享一下,程式設計師如何獨當一面這個話題,這是一個很大的話題,我把他分成三部分來談:
  一、需求轉換的能力或者叫理解需求的能力;
  二、分配時間的能力;
  三、開發質量的問題;

我為什麼把時間分配優先順序放到程式碼質量的前面呢,原因有兩個:
  1.如果時間把控的好,及時功能有點問題,也是有時間來修復,相反及時程式程式碼質量再高,到了完成的時間節點沒有完成,那就是災難性的。
  2.程式碼質量是通過時間的積累,技術的沉澱,修復成本越來越低,提升空間越來越小的因素;而時間規劃卻是和人的行為習慣掛鉤不好去改正的一個點,比如你讓一個拖延症的人變的行動迅速,是一個相對艱難的事情。
所以,我覺的合理分配時間的能力的權重要>開發質量的問題。


在開始之前,先給大家看一下思維導向圖:


一、需求轉換的能力
  需求轉換的核心就兩個字“溝通”,開發成本最大的浪費是需求浪費,這分為兩方面,一方面需求方,無效需求或者需求變動帶來的研發成本浪費,另一方面是需求方和研發方需求傳遞不一致的浪費,簡單來說就是沒有充分溝通,導致研發所做的功能和需要方需要的功能不一致,導致返工的現象。第一點是我們作為研發不能把控的,我們能做好的就是在需求傳遞的過程中,保證需求的有效性和完整性。
那麼具體要怎麼做呢,可以通過以下幾點:
  1.開發前需求溝通,最理想的溝通方式:產品提供需求文件 => 研發人員先過一遍,記錄有疑問的需求點 => 產品和研發討論需求,把所有的需求都過一遍,有疑問的點重點溝通 => 研發人員用產品能聽懂的話,大概的描述一下重點討論的需求和實現方式 => 產品確認無誤,啟動開發流程。
  2.開發中溝通,或者是開發前模擬程式實現流程的時候,如果有未談到的需求或者有異議的需求,及時和產品溝通之後在開始做編碼。
  3.測試階段,給需求方演示程式,最後一遍對接核對需求。
如果能保證以上三點,基本上在需求轉換的工程中已經算一個合格的程式設計師了。


二、分配時間的能力
  做軟體開發的一般情況下都是,以功能(或叫結果)為導向,以時間為衡量標準的一項嚴謹的工種。所有“時間概念”在軟體開發中發揮著無疑比喻的重量。
在說合理分配時間之前,我想有必要先說一下,程式開發的生命週期,在很多人眼裡,程式開發有啥週期,做完不就完事了嗎?其實這是小作坊的思維方式,對於一個合格的軟體公司或者大一點的軟體公司來說,即使到了開發實施的這一步,也分為5步:軟體設計,思考最優實現方式 => 擼碼 => 測試階段 => 修復完善 => 交付,完成開發。
一般來說,對我個人而言軟體設計,思考最優實現方式要佔用30%的時間,擼碼佔用50%,測試和完善20%,當然,這個不能一概而論,對於新書來說思考的時間短點,關鍵點在留夠測試和完善的時間,測試和完善的時間越長,專案的成功機率就越大;對於大咖來說思考的時間更長,因為程式碼質量過硬,所有測試和完善的時間可以相對分少一點。
如果你能認識到小作坊和生產線的區別,就能合理的安排時間,儘量提前完成開發,進入測試和完善的階段,才是關鍵。
影響時間規劃的還有另一個原因,專案衝突,比如你再做B專案,突然測試人員找你說你的A專案有一個xx問題,這個時候,你就要平衡一下優先順序,原則上來說,是先處理優先順序高的問題,但一定要把控的是儘量不影響自己的B專案計劃開發進度。如果實現迷茫可找你的領導來權衡,讓他做決定,這一點很重要,一定不能忽略。

三、開發質量的能力
  這一點是最後一點,也是最偏重技術的一點,那麼怎麼去衡量開發質量的,我把它分為三個元素:
  1.基本的評判標準,功能可以正常使用;
  2.可讀性高,利用他人和自己閱讀、修改,降低維護成本;
  3.模組化程度高,提高擴充套件性,降低維護成本,提高開發效率。

 

綜上所屬,寫給正在奮鬥的你一點小小的建議:提高自己主觀能動性,調整自己心態,以主人翁的心態,積極的面對工作。你在認同公司的同時,公司才能認同你!

 

相關文章