對軟體開發人員的幾個階段思考和總結

標籤：軟體開發

  最近在瞭解一下關於開發的事情，覺得一些文字對開發人員的總結和思考相當不錯。

進 入IT的人員都是基本素質不錯的人員，但IT產業似乎總是缺少合適的開發人員，為什麼會產生這樣現象，關鍵是缺少合適的開發人員，也就是說我們並不缺少開 發人員，而是確認進階或者說專業的人員，從而使我們的整體人力優勢無法體現出來，在這裡說一下我自己在工作期間對軟體開發人員的發展過程的一些感受和體 會。
    首先，大致的說一下自己給IT人員發展過程的分類，以及和工作時間的大致關係（以下觀點屬於個人觀點）
    階段名稱              工作年限 
   1入門階段          本科畢業1-2年以及剛畢業的研究生
   2中級人員          本科畢業3-4年以及研究生畢業1-2年
   3進階人員          本科畢業5-6年以及研究生畢業2-3年
   4架構師            本科畢業7-8年以及研究生畢業3年以上 
   5專案管理人員      本科畢業9年以上以及研究生畢業4年以上

   這是根據我的經驗做的一個大致的階段以及和研發人員工作資曆的一個簡短的對應情況。關於這個對應關係有幾點需要說明，
    1 本科畢業是指軟體工程專業，或者相關專業，一些大學的電腦科學等專業和軟體工程專業是有很大差別的，比如軟體工作專業強調資料結構、演算法、軟體工程、作業系統、資料庫設計概論等專業課程的學習，而其他電腦相關專業是沒有這些課程的，其中資料結構、演算法、軟體工程對開發人員的工作能力和發展影響比較大。
    2現在的本科和研究生雖然數量增加了不少，但從整體能力上來講水平下降了不少，這和整個社會風氣以及自身的素質有關。總體上將，現在的研究生的工作能力和10年前的本科差不多，現在的本科和原來的大專差不多。
    3 博士學位我沒有加進去，主要是博士的研究方向太專，一旦單純的軟體行業的博士比較少，多是其他行業的專業博士，這些人的特點是一個整體素質比較高，有很多人，在做開發的時候對軟體專業的瞭解比很多軟體專業的碩士要精通很多，但更多的對軟體開發的細節重視不夠，而往往是這些細節會給項目帶來很大的風險，所以不太好做一個標準來說。
    4專案管理人員是我寫的最後一個。這個職位和其他的職位似乎不是一個系列的，但在實際工作，技術人員最終的發展都是這個職位，如果你有很好的技術背景和項目經驗，成為一個專案管理人員不是一個很難的事情，但如果沒有紮實的技術基礎容易出現外行領導內行的現象，結果是上級壓，下級反，兩面受氣。
    好了廢話說了不少，開始說正題吧。評價一個開發人員有很多方法，我自己一般會從幾個方面評價一個開發人員工作能力（只評價能力，而不評價態度，實際工作中開發人員的工作態度對工作能力影響是很大的，這一點大家千萬要注意）。A代碼編寫能力，B設計能力，C調試能力，D文檔編寫能力，E調研能力，F代碼閱讀能力，作為進階技術人員還需要G專案管理能力（包括溝通能力，項目控制能力等）

    我們以本科畢業的工作人員來講述開發人員的不同發展階段以及相關表現吧
    1入門階段          本科畢業1-2年以及剛畢業的研究生
     處於入門層級的工作都是剛畢業不久的大學本科學生，一般來說他們沒有太高的工作能力，各項技術能力是他們的弱項（中國的教育的確很失敗），他們的優勢是在於他們的心態，現在的本科一般來說都瞭解自己的就業情況，所以你一旦給他們一個機會，他們往往會抓住不放，努力地去工作。如果真能努力的去工作，2-3年以後他們的實際工作能力往往比剛畢業的研究生要強很多。好了具體說一下。
    缺點：
       1代碼編寫能力差，一般在大學4年的全部程式碼在1-2萬行以下（這個數量在10年前的本科是無法畢業的），另外一個重要的問題，單個程式的程式碼比較少，基本在1千行左右，缺乏大代碼複雜程式的編程經驗，而在實際工作中2-3千行是不可能是一個有效系統的。由於代碼量少，他們對很多理論的理解基本上基於紙面上的。由於對基礎理論的忽視，造成了他們在開發的時候急於編碼，而不是進行設計，這樣做的效果就是編寫了一大堆雞肋代碼。這對於其他開發人員來說簡直就是災難，而別人對他們代碼的評價又直接打擊了這些人員工作信心。
       2設計能力，雖然現在的代碼開發環境比10年前方便了許多，但由於代碼量的限制，他們對系統的整體結構和異常情況缺乏清晰的認識，他們設計的系統在正常使用的時候一般可以正常運行，但一旦遇到異常情況則完全無法使用，而產生的問題，嚴重的時候不但會影響自己，而且會影響其他模組，甚至造成整個系統的崩潰.所以一般不應該讓他們做太大的系統設計，另外需要格外說明的一個問題，對設計方法的使用是他們的一個很大的欠缺，比如設計資料庫結構的時候採用拍腦門法，設計面向流程的程式不會使用流程圖，設計物件導向的時候不會使用UML都是他們的特點。
       3 會編碼，不會調試，不會發現問題，不會分析問題發生的原因，和排查錯誤。在測試人員將問題提高給他們的時候，他們一般的表現不是首先檢查自己的代碼，而是將問題歸給別人，什麼測試人員測試資料不規範使用者不會這麼變態輸入這些錯誤的資料，什麼這是上邊介面傳過來的資料，他傳錯了，我也沒有辦法處理等等。即使確定是他們的問題，怎麼去重現這個問題，定位這個問題發生的地點的方法和手段是他們缺乏的，往往是一籌莫展。
       4基本沒有文檔編寫意識和能力，彷彿項目的最後成果就是代碼，不知道文檔可以起到什麼作用，也不知道如何編寫，解決問題，討論問題最愛用的方法是拍腦門法和直接交流，所以你在項目進入階段往往會看到幾個新開發的人員在一起吵得一塌糊塗。而討論的內容無非是，上回說好了是這麼做，怎麼現在又變了，或者，你不給我什麼東西，我的功能就做不下去了，等等。。。而這些東西其實在是方案討論和編寫相關文檔的時候就應該已經解決的問題了。由於沒有文檔編寫能力，他們往往無法描述一個商業流程或者程式處理流程，（有經驗的開發人員是可以在不藉助文檔的情況下直接給你寫出來這些流程的，這些流程經過思考和文檔編寫過程已經映入了他們的大腦中）。
       5調研能力，剛參加工作的開發人員是不應該去做調研工作的，做調研工作的技術人員應該是項目組中技術能力最強的工作人員，可惜在實際中卻不是這個樣子，很多剛入門的技術人員沒有經過任何培訓就被派去做調研，做系統該調研什麼內容，如何和客戶進行有效交流，或者真實的需求（而不是表面的膚淺的需求）。如何將這些需求用文字正確的無二義性的表達出來，都是問題，而那種40-50頁的需求文檔是一個項目失敗的第一個訊號。
       6 代碼閱讀能力，這裡說的代碼閱讀能力不是說在閱讀什麼《java小程式》之類的書的時候對書中的代碼的理解，對於一個好的開發人員來說，真正的代碼閱讀能力是你能否閱讀那些真實的系統的代碼，甚至在沒有任何技術文檔和程式註解的代碼的閱讀，能否通過對這些代碼的閱讀瞭解系統的架構、系統的操作過程以及發現程式中的錯誤，這種閱讀代碼的能力是非常重要的，不過可惜的剛畢業的開發人員代碼閱讀能力基本為零，一個能很好理解《java小程式》的代碼的入門級的開發人員已經很不錯了。讓他們直接閱讀2000行以上的應用系統的代碼基本是不可能的。
    

    說了這麼多，估計很多剛參加工作的技術人員要氣死了，現在讓我們看一下他們的優點吧。
        1心態好，能夠接受別人的意見，特別是老鳥們的意見（當然對對同層級的人可能不行），不要小看這一點，是否善於接受別人的建議對開發人員的成長是極為重要的，而入門層級的開發人員在這一點往往是做得最好的。
        2 有工作熱情，肯加班。加班不是一種好的工作方式，但對於剛入門的開發人員來說，卻是很重要的事情，效率*時間=工作成果。如果效率很高，工作時間少，工作成果也不會差，但既然我們的新工作人員無法一下提高工作效率，卻可以提高工作時間的方法來保證工作成果，另外，隨著工作時間的增加，工作經驗也是同步增加的，而這也會使你的工作效率逐步提高，讓我們假設一個工作人員每天比別人多工作1小時來計算，一年220個工作日，如果你可以堅持你比別人的提高是多少倍大家可以自己計算一下。（為什麼菜鳥看老鳥是什麼高不可攀，你算一下就知道了）
         3你可以犯錯誤，新人必然犯錯誤，甚至是很低層級的錯誤，而且由於你年輕，你會有更多的機會，所以這個階段的技術可以利用自己的有時嘗試各種方法。
    以上就是人門層級的IT開發人員的一些特徵，對於如何迅速地協助他們成為一個好的開發人員我們在以後的文章裡介紹吧    
    

 

