成為壹個真正合格的程序員，或者說，能夠完成壹件真正合格的事情。
做代碼的程序員應該具備的素質。
1:團隊精神和合作能力
把它當成壹個基本素質並不是不重要，相反，它是程序員應該具備的最基本的東西。
也是安身立命最重要的基礎。凡是把高水平程序員叫做獨行俠的都是在胡說八道，任何個人的權力。
數量有限，即使是萊納斯這樣的天才也需要通過。
組建強大團隊，創造奇跡。那些全世界為linux寫核心的高手，壹點合作精神都沒有。
難以想象。獨行俠可以做壹些小軟件賺點小錢，但是壹旦進入壹些大系統的研究，
開發壹個團隊，進入商業化和產品化的任務，缺乏
這種素質的人完全不合格。
2.記錄習慣
那些說高級程序員從不寫文檔的人，壹定是乳臭未幹。好的文檔是正式的研發。
過程中很重要的壹個環節，作為代碼程序員，30%的工作時間寫技術文檔是很正常的，而
作為壹個資深程序員和系統分析師，這個比例要高得多。缺乏
沒有文檔，壹個軟件系統就會缺乏生命力，這在以後的錯誤檢測、升級和模塊重用中都會遇到。
很麻煩。
3.標準化和規範化的代碼編寫習慣
像國外壹些知名軟件公司的規則，代碼的變量命名，代碼中註釋的格式，甚至嵌套。
行縮進的長度和函數之間的空行數量都有明確的定義。好的寫作習慣不僅僅是對代碼有幫助。
移植和糾錯也有助於不同技術人員之間的配合。迷
s叫囂高級程序員寫的代碼別人永遠看不懂。這種叫囂只能證明他們根本不配自稱。
程序員。代碼可讀性好，這是程序員的基本素質要求。看看整個linux結構，
沒有標準化和規範化的代碼習慣，全球研發
合作是絕對不可想象的。
4.理解需求的能力
程序員需要理解壹個模塊的需求。很多孩子在寫程序的時候往往只關註壹個功能需求。
科學家把所有的性能指標都歸結於硬件、操作系統和開發環境，而忽略了自己代碼的性能考慮。
有人曾經誇口說，寫壹個廣告交換程序非常簡單。這種人來自哪裏
不知道在幾百萬甚至幾千萬的訪問量的情況下，性能指數是怎麽做到的。對於這樣的過程，
音序器，妳給他深藍系統，他也做不到太極鏈的並行訪問能力。在性能要求中，穩定性
，並行訪問支持能力和安全性非常重要，作為壹個程序員需要
評估系統運行中的環境、負載壓力以及模塊的各種潛在危險和惡意。
襲擊的可能性。此時，壹個成熟的程序員至少需要2到3年的項目開發和跟蹤經驗。
有可能學到東西。
5.可重用性，模塊化思維能力
經常能聽到壹些程序員抱怨自己寫了幾年程序，成了熟練工，每天都是。
重復寫壹些沒有任何新意的代碼，其實是對中國軟件人才最大的浪費，帶有壹定的重復性。
工作已經成為熟練程序員的主要工作，這些其實是完全可能的。
為了避免它。
可復用設計，模塊化思維就是要求程序員完成任何功能模塊或功能。
多思考，不要局限於完成當前任務這種簡單的想法，想想模塊能不能脫離這個部門。
系統存在，是否可以通過簡單修改參數在其他系統和應用環境中直接引用，這樣
如果壹個軟件研發單位和工作組每次都能開發出來，那麽重復的開發工作是可以大大避免的。
這些問題在過程中都考慮到了，所以程序員不會在重復性的工作中耽誤太多時間，會有更多
花更多的時間和精力在創新的代碼工作上。
壹些好的程序模塊代碼，甚至是70年代寫的，現在作為作品放入壹些系統。
所有的功能模塊都很契合，但是我現在看到的是很多小公司總是在升級或者改進自己的軟件。
代碼重寫，大部分重復性的工作都是不必要的浪費時間和精力。
6.測試習慣
隨著壹些商業化和標準化的發展，專職測試工程師是不可或缺的，但這並不意味著
有了全職測試工程師，程序員可以停止自測；軟件研發作為壹個項目，壹個非常
重要的特點是發現問題越早，解決問題的成本越低，程序越多。
成員們在每壹段代碼、每個子模塊完成後都進行了認真的測試，可以盡量把壹些潛在的問題放在早期。
系統的發現和解決將保證整個系統建設的效率和可靠性。
其實測試需要考慮兩個方面。壹方面是正常調用的測試，就是看程序能不能
正常通話下完成基本功能是最基本的測試職責，但在很多公司是唯壹的測試。
嘗試任務其實差遠了；第二個方面是異常調用的測試，比如高壓負載下的穩定性。
性測試，測試在潛在異常用戶輸入的情況下，以及模塊受到影響的情況下整個系統的局部故障。
條件測試，頻繁異常請求阻塞資源時的模塊穩定性測試等等。當然，這並不是說程序員必須正確看待自己
每壹段代碼都需要完全測試，但是程序員必須清楚自己的代碼任務。
體項目中的狀態和各項性能要求，有針對性地開展相關試驗並盡快發現和解決問題，當
但是，這需要理解上面提到的需求的能力。
7.學習和總結的能力
程序員是人才很容易被淘汰和掉隊的職業，因為壹項技術可能只會持續三兩年。
有了裏面的領先地位，程序員要想安身立命，就必須跟上新技術，學習新技能。
善於學習，對於任何職業來說，都是進步的必要動力。對於程序員來說，這個要求是
甚至更高。但是學習也需要找準目標，壹些小編碼和壹些codingTO就是這樣。
就是壹些Cfans，也說說自己的學習能力。他們學了壹會asp，壹會ph。
p，過了壹段時間，學了jsp，他們就把它當成了炫耀的資本，壹味的追逐壹些表面的、膚淺的東西。
西和名詞，不知道作為網絡程序的通信傳輸協議，也不知道作為應用程序的中斷向量處理。
人員無論掌握了多少所謂的新語言，都永遠不會有質的提高。
善於總結也是學習能力的壹種表現。每次妳完成壹個研發任務，完成壹段代碼，妳總是
要有目的的跟蹤程序的應用狀態和用戶反饋，隨時總結，發現自己的不足，做到壹個壹個。
壹步壹步，壹個程序員才能成長。
壹個沒有成長的程序員，即使目前是高手，也建議不要選擇，因為他落伍了。
差不多是時候了。具備以上所有素質的人都應該是合格的程序員。請註意以上。
各種素質不是智商決定的，也不是壹些大學課本上能學到的。所需要的只是程序。
員工對自己工作的理解是壹個意識問題。
所以作為壹個高級程序員，甚至是系統分析師，也就是對於壹個程序項目的設計者來說。
，除了上述所有素質外，妳還需要具備以下素質:
第壹，需求分析的能力。
對於程序員來說，理解需求可以完成合格的代碼，但是對於R&D項目的組織和管理來說
管理者，他們不僅要了解客戶需求，更要經常提出自己的需求。為什麽這麽說？
壹般來說，R&D的任務可能由客戶提出，也可能由營銷部門提出。
嗯，在這個時候，對於R&D部門來說，他們看到的並不是壹個完整的需求。壹般來說，需求只是
壹些功能需求，或者更正式的，可能會得到完整的用戶視圖；但是這還不夠，因為
對於客戶來說，由於更多的非技術因素，他們可能很難提出完整明確的，或者專業的性能要求。
可以，但是對於項目的組織者和策劃人來說，他必須能夠清楚地了解這些需求的存在，並完成這些需求。
在尋求分析報告時，應適當提出，同時應充分明確地反映在設計規範中，以便於過程。
當序列發生器編碼時，這些標準不會丟失。
程序員必須正確理解用戶需求所在的環境，並做出有針對性的需求分析，例如
換句話說，通過ASP出租和許可發布的相同軟件的性能需求可能是存在的。
不同的是，前者強調更好的支持能力和穩定性，而後者可能更強調各種平臺。
安裝和使用的通用性和簡單性。
二、項目設計方法和流程處理能力。
程序員必須能夠掌握至少兩到三種項目設計方法(如自頂向下設計)
方法，如快速原型法等。)，並能根據項目需求和資源配置選擇合適的設計方法。
行項目的總體設計。設計方法選擇不當會延緩R&D循環，浪費R&D資源，甚至影響。
良好的研發效果。
壹個程序員還需要花很多時間在流程圖的設計和處理上，他需要做數據流程圖。
建立數據字典；他需要處理邏輯流程圖以形成整個系統處理流程。流程有問題
系統，再漂亮的代碼，再精致的每個模塊，都不會成為壹個好的系統。當然，做好流程。
分析和選擇壹個好的項目設計方法，需要很好的掌握需求分析的能力。
第三，復用設計和模塊分解能力。
這似乎又是老壹套了。基本素質不是已經說明這個問題了嗎？作為奴隸
作為壹個模塊任務的程序員，他需要考慮他所面對的特定功能模塊的可重用性，並且作為壹個
壹個系統分析師，他要面對的問題要復雜得多，需要用模塊化的方式對整個系統進行分析。
力被分解成許多可重用的功能模塊和功能，每個模塊形成壹個獨立的設計需求。上升
舉個例子，比如汽車生產，最早的時候，每輛車都是獨立安裝的，每個部件都是量身定做的。
但是後來就不壹樣了，機器量產了。壹家汽車廠開始通過裝配線、獨立部門生產汽車。
零件開始有壹定的復用性，後來標準化成為大趨勢，不同型號，不同品牌，甚至不同廠家。
汽車零部件也可以很容易地更換和升級，此時，汽車生產的效率最大化。
軟件工程也是如此。壹個成熟的軟件行業在壹些相關的項目和系統上是不壹樣的。
組件可以隨意更換，比如微軟的很多桌面軟件，在很多操作模塊(比如打開文件，
保存文件等。)是復用的同壹套功能模塊，這些接口
通過壹些類庫，方便桌面應用開發者掛接，在復用模塊設計上體現的很明顯。
壹個佐證。
將壹個龐大而復雜的應用系統分解成壹些相對獨立且高度可重用的應用系統。
而且只能依靠幾個參數來完成數據連接的模塊組合，這是高級程序員和系統分析師。
最重要的工作，合適的項目設計方法和清晰的流程圖是實現這壹目標的重要保證。
四、項目整體評價能力
作為壹個系統設計師，妳必須能夠從大局出發，對項目整體有壹個清晰的認識，比如公司的。
資源配置是否合理、到位，如項目進度是否能發揮最大效率，不達進度要求。
完成了。評估整個項目和各個模塊的工作量，評估項目需要的資源，評估項目可能遇到的問題。
困難需要大量的經驗積累，換句話說，這是壹個不斷總結積累才能達到的境界。存在
壹些西方的軟件系統設計負責人年齡很大，比如4、50歲，甚至更老，他們在編碼方面。
表面遠不如年輕人活躍，但就項目評估而言，他們幾十年的經驗積累是最多的
重要而寶貴的財富。中國缺少這樣壹代程序員，主要不是缺少那個年代的程序員，而是
各個年齡段的程序員基本都是研究所出來的，不是專業產品軟件研發出來的。
是的，他們沒有積累產品研發的經驗，也無能為力。
第五，團隊組織管理能力。
要完成壹個項目，團隊的齊新需要齊心協力。作為R&D的項目設計者或主管，他應該
當妳有能力將團隊的整體力量發揮到最大化的時候，技術管理因為其職業性質而不同於普通人員。
管理，因為有壹些技術指標和因素設計。
首先是工作的量化。沒有量化，就很難實現合適的績效考核，程序的量化也不簡單。
代碼的行數是可以計算的，因此技術經理需要能夠真正評估壹個模塊的復雜性和工作。
測量。
其次，團隊合作模式的調整。壹般來說，程序開發的合作通常分為小團體。
團體有主要的程序員方式，也有民主的方式，根據程序員之間的能力水平差距，以及根據項。
目的適應研發需要，選擇合適的團隊建設方式，將成員的責任和權利結合起來。
工作和任務緊密結合，從而最大化團隊建設的效率。
壹個代碼水平很高的人，未必是壹個合格的項目研發主管，這方面的能力是欠缺的。
過去很容易被忽略。
綜上所述，我們可以看到，作為壹個R&D的負責人和項目設計師，需要具備什麽樣的素質。
而且能力不是寫程序代碼的能力，當然壹般來說，壹個程序員是通過不斷的總結來提高的。
當他達到這個素質的時候，他寫代碼的能力已經相當簡單了，但是請註意這壹點。
裏面的因果關系，壹個高水平的項目設計師通常是壹個非常優秀的代碼編寫人員，但是
不是壹個代碼優秀的程序員就能勝任項目設計的，這裏面沒有智慧可言。
業務和教材的問題，是壹個程序員在積累經驗，逐漸提高的時候，沒有意識到自己應該思考。
測試什麽樣的東西，對項目的組織和復用設計沒有自覺的思考，也沒有壹個常規的文檔。
習慣和總結習慣，不改變這些，我們合格的項目設計師還是很稀缺的。
另外，為了防止無聊的人跟我較真，我補充壹點，本文針對的是商業化的軟件項。
項目和工程，科研機構的那些程序員，比如算法專家，比如圖像處理專家，他們的工作。
它是壹個研究課題而不是直接完成商業軟件(當然最終會間接成為壹個業務
產品，比如微軟研究院正在做的研究項目)，所以他們強調的質量可能是別的東西，這
有些人(專家)不能說是程序員，不能用程序員的標準來衡量。
最後，壹個軟件項目研發的設計流程是怎樣的？在通常的標準設計中
方法，比如，(但是我喜歡快速原型)。
第壹步是市場調研，技術和市場要結合起來才能體現最大的價值。
第二步是需求分析，需要三樣東西，用戶視圖，數據字典，用戶操作。
做壹個手冊。用戶視圖是軟件用戶(包括最終用戶和管理用戶)可以看到的頁面樣式，它
它包含許多操作流程和條件。數據字典是指出數據的邏輯關系並對其進行排列的東方。
董，當數據字典完成後，數據庫的設計也就完成了壹大半。用戶操作手冊說明了操作過程。
說明。請註意，用戶操作流程和用戶視圖是由需求決定的，所以應該在軟件設計中。
這些任務的完成為程序開發提供了約束和標準。不幸的是，太多的公司沒有這樣做。
因果顛倒，順序不分。所以開發工作和實際需求往往是割裂的。
需求分析，除了以上的工作，筆者認為作為壹個項目設計人員，應該完整的做出項目的性能需求。
請示，因為往往性能需求只有懂技術的人才懂，需要技術專家和需求者。
(客戶或公司市場部)能有真正的溝通和了解。
第三步是概要設計，初步劃分系統的功能模塊，給出合理的R&D流程和資源。
要求。作為壹種快速原型設計方法，完成概要設計後可以進入編碼階段，通常采用。
方法是因為所涉及的R&D任務屬於壹個新的領域，技術總監不可能壹上來就給出壹個清晰詳細的設計理論。
明書，但不代表詳細的設計規範不重要。事實上，完成原型代碼後，快速原型方法就紮根了。
根據評估結果和經驗教訓，應再次執行詳細的設計步驟。
第四步是詳細設計，這是考驗技術專家設計思維的重要關卡，詳細的設計說明。
具體的模塊要以最幹凈的方式(黑盒結構)提供給編碼者，這樣整個系統才能模塊化。
達到最大值；壹個好的詳細的設計規範，可以把編碼的復雜度降到最低，其實是嚴格的。
詳細的設計規範應根據需求詳細提供每個功能的每個參數的定義
從分析到概要設計，再到完成詳細設計說明書，壹個軟件項目應該是完成了壹半。換句話說
壹個大型軟件系統在完成壹半的時候，實際上還沒有開始壹行代碼工作。那些把它當軟蛋的人
壹個把它簡單理解為寫代碼的程序員，從根源上就犯了壹個錯誤。
第五步是編碼。在標準化的R&D過程中，編碼在整個項目過程中不會是最多的。
如果超過1/2，通常在1/3，所謂的銳化不漏柴工，設計過程完成的好編碼效率也會提高。
大大提高，不同模塊之間的進度協調和配合是編碼時最需要小心的，也許是壹個小模塊。
問題可能會影響整體進度，以至於很多程序員被迫停止工作等待，這是很多研究中的問題。
它已經出現在頭發的過程中。編碼過程中的相互溝通和應急方案對程序員來說非常重要。
壹般來說，bug會壹直存在，妳必須壹直面對這個問題。大名鼎鼎的微軟有沒有連續三個月不在的時候？
補丁什麽時候發？絕不！
第六步是測試。
測試有很多種:根據測試執行者，可以分為內部測試和外部測試；根據測試範圍，
可分為模塊測試和整體調試；根據試紙，可分為正常運行測試和異常工況測試。
測試；根據測試的輸入範圍，可以分為全覆蓋測試和抽樣測試。以上很好理解，不再贅述。
解釋壹下。
總之，測試也是項目開發中非常重要的壹步。壹個大型軟件，需要3個月才能1。
08年的外部測試很正常，因為總會有不可預知的問題。
在測試、驗收和壹些最終的幫助文檔完成之後，整個項目當然就告壹段落了。
以後還會有升級、維修等工作。只要不想壹錘子買賣騙錢，就要壹直跟蹤軟件。
軟件的運行狀況並繼續修復和升級，直到該軟件被徹底淘汰為
停下來。
寫這些步驟也沒什麽好炫耀的，因為說實話我手頭有本書《軟件工程》，是大學時候的。
這是計算機專業的必修課，但我知道很多程序員似乎總是熱衷於“精華30天”
Pass VC之類的，有的和我壹樣是遊擊隊，沒正式學過這個專業，有的是早期的。
混夠學分後，我把這些真正有用的東西還給老師。
粉絲大呼小叫，混淆視聽。其實真正的技術高手很少會在網上發帖，比如作者。
種壹點點，其實也不是高手，只是不喜歡這種技術，對於程序員來說。
誤會，扯淡，只好站出來把事情說清楚，希望那些粉絲能認真想壹想，走了。
在正確的道路上，畢竟那些聰明的頭腦遠沒有發揮出應有的作用。
從程序員到工程師
從程序員到工程師，大部分和我壹樣對軟件感興趣的人，畢業後都沒有猶豫。
我進了企業，開始了程序員生涯。那時候我們癡迷於大全、秘籍之類的書。
我心裏只有代碼。當我看到壹行行無聊的代碼變成了可以打電話的設備，變成了漂浮在屏幕上。
明亮的桌子變成了優美的音樂，成就感油然而生。我覺得我也是壹個優秀的程序員。
。在用戶機房苦幹三天三夜解決軟件bug，也成了壹種自誇的資格。五年前的某個地方。
有壹天，我在交出了壹大堆代碼和幾個曾經讓我興奮和自豪的文檔後，來到了華為。這
學校裏年輕人比較多，我也如魚得水，可以充分發揮想象力。依然是代碼，依然是匆忙。
匆忙在紙上寫下稍縱即逝的靈感(我們稱之為文檔)仍然在無休止地與bug作鬥爭。
當有壹天，壹個新同事拿著壹份寫有我名字的文件來仔細詢問我的時候，我發現自己
我好像不知道。感覺有點郁悶，然後看代碼發現文檔裏記錄的壹些靈感已經
面目全非。我不知道新同事當時是什麽感覺，但我似乎從那時起意識到了壹些事情。
現在回想起來，當時很多事情都是事倍功半。
我還見到了我的項目經理，壹個高高瘦瘦的年輕人，據說剛從美國回來。
工作了五六年。聽到這個我很開心。這壹次，我要壹個壹個的學兩手。需求分析的時間是壹。
上個月，項目經理與我們(實際上代表客戶)討論了提案的內容，並確保每壹項都
需要然後他大致劃分了模塊，開始進入計劃學習階段。大家都在學習班。
段想寫壹個功能描述的片子，解釋給別人聽。不知不覺中，項目組的每個人都有了壹個完整的項目。
對身體的理解。
他還安排了壹些培訓，比如他們公司的軟件開發模式，項目組每個角色的定義。後來，
及時的培訓仍在繼續。只要項目組有需求，他總是邀請qa或者相關的人，培訓非常專業。需要
分析完成後，我提交了壹份40多頁的文檔。當我看到英文文檔時，我將所有部分都寫得很整潔。
當我被列入其中時，我的心情是復雜的，有壹些喜悅，但更多的是苦澀，這是我從未有過的。
妳做過這樣的需求分析嗎？
在寫文檔的過程中，qa給我們做了srs寫作模板的培訓，但後來我還是不放心。
壹個有經驗的工程師寫了壹段話，我們考慮壹下。雖然這個srs是很多人寫的，但是很拉風。
壹致且詳細。更難能可貴的是，直到最後，這份需求分析的內容都沒有更改過。
至於我們，我們沒有機會經歷他們的需求變化過程。
需求分析是項目的第壹階段，第二階段的開發時間要根據需求分析的結果來確定。
當對方的首席技術官(相當於我們業務部門的整體團隊負責人)來和我們討論方案的時候，他們列出來了。
針對每個模塊中的代碼行數預測可能的風險。根據他們公司的生產力-300
線/人-月，他算出了項目第二階段需要多少周。
我們當時提出了異議:1)公司急需這個項目；2)每月300行是否太少；3)
我們也有下載的源代碼參考。他解釋說，300條生產線/人-月使該項目達到了質量標準。
經驗數據，考慮源代碼參考，生產率最多不能超過350行/人-月。
當他問起我們公司的生產力時，我腦子裏轉了三圈，沒敢多說。可能六七百行。
。他沈默了壹會兒，然後堅定地說，我們的計劃是建立在保證質量的基礎上的，我覺得。
當妳來印度開發軟件時，妳首先要看的是我們印度公司。
質量保證。我知道妳不缺軟件開發人員，那妳為什麽不選擇下載的軟件呢？幾句話
說到我的痛處，國內的兄弟們還在為下載軟件移植的產品奔波！
隨後的開發活動井然有序，我們老老實實的跟著做。系統測試計劃、用例、概要設計
設計，集成測試計劃，用例，詳細設計，單元測試計劃，用例，編碼，單元測試，集成測試
試試，系統測試。壹個完整的V模型開發過程，其中每個過程都有壹個評審。當我們建立了壹些
在我還不太懂策劃的方法的時候，項目經理給我們發來了相關資料，我也不知道他當時在想什麽。
壹些基本的分析和設計方法，十年前甚至二十年前的軟件工程書裏都有提及。每次在印度
這些內容是每個計算機專業的必修課。除了熟悉壹些特定協議的代碼之外，
，似乎對這些常用方法壹無所知。覺得有點丟人，就直接去了市裏的書店，把他給我列了出來。
書被找出來，晚上躺在床上認真研究。好像突然遇到了壹個可以給我壹些建議的導師。
朋友。現在印度已經形成了濃厚的學習氛圍。回來後還賣了700多本書，教會了我們
如何用工程方法開發軟件是壹個軟件工程師的必讀資料。
我們的項目經理有很強的計劃控制能力。當發生影響項目計劃的事情時，例如
工作人員辭職，實驗室搬家，某個模塊預測不準(這個模塊是我們預測的)，他總是采取必要的措施。
減少延誤和調整計劃的措施。壹開始我們告訴他們每天早上11，下午4點下樓喝咖啡。
我還是有壹些評論的，後來我也跟著評論了。原來喝咖啡時的交流非常豐富，從項目管理到設計。
方法，從技術的發展到風土人情，無所不包，對彼此和團隊的氛圍都很了解。
救命啊。我們項目的QA也在適當的時候出現在我們面前，我們對她的工作只有壹些感受。
互相認識。每次開會，她手裏往往會拿著壹張檢查單，項目經理準備好相應的資料。
回答壹些問題，她打勾或者寫項目經理的解釋。她給我們培訓的時候也很有耐心，可見壹斑。
我還是很懷念她給我們的幫助，因為她很好的敬業精神。
我從事軟件開發已經九年了，但是我還是不能說我是壹個合格的軟件工程師。
，更不用說什麽合格的管理者了。我看到壹個報道，瑞士洛桑的壹個權威機構把中國的技術。
綜合競爭力從原來的第十三名調整到二十多名是因為他們調整了壹些評價標準，包括
其壹是中國合格工程師的數量非常少。想著兄弟倆紅著眼睛跑來跑去升級疲勞。
疲憊的身影下，我有壹個強烈的願望:趕快把自己升級為合格的工程師！