關(guān)于敏捷開發(fā)的26個(gè)心得docxdocx(參考版)
2025-07-20 17:38本頁面
【正文】 客戶和客服基本都是對編程不懂的人。但站在客服技術(shù)支持的處境，他們因?yàn)檫@種不準(zhǔn)確的、不完整的錯(cuò)誤描述浪費(fèi)了大量時(shí)間。程序員一般都非常的懶，拋出異常時(shí)只描述錯(cuò)誤的表面現(xiàn)象。更重要的是，當(dāng)客戶看到了能運(yùn)行的程序后，你也就更能搞清客戶的需求是什么了。所以，你應(yīng)該直接實(shí)現(xiàn)你的設(shè)計(jì)，這樣客戶就能很容易明白你的設(shè)計(jì)細(xì)節(jié)。無數(shù)事實(shí)表明軟件比它的規(guī)格說明書善變的多?！鲕浖强伤艿?。詳細(xì)設(shè)計(jì)只應(yīng)該包括當(dāng)前需求用例中需要覆蓋的部分?！鲋挥挟?dāng)準(zhǔn)備好了實(shí)現(xiàn)和測試才去確定設(shè)計(jì)。所以，真正的最終用戶是不可能知道軟件的內(nèi)部工作機(jī)理的，不可能推理出這些復(fù)雜的指令組合會(huì)產(chǎn)生什么樣的預(yù)期結(jié)果。這種設(shè)計(jì)上的缺陷是：軟件里的各種操作的準(zhǔn)確定義在脫離了具體上下文的特定實(shí)現(xiàn)的情況下不可能被準(zhǔn)確的定義。通過配置文件來改變軟件行為所產(chǎn)生的后果是不過控的?！霾灰詣?chuàng)新語言。添加代碼總是容易的，刪除代碼總是困難的。更糟糕的錯(cuò)誤做法是把這些代碼注釋掉，留下一堆注釋碼。比如說，我們需要往類里添加一個(gè)新方法來替換以前的舊方法，通用人們會(huì)保留老方法‘以防不測’?！鰟h除死代碼。但不要害怕修改這些代碼、讓它符合真正的需求?！鑫覀儜?yīng)不斷的再設(shè)計(jì)、再分析。代碼質(zhì)量可以相差200倍之多，這是計(jì)算代碼行數(shù)的方法不能勝任的。編寫某個(gè)任務(wù)所產(chǎn)生的代碼行數(shù)會(huì)因程序員而異，因編碼風(fēng)格而異。盡可能的簡化但不要過度。但千萬不要把代碼壓縮的難以理解了?！鋈绻麅尚写a能完成就不要寫成三行。也就是我們所說的“YAGNI–YouAren’tGoingtoNeedIt”。小的、迅速的、完整的任務(wù)不僅僅會(huì)降低我們的認(rèn)知負(fù)荷，也減少了進(jìn)行中的開發(fā)對其他人正在進(jìn)行的開發(fā)的相互影響。我們的直覺告訴我們，當(dāng)我們在這種情況下時(shí)，我們希望三個(gè)一起完成。如果順序的開發(fā)，一個(gè)開發(fā)完成后再開發(fā)另一個(gè)，只會(huì)有3個(gè)‘單位’的風(fēng)險(xiǎn)。想象有三個(gè)任務(wù)，每個(gè)估計(jì)都要一天。當(dāng)開發(fā)人員開發(fā)一個(gè)設(shè)計(jì)用例時(shí)，有的功能會(huì)牽涉到所有修改著的但未完全開發(fā)完成、充分測試的代碼。相反，評(píng)審整個(gè)系統(tǒng)的運(yùn)行表現(xiàn)，找
公司管理相關(guān)推薦
鄂ICP備17016276號(hào)-1