軟件開發學習心得（精選12篇）

軟件開發學習心得 篇1

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

　　1. 代碼是軟件開發的基礎

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

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

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

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

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

　　2. 面向對象的代碼

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

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

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

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

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

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

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

　　4. 面向對象軟件開發過程

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

　　4. 1 盡量簡化和穩定客戶端。

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

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

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

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

軟件開發學習心得 篇2

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

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

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

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

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

軟件開發學習心得 篇3

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

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

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

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

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

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

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

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

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

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

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

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

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

軟件開發學習心得 篇4

　　本周是實習的第一周，很幸運碰到了產品部很有耐心的leader詹老師。 實習第二天他讓我做一個H5的游戲類應用， 主要用于微信中分享。之前對于自己的水平是否能完成完全沒底，但感覺第一次實操確實也有點讓人興奮，之前關于產品開發的印象只停留在書本上。

　　詹老師讓我模仿“過家家gogaga”所開發的“打電話認師姐”微信小游戲寫一個類似的應用。 我把原始應用找出來便開始摳代碼， 第一步是將套在微信接口中的原始應用摳出來(套在微信接口的原始應用只能在微信瀏覽器中運行，無法在電腦上測試)，周二開始做.

　　一開始我的效率非常低， 因為我很多測試方法并不熟悉， 在參閱了微信JS-SDK后總算把原始代碼摳出來， 厘清該應用的基本邏輯后開始重寫， 在詹老師的耐心地指導和對基礎知識的講解下，我們將原始代碼中120行的CSS代碼優化到60行，將五百多行的JS代碼優化到只有60行，這事實上是在原有的邏輯上完全重寫了，這讓我開始有點成就感了。

　　也第一次感受到產品開發中的大局觀，這種大局觀更多的是體現在細節上，比如代碼變量名的設置需要與文件存放聯合考慮，以便日后修改和維護。 詹老師在講代碼邏輯的時候親自寫了一個例子讓我體會， 雖然消化這些用了快一天，但感覺真的收獲很大， 有拔云見日之感。

　　實習一周后所遇到的種種困難也讓我意識到自己很多問題，歸納如下：

　　1.盡管之前對于書本的學習有一定積累，但還是暴露出代碼的不熟練，細節方面處理能力差，在細節上耗費時間太多。

　　2.缺乏基本的軟件開發測試思路， 比如之前不知道chrome具有相當強大的錯誤測試功能，它對于沒有觸發的函數也有錯誤提示。

　　3. 缺乏專注的習慣，比如詹老師讓我先完成功能方面，但我卻習慣于去找找界面的素材， 這就導致兩邊都沒有做好。雖然認識上知道不該這么做，但是習慣上卻很難改。

　　4.自己很多時候雖然有問題但是不能完全闡述清楚，所以跟leader溝通的時候往往支支吾吾，以后有問題自己首先得想清楚，將問題講明白也是很關鍵的能力。

　　另外也記錄一些自己的淺薄感受：

　　1.工科出身的詹老師對于代碼的運行效率有很多的考慮，但對于用戶體驗和交互效果似乎稍微少點，當然也可能是我新來并不了解的原因。

　　2. 公司在做小應用的時候并不會在用戶測試和產品結構功能上討論太多，公司要的是迭代效率， 就是要快速出應用，然后再快速上線下一個。

　　本周接到新的任務，為中國教育在線制作H5的招聘頁面， 之前的“給師姐打電話”的H5應用還沒有優化好，能做的改進的地方還有很多，leader詹老師讓我先把招聘網站做好， H5應用先放放， 他給了我大街網做的“中國好Offer”作為參考， 拿到之后確實感覺這些頁面都做得很好， 詹老師搜集的資源確實十分豐富，從實習到現在他發給我的參考很實用，在看完了五六十個H5的招聘頁面之后開始構思， 在將產品架構基本做好后，測試又發現很多問題， 有技術層面的，但更多的設計本身的問題。

　　技術的細節的問題：基于jquery mobile的開發框架國內的資料十分有限，不得不查閱原始的英文API，很多問題也只能去JQM的論壇查找，這些都十分考驗英文閱讀能力。CSS的布局問題繁雜，在各個瀏覽器，各個應用的渲染都不一樣， 也是很折磨人的過程，我現在就碰到了css中font-weight屬性在Safari沒有渲染的問題，至今沒有解決。

　　逐漸體會到前端工作的繁瑣與細節， 需要學的東西很多， 有時候可以憑自己一些小聰明在當前解決，但并沒有摸到問題的根源，揚湯止沸不是長久之計，但又好像沒有足夠的時間來系統的摸索，我只能先將這些問題一一記下來。這些技術的體會是一方面，另一方面便是產品的設計層面， 現在就是因為產品快做好后發現有很多地方犯了低級錯誤， 以往的紙上談兵頭頭是道，等到自己親身實踐卻感到把握不住很多設計原則， 比如界面設計給用戶造成的不必要的干擾， 功能可見性的不足，邏輯上的不嚴謹， 以下我歸納了下崗做好的H5界面存在的交互問題：

　　1.頁面的設計初衷是左右滑動來切換頁面，但給幾個朋友測試后都不能進入頁面后就自然而然的知道是左右滑動。

　　2.join us的圖標給用戶是按鈕的錯覺，在測試中很多用戶以為是按鈕，都會下意識的點擊。

　　3.交互效果的乏善可陳，與滑動的邏輯似乎也沒有太大關聯，只是單純的加入了一些css3的動畫。

　　4.用于提示左右滑動的動態箭頭會讓用戶以為是點擊作用

軟件開發學習心得 篇5

　　首先我是一個女孩，學軟件開發的女孩相對于男孩來說并不是太多，但是因為我自己對編程比較感興趣，所以就從事了這個行業。

　　我們學校的學生從20xx年的下半年就已經開始出來實習了，據我所知我們計算機系的學生大都從事別的行業去了，從事計算機行業的人數非常少，我想大部分是沒有過硬的技術知識的原故，不敢去應聘本行業的工作吧。

