軟件開發(fā)學習心得

　　學習軟件并非易事，這其中的碰到的困難也有很多。你知道軟件開發(fā)學習心得是怎樣的嗎?今天學習啦小編為大家整理了關于軟件開發(fā)學習心得，歡迎大家閱讀!

　　軟件開發(fā)學習心得篇一

　　受某文化公司委托，開發(fā)一款用于視頻和圖像處理的軟件，開發(fā)難度高，高到從未搞過，開發(fā)周期長，長到是我以前項目監(jiān)控最長開發(fā)周期的兩倍，開發(fā)成本之底，讓我覺得程序員成了高級打字員。首先是需求分析書、產品規(guī)格說明書、設計說明書、代碼規(guī)范說明書、測試計劃，光文稿就不知道熬了多久才做完。

　　緊接著，遇到一系列問題，首先是語言選擇，vc++和c#都是可以保證開發(fā)完成的選擇，但是vc++內存容易報錯，界面很難修改，而客戶要求的界面質量甚至比程序的功能更嚴格，沒辦法，客戶就是上帝，上帝做事一定有他的道理。c#語言易于開發(fā)，而且圖形界面繪制也易于修改，可以做出客戶體驗很好的界面，但是在資源的消耗上，讓我很吃驚。做到第二個月，大概的界面已經完成時，出現(xiàn)界面刷新的問題，刷新時開始卡，界面不流暢。沒辦法，改。

　　開會，總結，技術骨干找問題，拿出解決方案，力爭第一次做軟件把它做好：

　　重新做軟件開發(fā)進度計劃和軟件測試計劃，并且讓獨立功能demo制作和測試先行;

　　用direct draw、direct 3d或者opengl中的一個替代c#本身的gdi繪圖，將在接下來的開發(fā)任務中加入進去。

　　事無巨細，當我滿意的看著界面流暢，功能也已實現(xiàn)時，發(fā)現(xiàn)軟件在低分辨率或者小本上根本亂到沒法看，甚至是界面功能按鈕錯位，重疊等等。沒辦法，改。畢竟軟件的多分辨率兼容和操作系統(tǒng)兼容是必須要做的。

　　接下來一大堆的麻煩找了上來，軟件出現(xiàn)各種各樣想都想不到的問題，總算是按時將第一個版本發(fā)布出去，并且開始接下來的升級開發(fā)任務。

　　最后，給剛剛接手軟件開發(fā)項目的朋友一些忠告：

　　一、相關的文檔不是給別人看的，而是給自己看的，相關文檔一定要齊備，而且讓所有涉及開發(fā)的人員都清楚的知道你文檔里所要表達的意思;

　　二、一定要注意多做demo，多做實驗，一個demo程序員幾個鐘頭就可以完成，甚至更少，但是不做demo，核心程序沒有做實驗，其他的東西都圍繞核心程序做了上去，到時候耽誤的可不是幾個鐘頭

　　三、程序設計要注重用戶體驗，當初客戶對我要開發(fā)軟件提出近乎苛刻的要求時我不在意，但是當我自己反復使用軟件時有了很多體會，流暢美觀的界面帶給人心理的快感的確能替代一些尚未開發(fā)完整的功能帶給用戶的遺憾。

　　四、測試計劃多次進行，分批進行，不要全部開發(fā)完成再對軟件做測試。

　　還要堅持三個月，軟件馬上發(fā)布，希望大家的支持，謝謝!!!

　　軟件開發(fā)學習心得篇二

　　軟件開發(fā)過程中的任何一個活動都是為了能夠產出優(yōu)秀的代碼。所以，代碼才是核心。

　　1. 代碼是軟件開發(fā)的基礎

