web學習心得體會

[寄語]web學習心得體會共含2篇，由本站的會員投稿推薦，小編希望以下多篇範文對你的學習工作能帶來參考借鑑作用。

第1篇：web學習心得體會

本文是本站的網友推薦，並由本站編輯整理的web學習心得體會範文精選，僅供參考。

所謂行萬里路，必先始於足下。剛開始學習WEB前端基礎的時候，老師說，其實你們學的這個後面真正去工作的時候可能也不是很會用到，所以就有很多人會問，既然我們都用不到，那幹嘛還學呀？其實，對於一個程式設計師來說，你不僅要有很好的後端專業能力，你還應當具備一定的前端素養，知道一些起碼的前端知識。

來到傳智的第一個月，我們是以基礎為主吧，因為大家到這裡的基礎都不一樣，有一些本身就具備很高水準的人，也有很多像自己一樣從小白開始的人，所以，對我們而言，傳智開設的這種雙元模式對我們是有很大用處的。我們從最基礎的開始學習，在學習HTML的時候，我們還延續著很古老和古老的表格製作網站，然後到後面的CSS學習，用CSS樣式去進一步完善我們製作的網址，再到著一期的難點JS課程體系，一級最後的JQ和BOOtstrap，可以說這個過程其實也是一個循序肩頸的過程，有簡到難的過程。

首先我們回顧一下最開始我們對HTML的學習。

其實HTML的四天學習的話，重要的就是一個標記的學習，這大概是學習一門語言最基礎的一部分吧。但是也不是說背一背就解決問題的，選擇IT，程式設計師這一方面，只要多練習，多敲程式碼感覺就好了，所以熟練的使用這些標記其實不是很大的問題，對自己來說，比較難的是一個表格和框架，也許會有人說，表格有什麼難的，就行列的問題啊，但是不知道為什麼，在學習的那幾天對於表格的學習和接受能力都沒有別的那麼好，表格的整體框架能搭出來，但是就是對於表格的美化總做不到自己心裡所預期的那樣。其實練習的話也是挺多的，對於表格的網頁練習做了應該也有一二十個的，但是就是沒那麼理想，所以這方面的話也是需要自己多加練習和修正的，因為表格的用處還是挺大的。HTML的學習方面還有框架和表單，框架的話，就是一個網頁的主體了，網頁的大致形式基本上從你的框架結構就可以知道的，學習框架，重要的就是網頁的佈局如何劃分，然後利用框架的巢狀，浮動就可以解決的，學習過程也不會是很大的難度。

想想HTML還學了些什麼呢？表單！表單對前端開發來說還是挺高的，因為我們能在一個網頁中看到很多的表單應用。包括使用者的註冊啦，密碼驗證啦，還有搜尋欄之類的，幾乎全是表單的應用。表單學習比較重要的地方應該就是那十來個表單控制元件的應用，這些表單控制元件進一步區分的話還有就是單邊標記和雙邊標的的表單控制元件，因為很多單邊標記的表單，他的值一般只能是存在value當中，如果不注意的話，很多時候我們會忘記寫上這個value。這個階段的表單感覺並不是那麼難，當然，學到後面的JS之後，相對於表單驗證之類的才感覺難了很多。

第二部分：CSS學習

對我來說，CSS課程雖然只有三天，但是卻是更應該學好的一個模組。因為我們都知道，其實一個網站的WEB前端，就是用加CSS來寫的，不是用之前的表格來寫的，足以見得CSS的重要性。CSS就是網頁樣式，一個網頁的整體美感，在你確定了框架之後，就看你的CSS樣式的添加了，所以一直以來都很想把CSS學好。記得CSS學習的那幾天，自己的消化還是很好的，自己去獨立完成練習的時候也是沒有太大難度的，但是不知道是為什麼，到後面學習JSJQ的時候，操作CSS時居然會吧CSS和HTML弄的有點混淆，這一點一直沒做好。CSS的學習還有一個地方就是浮動，因為存在塊元素和行輩元素，塊元素因為其本身特性，一個塊元素標記他要佔用一整行的空間，而一個行內元素他只能佔用行內的一些空間，但是在實際操作中，很多時候我們卻要想將多個塊元素排在同一行，或者將多個行內元素排在不同行，這時候就可以使用浮動的方法來實現，浮動最主要做的就是這個，唯一要記住的一點就是做了浮動之後，如果他的父元素是沒有進行匡高的設定的話，是不是要進行清除浮動，防止下面的操作也是有浮動的。

第三部分：重點學習——JS