　　我一直是一個有上進心的女孩，對軟件編程有很大的興趣，總想著自己也要像男孩一樣，做一番屬于自己的事業，不能白白的虛度自己的青春，但我又不想從事與計算機沾邊的初級職位，比如文員之類的。因為如果自己的第一份工作從做文員開始，以后自己的職業生涯就不好規劃，肯定會離軟件編程越來越遠的。

　　說實話我的家庭條件并不富裕，但是我有一個非常支持我上學的父母，他們狠狠心在我上了幾年大學之后又給我交了幾千元的培訓費。從那時候起我就想著我一定要好好學習，對得起父母。

　　就這樣開始了我的培訓旅程，其實說實話在培訓的過程中我是時而感到特別迷茫，時而又有了奮斗的激情，這不免有個人的因素，也有培訓環境的影響。

　　在這里我想提醒一下那些想參加軟件培訓的學生，在你們選培訓班的時候一定要看清這個學校以前培訓學員的就業情況，特別重要的是培訓老師有沒有教學經驗，一些培訓機構總是以賺錢為目的，鼓吹著自己的培訓老師擁有幾年幾年的項目經驗，其實我感覺沒有教學經驗的老師還不如項目經驗少一些的老師。

　　我們培訓部就是一個例子，我有時候就感覺聽我們老師講課簡直是一件非常痛苦的事情，他講課從來就不備課，只是根據自己的工作經驗，想到哪個知識點就講哪個，我們聽課的學生一點思想準備都沒有，而他常常在課堂上為了調試一個程序的一個小小的錯誤耽誤一兩個小時的時間，而這期間往往也是我們最煎熬的時候，因為我們要坐在那個地方陪著他找錯誤，這種情況下的我們非常受折磨，并且感覺時間都白白浪費掉了，以至于根本沒有什么收獲。

　　再來談談我自己的情況吧，我在大學期間編程語言學的還算不錯，當時我們只開了c++、java兩門編程語言課，還有軟件開發相關的SQLServer20xx數據庫，我的這三門主修課程每次考試都很優秀，參加培訓時也有老師勸我學軟件前臺，網頁設計什么的，說是女孩比較適合學這個，好就業，而軟件開發大都是男孩子，女孩幾乎是學不通的。我當時就是為了證明自己的能力，根據大學期間自己的學習情況，我相信自己能學好。

　　但是也因為我們老師講課的無計劃性，課程拖到現在還沒有結束掉，時間已經過去6個月了，我開始思索我自己的人生了。

　　經過四個月的培訓，我不能說我沒有學到什么東西，但我還要說一點，我雖然每一樣技術都知道了，但是我學的僅僅還只是一個皮毛而已。軟件開發最重要的就是編程思想，可我現在的水平只是編寫代碼達到非常熟練的程度罷了，對于編程思想感覺還是沒有踏入軟件開發的門檻。而編程思想主要來自于你所做過的實際項目獲得的經驗。而我們培訓部的項目不僅少而且不怎么實用。所以要想參加培訓還要看清這個培訓部的項目是不是夠份量，沒有實際的項目經驗去應聘軟件開發的工作還是不行的。

　　經過仔細的思索，我已經決定去找工作了，現在正是找工作的好時候，雖然我沒有多少項目經驗，但我相對于應屆畢業生自信多了，也許這就是培訓的力量。不過哪怕找到一份小小程序員的工作干著也行，因為現在對自己的職業定位還有點迷茫，我自己的性格屬于那種做事情非常認真、踏實、細心，感覺更適合做軟件測試方面的工作，對于軟件開發我還是抱著先試試工作的態度，主要源自于我自己頭腦反應太慢，估計一直做軟件開發對職業發展前景是有礙的。

　　最后告誡那些還在上大學的朋友們，如果你們想在軟件行業發展，那你們一定要在上學期間多上網看一些編程方面的視頻，自已嘗試著把企業要求的知識點自學一下，跟著視頻做一些小型的項目。其實自學知識點是不難的，只有你有恒心。因為我培訓的感覺就是公司要求的一些東西很多并不是我們不懂，而是我們在學校其實是連聽說過都沒有聽說過，這樣的話哪個公司會愿意。

軟件開發學習心得 篇6

　　歲月流轉，時光匆匆，轉眼間我的大學生活已經接近了尾聲�；厥淄�昔，有太多美好的，也有太多艱辛。我的大學生活的主旋律還是學習，我所選學的專業是軟件技術，在這條道路上走了那么久，也有一些小小的感悟與體會。

　　還記得上初中時，英語課本上有一篇關于比爾蓋茨的文章，當時真的很佩服比爾蓋茨，也就是那時我才第一次接觸到軟件一詞，學過那篇文章后我有個想法，就是也要做個比爾蓋茨，可是由于家庭條件的限制，那也只能是個美好的夢想。后來上了高中，再報考時我就選擇了軟件技術這個專業，這樣我想就向那個遙遠而又美好的夢想邁進了一點點吧。

　　然而當我真正上了大學，學了這個專業，我才知道要做個比爾蓋茨是多么的難，要想學好我的專業要花費很大的精力。第一學期我們開設了C語言這門課程，當時我學著真的是云里霧里、一竅不通，很是失落，學了不久之后我開始覺得自己可能并不喜歡這個專業，只是一時昏了頭，錯以為喜歡了�，F實的打擊讓我有點不知所措，然而我已經選擇了它，有句話說：既然選擇了遠方便只顧風雨兼程。我既然選擇了這個專業，我便也只有硬著頭皮也要走下去了。有了這樣的想法之后，在之后的一段時間里，只要是沒課的時候我就抱起了C語言課本，努力的看，記語法知識，語法規則，學語句、小算法等等。經過一段時間的研究學習，我發現C語言并沒有我想象中的那么難了，還是很有意思的。就這樣在學與玩中我的大學第一個星期就過完了。

