1:團隊精神和協作能力
這是程式員應該具備的最基本的,也是最重要的安身立命之本。即使成為了高水平程式員,也不表示以後要以獨行俠的姿態來工作。那些遍布全球的為Linux寫核心的高手們,沒有協作精神,這樣的合作簡直是不可想象的。一旦進入某些大系統的研發團隊,進入商業化和產品化的開發工作單位,缺乏這種團隊精神和合作素質的獨行俠們就完全不合格了。
2:文檔習慣
良好的文檔是正規研發流程中非常重要的環節。作為代碼程式員,30%的工作時間寫技術文檔是很正常的,而作為進階程式員和系統分析員,這個比例還要高很多。缺乏文檔,一個軟體系統就缺乏生命力,在未來的查錯、升級以及模組的複用時就都會遇到極大的麻煩。
3:正常化,標準化的代碼編寫習慣
作為一些外國知名軟體公司的規矩,代碼的變數命名,代碼內注釋格式,甚至嵌套中行縮排的長度和函數間的空行數字都有明確的規定。良好的編寫習慣,不但有助於代碼的移植和錯誤修正,也有助於不同技術人員之間的協作。代碼具有良好的可讀性,這是程式員基本的素質需求。
4:需求理解能力
程式員需要理解一個模組的需求,很多人寫程式往往只關注一個功能需求,他們把效能指標全部歸結到硬體、作業系統和開發環境上,而忽視了對本身代碼的效能考慮。事實上,在效能需求的各項指標中,穩定性、並訪支撐能力以及安全性都很重要。作為程式員,我們需要評估該模組在系統運營中所處的環境,將要受到的負荷壓力,以及各種潛在的危險和被惡意攻擊的可能性。就這一點,一個成熟的程式員至少需要2到3年的項目研發和跟蹤經驗才會有更深刻的心得體會。
5:複用性,模組化思維能力
複用性設計和模組化思維就是要求程式員在完成任何一個功能模組或函數的時候,要多想一些,不要局限在完成當前任務的簡單思路上,而是應該想想,該模組是否可以脫離這個系統存在,是否可以通過簡單的修改參數的方式在其他系統和應用環境下直接引用,這樣就能避免某些重複性的開發工作。如果一個軟體研發單位和工作群組能夠在每一次研發過程中都考慮到這些問題,那麼程式員就不會在重複性的工作中耽誤太多時間,就會有更多時間和精力投入到創新的代碼工作中去。
6:測試習慣
作為一些商業化、正規化的開發而言,專職的測試工程師是不可少的,但是並不是說有了專職的測試工程師,程式員們就可以不進行自測;軟體研發作為一項工程而言,一個很重要的特點就是問題發現得越早,解決的代價就越低。程式員在每段代碼、每個子模組完成後進行認真的測試,就可以盡量將一些潛在的問題儘早地發現和解決,這樣,整體系統建設的效率和可靠性就有了最大的保證。
測試工作實際上需要考慮兩方面:一方面是正常調用的測試,也就是看程式是否能在正常調用下完成準系統,這是最基本的測試職責;第二方面就是異常調用的測試,比如高壓力負荷下的穩定性測試,使用者潛在的異常輸入情況下的測試,整體系統局部故障情況下該模組受影響狀況的測試,頻發的異常請求阻塞資源時的模組穩定測試,等等。當然,程式員也不需要對自己的每段代碼都進行這種完整的測試,但程式員必須清醒認識自己的代碼任務在整體項目中的地位和各種效能需求,有針對性地進行相關測試,並儘早發現和解決問題。
7:學習和總結的能力
善於學習,對於任何職業而言,這都是前進所必需的動力,對於程式員,這種要求就更高了。善於總結,也是學習能力的一種體現,每次完成一個研發任務,完成一段代碼,都應當有目的地跟蹤該程式的應用狀況和使用者反饋,隨時總結,找到自己的不足。這樣逐步提高,一個程式員才可能成長起來。
具備以上全部素質的人,應當說是夠格的程式員了。請注意,以上的各種素質都不是僅僅由IQ決定的,也不是從大學課本裡就可以學習到的,需要的是程式員對自己工作的認識,是一種意識上的領悟問題。
那麼,作為進階程式員,以至於系統分析員,也就是對於一個程式項目的設計者而言,除了應該具備上述全部素質之外,還需要具備以下素質:
第一,需求分析能力
對於程式員而言,理解需求就可以完成合格的代碼。但對於研發項目的組織和管理者,他們不但要理解客戶需求,更多時候還要自行制定一些需求,為什麼這麼說呢?
一般而言,進行研發任務,或者是客戶提出需求,或者是市場和營銷部門提出需求。這時候,對於研發部門,他們看到的不是一個完整的需求,而僅僅是一些功能上的要求,或者更正規些,可能獲得一個完整的使用者視圖。但這些都不夠,因為客戶一般非技術因素多一些,可能很難提出完整和清晰的、專業性的效能需求,但是對於項目召集人和規劃者,他必須能夠清醒認識到這些需求的存在,並在完成需求分析報告的時候適當提出,同時要完整和清晰地體現在設計說明書裡面,以便於程式員編碼時不會失去這些準則。程式設計者必須正確理解使用者需求所處的環境,並針對性地做出需求的分析。
第二,項目設計方法和流程處理能力
程式設計者必須能夠掌握不少於兩到三種的項目設計方法(比如自頂至下的設計方法、快速原型法等等),並能夠根據項目需求和資源搭配,選擇合適的設計方法,進行項目的整體設計。設計方法上選擇不當,就會耽誤研發周期,浪費研發資源,甚至影響研發效果。
一個程式設計者還需要把很多功夫用在流程圖的設計和處理上,他需要做資料流圖以確立資料詞典;他需要加工邏輯流圖以形成整體的系統處理流程。一個流程有問題的系統,無論代碼多漂亮,每個模組多精緻,也不會成為一個好的系統。當然,做好流程分析並選擇好項目設計方法,都需要在需求分析能力上具有足夠的把握。
第三,複用設計和模組化分解能力
作為一個從事模組任務的程式員,他需要對他所面對的特定功能模組的複用性進行考慮;而作為一個系統分析人員,他要面對的問題複雜得多,需要對整體系統按照一種模組化的分析能力分解為很多可複用的功能模組和函數,並針對每一模組形成一個獨立的設計需求。一個成熟的軟體行業,在一些相關項目和系統中,不同的組件是可以隨意換裝的,比如微軟的許多案頭軟體,在很多操作模組(如開啟檔案、儲存檔案)都複用了同一套功能模組,而這些介面又通過一些類庫提供給了傳統型應用程式開發人員,方便掛接。這就是複用化的模組設計明顯的一個佐證.
將一個大型的、錯綜複雜的應用系統分解成一些相對獨立的、具有高度複用性的、並能僅依靠幾個參數完成資料聯絡的模組組合,是作為進階程式員和系統分析員一項最重要的工作。合適的項目設計方法,清晰的流程圖,是實現這一目標的重要保證。
第四,整體項目評估能力
作為系統設計人員,必須能夠從全域出發,對項目具有整體的、清醒的認識,如公司的資源配置是否合理到位,比如工程進度安排是否能最大化體現效率又不至於無法按期完成。評估項目整體和各個模組的工作量,評估項目所需的資源,評估項目可能遇到的困難,都需要大量的經驗積累。換言之,這是一種不斷總結的累計才能達到的境界。在西方一些軟體系統設計的帶頭人都是很年長的,比如四、五十歲,甚至更老,他們在編碼方面已經遠遠不如年輕人那樣活絡,但就項目評估而言,他們幾十年的經驗積累就是最重要和最寶貴的財富。
第五,團隊組織管理能力
完成一個項目工程,需要團隊的齊心協力。作為項目設計者或研發主管人,就應當有能力最大化地發揮團隊的整體力量。技術管理由於其專業性質,不同於一般的人事管理,因為這裡涉及了一些技術性的指標和因素。
首先是工作的量化,沒有量化就很難做到合適的績效考核,而程式量化又不是簡單的程式碼數可以計算的,因此要求技術管理員需要能真正評估一個模組的複雜性和工作量。其次是對團隊協作模式的調整。根據程式員之間的能力水平差距,以及根據項目研發的需求,選擇合適的組隊方式,並能將責權和成員的工作任務緊密結合,這樣才能最大發揮組隊的效率。
那麼,一個軟體項目研發的設計流程是怎樣的呢?
第一個步驟是市場調研。技術和市場結合,才能體現最大價值。
第二個步驟是需求分析。這個階段需要出三樣東西:使用者視圖,資料詞典和使用者操作手冊。使用者視圖是該軟體使用者(包括終端使用者和系統管理使用者)所能看到的頁面樣式,這裡麵包含了很多操作方面的流程和條件。資料詞典是指明資料邏輯關係並加以整理的材料,完成了資料詞典,資料庫的設計就完成了很大一部分。使用者操作手冊是指明了操作流程的說明書。請注意,使用者操作流程和使用者視圖是由需求決定的,因此應該在軟體設計之前完成;完成了這些,就為程式研發提供了約束和準繩。
第三個步驟是概要設計。將系統功能模組初步劃分,並給出合理的研發流程和資源要求。作為快速原型設計方法,完成概要設計就可以進入編碼階段了。快速原型法在完成原型代碼後,根據評測結果和經驗教訓的總結,還要重新進行詳細設計的步驟。
第四個步驟是詳細設計。這是考驗技術專家設計思維的重要關卡,詳細設計說明書應當把具體的模組以最“乾淨”的方式(黑箱結構)提供給編碼者,使系統整體模組化達到最大;一份好的詳細設計說明書,可以使編碼的複雜性減低到最低
第五個步驟是編碼。在正常化的研發流程中,設計過程完成的好,編碼效率就會極大提高,編碼時不同模組之間的進度協調和協作是最需要小心的,也許一個小模組的問題就可能影響了整體進度,讓很多程式員因此被迫停下工作等待。因此,編碼時的相互溝通和應急的解決手段都是相當重要的。
第六個步驟是測試。測試有很多種:按照測試執行方,可以分為自我裝載和正式發行前小眾測試;按照測試範圍,可以分為模組測試和整體聯調;按照測試條件,可以分為正常操作情況測試和異常情況測試;按照測試的輸入範圍,可以分為全覆蓋測試和抽樣測試。完成測試後,完成驗收並完成最後的一些協助文檔,整體項目才算告一段落。