JS是相對於這整個月學習的重點吧，也是很多人沒辦法很好接觸的地方，當然，自己在這裡的學習也是有不足的地方。像一些對屬性的操作的標記之類，懂得怎麼用，但是不是很熟悉，所以經常在操作的時候要去查手冊。學的最不好的一個地方應該是將陣列中的元素按照一定的規則或者順序新增到指定或對應的表格中，這中題型是自己做的比較少的，也是掌握很不好的地方，所以也希望用放假的這幾天好好練習一下，不能拖到下一個階段去。個人對JS的理解其實就是大量演算法的集合，因為很多時候你都會用到函式，只是多了一些找元素和對元素繫結標記的過程，最重要的還是建構函式，呼叫函式的過程！

第四部分：JQ及Bootstrap

對於JQ和Bootstrap的學習來說，其實就是一個應用的過程吧，所有的函式都幫你寫好了，你只需要學會呼叫就好了的。當然。呼叫他，其實對於JQ來說，學習的過程沒有具備很大的難度，只是嘗試著去多寫寫，寫兩三次基本就記住怎麼用了。最後還有一天的Bootstrap學習，寫過一些案例，只要會改，基本沒有太大的難度。

後續：其實對於WEB前端的學習的話重要的就是多用，很多東西我們上課聽得時候其實都基本聽得懂，但是更重要的是在於你課後的練習，離開了老師的一個思維引導，我們該怎樣去完成專案才是我們該學會的。這一個月的學習難度係數都不是很高。但卻是一個比較繁雜的過程，因為作為前端來說，我們需要不斷的優化，不斷的修正，美化整個頁面。不管是前端還是後端，都希望自己能好好學！

第2篇：web學習心得體會

猜你正在找web學習心得體會的怎麼寫？那麼就給你這篇範文參考。

算起來我學習軟體設計也有快一年了，感到做這個工作最要緊的就是要明白，什麼叫因地制宜、因勢利導，就是說只有最合適的，沒有什麼叫對的，什麼叫錯的。我們的根本目的就是賺錢，而不是什麼研究機構，所以最忌諱的就是完美主義傾向，尤其是我們這些做技術人員出身的，喜歡尋找標準答案，耽誤了工作進度，也迷茫了自己。

在這個寒假裡，我也接過一個網站來做。先不論這個網站的好壞，首先，我的的確確在這裡面學到了很多東西。因為是我一個人做，所以也不可能做什麼大型的網站。在這個過程中，我真切的感到和客戶溝通才是最重要的。不管你的技術有多麼的好，能做出多麼漂亮的網站，但你做出的東西不是客戶想要的東西，你也只是徒勞，畢竟我們的目的就是賺錢。還有就是和客戶溝通的時候，千萬不要滿口的專業術語，（除非對方也懂這些）不然就會費更多的時間。當然在做專案的時候首先是要做好詳細的需求分析書，一份好的專案說明書不僅將要做的事情描述得很清楚（主要是講做什麼，而不是說怎麼做），而且把如何檢查也說明得很透徹。也就是說它不僅說明白了要做哪些事情，也讓客戶的業務人員（一般不懂技術）知道專案做成什麼樣就算完成了。簡單地說，專案說明書描述專案做哪些事情和每件事情做到什麼程度以及如何檢查每一個結果。

就像我們上學期的Web專案，我們都有一個專案小組。當然，在做這個專案時我們沒有自己選擇組員的權利。所以當我們成為一個專案小組的成員時，我們要做的就是要懂得互利共生的道理。特別是專案經理，對於專案總監、專案成員，要讓他們知道你打算怎麼做，什麼時候要他們做什麼準備這些事情將是你的主要工作。第一個是規定資訊的流動方式和介質，是推還是拉。推的意思就是專案經理將主動釋出資訊，不管通過電話、郵件還是書面方式，保證將資訊傳達到每個人，拉的意思就是我們需要什麼資訊就去問專案經理。說這些看似很無聊，其實裡面牽涉資訊傳達不完全的責任問題。

例如我們中有一個專案小組，就因為專案經理的前期資訊傳達不到位，而導致整個專案小組的進度不能跟上，團隊分得了零分。分數倒是小事，但要是我們走上了工作崗位，而不能按時交出客戶想要的產品，那可就不好辦了！