　　后來又開設了很多課程，有VB、網絡、數據庫、操作系統、數據結構等。在這些課程中最令我頭疼的就是數據庫了，老師講的時候老是劃重點，講的很少，當時學的時候真的好難受，一學期下來啥也不會，后來看書上的操作，一步一步的操作，才終于學會了建個數據庫，做下備份還原等操作。開設的那么多課程也有我很喜歡的課程，比如數據結構，這門課程理論的比較多，上機操作的很少，這門課程是很需要理解的，當然有的還是要死記的。學習這門課的時候，我覺得并不像其它課程那么吃力，可能高中是學理科的緣故吧，理解起來并不太費勁。所以當時就很喜歡這門課，然而這門課表皮的好學，但要深學起來還是很有難度的，所以期末考試的時候我的成績并不太理想，但這些打擊不了我對它的興趣，至少我知道我所學的這個專業還是有很多我是很喜歡的。

　　這樣走著走著就到了大二的下學期了，那個學期，我們有一門課是C++，這門課的老師很和藹，能力也很高，從他那里我學到了很多東西。老師教給了我們很多算法，也很系統的講解了語法知識，還教我們做小系統，有的時候他會給我門們一些小系統的代碼，讓我們去改寫，剛開始的時候我也是不會，后來經過學習請教改寫成功了，這個時候我就會很開心，很有成就感。就這樣在學與玩中，在快樂和憂愁中我們迎來了我們的大三時光。

　　大三剛一開學，老師們就告訴我們這學期就上十二周的課，然后就考試，就畢業了。這讓我很有緊迫感，一想到畢業在即，心頭就有種不舍，這兒有我美好的時光，然而我就要對這里說再見了。大三了我們的課全變成了專業課，也幾乎全成了上機課，老師還給我們布置了一個程序，就是一個小組要交一個系統來算作成績。我們這小組所選的課題是圖書管理系統，針對這個系統，我們上機的時候，利用網絡資源在網上查找了相關的資料，因為說實話，我們對此并不太理解，也只有通過網絡來查找信息，做好需求分析，功能模塊設計等工作。在這同時我們還去了學校的圖書館理解了相關的信息，這個系統并不要求功能有多么強大，關鍵在與一種鍛煉，思維的鍛煉，對所學東西的總結等。建立數據庫時我們就根據需要建立幾個表，里面的數據也是從我們學校圖書館里找來的。后來的界面設計，為了追求美觀，我們又在網上搜了很多美麗的圖片來美化界面。具體到功能的時候，有很多東西都不會，后來老師在課堂在做了講解，我們就把它用到了我們的系統中，真的就是學一步做一步的。整個的系統做下來，我學到了很多東西，也對那么知識有了很好的應用能力。

　　現在這個星期也就到了期末，這短暫的校園時光也在飛速的流逝著。回首過去學習的經歷，真是苦中有樂，樂中亦多苦，然而無論如何這些都已經走過去了，未來的路還要我們好好的走下去。人生本就是一個不斷的學習的過程，也是一個不斷完善的過程，在未來的道路上我會更加努力地學習，走出一個美好的人生。

軟件開發學習心得 篇7

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

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

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

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

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

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

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

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

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

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

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

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

　　還要堅持三個月，軟件馬上發布，希望大家的支持，謝謝�。�！

軟件開發學習心得 篇8

　　一、實訓過程

　　首先，我們學習通用編程：任何類類型的所有值都可以同object類型的變量來代替。封裝：就是把數據和行為結合起在一個包中)并對對象使用者隱藏數據的實現過程，一個對象中的數據叫他的實例字段(instance field)。重載：當多個方法具有相同的名字而含有不同的參數時，便發生重載。編譯器必須挑選出調用哪個方法。數組列表：ArrayList動態數組列表，是一個類庫，定義在java.util包中，可自動調節數組的大小。

　　class類 object類中的getclass方法返回class類型的一個實例，程序啟動時包含在main方法的類會被加載，虛擬機要加載他需要的所有類，每一個加載的類都要加載它需要的類。Java中對內存的分配是動態的,它采用面向對象的機制，采用運算符new為每個對象分配內存空間,而且，實際內存還會隨程序運行情況而改變。程序運行中 Java系統自動對內存進行掃描,對長期不用的空間作為”垃圾”進行收集，使得系統資源得到更充分地利用.按照這種機制,程序員不必關注內存管理問題，這使Java程序的編寫變得簡單明了,并且避免了了由于內存管理方面的差錯而導致系統出問題。而C語言通過malloc和free這兩個庫函數來分別實現分配內存和釋放內存空間的，C++語言中則通過運算符new和來分配和釋放內存，總之，Java語言是一個純的面向對象程序設計語言。

　　Java語言是分布式的。Java語言支持Internet應用的開發，在基本的Java應用編程接口中有一個網絡應用編程接口(java net)，它提供了用于網絡應用編程的類庫，包括URL、URLConnection、Socket、ServerSocket等。Java的RMI(遠程方法激活)機制也是開發分布式應用的重要手段。 Java語言是健壯的。Java的強類型機制、異常處理、廢料的自動收集等是Java程序健壯性的重要保證。對指針的丟棄是Java的明智選擇。Java的安全檢查機制使得Java更具健壯性。 Java語言是安全的。Java通常被用在網絡環境中，為此，Java提供了一個安全機制以防惡意代碼的攻擊。除了Java語言具有的許多安全特性以外，Java對通過網絡下載的類具有一個安全防范機制(類ClassLoader)，如分配不同的名字空間以防替代本地的同名類、字節代碼檢查，并提供安全管理機制(類SecurityManager)讓Java應用設置安全哨兵。 Java語言是體系結構中立的。Java程序(后綴為java的文件)在Java平臺上被編譯為體系結構中立的字節碼格式(后綴為class的文件), 然后可以在實現這個Java平臺的任何系統中運行。這種途徑適合于異構的網絡環境和軟件的分發。 Java語言是可移植的。這種可移植性來源于體系結構中立性，另外，Java還嚴格規定了各個基本數據類型的長度。Java系統本身也具有很強的可移植性，Java編譯器是用Java實現的，Java的運行環境是用ANSI C實現的。

