1：團隊精神和協作能力2：文件習慣3：規範化，標準化的程式碼編寫習慣fans叫囂高水平程式設計師寫的程式碼旁人從來看不懂，這種叫囂只能證明他們自己壓根不配自稱程式設計師。程式碼具有良好的可讀性，是程式設計師基本的素質需求。再看看整個linux的搭建，沒有規範化和標準化的程式碼習慣，全球的研發協作是絕對不可想象的。4：需求理解能力 程式設計師需要理解一個模組的需求，很多小朋友寫程式往往只關注一個功能需求，他們把效能指標全部歸結到硬體，作業系統和開發環境上，而忽視了本身程式碼的效能考慮，有人曾經放言說寫一個廣 告交換程式很簡單，這種人從來不知道在百萬甚至千萬數量級的訪問情況下的效能指標是如何實現的，對於這樣的程 序員，你給他深藍那套系統，他也做不出太極鏈的並訪能力。效能需求指標中，穩定性，並訪支撐能力以及安全性都很重要，作為程式設計師需要評估該模組在系統運營中所處的環境，將要受到的負荷壓力以及各種潛在的危險和惡意攻擊的可能性。就這一點，一個成熟的程式設計師至少需要2到3年的專案研發和跟蹤經驗才有可能有心得。5：複用性，模組化思維能力複用性設計，模組化思維就是要程式設計師在完成任何一個功能模組或函式的時候，要多想一些，不要侷限在完成當前任務的簡單思路上，想想看該模組是否可以脫離這個系統存在，是否可以透過簡單的修改引數的方式在其他系統和應用環境下直接引用，這樣就能極大避免重複性的開發工作，如果一個軟體研發單位和工作組能夠在每一次研發過程中都考慮到這些問題，那麼程式設計師就不會在重複性的工作中耽誤太多時間，就會有更多時間和精力投入到創新的程式碼工作中去。一些好的程式模組程式碼，即便是70年代寫成的，拿到現在放到一些系統裡面作為功能模組都能適合的很好，而現在我看到的是，很多小公司軟體一升級或改進就動輒全部程式碼重寫，大部分重複性工作無謂的浪費了時間和精力。6：測試習慣測試工作實際上需要考慮兩方面，一方面是正常呼叫的測試，也就是看程式是否能在正常呼叫下完成基本功能，這是最基本的測試職責，可惜在很多公司這成了唯一的測試任務，實際上還差的遠那；第二方面就是異常呼叫的測試，比如高壓力負荷下的穩定性測試，使用者潛在的異常輸入情況下的測試，整體系統區域性故障情況下該模組受影響狀況的測試，頻發的異常請求阻塞資源時的模組穩定測試等等。當然並不是程式設計師要對自己的每段程式碼都需要進行這種完整測試，但是程式設計師必須清醒認識自己的程式碼任務在整體專案中的地位和各種效能需求，有針對性的進行相關測試並儘早發現和解決問題，當然這需要上面提到需求理解能力。7：學習和總結的能力程式設計師是人才很容易被淘汰，很容易落伍的職業，因為一種技術可能僅僅在三兩年內具有領先性，程式設計師如果想安身立命，就必須不斷跟進新的技術，學習新的技能。善於學習，對於任何職業而言，都是前進所必需的動力，對於程式設計師，這種要求就更加高了。但是學習也要找對目標，一些小coding有些codingTO就是這樣的coding上只是一些Cfans們，他們也津津樂道於他們的學習能力，一會學會了asp，一會兒學會了php，一會兒學會了jsp，他們把這個作為炫耀的資本，盲目的追逐一些膚淺的，表面的東西和名詞，做網路程式不懂通訊傳輸協議，做應用程式不懂中斷向量處理，這樣的技術人員，不管掌握了多少所謂的新語言，永遠不會有質的提高。善於總結，也是學習能力的一種體現，每次完成一個研發任務，完成一段程式碼，都應當有目的的跟蹤該程式的應用狀況和使用者反饋，隨時總結，找到自己的不足，這樣逐步提高，一個程式設計師才可能成長起來。一個不具備成長性的程式設計師，即便眼前看是個高手，建議也不要選用，因為他落伍的時候馬上就到了。
1：團隊精神和協作能力2：文件習慣3：規範化，標準化的程式碼編寫習慣fans叫囂高水平程式設計師寫的程式碼旁人從來看不懂，這種叫囂只能證明他們自己壓根不配自稱程式設計師。程式碼具有良好的可讀性，是程式設計師基本的素質需求。再看看整個linux的搭建，沒有規範化和標準化的程式碼習慣，全球的研發協作是絕對不可想象的。4：需求理解能力 程式設計師需要理解一個模組的需求，很多小朋友寫程式往往只關注一個功能需求，他們把效能指標全部歸結到硬體，作業系統和開發環境上，而忽視了本身程式碼的效能考慮，有人曾經放言說寫一個廣 告交換程式很簡單，這種人從來不知道在百萬甚至千萬數量級的訪問情況下的效能指標是如何實現的，對於這樣的程 序員，你給他深藍那套系統，他也做不出太極鏈的並訪能力。效能需求指標中，穩定性，並訪支撐能力以及安全性都很重要，作為程式設計師需要評估該模組在系統運營中所處的環境，將要受到的負荷壓力以及各種潛在的危險和惡意攻擊的可能性。就這一點，一個成熟的程式設計師至少需要2到3年的專案研發和跟蹤經驗才有可能有心得。5：複用性，模組化思維能力複用性設計，模組化思維就是要程式設計師在完成任何一個功能模組或函式的時候，要多想一些，不要侷限在完成當前任務的簡單思路上，想想看該模組是否可以脫離這個系統存在，是否可以透過簡單的修改引數的方式在其他系統和應用環境下直接引用，這樣就能極大避免重複性的開發工作，如果一個軟體研發單位和工作組能夠在每一次研發過程中都考慮到這些問題，那麼程式設計師就不會在重複性的工作中耽誤太多時間，就會有更多時間和精力投入到創新的程式碼工作中去。一些好的程式模組程式碼，即便是70年代寫成的，拿到現在放到一些系統裡面作為功能模組都能適合的很好，而現在我看到的是，很多小公司軟體一升級或改進就動輒全部程式碼重寫，大部分重複性工作無謂的浪費了時間和精力。6：測試習慣測試工作實際上需要考慮兩方面，一方面是正常呼叫的測試，也就是看程式是否能在正常呼叫下完成基本功能，這是最基本的測試職責，可惜在很多公司這成了唯一的測試任務，實際上還差的遠那；第二方面就是異常呼叫的測試，比如高壓力負荷下的穩定性測試，使用者潛在的異常輸入情況下的測試，整體系統區域性故障情況下該模組受影響狀況的測試，頻發的異常請求阻塞資源時的模組穩定測試等等。當然並不是程式設計師要對自己的每段程式碼都需要進行這種完整測試，但是程式設計師必須清醒認識自己的程式碼任務在整體專案中的地位和各種效能需求，有針對性的進行相關測試並儘早發現和解決問題，當然這需要上面提到需求理解能力。7：學習和總結的能力程式設計師是人才很容易被淘汰，很容易落伍的職業，因為一種技術可能僅僅在三兩年內具有領先性，程式設計師如果想安身立命，就必須不斷跟進新的技術，學習新的技能。善於學習，對於任何職業而言，都是前進所必需的動力，對於程式設計師，這種要求就更加高了。但是學習也要找對目標，一些小coding有些codingTO就是這樣的coding上只是一些Cfans們，他們也津津樂道於他們的學習能力，一會學會了asp，一會兒學會了php，一會兒學會了jsp，他們把這個作為炫耀的資本，盲目的追逐一些膚淺的，表面的東西和名詞，做網路程式不懂通訊傳輸協議，做應用程式不懂中斷向量處理，這樣的技術人員，不管掌握了多少所謂的新語言，永遠不會有質的提高。善於總結，也是學習能力的一種體現，每次完成一個研發任務，完成一段程式碼，都應當有目的的跟蹤該程式的應用狀況和使用者反饋，隨時總結，找到自己的不足，這樣逐步提高，一個程式設計師才可能成長起來。一個不具備成長性的程式設計師，即便眼前看是個高手，建議也不要選用，因為他落伍的時候馬上就到了。