　　編碼是軟件開發(fā)過程中最基本、最底層的技藝，然而也是最重要的技藝。任何一個領域的專家都需要花費大量的時間來進行基本技藝的鍛煉，木匠需要花費大量的時間來鍛煉他們對各種工具的掌握，廚師則需要練習刀工和火候。程序員也是一樣的，對我們來說，語言的各種特性必須要了然于胸。而對軟件的管理也需要從代碼做起。

　　從2000年到現(xiàn)在，國內興起了一股軟件工程熱，需求管理、配置管理、甚至CMM。面對紛至沓來的各種方法學、UML、OOA，大家似乎已經熱衷于這些概念本身了，卻往往忽略了軟件開發(fā)中最基本的元素:代碼。在和很多軟件組織的接觸過程中，我們認為大多數(shù)組織急切需要的并不是這些工程理論，不是說這些理論不重要，而是這些組織的癥結不在于此。很多的組織連代碼的質量都管理不好，又何談其它呢?代碼管理是基礎的基礎，從管理的角度上來看，任何一個組織的管理都需要一個從上至下的管理過程，有基層的管理人員，也有高層的管理人員。對代碼的管理就是軟件開發(fā)中的基層管理，它起到的作用就是能夠把需求、設計的思路貫徹到最終的代碼中。

　　“管理無大事”。對軟件的管理也是一樣，大部分的問題都是由于很小的原因引起的。例如，一個產品如果后期在debug上花費了大量的時間，那么，這種現(xiàn)象是由于什么原因引起的?一種可能的原因是前期的代碼設計中對代碼質量的把握不嚴。每一次代碼功能的演化并不會產生太多的問題，但是當代碼累積越來越多的時候，問題也就慢慢出現(xiàn)了。那么如何解決呢?可以加強QA的力量，也可以引入復審，還可以引入單元測試?？傊?，要有一種方法對代碼進行控制。

　　軟件的開發(fā)過程就象是一部精密的機器，任何一個環(huán)節(jié)的變化，都會對其它的環(huán)節(jié)產生影響。把軟件過程按照瀑布的形式進行劃分是一種分解的處理思路，但同時我們還應該看到不同活動之間的相互影響。軟件開發(fā)中的生命周期模型也是一個層次模型，從業(yè)務建模一直到軟件實現(xiàn)，需要跨越數(shù)個層次，同樣會出現(xiàn)執(zhí)行不力的情況，例如，代碼設計偏離需求、偏離設計的情況比比皆是。

　　如何避免這種情況呢?這就需要我們從源代碼的角度，反思其上游的實踐活動，是否足以約束代碼設計?就拿XP來說，他解決這個問題的方式是盡快的進入代碼開發(fā)階段，從代碼開發(fā)中發(fā)現(xiàn)問題，并在下一輪的開發(fā)中解決。這種思路是正確的，但XP畢竟是方法論，他不會告訴你過于細節(jié)的東西，盡管XP已經提供了大量面向代碼的實踐。因為方法論的抽象級別比較高，使得他必須舍棄部分的細節(jié)。而這篇文章告訴你的，就是這些細節(jié)。就像我們在下一節(jié)中討論的例子，需要在代碼中加入對異常的處理，那么，異常的源頭在哪里呢?是需求，在需求中，我們發(fā)現(xiàn)了一些業(yè)務的非正常的處理序列，發(fā)現(xiàn)了一些業(yè)務實體的限制性的要求，所以在代碼實現(xiàn)中，就需要有相應的異常處理。在例如，一個優(yōu)秀的異常處理，還需要讓客戶端程序員了解可能發(fā)生的異常，以保證不同代碼間正確的集成。

　　2. 面向對象的代碼

　　面向對象的代碼已經在現(xiàn)在的軟件開發(fā)中占據了主流的位置，面向對象的思路也有其優(yōu)勢所在，就像后文所討論的，面向對象代碼有著非面向對象代碼的很多優(yōu)勢，而軟件業(yè)中很多新的思潮的產生，也都是基于面向對象語言的，所以我們關注的代碼將是面向對象代碼。