　　Java語言是解釋型的。如前所述，Java程序在Java平臺上被編譯為字節碼格式，然后可以在實現這個Java平臺的任何系統中運行。在運行時，Java平臺中的Java解釋器對這些字節碼進行解釋執行，執行過程中需要的類在聯接階段被載入到運行環境中。 Java是高性能的。與那些解釋型的高級腳本語言相比，Java的確是高性能的。事實上，Java的運行速度隨著JIT(Just-In-Time)編譯器技術的發展越來越接近于C++。 Java語言是多線程的。在Java語言中，線程是一種特殊的對象，它必須由Thread類或其子(孫)類來創建。通常有兩種方法來創建線程：其一，使用型構為Thread(Runnable) 的構造子將一個實現了Runnable接口的對象包裝成一個線程，其二，從Thread類派生出子類并重寫run方法，使用該子類創建的對象即為線程。值得注意的是Thread類已經實現了Runnable接口，因此，任何一個線程均有它的run方法，而run方法中包含了線程所要運行的代碼。線程的活動由一組方法來控制。Java語言支持多個線程的同時執行，并提供多線程之間的同步機制(關鍵字為synchronized)。

　　二、心得體會

　　剛開始時張宇老師先教我們配置JAVA的編程工具和運行環境，然后教我們學JSP，在此期間，我們自學了JAVA，又學了Tomcat的使用及MySql和HTML語言，當我們JSP入門后，陳老師開始教我們學習JSF框架，但由于學校的安排，剛開始學，陳老師便去了蘇州，由在蘇州帶隊的孔祥盛老師回來教我們，在孔老師的安排下，我們又學習了SQL Server 20xx和Struts框架，教我們學會了Javawebstudio的使用�？傊�，

　　在兩位老師的細心輔導下，我們有了很大的進步，知識得到了擴充，認識得到了加深，也使得我們的自學能力得到了很大的提高，在此，我向兩位老師表示由衷地感謝。這次實訓是三年中所學知識的一次匯總，是三年來學習能力的一次集中體現，有的知識在這次實訓中用不到，但以后會用到，我敢說肯定會用到。因為好多東西都是厚積而薄發，所學的知識在關鍵的時刻也許只有一種用得上，但這一種也許足以成就我們的人生，到那時我們才能真正體會到知識的偉大，才能真正了解老師的重要性。我覺得要成為一個合格的程序員，首先要具備的是一種自學能力，遇到了問題自己要有能力去解決，當你嘗試了各種方法，實在無能為力時再去請教別人，這時你所學的知識你一生都不會忘記，它將成為你一生的財富。有句話說得好：進攻是最好的防守!當你遇到了問題，你要試著去解決，編程嘛，想到了就要去試，你的面前就一臺電腦而已，它又不會爆炸，你怕什么呢?我不敢說我的觀點一定正確，每個人有每個人的想法，也正是因為大家的觀點各不相同，才使得IT業這個新興的產業在短短的幾十年中得到了長足的發展，給人類社會創造了超過以往人類社會所創造的價值的總和，這不能不令人驚嘆，也正是因為如此，它才使得我對它產生了強烈地好奇心和探索欲。未來的社會是信息的社會，信息業所創造的財富在人類社會中占據首位，經濟、軍事、教育、醫學、農業等領域無一不用到信息業所產生的科技成果。我能感受到它所創造的經濟效益會有多大，所以，我要說：我愛編程,�？菔癄�，矢志不渝!我是一個新技術的狂熱追隨者，每次上網時總要到MLDN上逛一下，當看到短短的幾行代碼卻能產生令人驚嘆的功能時，我就被編程者的那種魅力所折服，我想成為其中的一員，我為自己現在所學習的專業感到自豪。

　　在我學習的過程中我也遇到了很多的問題，可是我卻發現我遇到的好多問題在網上總能找到答案，我才明白我遇到的問題很多人都遇到過，并且他們也把解決的辦法發布到了網上，以使我們這些初學者少走些彎路，我覺得他們太善良了，同時我也明白了自己是多么的渺小，我正在走前人走過的路，到底前面的路有多長多遠，我不知。他們是開路先鋒，他們為我們學習新技術新知識鋪平了道路，我們所要做的就是把他們所發明和創造的東西掌握使用而已，并且知識量又很大，當我看到有無窮無盡地學習資源供我享用時，我只能說，他們像太陽一樣照耀著我成長，他們太好了。當我看到程序代碼，我就有一種特別的感覺，讓我不斷想成為一名編程高手，如果真的有一天，我的理想會實現，我會加倍努力好好學編程，永遠不改變!通過三個月的實訓，我感到自己學到了很多東西，雖說不精，但已經入門，于世間萬物之中，遇見我所遇見的事物;于千萬年之中，時間的無涯荒野里，沒有早一步，也沒有晚一步，剛巧趕上了，上蒼讓我有機會接觸編程，給了我一條路。我很清楚以后的路還很長，再長的路，一步步也能走完，再短的路，不邁開雙腳也無法到達。任何業績的質變都來自于量變的積累，成功不是將來才有的，而是從決定去做的那一刻起，持續累積而成，讓我們將事前的憂慮，換為事前的思考和計劃吧!在實訓的過程中，我深深感覺到自身所學知識的有限，有些知識點以前沒有學過，但我也沒有去研究，實訓時突然間覺得自己真的有點無知，雖然現在去看依然可以解決問題，但要浪費許多時間，這一點是我必須在以后的學習中加以改進的地方，同時也要督促自己在學習的過程中不斷的完善自我。另外一點,也是在實訓中必不可少的部分，就是同學之間的互相幫助。所謂”當局者迷,旁觀者清”，有些東西感覺自己做的是時候明明沒什么錯誤，偏偏程序運行時就是有錯誤，讓其他同學幫忙看了一下，發現其實是個很小的錯誤。所以說，相互幫助是很重要的一點，這在以后的工作或生活中也是很關鍵的。