第二個問題就是文件問題，很多人怕寫文件，但是專案經理一定要牢記"好記性不如爛筆頭"的道理。有理有時候為什麼會說不清呢？就是因為沒有證據。所有需求變更全部要有書面文字，這點切記！這樣做好處多多：有書面證據，以後他還想改，你有了他以前要求的證據，告訴他：你以前可是這麼說的，便於需求變更管理，需求如何慢慢演變的歷史可以看清楚，從而更深切地體會客戶的目的，對於客戶來說，嘴巴一動最方便，反正是我們做，不花他的資源，所以要求是否合理，是否和專案的目的一致，他是不負責任的。但是如果要他寫書面要求，還要簽字蓋章，他就要謹慎多了，而且一寫東西，思想就會更加深入，很多無理要求也就這樣胎死腹中了。

其實，上學期的專案中，我們很多的組員意見不統一，就造成了意見剛剛達成，過來沒幾個鐘頭，又有人有好的點子，結果想更改計劃，最後改得什麼都不像。寒假的這個專案我也感到文件的重要。就比如說一次我正和他們中的一個老闆談得快達成協議了，這時，另一個老闆又來和我交涉。但是兩個老闆的意見不和，我也一時難以把握。最後，我決定由他們選出一個人專門和我交談，當達成協議時，就形成紙質檔案，由雙方簽字通過。

當然，在上學期，各位專案經理對自己職務的職責範圍還不是特別的明確。下面就說說我對這個職位的理解吧：和組員開會，除了一些專案進度跟蹤會議以外，還有很多討論會，需要大家用頭腦風暴方法給出解決問題。與會人員很多都是技術人員，他們的特點是注重細節、缺乏大局觀、有點消極悲觀、自尊心強，所以，你作為會議的主持人，只要負責提出問題和記錄下他們的觀點，千萬不要做評判者的角色。一個問題，有很多方面，從不同的角度看，現象是完全不同的，想想盲人摸象的故事吧。作為技術人員，他們往往精通一個方面，就自己的角度發表見解，除非一些很特別的情況，你都應該認為他們提出的方案，從他們的角度來看是最合理的'。專案經理的長處是掌握事情的優先順序，評估各個方面的輕重緩急，從而根據他們的意見得出一個合適的（而不是正確的）方案。所以，在會議上，你要充分尊重每一個人和他的意見，誇獎那些意見提得比較好的人，千萬不要把會議帶入無休止的爭論（你要讓大家知道事情不是非黑即白的，而是多元的）。會後，你自己整理結果，寫文件，做決定。會議上大家的面子都被照顧了，自然實施起來的阻力就小，如果還有意見的，你就私下找他聊，如果還不能說服他，你就要讓他明白，因為是你負責這個專案、你要擔當風險，所以，這個優先順序應該你來判斷。組織中的高層，並不見得水平會比一般的成員高，但是，他要承擔組織的風險，加之資訊的不對稱性，所以，對事情的優先順序的判斷肯定應該要比下屬強。

說了這麼多，還是想說說這次的專案，其實從這次軟體中心舉辦的“主導杯”班級主頁大賽中，我獲得的最多。由於以前有過專案經驗，所以這次我們的專案也逐漸接近了正軌。但看到好多組的工作方式實在是很感慨，大家對待專案的目的和流程並不太瞭解。所以我對專案作了一個總結：

在專案開始的時候組隊是很關鍵的，在選擇人員的時候一定要對組員進行一定的考察。其實同學們都算比較瞭解了，建議最好熟悉的人在一組，其一是方便溝通，其二則是方便管理。朋友即使有了矛盾很快就能化解，不過要注意的是不要放不下面子，特別是專案經理，千萬不能怕得罪誰（遇到問題時可以找其他組員先商量，在作決定，實在不行可以提出嚴厲的責罰，不過這只是下下策）。其次是專案經理千萬不要把自己當成是那麼一回事，說白了，大家都只是合作關係，沒有誰絕對服從誰。而更重要的是要有一個明確的制度，並讓所以組員對制度進行簽字。有了這樣的東西，在一定程度上能對組員起到不小的約束力。

接下來我們就要開始進行專案的需求分析書了現在是做專案說明書的時候了。一份好的專案說明書不僅將要做的事情描述得很清楚（主要是講做什麼，而不是說怎麼做），而且把如何檢查也說明得很透徹。也就是說它不僅說明白了要做哪些事情，也讓組員知道專案做成什麼樣就算完成了。簡單地說，專案說明書描述專案做哪些事情和每件事情做到什麼程度以及如何檢查每一個結果。一定要提前做出統一的模板，這就是一個風格的定位，有了這個定位相信大家在以後的工作中會順利很多。

