程序員如何獨當一面

今天和大家分享一下，程序員如何獨擋一面這個話題，這是一個很大的話題，我把他分成三部分來談：

一、需求轉換的能力或者叫理解需求的能力；

二、分配時間的能力；

三、開發質量的問題；

我為什麼把時間分配優先順序放到代碼質量的前面呢，原因有兩個：

1.如果時間把控的好，及時功能有點問題，也是有時間來修復，相反及時程序代碼質量再高，到了完成的時間節點沒有完成，那就是災難性的。

2.代碼質量是通過時間的積累，技術的沉澱，修復成本越來越低，提升空間越來越小的因素；而時間規劃卻是和人的行為習慣掛鉤不好去改正的一個點，比如你讓一個拖延症的人變的行動迅速，是一個相對艱難的事情。

所以，我覺的合理分配時間的能力的權重要>開發質量的問題。

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

一、需求轉換的能力

需求轉換的核心就兩個字「溝通」，開發成本最大的浪費是需求浪費，這分為兩方面，一方面需求方，無效需求或者需求變動帶來的研發成本浪費，另一方面是需求方和研發方需求傳遞不一致的浪費，簡單來說就是沒有充分溝通，導致研發所做的功能和需要方需要的功能不一致，導致返工的現象。第一點是我們作為研發不能把控的，我們能做好的就是在需求傳遞的過程中，保證需求的有效性和完整性。

那麼具體要怎麼做呢，可以通過以下幾點：

1.開發前需求溝通，最理想的溝通方式：產品提供需求文檔 => 研發人員先過一遍，記錄有疑問的需求點 => 產品和研發討論需求，把所有的需求都過一遍，有疑問的點重點溝通 => 研發人員用產品能聽懂的話，大概的描述一下重點討論的需求和實現方式 => 產品確認無誤，啟動開發流程。

2.開發中溝通，或者是開發前模擬程序實現流程的時候，如果有未談到的需求或者有異議的需求，及時和產品溝通之後在開始做編碼。

3.測試階段，給需求方演示程序，最後一遍對接核對需求。

如果能保證以上三點，基本上在需求轉換的工程中已經算一個合格的程序員了。

二、分配時間的能力

做軟體開發的一般情況下都是，以功能（或叫結果）為導向，以時間為衡量標準的一項嚴謹的工種。所有「時間概念」在軟體開發中發揮著無疑比喻的重量。

在說合理分配時間之前，我想有必要先說一下，程序開發的生命周期，在很多人眼裡，程序開發有啥周期，做完不就完事了嗎？其實這是小作坊的思維方式，對於一個合格的軟體公司或者大一點的軟體公司來說，即使到了開發實施的這一步，也分為5步：軟體設計，思考最優實現方式 => 擼碼 => 測試階段 => 修復完善 => 交付，完成開發。

一般來說，對我個人而言軟體設計，思考最優實現方式要佔用30%的時間，擼碼佔用50%，測試和完善20%，當然，這個不能一概而論，對於新書來說思考的時間短點，關鍵點在留夠測試和完善的時間，測試和完善的時間越長，項目的成功幾率就越大；對於大咖來說思考的時間更長，因為代碼質量過硬，所有測試和完善的時間可以相對分少一點。

如果你能認識到小作坊和生產線的區別，就能合理的安排時間，盡量提前完成開發，進入測試和完善的階段，才是關鍵。

影響時間規劃的還有另一個原因，項目衝突，比如你再做B項目，突然測試人員找你說你的A項目有一個xx問題，這個時候，你就要平衡一下優先順序，原則上來說，是先處理優先順序高的問題，但一定要把控的是盡量不影響自己的B項目計劃開發進度。如果實現迷茫可找你的領導來權衡，讓他做決定，這一點很重要，一定不能忽略。

三、開發質量的能力

這一點是最後一點，也是最偏重技術的一點，那麼怎麼去衡量開發質量的，我把它分為三個元素：

1.基本的評判標準，功能可以正常使用；

2.可讀性高，利用他人和自己閱讀、修改，降低維護成本；

3.模塊化程度高，提高擴展性，降低維護成本，提高開發效率。

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

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！