　　俗話說：“要想為事業多添一把火，自己就得多添一捆材”。此次實訓，我深深體會到了積累知識的重要性。在實訓當中我們遇到了不少難題，但是經過我們大家的討論和老師細心的一一指導，問題得到了解決。兩個月的實訓結束了，收獲頗豐，同時也更深刻的認識到要做一個合格的程序員并非我以前想像的那么容易，最重要的還是細致嚴謹。社會是不會要一個一無是處的人的，所以我們要更多更快地從一個學生向工作者轉變，總的來說我對這次實習還是比較滿意的，它使我學到了很多東西，為我以后的學習做了引導，點明了方向，我相信在不遠的未來定會有屬于我們自己的一片美好天空。

軟件開發學習心得 篇9

　　國貿軟件實訓心得體會(793字)經過長時間對國貿軟件的的使用，在不斷練習操作的過程中，我對國貿軟件的最深刻感覺是：學以致用、有趣、必須細心耐心反應迅速。

　　1.學以致用

　　作為國貿專業，經過長時間的理論學習，急需通過實際操作或某種近似于實際操作的平臺對所學的理論知識加以實踐，以求進一步掌握和鞏固，而國貿軟件正提供了這樣一種平臺。該軟件涉及了及出口貿易的各個方面和環節，從外貿公司的經營運作到實際的進出口業務流程，都能進行模擬實訓。在使用過程中，會遇到很多國貿的基礎理論知識和實務技能，這是對國貿理論掌握程度的最好考察。眼過千遍不如手過一遍，相對于理論部分而言，國貿實務更注重實際操作，通過這種理論結合實踐的方式，鞏固基礎知識，查找理論學習的不足，以前學習的實物理論基礎知識會更加的具體和直觀。同時，該軟件的實務操作部分與報關員報關實務所涉及的知識基本一致，這對于我的報關員考試復習提供了很大的幫助。

　　2.有趣

　　該軟件通過“實戰”方式訓練，會在操作過程中遇到很多難題和挑戰，這些必須自己想辦法解決。由于大家進行了角色劃分，形成了一個虛擬市場，所以大家之間相互的競爭是必不可少的，大家會從各個方面進行競爭。競爭在現在是無法避免的，意識正是現代社會生存發展所需要的。正是這種競爭，使得我(相信大家)對該軟件產生了濃厚的興趣。

　　3.細心、耐心、反應迅速

　　國貿軟件涉及大數據計算的繁瑣的單證填寫，所以必須做到細心耐心，例如，在填制外貿合同時，一個小小的數據錯誤或是貨物裝運、指運港名稱的錯誤都會是合同填寫失敗;填寫保險單或是報關單證，沒有嚴格按照合同數據填制就會導致填寫出現錯誤，無法進行下一步驟，影響實驗效率。

　　在操作過程中，除了復習、鞏固所學國貿理論外，另一個重要任務就是想辦法“賺錢”，提高自己企業的盈利水平和生存能力，這就要求必須反應迅速、判斷準確，否則會覺得企業經營的舉步維艱。 以上就是經過一段時間對國貿軟件的操作使用產生的心得體會。

　　軟件實訓心得體會四：軟件實訓心得(778字)轉眼間，到昆山已經兩個多月了。不知不覺中我已經從一個在校生變成了一個職員。這跟在我們學校是完全不一樣的。除此之外，安博還制定了嚴格的制度，這些使我們在安博的培訓像職工在公司工作一樣，讓我們提早接觸到公司的氛圍。

　　來安博最重要的目的還是學技術，那就說說這里的教育情況吧。安博實行的是上午授課，下午上機練習的制度。我覺得我們這個班上午的授課經理非常好，他對java的理解非常透徹。我在大學學了半年的java，僅僅停留在表面上，對實質的內容根本都不了解。比如說==與equals的區別，方法的覆蓋，變量的隱藏等等。老師通過圖的方式，給我們講解它們在內存中的情況，使我們從本質上了解了這些東西。他的這種授課方式，既生動又形象，徹底地將問題講明白，我們接受起來輕松容易，也不容易遺忘。

　　除了他的講課方式以外，他還是一個非常幽默的人，坐在凳子上聽四個小時的課，會很乏味的，他時不時的給我們說一些搞笑的事，或者開玩笑的話，使課堂氣氛非�；钴S。他每講完一個新知識點，都給我們留一點時間練習，加深對新知識的理解。我們有什么問題，他都會很耐心的跟我們講解，不管程度是好是壞，他都一樣對待�？傊�，聽他的課就是一種享受。他還把跟知識相關的材料發給我們，讓我們有研究的空間。有時還給我們一些面試題，讓我們提早看，只有準備好了去應聘才有機會。

　　昆山還給我們開了一些素質課，講解一些職場素質，如何為人處事，如何同面試官講話，還要求我們在日常生活中也盡量做到。在我們就業之前開這樣的課，對我們這些即將踏入社會的大學生來說是非常重要的。公司招聘員工，一看實力，二看素質，兩者缺一不可。

　　總之在昆山的這段時間中，我學到了很多。時間雖短，但所學到的和知識的實用性很強。所有的老師們都教給了我們很多工作習慣、工作技巧、日常禮儀、職業素養和心態方面的東西。使我們對今后的工作有了新的認識，增添的極大的信心。

　　軟件實訓心得體會五：軟件工程實訓心得體會(1521字)這次軟件工程實訓是從20xx.12.26號開始的，截至20xx.12.31號。實訓內容是用java相關知識(主要是jsp)做一個物流配送系統。下面談談對這次實訓的看法。