2中級人員          本科畢業3-4年以及研究生畢業1-2年
     中級開發人員一般都有了一定的編碼經驗，一般來說，如果你的工作比較飽滿的話，一個中級的開發人員應該有7-8萬行左右的代碼量，他們對某種語言的使用已經比較有經驗了，對系統架構有一些瞭解，至於文檔，他們現在只編寫過一些無用的文檔，為什麼說他們編寫的文檔是無用的，主要是指他們對文檔的作用沒有更深刻的理解，他們可以很清晰地說出在開發過程中需要那些文檔，但對這些文檔應該包括那些內容，這些內容對以後的開發能夠起到什麼作用卻不甚瞭解。也就是這個原因，他們編寫的文檔更多地是為了對付單位的檢查，而不是對開發有什麼實際作用，很多開發人員就是因為這個問題一直沒有克服，使得他們一直處於中級開發人員（有時候會持續幾年甚至十幾年）。好了，說說中級開發人員的一些特徵吧。
     1代碼編寫能力：重視語言的差異，是JAVA還是。net好，是他們熱衷討論的問題，但對編程的一些基礎理論的卻很少重視，他們由於在3-4年的時間裡一直使用開發語言，對某種開發語言會比較精通，而且可以在短時間內生產大量的代碼，比如在一天之內編寫1-2千行的代碼對他們來說是很正常的事情，但代碼的品質如何就不好說了，出現這個問題的原因有時候大致有兩個，一個對代碼編程規範的瞭解，比如什麼是高內聚低偶合，如何提高代碼的複用等問題，作為一個開發人員如果不考慮這些問題，其代碼品質是不可能很高的，另外一個問題就是調研、設計品質對編碼品質的影響，我們開發的實際情況是開發人員往往是調研/設計/編碼一勺燴的，如果前邊的調研和設計問題多多，必然降低代碼的有效性和品質。最後說一個就是是否有快速掌握一種開發語言的能力對中級開發人員來說一個很重要的能力。如果你無法快速學習一種新的開發語言並使用它進行新系統的開發，你恐怕還不是好的中級開發人員。

     2設計能力，應該說設計能力是中級開發人員和初級開發人員的主要區別。但實際情況卻不容我們樂觀。我們的中級開發人員的設計能力現在對項目的制約，對自己的以後的發展都產生了很大的阻力，其中最主要的表現就是設計工作的不正規。有時候簡直如同兒戲。讓我們舉幾個例子吧。
     1不會使用正規的設計方法，在面向過程的設計不會畫流程圖和DFD圖，物件導向的設計方法不會使用UML，設計資料庫不知道3NF和BCNF等，最好使用的方法就是拍腦門來進行各種設計。
     2各種設計方法混用，一會兒使用面向過程的方法，一會兒使用物件導向的方法，還有就是將流程圖和系統結構圖結合起來一起用，總之最好的設計是一個四不象，如果你問他為什麼這麼做，他總會告訴你這樣畫清楚，其實這都是對基礎的設計方法掌握不好的表現。
     3 階層不清晰，單一層次複雜，中級開發人員一個衡量的標準就是是否可以獨立完成一項任務，這是初級人員和中級技術人員標誌性的差別，獨立處理問題，最主要的一個技能就是是否可以將複雜問題簡單化，而簡單化的最常用的方法就是將問題分不同的層次，簡化同一層次的複雜度，從流程圖的設計上來看，就是根據問題複雜度不同，分層次畫圖，而同一層次處理的模組不應該超過8項，這樣你可以很好的掌控你的程式。如果系統的確很複雜，可以不斷將處理模組細化下去，直到最低層的處理模組。
     4設計無法和代碼結合起來，無論是採用那種設計方法，好的設計都可以代碼對應起來，如果你做的設計報告很詳細，設計報告甚至可以和代碼逐行對應起來的，如果你不能做到這一點，只能說明你對系統的理解和設計是有問題的
     5 無法說明處理的詳細流程，所謂詳細流程是指是否可以說出來電腦在做一個事情的步驟，如果你的可以說出來電腦每一個處理步驟（最詳細的步驟可以細到變數的賦值），如果你真能說的出來，說明你對系統有了詳細的瞭解和考慮，一般來說你編寫的代碼出問題的可能性比較小。順便說一句，這也是概要設計和詳細設計的一個檢查方法。
     6不考慮系統出現異常的情況以及異常情況的處理，這裡有兩個問題，一個是你是否熟悉客戶的商業流程，以及處理方法，如果你不瞭解客戶的商業流程，你很難發現有那些異常情況以及這些異常的處理方式，而在實際情況這些異常情況總會出現，如果缺乏這些問題的考慮那你就準備不斷的修改你的代碼吧。
     7介面問題的考慮，以及設計是體現開發人員能力的一個方面， 
     在中級開發人員的思維中，總會出現用自己的想法替代使用者的實際需要，比如，他們總是說，我認為客戶應該是怎麼怎麼樣，或者說，客戶需要什麼什麼功能等，用一些模糊，不確定的語句描述系統是中級人員一個特徵，而這些模糊的語言是系統開發失敗的一個標誌。

     3 文檔編輯能力：作為中級開發人員，你是否在系統開發的時候可以不編碼而只用文檔就完成你的設計工作？我想很多人是做不到這一點的，在我們的實際開發環境中，似乎開發能力就是指代碼編寫，但實際上文檔的編寫能力才是最重要的，如何編寫文檔，如何讓自己編寫的文檔讓別人看得明白，如何讓自己編寫的文檔成為真正的有效文檔，這都是中級開發人員應該具備的基本素質，而文檔編寫的好壞一個體現了你的設計能力（沒有好的設計能力是不可能編寫出好的設計文檔的），另外一個是體現出了你的文字功底的，如果你只能做，而不會表達，你怎麼可能帶領一個團隊去完成一個複雜的項目。
    4調研能力：80%軟體項目的失敗是由於調研的問題，這個統計結果充分說明了調研能力在軟體開發中的重要地位，一般來說調研工作是應該由一個項目中最富有開發經驗的工作人員來完成，但可惜的是，在我們的實際開發中卻往往不是這個樣子。如何調研？調研那些內容？調研的步驟有那些？調研需要細緻到什麼程度？這些問題都應該是很明確的，否則你無法進行有效調研，我們的開發人員一般在調研系統的時候經常提交幾十頁的調研文檔，如果可以有一百多頁就認為很有成就了，這就是中級開發人員在調研中表現（如果能提供一百多頁的調研報告一定是不錯的中級開發人員了），實際上這種程度的調研報告很多地方是很模糊的，這種模糊的調研報告無法滿足實際開發的需要，而在開發過程中又很難進行補充調研，所以在設計和編碼階段會表現出很明顯的一些現象，比如開發人員在設計階段拍腦門決定功能或者在編碼的時候不斷髮生爭吵都是需求不完善的表現。

     5調試能力：工作3-4年的開發人員應該已經掌握的調試的基本方法，但他們面臨的問題是否可以掌握和別人聯調的能力，幾個人合作開發，介面問題，問題定位對中級開發的考驗都是比較大的，特別是穩定的確切的發生地點的定位的能力是體現中級開發人員的能力的標誌，另外就是你協助其他人進行調試的能力，對一個你瞭解不多的代碼中進行調試，發現問題發生的規律，對一個中級開發人員是很重要的，特別是調試那些不規範的代碼的時候，是中級開發人員經常要做的事情。

     6代碼閱讀能力，中級開發人員有一定的代碼閱讀能力，否則他無法和其他開發人員進行聯合開發和聯合調試，但中級代碼人員缺乏的是快速閱讀能力，和其他語言的閱讀能力（指那些未學習過的語言）。所以中級技術人員最怕開發平台的變化。
     說了這麼多。關於中級技術人員說一點自己的的看法。中級技術人員是一個承上啟下的階層，一方面他們要完成自己的工作，另外一個方面他們要完成技術的傳播，帶人門層級的工作通常是他們的正式或者非正式的任務之一，但令人遺憾的是：由於他們的技術水平的現在，往往讓新技術人員走更多的彎路。如何提高自身的技術水平，是他們面臨的最主要的問題。另外要格外強調的一點就是方法論（做事情的方法）的掌握往往比做具體事情更為重要，不過這一點是很多技術人員忽視的一個問題，這個缺陷造成了我們的技術人員總是在一個層次上低水平迴圈，而不是螺旋式上升。由於沒有掌握做事情的方法，中級技術人員總是有一點怕接受新的，自己不熟悉的東西。由於自己技術基礎不牢靠，會遇到多次技術生涯的失敗，失敗的開發經曆以及不知道失敗的原因，無法找到解決問題的有效方法，造成了大量中級實際人員離開技術崗位（別跟我說編碼只能做到30歲，我見過很多50。60歲的軟體開發人員）。而正式由於這一個層級的技術人員少而且技術水平不能符合開發的要求（包括技術上和其他方面）。使得我們的軟體開發流程很不規範，而這種不規範往往又會造成項目的失敗，從某種程度來說，中級技術人員的技術水平的提高和保證一定數量的合格的中級技術人員是保證項目成功、企業發展的重要因素。
    下邊說一下對中級技術人員的提高技術水平的一些個人的看法：
    1重視方法論
    中級人員和初級人員最大的區別就是中級開發人員應該掌握了一定的開發方法而不僅僅是某一個工具的使用，要做到知其然知其所以然。如果你沒有關注你的工作方法的改進，拿你只能是做一個低層次開發人員，不斷進行低水平迴圈，而這種低水平迴圈很容易讓你喪失對開發的興趣。比如無論是那種開發方法都存在對問題的抽象，如何抽象出問題的本質就很重要了，很多開發人員在討論的時候不會抽象，或者採用的抽象方法不對，成了空對空飛彈。在比如如何降低問題的難度，在你寫各種技術文檔以及代碼開發的時候是否能夠將問題分層次，好的層次劃分不但可以降低問題的難度，而且可以增加系統的靈活性，在系統需求發生變化的時候可以降低解決問題的難度，這些問題都是屬於方法論的問題，在說一個最簡單的問題，如何編寫文檔，如何不落下任何東西，如何保持文檔結構的清晰，如何讓自己的文檔不成為枯澀難懂的所謂的純技術文檔，如何檢查文檔這些都是有一些方法和竅門，你是否掌握了這些方法直接關係你的以後技術生涯的方法，的確是不能不重視的問題
    2注意交流，不要搞技術封鎖
    一招鮮吃遍天，這是中國的一句古話很有道理，精通一門技藝對我們這些開發人員的確很重要，但如果把這句話理解為對別人的技術封鎖就不對了。由於有二，第一現在的技術發展很快，在IT行業基本不存在會一種技術可以吃一輩子的情況，而網路發展使你的封鎖基本成為一個不可能。說一個我自己的技術人員的故事吧，2005年的時候，我招聘了一個測試人員，年底的時候我讓他學習QTP自動化測試技術。這個同志學習很認真，很快掌握了這個工具的使用，後來我讓他總結一下經驗寫一個總結，將自己在學習的時候遇到的問題做一個總結。奇怪的是他很長時間沒有寫出來（他平時的工作效率不是這樣的），後來在一次聊天的時候他才告訴我真實的原因，原來是他母親告訴他，如果這些東西都寫出來並且發表的網路上，怕對以後的有影響。知道這個事情後我很明確的告訴他，首先QTP這個東西是一個一時性的工具，而不是一世的工具。我工作15年來，開發平台經曆了DOS-WIN30-WINNT-WIN2003,原來在的開發工具和代碼現在已經不能使用了，所以根本沒有必要去保密。另外如果願意將自己的知識和其他人共用，你可以擴充自己的朋友圈，為自己的技術生涯創造更好的環境。後來他還是完成了QTP使用的總結，當時一共回答了80多個在使用QTP的時候會遇到的問題。這個電子文檔他發表在了www.51testing.com上的測試論壇。結果也不錯，首先引起了斑竹的注意，把他從初級戰友提升為進階戰友（我到現在還是初級戰友，哈哈）。其次有很多朋友問他問題，後來北京的一個朋友約他周六、周六去講課，500元/日。哈哈，效果好的讓人驚訝。所以作為中級技術人員，要各位注意和他人交流，不斷總結自己的經驗和別人共用，單純的技術封鎖無論對個人的發展還有是對項目團隊有沒有任何好處。  
    3他山之石可以攻玉
     要成為進階開發人員，有兩個方面的知識是必須具備的，一個是專業知識，包括對開發平台/工具的瞭解，對開發流程的理解和使用（軟體工程）。另外一個方面就是對客戶的商業流程的理解。如果只瞭解單純的開發知識很難成為好的進階技術人員。我們現在的應用系統都要和具體的應用相結合才可能成為一個真正實用的使用的系統。比如做辦公自動化系統你不瞭解國家機關的公文流轉的規矩，做ERP系統不瞭解財務系統、物流管理，做手機開發不瞭解通訊系統、使用者使用習慣都不能保證你的系統是符合使用者的真實的需求的，所以作為中級開發人員如果要向上發展成為進階技術人員除了對開發專業知識的瞭解，會需要對開發設計的行業知識，行業規範多瞭解，而這種瞭解一方面要通過各種行業檔案來瞭解，另外一個重要的方面通過和客戶交流去瞭解。
    4注意情商的培養
