化學專業(yè)前沿講座心得體會(編輯修改稿)
2024-09-28 14:41 本頁面
【文章內容簡介】 上一次集成未通過，需要盡快定位失敗原因從而讓燈變綠。 有很多很多的書用來介紹重構，最著名的是martin的《重構》，joshua的《從重構到模式》等。重構是在不改變系統外部行為下，對內部結構進行整理優(yōu)化，使得代碼盡量簡單、優(yōu)美、可擴展。在以往開發(fā)中，通常是在有需求過來，現在的系統架構不容易實現，從而對原有系統進行重構；或者在開發(fā)過程中有剩余時間了，對現在代碼進行重構整理。但是在敏捷開發(fā)中，重構貫穿于整個開發(fā)流程， 2每一次開發(fā)者checkin代碼之前，都要對所寫代碼進行重構，讓代碼達到cleancodethatworks。值得注意的是，在重構時，每一次改變要盡可能小，用單元測試來保證重構是否引起沖突，并且不只是對實現代碼進行重構，如果測試代碼中有重復，也要對它進行重構。 pairprogramming，結對編程。在敏捷開發(fā)中，做任何事情都是pair的，包括分析、寫測試、寫實現代碼或者重構。pair做事有很多好處，兩個人在一起探討很容易產生思想的火花，也不容易走上偏路。 standup，站立會議。每天早上，項目組的所有成員都會站立進行一次會議，由于是站立的，所以時間不會很長，一般來說是1520分鐘。會議的內容并不是需求分析、任務分配等，而是每個人都回答三個問題： 。 。 。站立會議讓團隊進行交流，彼此相互熟悉工作內容，如果有人曾經遇到過和你類似的問題，那么在站立會議后，他就會和你進行討論。 frequentreleases，小版本發(fā)布。在敏捷開發(fā)中，不會出現這種情況，拿到需求以后就閉門造車，直到最后才將產品交付給客戶，而是盡量多的產品發(fā)布，一般以周、月為單位。這樣，客戶每隔一段時間就會拿到發(fā)布的產品進行試用，而我們可以從客戶那得到更多的反饋來改進產品。正因為發(fā)布頻繁，每一個版本新增的功能簡單，不需要復雜的設計，這樣文檔和設計就在很大程度上簡化了。又因為簡單設計，沒有復雜的架構，所以客戶有新的需求或者需求進行變動，也能很快的適應。 minimaldocumentation，較少的文檔。其實敏捷開發(fā)中并不是沒有文檔，而是有大量的文檔，即測試。這些測試代碼真實的反應了客戶的需求以及系統api的用法，如果有新人加入團隊，最快的熟悉項目
黨政相關相關推薦
鄂ICP備17016276號-1