　　因為自己平時對java知識儲備不足，特別是jsp這一塊基本不了解怎么回事，所以一拿到這個項目，我心里都是沒有底的，再加上我被分到的那個組，我知道就意味著是我一個人在戰斗了。呵呵，26號，實訓開始了，我們的老師是來自中軟國際公司的程序員，一個是周褀，一個是朱映，都是一身樸素的著裝，讓我感覺做軟件的也沒什么兩樣。老師介紹了自己之后，就直接切入正題了，分析了下我們各個組的系統，即將用到的知識，然后就總體把覺得需要補充的知識(jsp和數據庫連接等這幾塊)給我們實際操作了下，因為當時看到用jsp，還講的那么認真，當時我就后悔了，平時要是多聽點，現在老師這么認真的給我們講，這是一個多么難得的機會啊。后悔也沒用啊，開始還勉強能理解一點，后來就直接暈了。然后再給大家介紹了一些即將用到的工具，比如rationalRose，SVN，MyEclipse等等。接下來的幾天就不再細講了。下面談談通過這次實訓的心得體會吧。

　　通過這次實訓，讓我了解到工程開發的過程，可行性分析——>需求分析——>概要設計——>詳細設計——>代碼編寫——>測試——>驗收。從技術方面上，我開始jsp基礎基本上就是零的，在老師和syz2(另外一個物流小組，我一個人基本上是跟她們做的，或者說是看著她們做的)的幫助下，對jsp有了一個大概的認識。其實實訓開始前，我還以為做個系統沒什么大不了，可是當真正拿到一個項目，我卻真的無從下手了，而且就是在知道需求分析和詳細設計，在代碼編寫時，一樣寸步難行。通過這個實訓，也讓我了解到，團隊協作是多么的重要。一個人的精力是多么的有限。進一步理解到，企業為什么如此重視團隊協作。同時借用老師的話就是團隊協作固然重要，但是是建立在個人素質的基礎上，假設你個人素質不行，將會影響到整個團隊，就別提對團隊作更多貢獻了。**老師說這幾句話的時候，朝向了我，估計是有特殊意義的吧，所以，我將謹記老師的教導。

　　還有一個收獲是從一個同學(小胖)那里得到的，他的那組成員跟我的這組大體一樣，我倒是覺得沒什么了，不過他倒是很重視這個問題吧。然后他說出來，我也覺得這個問題確實其實是個大的問題。就是不管你會不會這門技術，會不會做這個東西，態度要正確才好，就算你不會做，你也應該認真的對待，將來 出身到社會，就不是說像你現在，不會做就不做，跑去玩游戲了。小胖說出了這段話，也在我身上有了一個印證，雖然我jsp技術知識為0，但我也還是在認真的跟著他們一起做，不會做，就多問，畢竟現在我們是學生，可以毫不顧忌的詢問各種問題，老師也會盡力為你回答。將來出身社會就不一樣了。雖然，我就算個打醬油的水平，但是這個醬油也要打得有涵量啊。不管怎么樣，我能對自己有個交待，雖然我不會，但是這次實訓我確實是認真對待了，六天的實訓，除了晚上加班外，還花了2個通宵來完成不同階段的任務，完成與否也不重要了，我至少我做了，這點，是這次我應該對自己的一個肯定。

　　這次實訓的心得基本上就是這些了，最后特別感謝中軟國際帶我們的那兩個老師(周褀，朱映)，這兩個老師對待我們很平易近人，對我們提出的問題，總是不光解決了，還進行了擴展，晚上也跟我們一起加班加到很晚，印象尤其深刻就是朱映老師為了給小胖解決一個問題，臉都變紅了，還在繼續努力，這點我并不會覺得老師知識儲備不夠，我想應該是這個問題的突發吧，一時沒想到怎么處理。相反讓我感覺更多的就是老師很認真，很負責。

軟件開發學習心得 篇10

　　我是公司一名文員，部門涉及很多業務數據的東西，在此之前，公司的所有業務記錄都是通過一張excel表格來完成，第一次看到那張表的時候是真心嚇到了，字段有幾十個，項下又有很多拆分合并，其中又大多為數據和日期，通過幾天的整理發現了不少錯誤，更加感嘆需要一個數據庫來解放人力、提高效率。

　　從開始接受access培訓到現在已經有半年時間，雖然上學期間學校的老師也有給我們講過access的知識，但只是講了些關系的建立及簡單的查詢，以為access就好比word、excel等相對比較簡單的辦公軟件一樣。但開始接受盟威Access的培訓后，對Access的看法才改變，原來Access還可以這樣玩；參加學習之初，由于自身一開始認識誤區的心態導致自己走了很多彎路。一開始所有的Access老師就告誡我說一定不要心急，要按培訓指南指導，要按照教程一步一步做下去，切忌眼高手低。但因為心想自己對電腦還算有點感覺，加上公司一直比較急，又很想短時間內做出點東西，就沒有很耐心的把教程步驟做完，導致后期回爐再造無數次耽誤很多時間，在這里希望大家引以為戒。

　　在學習的過程中，因為老師是一個階段一個階段發教程的，當我看到報銷系統時，就已經覺得十分十分的強大了，然后自己就想邊看教程邊偷懶開始自己開發，雖然老師一再強調不能不會走就想跑，但自己還是開始蠢蠢欲動了，等到做了一部分之后看到了進存銷系統后，又發現里面有很多自己可以學以致用的東西，然后又開始重新做，再等到新版的快速開發平臺出來了，自己又一次被震撼了，感慨Access快速平臺的強大，基本的模塊都不需要自己手動創建了，簡直太厲害，真是技術宅改變世界。

　　整個開發過程可以說是充滿艱辛，但又有很強的成就感。雖然自己有時候會想不出來該怎么做，但是！還有一群很厲害的老師可以幫你，有時候老師們一句話、一段代碼就能幫我搞定自己苦思冥想很久都做不出的步驟，可以說每一個成功的系統背后都有一群默默無聞的老師。

　　每次把自己一些亂七八糟的想法告訴一對一老師，其實自己都覺得可能做不了了，但每次杜老師都會給我驚喜，幫我完美解決掉，十分欣慰。