　　面向對象的思想來自于抽象數(shù)據類型。對于面向對象來說，它最重要的改進就是把世間萬物都描述為對象，而類則描述了同一種對象的特征，而不是像傳統(tǒng)的開發(fā)方法那樣，按照機器指令的執(zhí)行順序來進行設計。當然，面向對象代碼最終仍然是要按照時序來執(zhí)行的，但是從程序員的角度看來，面向對象代碼更側重于對象之間的交互，多個對象各司其職，相互協(xié)作以完成目標。而面向對象技術的發(fā)展，也是朝著更加貼近我們世界觀的方向發(fā)展。從這點來看，有人說完全沒有程序設計經驗的人學習面向對象可能會更加的容易，因為他不需要從原先的時序程序的桎梏中擺脫出來，但這未必是事實。面向對象決不是一種簡單的程序設計思路。這是我們的觀點，也會在下文中反復的論證。

　　和所有的職業(yè)一樣，程序員，或者是面向對象程序員，始終堅持的一點就是嚴謹。你會看到各種各樣優(yōu)秀的代碼，但那決不是一次能夠寫成的，要不斷的嘗試，不斷的改進。為什么重構和測試優(yōu)先是敏捷方法中很重要的一項實踐?因為程序員不是神，他們需要慢慢改進他們的代碼。雖然羅馬不是一天能夠建成的，但是在編寫面向對象代碼的過程中，有一些實踐是需要堅持的，它體現(xiàn)了我們所說的嚴謹。

　　3. 編寫并管理面向對象的代碼

　　編寫優(yōu)秀的面向對象代碼并不是一件容易的事情，優(yōu)秀的OO代碼如行云流水，糟糕的OO代碼讓人覺得渾身起雞皮疙瘩。編寫優(yōu)秀的OO代碼要求程序員有一定的自我修養(yǎng)，能夠以抽象的思路看待問題，找到問題的核心并對問題域進行分解。它強調的是一種解題的思路，但這個解不是唯一的。

　　典型的例子是設計模式，設計模式確實給了我們以很大的啟發(fā)，通過它，我們能夠了解到優(yōu)秀的代碼是如何用于解決實際問題的。但是是不是你必須在軟件中照搬設計模式呢?如果你這么做，那么你對設計模式的理解仍然不夠。我曾和在建筑行業(yè)的朋友聊起Christopher Alexander的建筑的永恒之道。他很興奮的告訴我，那確實是一本很好的書，能夠引發(fā)人很深的思考，但是現(xiàn)在也有另外的一種觀點，認為美仍然是無形的，應該發(fā)自建筑師的內心。對這句話我思考了很久，其實建筑是給人使用的，因此最重要的是它能都給人帶來的價值，隱含在其中的那種活生生的氣質，這是建筑師文化底蘊的外在表露。所以，Christopher Alexander在那本書中的目的，也是為了找到一種總結自己觀點的方法，來總結自己對人文的認識。至于現(xiàn)在大家對他的思路提出了質疑，那也是一件好事，這說明大家對建筑之道的認識到了新的高度。建筑是這樣，軟件中的模式也是一樣的，我也曾熱衷于研究模式的使用，直到某一天我猛然驚醒，與其沉迷于模式的表面形式，為什么不去研究隱藏在它背后的文化底蘊呢?武俠小說中常說無招勝有招，模式的應用也應當?shù)竭_這個境界，你如果可以在不經意間應用模式的思想，那又何必拘泥于模式的形式呢?

　　編寫優(yōu)秀OO代碼雖難，但還有更難的事情，就是讓整個開發(fā)團隊都產出優(yōu)秀的OO代碼。我們剛才說了，OO對問題的解不是唯一的，但各個不同的優(yōu)秀解匯集到一起，可能就是一個糟糕的解，這是風格和架構的問題。你如何在團隊中制定制度，營造氛圍，讓優(yōu)秀OO代碼成為團隊最終的成果?這些問題，在我看來，要比CMM難得多，這個問題并不是靠花錢就能夠解決的。如果能夠解決這個問題，這個團隊的創(chuàng)造力一定是驚人的。