現在專案已經完成了前期工作，瞭解了專案的目標、搞清楚了手上的資源，制定了專案的策略，然後編制了專案的整體計劃，專案進入實施階段。進入這個階段反而是專案經理比較空閒的時候，不像前期的時候專案經理要像記者一樣到處和不同的人接觸，搞清楚他們在說什麼，努力猜測他們在想什麼和他們的真正目的，那才是最累人的事情。當然，小專案的專案經理往往自己也是一個資源，要做很多事情，這時候反而比誰都苦。專案經理這個時候就要多和技術經理和行政經理多溝通，實時瞭解大家的工作情況和進度。當然這個時候和組員溝通的工作大部分交給了行政經理和技術經理手上了。這時你們要做的就是要多瞭解大家對這次專案的態度和想法，收集整理之後向專案經理彙報。當然並不是說專案經理就沒什麼事了，你要做的則是和老師溝通，畢竟老師是一種資源，有了老師的幫助，相信我們的專案會有更進一步的飛躍！

有一句話叫做細節決定成敗，專案的過程中一定要注意細節問題，如圖片的大小，太大了會佔空間，所以建議大家在用之前先用PS改變影象的大小，作為使用者都不希望軟體太大，這一點很多玩遊戲的同學相信更深有體會。在改變影象大小的時候建議大家按照原始比例來改變，最好一次就將原圖改變到需要的大小，不要破壞了圖片的結構（如果有特殊的要求除外），不然影象的質量也會受到一定程度的影響。儘量少用音視訊檔案（專業的音視訊網站除外），如果實在要用，就提前用專業的軟體對其進行壓縮。其次就是配色問題，一個網頁的色彩最好不要超過3種，一面視覺效果混亂，用色柔和，對比度強的色彩不能應用於一般網站，時尚網站使用還可以。一般不好搭配的顏色，用灰度搭配。再次，就是整體的頁面佈局，最好在初期做好一個規範，這時就體現了css樣式表的重要性，對不同的字型定義不同的樣式，以後每次用直接呼叫就可以了，這樣專案的工期也縮短了一大半。還需要注意的就是資料庫的編碼規範，圖片、音訊檔案等的命名規範以及對檔案的命名規範。後期我們要安排更多的時間放在測試上，測試是非常重要的，當你的網站或者軟體完成了，但是有一個功能不能實現，也許只是一個小小的問題，但也會對你的產品造成更大的漏洞。也就是說花了那麼多的時間去做專案，然而專案完工了，卻是個不合格產品。

其實做網站或者軟體總結起來就幾個字：佈局合理、介面美觀、功能完善、操作簡單、壓縮大小。

當專案做完了，我們就要面臨殘酷的答辯關了，當然，在面對答辯的時候我們不必慌張，要做到有理有據，大方得體，在答辯之前做好一個答辯的流程，先介紹什麼，在介紹什麼。不要像上學期那樣一個一個都上去講。其實只需要一個人演示，一個人講解就可以了，演示的人一定要注意講解人的語言，不要講解人已經講到下一步了，演示人還沒有反應，這也是對我們配合的一種鍛鍊。講解的時候要注意從哪裡開始，是從內到外，還是從整體到區域性，這是開始的時候需要大家一起商量的。當然在演示的時候難免會出現錯誤，特別是這學期我們學的asp動態專案，當我們遇到某些功能無法執行時，也不要慌張，我們要從理性的角度分析這種問題是因為什麼原因所產生的，當場給評委做出解釋，如果不能分析出來也不要緊，你可以告訴評委們，這個問題的原因我們待會兒再給大家解釋。到了後面即使你還是不能找到原因所在，你完全可以不說，評委也不會去刻意去追問你是什麼原因。這樣的目的是為了大家在做答辯時能夠順暢的完成，不會就直接跳過，不會產生什麼尷尬的場面。

專案做完後一定要記得儲存好自己的產品，這是我們以後找工作的一份憑證。當然每次專案完後一定要記得寫專案總結，收集專案的一些必要的東西，如專案管理文件，專案進度跟進表等等，這樣對我們以後會有很大的幫助！

最後，我想對我們上學期期末的專案答辯做個總結：上學期期末的答辯總體來說還算不錯，有優秀的專案，當然也有很不上面的專案作品（我們總不能要求所以的東西都達到理想的效果吧！）。所以，從這些優秀的專案中我們確實學到了很多，而且我們還從那些不那麼優秀的作品中找出許多的不足。總的來說，我們是在專案中快速的成長，快速的壯大！希望我們以後的專案做的越來越好，能有更優秀的專案出來，讓我們一起努力，把軟體做得更好！

本站的小編希望你能喜歡以上2篇web學習心得體會範文，你還可以點選這裡查詢更多web學習心得體會範文。