　　　作為中級開發人員，其交往的人群比初級開發人員的範圍要廣得很多，從大範圍來劃分，有客戶、公司管理員、技術人員等，而每一種類型人員都可以細分比如技術人員就有，進階技術人員，同層級技術人員（中級技術人員）。低級技術人員，由於不同角色的差異，交往的內容和方式都有很大的不同。即使同一類型的人群，由於每個人脾氣秉性的不同，交往的方式差異也很大，作為中級技術人員能否和其他合作者，處理好彼此關係，善用其他的力量，是起進一步發展的關鍵，而你的情商在這個時候往往比你的智商要重要的多。
　　總之，中級開發人員情況往往會決定一個單位和部門的發展，他們是公司發展最中堅的力量，是否會引導他們不斷進步是一個公司和部門領導要格外注意的問題。在我自己的開發經曆中，中層人員的流失不但是某一個公司或部門的問題，而是整個IT行業的問題，很多開發人員在沒有經過訓練就不得不承擔中級開發人員要承擔的工作，由於綜合能力的問題，等待他們的往往是一個又一個的失敗，而在看到很多做銷售的同齡人，無論在收入和地位和自己的差別後，紛紛轉行，這又進一步造成了中級技術人員的流失。中級技術人員整體素質和人員的流失才是中國IT人員真正的痛

對軟體開發人員的幾個階段思考和總結