　　4. 面向對象軟件開發(fā)過程

　　普通的軟件開發(fā)過程和面向對象開發(fā)過程有著很大的不同?；叵胛覀冊诜敲嫦驅ο笾虚_發(fā)過程中，最經常采用的任務分配方法就是以軟件模塊為單位，這樣的好處是分配簡單，不同任務之間耦合程度低，容易操作。壞處是幾乎無法做到重用，也缺乏整體性的設計。而面向對象軟件開發(fā)則不同，它是以類、類集合作為基本單位的。類之間關系錯綜復雜(雖然我們提倡低耦合的設計，但類之間的關系仍然是相對復雜的)。這種情況下程序員之間相互協(xié)作的要求就非常之高，這種關系如果處理恰當，則能夠完全體現(xiàn)出面向對象的威力，否則，那將會是一場大災難，面向對象的軟件開發(fā)過程要養(yǎng)成一些好的習慣：

　　4. 1 盡量簡化和穩(wěn)定客戶端。

　　個人編程可以是一種享受，但團隊開發(fā)始終是一項嚴謹?shù)穆殬I(yè)活動，因此多考慮別人，不要設計復雜的接口，雖然你省事了，但這會給理解和使用你的接口和人造成障礙。

　　4.2 準備一份簡潔的文檔，并保持更新。

　　隨便一種形式的穩(wěn)定，可以是代碼，可以是UML圖，也可以是純粹的文字(估計沒幾個程序員喜歡這種形式)。只要它能夠傳達你的代碼的目的，那就足夠。記住，更新代碼后，同時更新你的文檔。過期的文檔不僅是廢紙這么簡單，它會給其它人造成麻煩。切記!

　　4. 3 盡可能多的考慮異常和錯誤的情況。

　　軟件開發(fā)學習心得篇三

　　來到北大青鳥通州校區(qū)學習已經快一年了，雖然時間不算太長，但對于我而言，在北大青鳥，我的收獲是無法用時間長短來衡量的!

　　因為在來北大青鳥之前，我從沒接觸過軟件方面的知識，所以剛開始很擔心自己學不了，自卑的情緒很嚴重。但是細心的班主任發(fā)現(xiàn)了我的問題，總是很耐心的找我談心，開導我!慢慢的，我想明白了，不要盲目的和其他同學作比較，今天的我只需要比昨天的我有進步，我的目的就達到了!

　　想通了以后，我自己也越來越自信了。就像一只從起跑線上開始爬行的蝸牛，雖然很慢，但是我目標很明確，很堅定!或許很多人會認為學習軟件是一門很枯燥的課程，但是我覺得這乏味中也有不少樂趣。例如學習.NET和C#時，我們小組就自己制作了一款小游戲，雖然是一款很簡單的小游戲，只能有一些普通的攻擊動作，但是它就是我們的學習成果。玩著自己編寫出來的小軟件，想著以后能開發(fā)出更厲害更完善的系統(tǒng)，讓我們對未來的工作和學習充滿了動力!

　　剛開始接觸三層架構的時候，我上課聽老師的講課真是一頭霧水。但是我并沒有放棄，而是更加認真，調整好心態(tài)，強迫自己反復的看書，查資料，一遍遍的練習，遇到不懂的就馬上去問老師，就這樣，終于攻下了一道道難題。

　　如果你問我在學習軟件的過程中，什么學習方法最重要，那我會認為勤奮是最重要的。一定要反復的練習，這樣你才會掌握得更扎實，基礎打得好，后期的學習才會更省力!另外，我覺得課余時間應該好好的利用起來，不要局限于課本，要主動的去學習更多的知識和技能，為以后的工作準備更多的能力!