　　現在系統開發的已經在測試應用，雖然還有些部分在一步步完善修改，但我相信access的強大，能解決我的數據問題，也相信盟威老師們的技術給我的支持，在此感謝這半年來所有老師的大力支持與幫助，也希望盟威軟件快速開發平臺做得越來越好，讓更多跟我一樣的菜鳥開發出屬于自己的數據庫軟件，解放自己的工作強度。

軟件開發學習心得 篇11

　　立項前

　　1、統一元素設計需考慮周全

　　也許是初創團隊的緣故，我不得不感嘆團隊對產品經理要求之嚴格之縝密，項目全程只有一個人負責，所以大到產品線對接，小到一句提示的位置和展示形式都需要一一推敲。

　　哪些元素應該做到統一

　　a、提示方面：統一的操作成功/失敗提示;統一的彈窗形式;提示語言采用較統一的句型;為空情況的友好提醒;溢出情況的友好提醒;表單實時驗證的提醒形式等。

　　b、文字方面：是否有統一的段落前“·”號;統一的鏈接狀態;統一的字體、間距、行高等。

　　c、圖片方面：調取圖片的統一尺寸;如果是上傳圖片類的操作，需要考慮周全全站的調取情況，以及考慮是否統一預覽圖的尺寸等。

　　d、細節交互：未激活功能的按鈕做“灰色”處理(例如用戶沒有勾選信息時批量刪除按鈕不可使用);按鈕點擊的狀態統一(例如增加“提交中”的按鈕狀態，以防止網速慢用戶狂點某一按鈕的情況);特殊控件的統一等。

　　也許會有朋友說，上面有些是交互設計師需要做的事，但我一直認為作為一個產品經理考慮周全一些，沒壞處。這些“統一”同樣可以用在驗收階段，要知道，即使一個像素也可以改變整個產品的感覺。

　　2、原有功能的去留

　　我一直覺得升級已有產品比開發新產品難一些。這就像栽培植物一樣，新種下一棵果樹無非需要選對了土地，然后刨個坑種下去，然而成長期的去病枝、打頂等各種修剪所消耗的精力往往更多。

　　改進已有產品常常需要面對一個最棘手的問題：原有功能是去是留?

　　原功能去掉的話是不是會影響部分用戶使用?是否需要通過公告、站內信、界面引導等方式友好地告知用戶?怎樣把對用戶的傷害降至最低?

　　原功能留下的話是不是可以優化完善?聽到了什么用戶群怎樣的聲音?是否要在這次升級中做調整?

　　這些問題當接到項目的時候，產品經理就應該考慮周全了。特別需要注意的是，如果這個產品之前不是自己設計的，那么最好找到prd說明文檔細細研究一遍，對把握不準的功能點找到原負責人確認，畢竟樹苗是ta摘的，別把將來最能結果的枝干給砍了。

　　3、產品線上下游的對接

　　昨天有跟朋友聊起淘寶強勢之處，就是產品與產品緊密捏合，線上線下、跨平臺跨行業形成了一個盤根錯節、根深蒂固的根基，無可撼動。

　　所以把握產品線上下游和產品周邊很重要，即使一個看似簡單的新聞展示頁面修改也會牽扯到編輯后臺、廣告位管理、幫助中心，甚至是訪問統計、數據需求的變更。

　　這要求在產品設計開始前，需要把該產品“連根拔起”，仔細梳理相關脈絡，如果產品線夠長，一個清晰的產品線結構圖很有必要。

　　項目中

　　1、項目期間來自相關產品線調整的影響

　　項目期間相關產品線的調整是我最不愿意遇到的情況，這就像你在通往目的地的道路上高速行駛，就快要到達終點了，突然一個人告訴你：你走錯路了。

　　項目里有一個通用模塊，產品設計到一半，這個通用模塊改了;項目里有一個流程，產品做到一半，這個流程廢棄了;最要命的是已經立項開發了，你不得不硬著頭皮跟程序員說：“因為一些不可抗拒原因，這個需求咱不做了。”

　　對于一個耗時較長的項目來說，這種情況難以避免，事出原因私自總結有三：

　　a、嚴重體驗性問題：例如某個流程遭到大量用戶的不滿，為防止用戶流失，不得不做臨時調整，而倒霉的是，你也在用這個流程。

　　b、相關項目的影響：包括并行項目和新項目。例如你的同事在設計另一個產品，你們的產品相互牽扯較多，所以需求分析時做過很多溝通，但有一天，同事告訴你，ta的一個需求做臨時調整了會影響到你，怎么辦?

　　c、老板的突然決定：不舉例。

　　最終的解決方法不外乎三種：立即調整、延期調整、不調整。個人的處理原則一般是對a種情況進行立即調整，對b、c情況討論并選擇性延期。

　　為什么這么做呢?a情況是必須要改的，時間早晚問題，長痛不如短痛，b、c兩種情況必須坐下來細細討論。需了解這個需求為什么要改?是長期對策還是臨時決定?能否延期，記錄需求等下一版本再開發?如果b、c情況提出來的需求沒過兩天又有改變，那與你配合的前端和程序員也太沒有安全感了。

　　這個時代能耐心閱讀完枚漢字的人越來越少，較大型項目的產品工作心得[下]未完待續，歡迎交流……

　　2、需求變更

　　承上，需求變更是每個程序員、產品經理、設計師等都會遇到的情況。產品經理不是神，項目組也不可能是開了無敵狀態抵擋任何外界的影響。

　　當遇到不得不變更需求的時候，產品經理應該怎樣處理呢?下面是個人的四條建議：

　　a、積極處理。往往，當一個設計愈是趨于完成，人們愈是傾向于局部調整，而不是做重新設計。當一個需求因為眾所周知的原因不得不調整的時候，作為產品經理需要做的第一件事便是積極面對問題，積極處理。

　　項目開發往往是一個緊張的過程，每半天甚至每幾個小時就有若干個功能點開發完成，當一個需求變更傳達出現“延遲”，這個變更對項目的正常進程的“破壞力”就會更大一些。

