A. 網站程序員的程序員成長之路大概分幾個階段和未來的發展
第一階段：不知道自己不知道
一開始，和導師一起做過一些小項目，感覺自己知識和技能已經掌握的差不多了，當時自信滿滿的去投遞簡歷，參加面試，但是不知道為什麼就是沒有回復。
那個時期的我，壓根不知道自己不知道，還以為自己都學會了，足以應對工作了。現在想起來就覺得特別好笑，其實那個時候的我還算不上真正的「程序員」，頂多隻能算是個業余編程愛好者。
這個階段的表現：自大、假自信、過度承諾、滿口我能行沒問題、看不起其他程序員~
第二階段：知道梁豎自己不知道
工作後，橡仿大發現自己在項目中會遇到很多困難，不知道怎麼解決，知道了自己和同組人的差距，也知道了自己知識和技能的欠缺，意識到了自己技不如人，很多地方都有不足，需要拚命學習。
這個時候，就是大家所說的初級程序員階段，這個階段必須依靠別人指導。
這個階段的表現：有點心虛、虛心學習、偷偷努力、羨慕牛人~
第三階段：知道自己知道
工作了三四年後，隨著自己的不斷學習，技大畢能、經驗的不斷積累，終於成為了項目組的技術大拿，這時候也很自信，知道自己能夠解決遇到的所有問題，這時候就到了高級程序員階段了。
這個階段的表現：自信、比較客觀、真正承諾、有點自我~
第四階段：不知道自己知道
工作多年後，隨著自己知識的深度和廣度的不斷拓展，學得越多發現不懂的越多，覺得自己以前真是浪費了太多時間，走了太多彎路。
雖然覺得自己還有很多方面需要提高，但是對工作中遇到的問題基本沒有解決不了的，這個時候很多知識都自成體系，解決問題也有了自己的潛意識，有時連自己都不知道自己知道，這時候屬於架構師級別了。
這個階段的表現：開放、主動、好學、謙虛~
B. 軟體工程有哪些主要階段每個階段的主要工作是什麼
1問題定義
問題定義階段必須回答的關鍵問題：「要解決的問題是什麼？」如果不知道問題是什麼就試圖解決這個問題，顯然是盲目的，只會白白浪費時間和金錢，最終得出的結果很可能是毫無意義的。盡管確切地定義問題的必要性是十分明顯的，但是在實踐中它卻可能是最容易被忽視的一個步驟。
通過問題定義階段的工作，系統分析員應該提出關於問題性質、工程目標和規模的書面報告。通過對系統的實際用戶和使用部門負責人的訪問調查，分析員扼要地寫出他對問題的理解，並在用戶和使用部門負責人的會議上認真討論這份書面報告，澄清含糊不精的地方，改正理解不正確的地方，最後得出一份雙方都滿意的文檔。
問題定義階段是軟體生存周期中最簡短的階段，一般只需要一天甚至更少的時間。
2可行性研究
這個階段要回答的關鍵問題：「對於上一個階段所確定的問題有行得通的解決辦法嗎？」為了回答這個問題，系統分析員需要進行一次大大壓縮和簡化了的系統分析和設計的過程，也就是在較抽象的高層次上進行的分析和設計的過程。
可行性研究應該比較簡短，這個階段的任務不是具體解決問題，而是研究問題的范圍，探索這個問題是否值得去解，是否有可行的解決辦法。
在問題定義階段提出的對工程目標和規模的報告通常比較含糊。可行性研究階段應該導出系統的高層邏輯模型（通常用數據流圖表示），並且在此基礎上更准確、更具體地確定工程規模和目標。然後分析員更准確地估計系統的成本和效益，對建議的系統進行仔細的成本／效益分析是這個階段的主要任務之一。
可行性研究的結果是使用部門負責人做出是否繼續進行這項工程的決定的重要依據，一般說來，只有投資可能取得較大效益的那些工程項目才值得繼續進行下去。可行性研究以後的那些階段將需要投入要多的人力物力。及時中止不值得投資的工程項目，可以避免更大的浪費。
3需求分析
這個階段的任務仍然不是具體地解決問題，而是准確地確定「為了解決這個問題，目標系統必須做什麼」，主要是確定目標系統必須具備哪些功能。
用戶了解他們所面對的問題，知道必須做什麼，但是通常不能完整准確地表達出他們的要求，更不知道怎樣利用計算機解決他們的問題；軟體開發人員知道怎樣使用軟體實現人們的要求，但是對特定用戶的具體要求並不完全清楚。因此系統分析員在需求分析階段必須和用戶密切配合，充分交流信息，以得出經過用戶確認的系統邏輯模型。通常用數據流圖、數據字典和簡要的演算法描述表示系統的邏輯模型。
在需求分析階段確定的系統邏輯模型是以後設計和實現目標系統的基礎，因此必須准確完整地體現用戶的要求。系統分析員通常都是計算機軟體專家，技術專家一般都喜歡很快著手進行具體設計，然而，一旦分析員開始談論程序設計的細節，就會脫離用戶，使他們不能繼續提出他們的要求和建議。較件工程使用的結構分析設計的方法為每個階段都規定了特定的結束標准，需求分析階段必須提供完整准確的系統邏輯模型，經過用戶確認之後才能進入下一個階段，這就可以有效地防止和克服急於著手進行具體設計的傾向。
4總體設計
這個階段必須回答的關鍵問題是：「概括地說，應該如何解決這個問題？」
首先，應該考慮幾種可能的解決方案。列如，目標系統的一些主要功能是用計算機自動完成還是用人工完成；如果使用計算機，那麼是使用批處理方式還是人機交互方式；信息存儲使用傳統的文件系統還是資料庫……。通常至少應該考慮下述幾類可能的方案：
低成本的解決方案。系統只能完成最必要的工作，不能多做一點額處的工作。
中等成本的解決方案。這樣的系統不僅能夠很好地完成預定的任務，使用起來很方便，而且可能還具有用戶沒有具體指定的某些功能和特點。雖然用戶沒有提出這些具體要求，但是系統分析員根據自己的知識和經驗斷定，這些附加的能力在實踐中將證明是很有價值的。
高成本的「十全十美」的系統。這樣的系統具有用戶可能希望有的所有功能和特點。
系統分析員應該使用系統流程圖或其他工具描述每種可能的系統，估計每種方案的成本和效益，還應該在充分權衡各種方案的利弊的基礎上,推薦一個較好的系統 (最佳方案),並且制定實現所推薦的系統的詳細計劃。如果用戶接受分析員推薦的系統，則可以著手完成本階段的另一項主要工作。
上面的工作確定了解決問題的策略以及目標系統需要哪些程序，但是，怎樣設計這些程序呢？結構設計的一條基本原理就是程序應該模塊化，也就是一個大程序應該由許多規模適中的模塊按合理的層次結構組織而成。總體設計階段的第二項主要任務就是設計軟體的結構，也就是確定程序由哪些模塊組成以及模塊間的關系。通常用層次圖或結構圖描繪軟體的結構。
5詳細設計
總體設計階段以比較抽象概括的方式提出了解決問題的辦法。詳細設計階段的任務就是把解法具體化，也就是回答下面這個關鍵問題：「應該怎樣具體地實現這個系統呢？」
這個階段的任務還不是編寫程序，而是設計出程序的詳細規格說明。這種規格說明的作用很類似於其他工程領域中工程師經常使用的工程藍圖，它們應該包含必要的細節，程序員可以根據它們寫出實際的程序代碼。
6編碼和單元測試
這個階段的關鍵任務是寫出正確的容易理解、容易維護的程序模塊。
程序員應該根據目標系統的性質和實際環境，選取一種適當的高級程序設計語言（必要時用匯編語言），把說細設計的結果翻譯成用選定的語言書寫的程序，並且仔細測試編寫出的每一個模塊。
7綜合測試
這個階段的關鍵任務是通過各種類型的測試（及相應的調試）使軟體達到預定的要求。
最基本的測試是集成測試和驗收測試。所謂集成測試是根據設計的軟體結構，把經過單元測試檢驗的模塊按某種選定的策略裝配起來，在裝配過程中對程序進行必要的測試。所謂驗收測試則是按照規格說明書的規定（通常在需求分析階段確定），由用戶（或在用戶積極參加下）對目標系統進行驗收。
必要時還可以再通過現場測試或平行運行等方法對目標系統進一步測試檢驗。
為了使用戶能夠積極參加驗收測試，並且在系統投入生產性運行以後能夠正確有效地使用這個系統，通常需要以正式的或非正式的方式對用戶進行培訓。
通過對軟體測試結果的分析可以預測軟體的可靠性；反之，根據對軟體可靠性的要求也可以決定測試和調試過程什麼時候可以結束。
應該用正式的文檔資料把測試計劃、詳細測試方案以及實際測試結果保存下來，做為軟體配置的一個組成成分。
8軟體維護
維護階段的關鍵任務是，通過各種必要的維護活動使系統持久地滿足用戶的需要。
通常有四類維護活動：改正性維護，也就是診斷和改正在使用過程中發現的軟體錯誤；適應性維護，即修改軟體以適應環境的變化；完善性維護，即根據用戶的要求改進或擴充軟體使它更完善；預防性維護，即修改軟體為將來的維護活動預先做准備。
雖然沒有把維護階段進一步劃分成更小的階段，但是實際上每一項維護活動都應該經過提出維護要求（或報告問題），分析維護要求，提出維護要求，提出維護方案，審批維護方案，確定維護計劃，修改軟體設計，修改程序，測試程序，復查驗收等一系列步驟，因此實質上是經歷了一次壓縮和簡化了的軟體定義和開發的全過程。
都應該經過提出維護要求（或報告問題），分析維護要求，提出維護要求，提出維護方案，審批維護方案，確定維護計劃，修改軟體設計，修改程序，測試程序，復查驗收等一系列步驟，因此實質上是經歷了一次壓縮和簡化了的軟體定義和開發的全過程。
C. 軟體開發過程一般有幾個階段每個階段有什麼作用
1、首先制定項目計劃，最初計劃是里程碑性質的。可以先按瀑布模型設置，里程碑點主要為需求評審、設計評審、經過代碼開發和單元測試後進行集成測試、部署上線是一個很重要的里程碑，一般用戶會期望系統何時能使用，進入試運行期。
2、需求開發階段：怎麼樣寫好需求很關鍵，這個需要實踐經驗鍛煉自己。如果有項目成員，可以一起做需求，這個階段對於業務理解、分析、如何開展調研以及文字表述、業務流程圖描述還有文檔編輯能力都有不少要求。一般分為《用戶需求說明書》和《需求規格說明書》，小項目可以寫一個《需求分析報告》，《用戶需求說明書》是用用戶的語言進行描述，讓用戶和開發團隊對於需求的達成一致的理解，《需求規格說明書》，則是對用戶需求的分析，形成系統要具有的功能，這個是真正提供用戶可交互操作的文檔，也就是後期設計和代碼開發的重要基線。
另外，作為了解需求，拿出用戶UI和用戶交流也是一項比較重要的需求獲取手段，雖然這個屬於設計的范疇
3、系統設計階段：
系統總體架構，結合用戶對系統環境、開發語言以及運行的網路硬體等要求，確定開發工具等，對應用系統關系進行架構性設計，通過需求階段對用戶的分析歸類，用圖的方式描述出用戶和各子系統或模塊的全局視圖，以及和其他系統的關系。也就是搞清楚系統的邊界問題。
概要設計中除了高層架構設計，還需要設計網路拓撲圖，以及系統部署圖。概要設計比較重要的還有就是子系統、模塊進行合理的劃分。模塊的名稱很大程度上會成為用戶的主要菜單，如何用用戶的角度去取比較清楚的子系統和模塊是很重要的。
4、代碼開發和單元測試階段：這個階段一般來說需要改進瀑布模型，類似跌代開發，把模塊進行合理劃分，把項目總體計劃的代碼開發測試階段劃分為多個時間段，每個時間段都包括代碼開發、單元測試和集成測試，這個階段還需要對需求變更進行跟蹤控制，如果需求有變更，那麼要把需求文檔、設計文檔都重新跟上。跌代開發的好處就是不讓代碼開發階段拉的過程，沒有進行及時的自我檢查，不小心到了提交時間，卻不是用戶想要的，還有可能都不是自己想要的。
項目經理重要的責任是控制好進度，能及早發現風險，並能拿出好的預防和解決辦法的措施。合理安排好開發團隊的任務，合時的任務安排和銜接，你會覺得非常有藝術感，這個要自己體會了。另外，關注項目團隊各人員的狀況，保持高的戰鬥力，及時發現並能鼓勵團隊共同朝一個目標前進。
5、測試工作，測試是項目的很重要的環節，怎麼測試，怎麼准確測試，怎麼有效測試，怎麼覆蓋測試，時間、人手、經驗扽個方面都會有制約。高級測試人員能夠分析系統各測試要點，在需求、設計階段都要參與，提早了解如何去測試，能寫出測試用例。
6、文檔工作，文檔在項目開發中也佔有重要位置，除非你覺得代碼是項目唯一的成果，那麼你把文檔拋掉吧，什麼都在你的腦子里，團隊中人員一走，項目的一部分也就帶走了。代碼開發其實也需要文檔，代碼是成果，代碼注釋是成果，模塊開發卷宗也是重要的成果，因為程序員在開發時候的邏輯是怎麼樣的，對於今後查問題很有作用。除非你的系統設計程度到了方法、類，把代碼邏輯也都設計好了，那麼程序員就CODEING去吧。
7、QA是對項目過程的質量保障，有些公司吧QA和測試工作合成一個崗位叫做QA&測試人員，或者就叫QA人員。QA是對項目全過程的監管，獨立於項目之外。監督項目經理在各項目里程碑提交相關成果，入庫形成基線。