web前端實訓心得體會(通用5篇)
當我們對人生或者事物有了新的思考時,常常可以將它們寫成一篇心得體會,這樣可以幫助我們總結以往思想、工作和學習。相信許多人會覺得心得體會很難寫吧,下面是小編為大家收集的web前端實訓心得體會,歡迎閱讀與收藏。
web前端實訓心得體會 篇1
一、實訓項目
簡易記事本
二、實訓目的和要求
本次實訓是對前面學過的所有面向對象的編程思想以及JavaWEB編程方法的一個總結、回顧和實踐,因此,開始設計前學生一定要先回顧以前所學的內容,明確本次作業設計所要用到的技術點并到網上搜索以及查閱相關的書籍來搜集資料。
通過編寫采用JSP+Servlet+JavaBean技術框架的應用系統綜合實例,以掌握JavaWEB開發技術。
具體要求有以下幾點:
1、問題的描述與程序將要實現的具體功能。
2、程序功能實現的具體設計思路或框架,并檢查流程設計。
3、代碼實現。
4、設計小結。
三、實訓項目的開發環境和所使用的技術
基于J2SE基礎,利用MyEclipse8.5以上版本的集成開發環境完成實訓項目,界面友好,代碼的可維護性好,有必要的注釋和相應的文檔。
四、實訓地點、日程、分組情況:
實訓地點:4棟303機房
日程:
第一階段:
1、班級分組,選定課題,查閱相關資料半天。
2、劃分模塊、小組成員分工半天。
3、利用CASE工具進行系統設計和分析,并編制源程序5天。
第二階段:上機調試,修改、調試、完善系統2天。
第三階段:撰寫、上交課程設計報告,上交課程設計作品源程序(每人1份)2天。
web前端實訓心得體會 篇2
一、實訓目的
通過對java語言、JavaWeb、Oracle數據庫應用設計及SQL語言的復習和鍛煉,并且通過使用MyEclipse開發平臺設計庫存管理系統項目,以達到充分熟悉開發平臺及其應用設計。
同時掌握并實踐軟件項目設計規范及其開發流程:需求分析、概要設計、詳細設計、代碼編寫、系統測試及軟件手冊編寫,以便提前適應軟件公司開發流程、環境和工作要求進一步了解java開發的相關知識,掌握java開發的基本技術,豐富java開發的實戰經驗。
學習SQL的基礎知識及正確的運用方法,和有用的相關技術,提高自己的工作效率。
通過實訓,培養我們綜合運用已學知識Java語言的面向對象編程能力;培養我們動手能力;培養我們良好編程規范、編程方法;以便能較全面地理解、掌握和綜合運用所學的知識,提高自身的編程能力;增強自己的團隊協作意識,了解軟件開發的思考角度和主要流程。
為畢業之后能夠更快地進入工作狀態并且能夠更好的工作,打好一定的基礎。
二、實訓主要流程
1、公司管理規則,程序員素質,程序員編碼規范;
2、需求開發與管理;
3、面向對象分析與設計,面向對象編程的特性;
4、javaSE、javaWeb、頁面設計—JSP頁面;
5、數據庫設計、SQL應用;
6、軟件需求分析與設計;
7、項目實戰;
三、實訓內容
Oracle數據庫
數據庫是數據的結構化集合。
計算機是處理大量數據的理想工具,因此,數據庫管理系統在計算方面扮演著關鍵的中心角色,或是作為獨立的實用工具,或是作為其他應用程序的組成部分。
Oracle服務器還有一套實用的特性集合,這些特性是通過與我們用戶的`密切合作而開發的。
在我們的基準測試主頁上,給出了Oracle服務器和其他數據庫管理器的比較結果。
Oracle服務器最初是為處理大型數據庫而開發的,與已有的解決方案相比,它的速度更快,多年以來,它已成功用于眾多要求很高的生產環境。
盡管Oracle始終在不斷發展,但目前Oracle服務器已能提供豐富和有用的功能。
它具有良好的連通性、速度和安全性,這使的Oracle十分適合于訪問Internet上的數據庫。
java與SQL的應用。
Java語言是編寫數據庫應用程序的杰出語言之一,它提供了方便訪問數據的技術。
利用Java語言中的JDBC技術,用戶能方便地開發出基于Web網頁的數據庫訪問程序,從而擴充網絡應用功能。
JDBC(Java Database Connectivity,Java數據庫連接)是一種用于執行SQL語句的Java API,可以為多種關系數據庫提供統一的訪問接口。
JDBC由一組用Java語言編寫的類與接口組成,通過調用這些類和接口所提供的方法,用戶能夠以一致的方式連接多種不同的數據庫系統(如Access、SQL Server 20xx、Oracle、Sybase等),進而可使用標準的SQL語言來存取數據庫中的數據,而不必再為每一種數據庫系統編寫不同的Java程序代碼。
web前端實訓心得體會 篇3
進入XXweb班近一個月了,從一無所知的小白到現在也完成了京東詳情頁的一個小項目。學習過程中除了偶爾遇到困難,總體還算順利。在這里主要想分享自己以一個文科生——零基礎學員的角度來學習web前端開發的感受。
由于之前在大學里是學的旅游專業,和計算機毫無關系,來到XX時對自己有些半信半疑。不少人甚至懷疑XX是行騙機構。在做了全面的了解之后,我勸服家人同意我來這里學習。另一方面,我向老師咨詢了自己學習的方向,考慮到自己從文科到計算機專業跨度較大的轉變,我在Java與web之間選擇了web。相對于Java,web的學習更基礎,容易入手,就業的機會也非常多。
Web開班第一天,老師即從網頁基礎、HTML入手,攫取重點,給我們介紹了它的相關知識。我們主要學習了HTML5,里面有很多的新特性且時下較為流行。它相當于一個網頁界面的宏觀架構。如果把一個網頁的實現比作是一座建筑的建造過程,那么HTML即是這座建筑里的鋼筋混泥土,搭建起整個建筑的框架、承重。
之后,我們又學習了CSS基礎樣式,仍然借用上面的比喻,CSS則相當于建筑里各個房間的不同結構,它們使得這座建筑更加的多樣化。且相對于HTML,它更加的復雜、多樣化,呈現的效果也具有更多的可能性。老師向我們推薦了《CSS禪意花園》這本書,里面列舉了豐富且多種多樣的.CSS樣式。
作為今后可能成為的優秀前端工程師,僅僅學習自己內部的知識是遠遠不夠的。因此,第一個月中我們也學習了UI中PS繪圖制作基礎,這對于一個前端來說也是非常重要的,在今后的工作中,我們可能會面對各種各樣的問題,如果掌握部分PS尤其是切圖技術,在和UI的接觸中可以減少很多不必要的繁瑣工作。
總之,作為一個前端工程師,我們所要掌握的知識是全面的,當我們寫代碼時的思維是縝密的。HTML和CSS是基礎中的基礎。之后我們會學習更多的JavaScript相關知識和其他,希望自己在這過程中仍能保持謙遜的的心態,去學習前人留下的珍貴寶藏。
web前端實訓心得體會 篇4
寫代碼的時候要伴隨技術文檔,不管是方便自己以后的閱讀和快速回顧,還是方便他們對代碼進行重構編輯,都是非常必要的。
一個人的對手不是別人,而是自己,不是自己的智商,而是自己的懶惰。惰于思考。
踏實:關于踏實,今天才算是有了比較深刻的理解。不是嘴上說自己踏實能干,不盲目著急,不做一點把握都沒有但是對自己影響很大的事情,不要想著什么事情賭一把也許會有好的結果。于是我決定自己的實習如果有機會就要延長,不要匆匆結束,而且不止要延長,要再接下來的工作中有所得,有所建樹,有所收獲,有所貢獻。
前端工程師要有基礎和潛力:基礎可以是根正苗紅的科班出身所學的技術。潛力就是踏實,務實的精神。我操真不是在嘴上說說的傻玩意兒。
如果遇到瓶頸難以突破(WEB前端工作了2—3年左右),可以考慮豐富自己的文筆,讓自己的代碼或者想法可以清晰的表現在人前。
作為一個WEB前端工程師要了解HTTP協議,為了與后臺打交道,可以更直觀的把握全局,也需要適當的學習設計模式那些blablabla的東西,與產品打交道。
“我對Web開發人員最大的建議就是:熱愛你的工作。熱愛跨瀏覽器開發帶來的挑戰、熱愛互聯網技術的種種異端,熱愛業內的同行,熱愛你的工 具。互聯網發展太快了,如果你不熱愛它的話,不可能跟上它的步伐。這意味著你必須多閱讀,多動手,保證自己的才能與日俱增。下了班也不能閑著,要做一些對自己有用的 事兒。可以參與一些開源軟件的開發,讀讀好書,看看牛人的博客。經常參加一些會議,看看別人都在干什么。要想讓自己快速成長,有很多事兒可以去做,而且付出一定會有回報。”
年輕的工程師需要更多的了解需求和設計、產品經理更要懂得軟件迭代規律。對于前端工程師來講更是如此,多學習交互設計和UI,多了解網絡協議和軟件迭代模型,更能幫助前端工程師和需求方溝通、和后臺的銜接、以及控制版本的迭代。
剛出道的校招同學往往更加心高氣傲,以為自己有改變世界的本事,一定要參與一個牛逼的團隊做一款光鮮靚麗受人追捧能給自己臉上貼金的項目。如果你有這種想法,趁早打消掉這個念頭,當然,我們這里先不討論創業的情形。
第一,如果你剛畢業就加入一個牛逼團隊,說難聽點,你就是團隊中其他人眼中的“豬一樣的隊友”,不創造價值且拖項目后腿(顯然大家都要照顧你的成長啊),按照271理論,你沒有理由不是這個1。至少相當長一段時間內是這樣。
第二,你在所謂牛逼團隊中的創造性受限,因為創新多來自于團隊中的“資深“和大牛們,你參與討論但觀點通常不會被采納,他們只會給你這個菜鳥分活干,想想看,你如何能花兩到三年就超越身邊的大牛們?甚至連拉近與他們的距離都難。
第三,如果身在牛逼團隊,自然心理對周圍的牛人們有所期待,希望他們能灌輸給你一些牛逼的知識和牛逼的理念。這種思想上的惰性在職場生涯之初是非常危險的。要知道技術和知識本身是很簡單和淳樸的,只不過披上了一個光鮮項目的外衣而讓人感覺與眾不同。
第四,由簡入奢易,由奢入簡難,做過一個看似光彩的項目,心理再難放平穩,去踏實的做一個看上去不那么酷的產品。這種浮躁心態會嚴重影響今后的職業發展和成長。
第五,光鮮靚麗的項目被各種老大關注,是難容忍犯錯誤的,傻瓜都知道犯錯誤在成長之初的重要性。
就我所看到的情形看,一開始加入看似很牛的項目組,三年后得到的成長,比那些開始加入一個不被重視的項目的同學要小很多,而后者在能力上的彈性卻更大。所以,道理很簡單,你是要把一個很酷的項目做的和之前差不多酷,還是把一個不酷的項目做的很酷?項目是不是因為你的加入而變得與眾不同了?
從這個角度講,不管是轉行的新人還是剛出道的秀才,最好將自己當作“匠人”來對待,你的工作是“打磨”你的項目,并在這個過程中收獲經驗和成長。付出的是勤奮,鍛煉的是手藝,磨練的是心智。因此,你的價值來自于你“活兒“的質量,“活兒”的質量來自于你接手的項目之前和之后的差別。做好活兒是匠人應有的職業心態。想通這一點,內心自然少一些糾結,才會對自己對項目的貢獻度有客觀的認識,不會感覺被項目所綁架。
web前端實訓心得體會 篇5
2個月的暑期實習結束了,不能算非常圓滿但是也有許多感受。畢竟,擠了兩個月的地鐵,每天3個小時,無論是上班還是回家身體都是濕的,也算是體驗過了社會人的生活。
在公司做的是后端工程師,其實就是協助團隊實現一些小的模塊,修改頁面等一些外圍的工作。這些都在預料之中。我找實習的初衷還是想體驗一下互聯網公司的工作環境、工作模式和方法,同時了解一下他們是如何了解并學習新知識的,從這一點上來說算是如愿以償。
在學校,無論是作項目還是產品,往往是一個人大包干。從產品(網站)設計,前臺html,javascript編寫,數據庫架構,后端coding,都是一個人完成的。而在正規的公司里,這一套流程是有著嚴格分工的,大致如下:1 首先由產品經理與客戶交流,討論、溝通并產生需求,作出產品原型圖,(在軟件領域應該算是工業設計原型圖?) 。將原型圖交付設計師,讓設計師通過構想的原型圖設計出相關圖片。前端工程師通過設計師的圖片切圖并作出靜態頁。同時,產品經理通過溝通和文檔的方式將需求告知后端開發人員。研發人員根據需求設計數據庫并進行相應coding,其中還要與前端工程師溝通并完成一些接口交互(比如json等),產品完成后最后進行測試等步驟。
首先說說產品經理。我認為,對于產品經理來說,需求和體驗是靈魂,溝通和設計是方法,而制作原型圖與撰寫相關文檔是必備技能。體驗就不用說了,產品經理就是為優質的用戶體驗而生的,‘用戶體驗’往往被他們掛在嘴邊。而需求分兩方面,一方面是與外界進行溝通,從而了解到的一些需求。這里面的溝通是有一些技巧和方法需要注意的。另外一方面則是自己通過對產品的理解,對生活的感悟自己創造出來的,這里也是見真功夫的地方。這兩方面,前一種主要靠溝通,后一種主要靠自己的設計(create)。
然后是原型圖,什么是原型圖呢?比方說你想設計一個網站,那么,在大刀闊斧開工之前,你總要在在紙上寫寫畫畫,作出網站的一個view草圖,這個草圖就是原型圖。只不過把你原來要在紙上完成的工作放到電腦里進行,加快工作效率和將草圖交付他人進行交流的效率罷了。這里推薦兩款軟件,一個是balsamiq,一個輕量級的原型圖制作工具,我實習公司的產品經理一直在用。另一個的功能就相對較多同時軟件本身也相對臃腫許多,axure。百度的產品經理在用它。
產品經理由于是站在全局去把握產品的設計方向,所以需要有相當強的思想和眼光,更多的時候的確是需要從管理的眼光去看問題。產品經理需要見多識廣,思維活躍才能不斷為產品注入新的能量。同時又要腳踏實地去把握用戶而不能脫離用戶,“用戶至上”這一點微信的產品經理張小龍是一個榜樣。
個人認為走互聯網也就是電子商務方向的信管人比較適合做產品經理,基于技術而又高于技術(就是不用掌握太多的技術),同時需要一些創造性思維和較強的溝通能力。
接下來說說設計師,這個我了解的的確比較少了。諸如PS AI等相關工具的熟練掌握肯定是必不可少的。我主要是想強調設計師的不可或缺。誠然,即便沒有設計師,你仍然可以讓前端工程師直接作出一個符合大致標準的靜態頁出來。不過,像一些復雜的邊角光影效果你肯定不能指望能達到一個比較好的效果吧。一些細節方面的地方可不是你摳摳其他網站配色和插圖就能搞定的。
下面講一下前端工程師。前端,多么絢爛的一個字眼啊。所有復雜又牛逼哄哄的動態特效全部經自我手,想想都是激動人心的一件事。其實,前端工程師大部分工作還是蠻辛苦的,需要將設計師的圖稿轉化為html頁,要適應chrome 要適應火狐,要適應IE, 要適應IE6(這個囧),要適應iphone,要適應ipad,要適應ipod....適應你妹啊適應! 各種js效果不好調試有沒有?需要不斷大刷(清空緩存)瀏覽器有沒有?css要各種hack有沒有? 要考慮SEO優化,要sitemap有沒有?
上面全是前端苦逼而且做起來又略無聊的地方,有沒有除了js特效還讓前端大顯伸手的地方呢? 看看阿爾法城的前端設計吧。前端MVC架構。恩你沒看錯,就是前端mvc。事實上,做網頁經常遇到這樣的情況,就是網站的頁面很少但是單個頁面的前端設計及其復雜。這個時候普通的單一js文件就不適用了,你需要自己架構或者使用現有的javascript的MVC框架解決問題。這時如何優化js,css代碼,如何建立起一個低耦合,復用性高的框架,如何靈活地運用一些設計模式,這都是前端工程師面對大型需要而考慮的。
除此之外,現在html5的流行與移動互聯網的興起也讓前端有了更多的用武之地。最后推薦一些干貨吧。bootstrap是twitter推出的一個能夠使前端工程師快速開發出兼容性強,組件功能豐富的javascript開源庫;一個名為Alice-css的base.css文件也能解決一些兼容性方面的問題;backbone是一個javascriptMVC框架,這個我也有待學習。
接下來就是后端啦,geek們 哦不,hacker們一起high起來吧!這才是我們程序員的天下啊。各種算法數據結構、設計模式、各類語言各類框架各類大規模架構方案軟件讓你學個夠!
現在的編程語言百花其放,各自適合的工作均不同。使用哪種語言還真是蘿卜青菜各有所愛。注意一定要發揮各個語言之所長:python就要做膠水語言,java在業務處理方面非常出色,php最適合網頁展現;.NET在MIS方面獨領風騷。
選擇什么語言不重要,關鍵是要看清語言背后的東西。絕不是你學過一門語言,然后再使用過那門語言的相關框架開發過項目你就能出師了。那只是一種你掌握的技術,而單純的技術并不能轉化為自己的理解,不能轉化為自己的能力。先說面向對象。要搞清楚的是基于對象和面向對象是兩碼事,java是一門基于對象的語言,而不是你使用java編程你就面向對象了。在實踐中不斷地領悟GoF提出的設計模式原理,慢慢地學會對象的用法。能根據需要,靈活地運用接口與繼承是關鍵。
有人認為算法和數據結構在互聯網方面作用很小?抱有這種觀點的人一定沒涉及過web智能推薦算法以及大規模分布式算法等領域。其實這也是互聯網方向的另外一片天地,當網站規模不斷擴大,服務器數量不斷增多,如何靈活地去設計服務器架構,拆分數據庫表結構,并提出相應的分布式方案,也是一個非常有挑戰性的難題。這其中也涉及很多算法需要自己實現,因為數據庫默認內核封裝的算法并不能滿足你網站架構的具體需要。還有一些是根據用戶需要而產生的算法,涉及到了一些交叉學科領域(比如MachineLearning),剛才舉的web推薦算法就是一個例子。
一個合格的程序員很大程度上也是半個運維工程師。平時數據庫、服務器的維護往往也需要自己親歷親為。這就要求你熟練掌握linux,unix各項指令的使用,一些常用的服務軟件比如memcache,sphinx等的使用方法。
對了,還漏了移動開發。想做手機開發的人,我想說的是,做IOS吧,Android的各種不兼容實在是太頭疼了,而且安卓市場有一些不合理的地方,相對來說不太容易賺錢。另外,wp7,wp8應用也可以嘗試一下。
說到做應用,微軟最新的office13提出了支持社交的理念,同時也支持針對office進行第三方應用的開發,感興趣的同學可以嘗試一下。
最后是測試。無論是做網站還是做系統都需要測試。公司曾經在的周末分享會上請來了IBM的測試MM專門講了測試的過程與方法。主要講的是黑盒測試。大公司的測試步驟簡單說來分為這么幾步:1 開發團隊派遣一名負責人向測試團隊發出Test申請。Test團隊然后根據需要對其進行評估,主要考察是否值得動用團隊精力去做測試以及動用多少人力資源。確立之后,Test團隊再進行測試項目啟動會,制訂計劃,并向開發團隊索要需求文檔。之后就是很關鍵的一步:根據文檔設置測試用例,就是case。case會根據項目需要和測試團隊自己發掘出的一些問題不斷增加和細化。
細化到什么程度呢?IBM有一個進行了一年的項目,而根據需要產生的case就已經有上千多個了,每一個case的填寫字段超過20個。從這里首先可以看出測試和開發時并行的而不是先開發后測試,然后,根據項目的不同,測試用例可能會增長到非常恐怖的程度。所以其他人的經驗不能照搬照抄,要根據自己團隊的規模合理地決定測試用例的粒度。
測試除了黑盒測試還有白盒測試。這就需要測試人員自己去寫自動化測試腳本,還有可能借助現成的諸如loadrunner等測試工具輔助工作完成。說明測試人員自身也要懂一些技術的。
扯的越來越遠了,簡單說說我實習做后端的收獲。首先是學會了個MVC框架,又再次顛覆了我對MVC的認知,了解了開源領域的猿們是如何快速接受新東西的。在選擇開發工具方面,我想對IDE說再見了,不輕量的東西就不靈活,不簡潔。公司里的人大部分都使用sublime 一個輕量級的文本編輯器,其優點在于能靈活地自定義快捷鍵、高效的查找替換、更便捷地代碼書寫方法以及優美的UI(說到UI最近新出的vs2012也是我的菜)。如果你夠牛比,你可以嘗試emacs ,一個操作系統級的文本編輯器,為什么是操作系統級呢,因為它的設計初衷就是你能在里面干任何事情,比如敲代碼,比如發郵件,比如看電影,比如玩游戲,比如……不過相應的,學習門檻也很高。最后是一款大家公認的殺手級工具,vim 誰用誰知道吧。我是用不習慣。
實習中除了技術上提升之外更多是不斷體會溝通的技巧。比方說,客戶說:“我想要實現一個XXX功能”,然后你說好,然后去做了。最后給客戶看,客戶說,“你怎么作成了這樣的東西呀,我想實現的是XX效果”,你很委屈地說“你上次跟我說需求時并沒有提到這一點啊”。就此僵持。
誰的錯?客戶的錯嗎?其實是不完全的。首先,你要知道,往往在客戶的腦海里,他所想的需求就是不清晰的,是模糊的,也很有可能是整個客戶團隊經過各種討論最后折中的一個結果。其次,不同的人語言表達的方式和能力是不一樣的,他以為你能理解,你也以為你理解了,中間的差別也可能有十萬八千里。
如何解決呢?記得SYN的三握手嗎? 為什么要三次握手而不是一次就行呢? 就是要反復確認。溝通時要學會去向客戶提問題去驗證客戶的需求,這也是讓客戶明確自己需求的一個過程。我用信息的傳輸打個比方。客戶頭腦中的需求是信息。從客戶嘴里說出來是編碼,然后通過耳朵傳輸到你的腦子里,這個過程是信道傳輸,最后你通過自己的理解(就是信息的解碼)轉化為自己的信息。信息在傳輸的過程中是肯定會有丟失和錯誤(誤碼)的。原因可能出自多個方面:也許信息在源頭就是不確定的(客戶頭腦不清晰),也許信息在編碼時就發生了錯誤(客戶不懂得表達的技巧),在信道傳輸時發生丟失(客戶的話你左耳朵進右耳朵出),信息解碼發生錯誤(你自己理解能力有問題)。怎么辦呢? 我們說提高信息傳遞效果有多種方式,比如信息要有冗余,多次傳輸去驗證是否接受信息正確(要求客戶反復說明),信息傳遞后你要有校驗碼驗證(自己向用戶再次確認)。總之,要“正確領會客戶的意圖和弦外之音”。
還有一大感悟就是:在工作時是否要追求完美?追求到什么地步?這個時候我們可以嘗試遵循80/20原則,即先集中精力解決80%的問題,再慢慢解決剩下20%的問題。“許多失敗并不是因為人不夠優秀,而是做事情的方法不對,一開始最求大而全的方案,之后長時間不能完成,最后不了了之。”
實習的遺憾也是有的,本來打算好實習3個月的,結果開學有很多事情出乎我的意料。很多學校的事情是推不掉的,權衡再三,只好決定提前結束實習,不然兩方面的事情都做不好。感謝實習期間團隊的各位伙伴對自己的提攜和教導,使自己進步很多。臨行前公司贈書一本,望我繼續努力。
感覺自己還沒掌握的知識還有很多,至今我還沒學如何用git;在面向對象方面仍有許多困惑;前端代碼實現起來依舊有很多問題;很多框架和軟件都只是了解而沒有實踐操作過。在實習業余時間在網上還報了個MachineLearning公開課,望能堅持下去。
新的一周要開始了,公司里的伙伴們依舊要開會、工作,為geekpark,itvalue的成熟壯大而奮斗。我也要開始忙碌一些自己的事情,前面依舊是一片天空。
【web前端實訓心得體會(通用5篇)】相關文章:
實訓心得體會(通用15篇)03-09
實訓報告心得體會(通用15篇)02-27
實訓的心得體會03-09
軟件實訓心得體會03-08
個人實訓心得體會02-27
數控實訓心得體會02-26
禮儀實訓心得體會02-24
車工實訓心得體會02-18
繪圖實訓心得體會01-21
會計實訓心得體會通用15篇03-09