項目開發經驗談：如何成爲出色的開發人員

　　前言：之因此有此一文，不是空穴來風，也不是故意的譁衆取寵，而是最近的一些所見，所感。在本文中總結出來，但願對你們有幫助。

由於一些工做緣由，其餘的系列文章沒有接着寫下去，還望你們見諒。

 

本篇的議題以下：

不要成爲代碼的機器

如何有效的項目評估

不要成爲代碼的機器

開發人員的事情就是coding，沒日沒夜的coding，並且你們都是這樣在coding，可是效果和結局就不同：有人coding了N多年，技術仍是原地踏步，編寫出來的代碼仍是bug連連；有人coding就變成了技術骨幹，甚至有人成爲了CTO, 架構師等。

 

爲何？

 

首先從一個小的故事提及：一個項目，分配給了項目組的人開發。因而你們就熱火朝天的幹了起來。當時，就發現了一個現象：任務已分配完成以後，有人就開始coding了，噼裏啪啦的開始敲代碼，不久以後又開始噼裏啪啦的改代碼，而後又開始不斷的調試，找出bug，而後修改bug。很快，這個迭代的期限就到了，原計劃要完成的功能不少沒有實現，有的人也確實作完了，問題也一大堆，有人也確實完成了，沒有bug，可是在審查他的代碼的時候，就是看不懂。

 

這裏想起了本身剛剛步入IT開發行業時候的情景。老是但願儘快的把事情搞完，由於只要沒有作完，就拖了項目的後腿，極可能被leader訓導，甚至可能被認爲沒有能力而被開除。在寫代碼的過程當中，發現一點：儘管寫代碼的速度是快了，可是在寫完了以後，每次編譯，都發現錯誤，編譯經過了吧，邏輯又有錯誤，而後就這樣不斷的縫縫補補，功能是完成了，可是內心有一種想法：之後千萬不要讓我來看和來改這段代碼。由於代碼寫的很爛，爛的連本身都不想看，並且不少實現的方式也是很詭異。反正結果是：功能完成了。其實本身內心也很清楚，在寫代碼的時候，腦子有點糊，並且寫着寫着就不知道寫什麼了。

 

後來慢慢的發現：若是再這樣下去，對本身的發展是沒有好處的，並且本來認爲頗有技術含量的編程活動也變成了一種沒有技術含量體力活，有時候甚至不用腦子。

 

就如軟件開發中的需求同樣：變化。

人也要：改變。

 

因此在以後的項目開發過程當中，就給本身定了一個目標：寫完一個小功能的代碼，確保一次就編譯經過（固然，在寫代碼的時候確定得注意邏輯，可是偏重在使得編譯經過），因而，在開發的時候，就開始「用心」了，或者說是更加的細心了。

 

一段時間的磨練以後，這個目標達到了，並且還超出了指望的值：寫完一個大的功能代碼以後，編譯也沒有錯誤。

 

因此這裏悟出了一點：一樣是作事情，作的也是同一件事，目標不一樣，結果就不同。

 

這樣以後，寫的代碼質量確實是提升了，可是另外的問題又出來了：寫出來的代碼老是在縫縫補補，老是這裏差一點，那裏差一點。不少地方很欠考慮。

 

怎麼辦？

發現了怎麼一個問題：每次在任務分配了以後，就開始coding。這沒有錯。你們都這麼作的。可是有一點：每次在實現一個功能的時候，老是一邊寫代碼，一邊思考，就這樣，一步步的把功能實現。其實這就是問題所在。

 

就比如下棋，你老是走一步算一步，可是你的對手在走一步的時候，已經想到了後面的3步，4步，甚至更多步怎麼走。若是你和這樣的對手下棋，輸家經常是你。

寫代碼也是同樣的，不要走一步算一步。在寫代碼以前，首先從業務上，要把這個功能的流程搞清楚，而後再考慮：若是實現這個流程，要怎麼寫代碼。而後在開始寫代碼，因而帶着這個思想，發現本身寫出的代碼邏輯錯誤就少了，起碼在整體的流程上是對的，可能在有些地方缺乏一些考慮，如驗證等。這樣bug也少了，開發的速度天然快了。

 

說白了，就是在實現一個功能以前，先要設計，或者專業一點，畫畫流程圖，其實流程圖也不必定非得用UML畫的那麼標準，不少時候，就是拿一支筆和一個練習本開始畫了，只要本身認識就好了。

採用這種方式以後，發現不只本身的設計能力提升了，並且對開發出來的功能也是頗有信心的。

 

一個功能，在草紙上設計，一個模塊，也這樣設計，甚至一個小的體統也這樣設計，慢慢的，就能夠上機coding以前，整個功能就已經在頭腦中實現了，剩下的就是轉爲代碼的事情了。

 

如何有效的項目評估

在項目中，老是想控制項目的進度，可是每次在開會的估算一個功能何時能夠作完的時候，每每聽到的倒是這樣的話「應該能夠在一週之類完成」，「估計應該能夠吧」，等等，諸如此類的沒有把握的話，最後的結果是：什麼時間規劃都是白搭，延期，再延期。

 

其實很大的程度上就反映了設計的問題。

怎麼說？

 

其實當咱們在估算項目的時候，不少的時候咱們沒有一個準確的估算，或者說只有一個大概的估算。其實這就是設計作的不夠。

 

當一個任務分配下來以後，咱們確實一直在考慮業務流程和怎麼實現，可是終究只是停在「考慮」上，沒有進一步的細化，細化的顆粒度不夠，沒有細化到用到幾個類，幾個方法，不少的時候只是大概的想一想怎麼實現。就由於這樣，項目的風險很大，甚至不能控制項目，並且也不知道項目是否按照計劃在在進行。

 

若是設計作的充分的好，最後的結果就是：整個類，流程都基本敲定，只是填充方法的實現而已，這樣項目是否按照計劃進行就一目瞭然。

 

 

固然，這裏不是閒着沒事專門的說教，也不是說些大話，空談，大談。

其實，編程終究是須要動腦的，多多的思考。