軟件開發(fā)學(xué)習(xí)心得
軟件開發(fā)學(xué)習(xí)心得
學(xué)習(xí)軟件并非易事,這其中的碰到的困難也有很多。你知道軟件開發(fā)學(xué)習(xí)心得是怎樣的嗎?今天學(xué)習(xí)啦小編為大家整理了關(guān)于軟件開發(fā)學(xué)習(xí)心得,歡迎大家閱讀!
軟件開發(fā)學(xué)習(xí)心得篇一
受某文化公司委托,開發(fā)一款用于視頻和圖像處理的軟件,開發(fā)難度高,高到從未搞過,開發(fā)周期長,長到是我以前項(xiàng)目監(jiān)控最長開發(fā)周期的兩倍,開發(fā)成本之底,讓我覺得程序員成了高級打字員。首先是需求分析書、產(chǎn)品規(guī)格說明書、設(shè)計說明書、代碼規(guī)范說明書、測試計劃,光文稿就不知道熬了多久才做完。
緊接著,遇到一系列問題,首先是語言選擇,vc++和c#都是可以保證開發(fā)完成的選擇,但是vc++內(nèi)存容易報錯,界面很難修改,而客戶要求的界面質(zhì)量甚至比程序的功能更嚴(yán)格,沒辦法,客戶就是上帝,上帝做事一定有他的道理。c#語言易于開發(fā),而且圖形界面繪制也易于修改,可以做出客戶體驗(yàn)很好的界面,但是在資源的消耗上,讓我很吃驚。做到第二個月,大概的界面已經(jīng)完成時,出現(xiàn)界面刷新的問題,刷新時開始卡,界面不流暢。沒辦法,改。
開會,總結(jié),技術(shù)骨干找問題,拿出解決方案,力爭第一次做軟件把它做好:
重新做軟件開發(fā)進(jìn)度計劃和軟件測試計劃,并且讓獨(dú)立功能demo制作和測試先行;
用direct draw、direct 3d或者opengl中的一個替代c#本身的gdi繪圖,將在接下來的開發(fā)任務(wù)中加入進(jìn)去。
事無巨細(xì),當(dāng)我滿意的看著界面流暢,功能也已實(shí)現(xiàn)時,發(fā)現(xiàn)軟件在低分辨率或者小本上根本亂到?jīng)]法看,甚至是界面功能按鈕錯位,重疊等等。沒辦法,改。畢竟軟件的多分辨率兼容和操作系統(tǒng)兼容是必須要做的。
接下來一大堆的麻煩找了上來,軟件出現(xiàn)各種各樣想都想不到的問題,總算是按時將第一個版本發(fā)布出去,并且開始接下來的升級開發(fā)任務(wù)。
最后,給剛剛接手軟件開發(fā)項(xiàng)目的朋友一些忠告:
一、相關(guān)的文檔不是給別人看的,而是給自己看的,相關(guān)文檔一定要齊備,而且讓所有涉及開發(fā)的人員都清楚的知道你文檔里所要表達(dá)的意思;
二、一定要注意多做demo,多做實(shí)驗(yàn),一個demo程序員幾個鐘頭就可以完成,甚至更少,但是不做demo,核心程序沒有做實(shí)驗(yàn),其他的東西都圍繞核心程序做了上去,到時候耽誤的可不是幾個鐘頭
三、程序設(shè)計要注重用戶體驗(yàn),當(dāng)初客戶對我要開發(fā)軟件提出近乎苛刻的要求時我不在意,但是當(dāng)我自己反復(fù)使用軟件時有了很多體會,流暢美觀的界面帶給人心理的快感的確能替代一些尚未開發(fā)完整的功能帶給用戶的遺憾。
四、測試計劃多次進(jìn)行,分批進(jìn)行,不要全部開發(fā)完成再對軟件做測試。
還要堅持三個月,軟件馬上發(fā)布,希望大家的支持,謝謝!!!
軟件開發(fā)學(xué)習(xí)心得篇二
軟件開發(fā)過程中的任何一個活動都是為了能夠產(chǎn)出優(yōu)秀的代碼。所以,代碼才是核心。
1. 代碼是軟件開發(fā)的基礎(chǔ)
編碼是軟件開發(fā)過程中最基本、最底層的技藝,然而也是最重要的技藝。任何一個領(lǐng)域的專家都需要花費(fèi)大量的時間來進(jìn)行基本技藝的鍛煉,木匠需要花費(fèi)大量的時間來鍛煉他們對各種工具的掌握,廚師則需要練習(xí)刀工和火候。程序員也是一樣的,對我們來說,語言的各種特性必須要了然于胸。而對軟件的管理也需要從代碼做起。
從2000年到現(xiàn)在,國內(nèi)興起了一股軟件工程熱,需求管理、配置管理、甚至CMM。面對紛至沓來的各種方法學(xué)、UML、OOA,大家似乎已經(jīng)熱衷于這些概念本身了,卻往往忽略了軟件開發(fā)中最基本的元素:代碼。在和很多軟件組織的接觸過程中,我們認(rèn)為大多數(shù)組織急切需要的并不是這些工程理論,不是說這些理論不重要,而是這些組織的癥結(jié)不在于此。很多的組織連代碼的質(zhì)量都管理不好,又何談其它呢?代碼管理是基礎(chǔ)的基礎(chǔ),從管理的角度上來看,任何一個組織的管理都需要一個從上至下的管理過程,有基層的管理人員,也有高層的管理人員。對代碼的管理就是軟件開發(fā)中的基層管理,它起到的作用就是能夠把需求、設(shè)計的思路貫徹到最終的代碼中。
“管理無大事”。對軟件的管理也是一樣,大部分的問題都是由于很小的原因引起的。例如,一個產(chǎn)品如果后期在debug上花費(fèi)了大量的時間,那么,這種現(xiàn)象是由于什么原因引起的?一種可能的原因是前期的代碼設(shè)計中對代碼質(zhì)量的把握不嚴(yán)。每一次代碼功能的演化并不會產(chǎn)生太多的問題,但是當(dāng)代碼累積越來越多的時候,問題也就慢慢出現(xiàn)了。那么如何解決呢?可以加強(qiáng)QA的力量,也可以引入復(fù)審,還可以引入單元測試??傊幸环N方法對代碼進(jìn)行控制。
軟件的開發(fā)過程就象是一部精密的機(jī)器,任何一個環(huán)節(jié)的變化,都會對其它的環(huán)節(jié)產(chǎn)生影響。把軟件過程按照瀑布的形式進(jìn)行劃分是一種分解的處理思路,但同時我們還應(yīng)該看到不同活動之間的相互影響。軟件開發(fā)中的生命周期模型也是一個層次模型,從業(yè)務(wù)建模一直到軟件實(shí)現(xiàn),需要跨越數(shù)個層次,同樣會出現(xiàn)執(zhí)行不力的情況,例如,代碼設(shè)計偏離需求、偏離設(shè)計的情況比比皆是。
如何避免這種情況呢?這就需要我們從源代碼的角度,反思其上游的實(shí)踐活動,是否足以約束代碼設(shè)計?就拿XP來說,他解決這個問題的方式是盡快的進(jìn)入代碼開發(fā)階段,從代碼開發(fā)中發(fā)現(xiàn)問題,并在下一輪的開發(fā)中解決。這種思路是正確的,但XP畢竟是方法論,他不會告訴你過于細(xì)節(jié)的東西,盡管XP已經(jīng)提供了大量面向代碼的實(shí)踐。因?yàn)榉椒ㄕ摰某橄蠹墑e比較高,使得他必須舍棄部分的細(xì)節(jié)。而這篇文章告訴你的,就是這些細(xì)節(jié)。就像我們在下一節(jié)中討論的例子,需要在代碼中加入對異常的處理,那么,異常的源頭在哪里呢?是需求,在需求中,我們發(fā)現(xiàn)了一些業(yè)務(wù)的非正常的處理序列,發(fā)現(xiàn)了一些業(yè)務(wù)實(shí)體的限制性的要求,所以在代碼實(shí)現(xiàn)中,就需要有相應(yīng)的異常處理。在例如,一個優(yōu)秀的異常處理,還需要讓客戶端程序員了解可能發(fā)生的異常,以保證不同代碼間正確的集成。
2. 面向?qū)ο蟮拇a
面向?qū)ο蟮拇a已經(jīng)在現(xiàn)在的軟件開發(fā)中占據(jù)了主流的位置,面向?qū)ο蟮乃悸芬灿衅鋬?yōu)勢所在,就像后文所討論的,面向?qū)ο蟠a有著非面向?qū)ο蟠a的很多優(yōu)勢,而軟件業(yè)中很多新的思潮的產(chǎn)生,也都是基于面向?qū)ο笳Z言的,所以我們關(guān)注的代碼將是面向?qū)ο蟠a。
面向?qū)ο蟮乃枷雭碜杂诔橄髷?shù)據(jù)類型。對于面向?qū)ο髞碚f,它最重要的改進(jìn)就是把世間萬物都描述為對象,而類則描述了同一種對象的特征,而不是像傳統(tǒng)的開發(fā)方法那樣,按照機(jī)器指令的執(zhí)行順序來進(jìn)行設(shè)計。當(dāng)然,面向?qū)ο蟠a最終仍然是要按照時序來執(zhí)行的,但是從程序員的角度看來,面向?qū)ο蟠a更側(cè)重于對象之間的交互,多個對象各司其職,相互協(xié)作以完成目標(biāo)。而面向?qū)ο蠹夹g(shù)的發(fā)展,也是朝著更加貼近我們世界觀的方向發(fā)展。從這點(diǎn)來看,有人說完全沒有程序設(shè)計經(jīng)驗(yàn)的人學(xué)習(xí)面向?qū)ο罂赡軙拥娜菀?,因?yàn)樗恍枰獜脑鹊臅r序程序的桎梏中擺脫出來,但這未必是事實(shí)。面向?qū)ο鬀Q不是一種簡單的程序設(shè)計思路。這是我們的觀點(diǎn),也會在下文中反復(fù)的論證。
和所有的職業(yè)一樣,程序員,或者是面向?qū)ο蟪绦騿T,始終堅持的一點(diǎn)就是嚴(yán)謹(jǐn)。你會看到各種各樣優(yōu)秀的代碼,但那決不是一次能夠?qū)懗傻?,要不斷的嘗試,不斷的改進(jìn)。為什么重構(gòu)和測試優(yōu)先是敏捷方法中很重要的一項(xiàng)實(shí)踐?因?yàn)槌绦騿T不是神,他們需要慢慢改進(jìn)他們的代碼。雖然羅馬不是一天能夠建成的,但是在編寫面向?qū)ο蟠a的過程中,有一些實(shí)踐是需要堅持的,它體現(xiàn)了我們所說的嚴(yán)謹(jǐn)。
3. 編寫并管理面向?qū)ο蟮拇a
編寫優(yōu)秀的面向?qū)ο蟠a并不是一件容易的事情,優(yōu)秀的OO代碼如行云流水,糟糕的OO代碼讓人覺得渾身起雞皮疙瘩。編寫優(yōu)秀的OO代碼要求程序員有一定的自我修養(yǎng),能夠以抽象的思路看待問題,找到問題的核心并對問題域進(jìn)行分解。它強(qiáng)調(diào)的是一種解題的思路,但這個解不是唯一的。
典型的例子是設(shè)計模式,設(shè)計模式確實(shí)給了我們以很大的啟發(fā),通過它,我們能夠了解到優(yōu)秀的代碼是如何用于解決實(shí)際問題的。但是是不是你必須在軟件中照搬設(shè)計模式呢?如果你這么做,那么你對設(shè)計模式的理解仍然不夠。我曾和在建筑行業(yè)的朋友聊起Christopher Alexander的建筑的永恒之道。他很興奮的告訴我,那確實(shí)是一本很好的書,能夠引發(fā)人很深的思考,但是現(xiàn)在也有另外的一種觀點(diǎn),認(rèn)為美仍然是無形的,應(yīng)該發(fā)自建筑師的內(nèi)心。對這句話我思考了很久,其實(shí)建筑是給人使用的,因此最重要的是它能都給人帶來的價值,隱含在其中的那種活生生的氣質(zhì),這是建筑師文化底蘊(yùn)的外在表露。所以,Christopher Alexander在那本書中的目的,也是為了找到一種總結(jié)自己觀點(diǎn)的方法,來總結(jié)自己對人文的認(rèn)識。至于現(xiàn)在大家對他的思路提出了質(zhì)疑,那也是一件好事,這說明大家對建筑之道的認(rèn)識到了新的高度。建筑是這樣,軟件中的模式也是一樣的,我也曾熱衷于研究模式的使用,直到某一天我猛然驚醒,與其沉迷于模式的表面形式,為什么不去研究隱藏在它背后的文化底蘊(yùn)呢?武俠小說中常說無招勝有招,模式的應(yīng)用也應(yīng)當(dāng)?shù)竭_(dá)這個境界,你如果可以在不經(jīng)意間應(yīng)用模式的思想,那又何必拘泥于模式的形式呢?
編寫優(yōu)秀OO代碼雖難,但還有更難的事情,就是讓整個開發(fā)團(tuán)隊都產(chǎn)出優(yōu)秀的OO代碼。我們剛才說了,OO對問題的解不是唯一的,但各個不同的優(yōu)秀解匯集到一起,可能就是一個糟糕的解,這是風(fēng)格和架構(gòu)的問題。你如何在團(tuán)隊中制定制度,營造氛圍,讓優(yōu)秀OO代碼成為團(tuán)隊最終的成果?這些問題,在我看來,要比CMM難得多,這個問題并不是靠花錢就能夠解決的。如果能夠解決這個問題,這個團(tuán)隊的創(chuàng)造力一定是驚人的。
4. 面向?qū)ο筌浖_發(fā)過程
普通的軟件開發(fā)過程和面向?qū)ο箝_發(fā)過程有著很大的不同?;叵胛覀冊诜敲嫦?qū)ο笾虚_發(fā)過程中,最經(jīng)常采用的任務(wù)分配方法就是以軟件模塊為單位,這樣的好處是分配簡單,不同任務(wù)之間耦合程度低,容易操作。壞處是幾乎無法做到重用,也缺乏整體性的設(shè)計。而面向?qū)ο筌浖_發(fā)則不同,它是以類、類集合作為基本單位的。類之間關(guān)系錯綜復(fù)雜(雖然我們提倡低耦合的設(shè)計,但類之間的關(guān)系仍然是相對復(fù)雜的)。這種情況下程序員之間相互協(xié)作的要求就非常之高,這種關(guān)系如果處理恰當(dāng),則能夠完全體現(xiàn)出面向?qū)ο蟮耐?,否則,那將會是一場大災(zāi)難,面向?qū)ο蟮能浖_發(fā)過程要養(yǎng)成一些好的習(xí)慣:
4. 1 盡量簡化和穩(wěn)定客戶端。
個人編程可以是一種享受,但團(tuán)隊開發(fā)始終是一項(xiàng)嚴(yán)謹(jǐn)?shù)穆殬I(yè)活動,因此多考慮別人,不要設(shè)計復(fù)雜的接口,雖然你省事了,但這會給理解和使用你的接口和人造成障礙。
4.2 準(zhǔn)備一份簡潔的文檔,并保持更新。
隨便一種形式的穩(wěn)定,可以是代碼,可以是UML圖,也可以是純粹的文字(估計沒幾個程序員喜歡這種形式)。只要它能夠傳達(dá)你的代碼的目的,那就足夠。記住,更新代碼后,同時更新你的文檔。過期的文檔不僅是廢紙這么簡單,它會給其它人造成麻煩。切記!
4. 3 盡可能多的考慮異常和錯誤的情況。
軟件開發(fā)學(xué)習(xí)心得篇三
來到北大青鳥通州校區(qū)學(xué)習(xí)已經(jīng)快一年了,雖然時間不算太長,但對于我而言,在北大青鳥,我的收獲是無法用時間長短來衡量的!
因?yàn)樵趤肀贝笄帏B之前,我從沒接觸過軟件方面的知識,所以剛開始很擔(dān)心自己學(xué)不了,自卑的情緒很嚴(yán)重。但是細(xì)心的班主任發(fā)現(xiàn)了我的問題,總是很耐心的找我談心,開導(dǎo)我!慢慢的,我想明白了,不要盲目的和其他同學(xué)作比較,今天的我只需要比昨天的我有進(jìn)步,我的目的就達(dá)到了!
想通了以后,我自己也越來越自信了。就像一只從起跑線上開始爬行的蝸牛,雖然很慢,但是我目標(biāo)很明確,很堅定!或許很多人會認(rèn)為學(xué)習(xí)軟件是一門很枯燥的課程,但是我覺得這乏味中也有不少樂趣。例如學(xué)習(xí).NET和C#時,我們小組就自己制作了一款小游戲,雖然是一款很簡單的小游戲,只能有一些普通的攻擊動作,但是它就是我們的學(xué)習(xí)成果。玩著自己編寫出來的小軟件,想著以后能開發(fā)出更厲害更完善的系統(tǒng),讓我們對未來的工作和學(xué)習(xí)充滿了動力!
剛開始接觸三層架構(gòu)的時候,我上課聽老師的講課真是一頭霧水。但是我并沒有放棄,而是更加認(rèn)真,調(diào)整好心態(tài),強(qiáng)迫自己反復(fù)的看書,查資料,一遍遍的練習(xí),遇到不懂的就馬上去問老師,就這樣,終于攻下了一道道難題。
如果你問我在學(xué)習(xí)軟件的過程中,什么學(xué)習(xí)方法最重要,那我會認(rèn)為勤奮是最重要的。一定要反復(fù)的練習(xí),這樣你才會掌握得更扎實(shí),基礎(chǔ)打得好,后期的學(xué)習(xí)才會更省力!另外,我覺得課余時間應(yīng)該好好的利用起來,不要局限于課本,要主動的去學(xué)習(xí)更多的知識和技能,為以后的工作準(zhǔn)備更多的能力!