　　b、保持溝通�！罢f話容易，溝通很難。很多事除非對方自己想明白，勸是沒有用的。所以，很多時候，溝通是個自己掙扎的過程”這話沒錯。需求變更直接會影響到下一道工序，產品經理需要將需求變更的細節和原因傳達給相關人員，包括視覺、前端、程序、測試等。

　　這是很多產品經理表示非常痛苦的過程，因為可能會遭到數落和冷眼，日本有一個禮儀原則是“不要給別人添麻煩”，但是在項目中，這不可避免。

　　個人認為所有溝通的障礙都源于思想的不統一，如果讓大家覺得這個需求修改是在浪費時間，那么溝通上的不暢快在所難免。項目不是這樣算的，需求既然更改一定有所目的，產品經理需要將這個原因講明白，不做修改或節約溝通時間導致的返工，后果往往更嚴重。

軟件開發學習心得 篇12

　　在大學里的最后一個冬天，我完成了3個月的實習，實習對我而言是一個難忘的.體驗，讓我不論做人還是做事都改變了很多。 總的來說，雖然說不上樂在其中，但實習的確是一段充實而有意義的事。

　　實習期間積蓄了太多太多的感悟。 借此機會跟大家分享一二。

　　感悟一: 當我們進入社會工作，就先要進入各種規范中去。

　　作為一個軟件開發人員，記得在我第一天進入公司實習的時候，首先要學習的就是編程規范。 相信每個搞開發的同學都跟我一樣吧。

　　編程規范在學校里是十分不重視的。 老師也不會硬性地要求學生要遵照怎樣的規范去編寫代碼，實驗或者作業什么的，只要能實現功能就ok了。 但是公司卻不一樣，公司的代碼并不是一個人編寫，別人很可能需要閱讀甚至修改你的代碼，閱讀一個不符合規范的代碼，所需要的時間可能比重新開發還要漫長。 代碼規范的重要性是不言而喻的。

　　當然，作為一個開發人員的前提，我還是公司里的一個員工(雖然不是正式的。。。)。 我還必須遵守員工的規范。

　　其實員工規范也沒有什么特別多的要求，個人認為就跟上學差不多，雖然規范是差不多，心態上卻有著很大的差異。 原因無他，你到學校是自己交錢上學，上班卻是別人發工資給你。 拿了人家錢，還要擾亂人家的規范，這種事我還真干不出來。 看來錢不論到哪里都是一個問題，呵呵

　　感悟二: 我其實是一種很唯心的動物

　　其實本來，我是寫"人其實是一種很唯心的動物"，但不知道別人是不是也這樣，雖然我覺得是，卻無從考究，還是嚴謹點。

　　為什么說我唯心呢? 當我心里把自己當作一個學生，跟把自己當作一個上班族時，在各種細節上都會不一樣，例如那有點虛無縹緲的"氣質"，或者是說話的語氣。

　　這個大概是"站在不同的高度，看到不同的風景"吧。 正如老總看的是公司發展方向，主管卻在看業績，經理在看項目，小弟們在看代碼。。。

　　感悟三: 設計模式很重要

　　設計模式是我到公司才接觸的事物，主要是講述一種面向接口的編程思維，按照設計模式所編寫的代碼，會比學校那種直接實現功能的代碼繁瑣一點，增加很多看似多余的虛類或者接口。 但是這種代碼更加具有拓展性，更好地把數據封裝起來。 在增加狀態，增加類的時候，并不需要修改過多代碼，這種代碼對于版本升級尤其重要。

　　在公司培訓學習中，我總能很快地掌握各種設計模式的要領，獲得上司的好評。 但是我明白，設計模式真要應用到代碼中去，是要培養一種習慣。

　　個人觀點好像說得有點多了，下面說說我這3個月里的實習情況。 總的而言，我到公司接觸了2個平臺，一個是現在很火的android，另一個則是nokia的qt。 android 用的基本是java語言，其中還會帶點xml語言; 而qt用的則是c++。

　　對于這2個平臺，用著的感覺其實大同小異，用我上司的話說，基礎打好了，語言就不應該是障礙。 感覺挺有道理的。 想當年我作為一個vb助教，卻沒半點vb基礎，對vb那些基礎問題還是可以比較輕松地解決，這跟我其他程序語言基礎比較好有著密不可分的關系。

　　android平臺的一個基本窗口是一個activity，除了基本的activity外，還提供listactivity和tabactivity這些拓展的子類，每一個activity都可以看作一個窗口，一個進程可以有多個activity，每個activity都擁有一個view，view可以通過xml設定，當使用activity的子類時，必須注意這些子類的xml必須含有特定id的控件，或者不用xml實現view，系統會有一個默認的xml去實現那些一個基礎view并且實現必要的id。

　　在談到view，那么就必須說到layout了，android的layout很強大，最基礎的是橫向或豎向的排列布局，另外還有網格，表格布局等等。 掌握好布局的方法可以讓我們對界面設計事半功倍。

　　android有趣東西有很多，在我完成那個移植應用的時候，android總能給我一些驚喜，例如popwindows這個設計，他作用是彈出一個窗口等，或者你可以把他看作一個acticity，效率卻比activity快很多。 利用popwindows，你可以做出風格各異的消息框，菜單欄，下拉菜單等等。

　　另外還有一個抽屜類也很特別，他就像觸屏系統的解鎖一樣，拖動手柄，便可拉出一個界面，這種設計大大地節省應用的空間，減少切換界面的操作，從而降低應用的功耗。

　　告訴大家一個很多人不注意的地方，android應用如果進行橫豎屏幕切換的時候，進程會完全關閉后，再重新打開的，因為android做了保存狀態的操作，所以很多人會以為屏幕切換后，進程還是本來的進程。

　　qt跟android有很多共通點，例如android的activity就如qt的qwidget，當然，他們的狀態機有著很大的區別。

　　qt最大的特點是他的信號槽，通過信號和槽的連接，可以把很多類與類間相關的函數連接在一起，甚至可以傳遞參數