有關(guān)敏捷開發(fā)的26個心得docxdocx(編輯修改稿)
2025-08-14 07:18 本頁面
【文章內(nèi)容簡介】 這種情況，但沒人采取措施。我們應(yīng)該明白，應(yīng)該廣泛的認(rèn)識到，只要做出一點(diǎn)點(diǎn)工作，整個的團(tuán)隊(duì)會因此得到非常大的回報(bào)。■團(tuán)隊(duì)的每個成員都要知道客戶的需求。大型復(fù)雜的項(xiàng)目必須要分割到幾個獨(dú)立的團(tuán)隊(duì)去開發(fā)，然后派發(fā)到每個開發(fā)人員的手中，但這絕對不能變成程序員可以不明白最終產(chǎn)品的使用用戶的需求和目標(biāo)是什么。■把意義相關(guān)的東西放在一起。組織好代碼，讓高度相關(guān)的東西都放在一起，也就是放在一個類里。這是標(biāo)準(zhǔn)的面向?qū)ο笤O(shè)計(jì)原則里的封裝的概念。理想情況下，類之外的程序并不需要知道類里面的工作細(xì)節(jié)。有些開發(fā)人員喜歡把代碼放到好幾個文件里，這樣是為了按另一種方式組織它們：例如把相同的數(shù)據(jù)類型的放到一起，或按字母順序分類。舉個例子，有人會把所有的常量放在單獨(dú)一個包下的一個類里，他們這樣做毫無必要，增加了程序的復(fù)雜性。按照指導(dǎo)原則，它們應(yīng)該按照相關(guān)性進(jìn)行分組，從而減少復(fù)雜性?！鱿葴y試后提交代碼。這個準(zhǔn)則能讓你確?！坝肋h(yuǎn)不要讓集成構(gòu)建失敗”的準(zhǔn)則?！鲞^早優(yōu)化是災(zāi)難之源這句話是引用DonKnuth的，今天聽起來一點(diǎn)不錯。在內(nèi)核里的代碼應(yīng)該盡力的寫好來避免不要的浪費(fèi)，但針對高于單個方法的級別的優(yōu)化應(yīng)該在整個項(xiàng)目測試通過、針對最終實(shí)際用戶的壓力測試用例通過之后才能進(jìn)行。僅僅根據(jù)靜態(tài)的代碼來判斷哪些是影響整個性能最主要的問題的論斷往往是錯誤的。相反，評審整個系統(tǒng)的運(yùn)行表現(xiàn)，找出真正影響性能的1%的代碼，只針對這些代碼做優(yōu)化?！鲎钚』赐瓿傻木幋a任務(wù)的工作包（backlog）。當(dāng)開發(fā)人員開發(fā)一個設(shè)計(jì)用例時，有的功能會牽涉到所有修改著的但未完全開發(fā)完成、充分測試的代碼。把未修改完成的代碼保存到本地?cái)?shù)天或數(shù)星期，這樣增加了工作浪費(fèi)的風(fēng)險，會出現(xiàn)返工。想象有三個任務(wù)，每個估計(jì)都要一天。如果三個一起開發(fā)，并行起來每個都需要3天，這樣一累計(jì)會有9個’單位’的風(fēng)險。如果順序的開發(fā)，一個開發(fā)完成后再開發(fā)另一個，只會有3個‘單位’的風(fēng)險。這個并不符合我們的直覺。我們的直覺告訴我們，當(dāng)我們在這種情況下時，我們希望三個一起完成。但是軟件
語文相關(guān)推薦
鄂ICP備17016276號-1