Bài tập lớn nhập môn công nghệ phần mềm đề tài refactoring
Bài tập lớn Nhập môn Công nghệ Phần mềm Đề tài: Refactoring Sinh viên : Lê Ngọc Minh Lớp : Khoa học máy tính Khoá : 52 SHSV : 20071946 Giáo viên : Lê Đức Trung Hà Nội, tháng 11/2015 Page Chương Giới thiệu Chương Các nguyên lý refactoring 2.1 Định nghĩa refactoring 2.2 Hai mũ 2.3 Tại cần refactor? .7 2.3.1 Refactoring giúp cải thiện thiết kế 2.3.2 Refactoring giúp phần mềm dễ hiểu .7 2.3.3 Refactoring giúp bạn lập trình nhanh 2.4 Khi nên refactor? 2.4.1 Nguyên tắc lần .8 2.4.2 Refactor thêm chức 2.4.3 Refactor sửa lỗi 2.4.4 Refactor xem lại mã nguồn (code review) .8 2.5 Các vấn đề refactor 2.5.1 Cơ sở liệu 2.5.2 Thay đổi giao diện 2.6 Refactoring với thiết kế 2.7 Refactoring với hiệu 10 Chương Nhận biết mã nguồn cần refactor 11 3.1 Trùng lặp mã .11 3.2 Phương thức dài 11 3.3 Lớp lớn 12 Chương Xây dựng kiểm thử 14 4.1 Giá trị mã kiểm thử .14 Chương Các phương pháp refactor 15 5.1 Định dạng phương pháp refactor 15 5.2 Trích phương thức .15 5.2.1 Tóm tắt 15 5.2.2 Động 16 5.2.3 Ví dụ: Không có biến nội 16 5.2.4 Ví dụ: Có sử dụng biến nội .17 5.2.5 Ví dụ: Gán lại biến nội .19 5.3 Nhập phương thức (Inline method) .20 5.3.1 Tóm tắt 20 5.3.2 Động 20 5.4 Nhập biến tạm .21 5.4.1 Tóm tắt 21 5.4.2 Động 21 5.5 Di chuyển phương thức .21 5.5.1 Tóm tắt 21 Page 5.5.2 Động 21 5.5.3 Ví dụ .22 Chương Các công cụ refactor .23 6.1 Refactor công cụ 23 6.2 Refactor mã nguồn Java Eclipse 23 6.2.1 Thực đơn refactor 24 6.2.2 Đổi tên 24 6.2.3 Trích phương thức 25 6.2.4 Nhập phương thức 26 6.2.5 Nhập biến tạm 27 6.2.6 Di chuyển phương thức 27 Phụ lục A Tài liệu tham khảo 29 Phụ lục A Danh sách “bad smells in code” 30 Phụ lục A Danh sách phương pháp refactor 31 Phụ lục A Các công cụ refactor mã nguồn Java Eclipse Helios 34 Page Page Chương Giới thiệu Refactoring trình thay đổi hệ thống phần mềm nhằm tiến cấu trúc bên không làm biến đổi hành vi bên Refactoring việc dọn dẹp mã nguồn cách có tổ chức cho tối thiểu hoá khả gây lỗi Về chất refactoring nâng cấp thiết kế mã nguồn sau viết Trong hiểu biết thông thường công nghệ phần mềm, thiết kế trước sau cài đặt Cần có thiết kế tốt trước sau có cài đặt tốt Qua thời gian, mã nguồn bị sửa đổi quán hệ thống, cấu trúc theo thiết kế, mờ nhạt Quá trình cài đặt chuyển dần từ chế tạo sang chắp vá Refactoring cách làm ngược lại Khi refactor bạn lấy thiết kế tồi, chí hỗn loạn, làm lại để trở thành mã nguồn thiết kế tốt Mỗi bước đơn giản, chí đơn giản Bạn chuyển trường từ lớp sang lớp khác, lấy vài đoạn mã khỏi phương thức để tạo phương thức riêng đẩy vài đoạn mã lên hay xuống thừa kế Tuy nhiên tác động tích luỹ thay đổi nhỏ thiện đáng kể thiết kế Đó đảo ngược khái niệm software decay Khi refactor bạn nhận thấy phân phối công việc thay đổi Thiết kế thay diễn đầu tiên, lại diễn liên tục suốt trình phát triển Bạn học cách cải tiến thiết kế từ việc xây dựng hệ thống Kết tương tác dẫn đến chương trình với thiết kế tốt trình phát triển tiếp diễn Qua trình phát triển công nghệ phần mềm, với phát triển mạnh mẽ phần cứng yêu cầu hiệu suất xử lý ngày quan trọng thay vào đó, tính dễ hiểu đề cao Do kỹ thuật refactoring ngày ý nhằm nâng cao chất lượng phần mềm Thực tế học tập sinh viên Việt Nam cho thấy phần mềm viết ghế nhà trường thường thiết kế tốt từ ban đầu Dẫn đến tình trạng có nhiều nguyên nhân chủ quan lẫn khách quan thiếu kinh nghiệm, thiếu thời gian, chưa trọng đến quy trình phát triển phần mềm v.v Để phần mềm vượt khỏi phạm vi tập lớn, đồ án môn học, đồ án tốt nghiệp tiếp tục phát triển thành sản phẩm thực tế thành công sống kỹ refactoring cần thiết Page Chương Các nguyên lý refactoring 2.1 Định nghĩa refactoring Thuật ngữ refactoring phát minh Ward Cunningham Kent Beck vào khoảng năm 1980 làm việc với ngôn ngữ Smalltalk Trong sách “Refactoring: Improving the Design of Existing Code” cung cấp hai định nghĩa sau: Refactoring (danh từ): thay đổi cấu trúc bên phần mềm giúp dễ hiểu dễ sửa đổi mà không làm thay đổi hành vi bên Refactor (động từ): tái cấu trúc phần mềm cách áp dụng loạt thao tác refactoring mà không làm thay đổi hành vi bên Trong số tài liệu tiếng Việt, refactoring chuyển ngữ thành “cải tiến mã nguồn” nhiên cách nói dài dòng không diễn tả nghĩa thuật ngữ Tài liệu để nguyên thuật ngữ tiếng Anh với hai dạng trên, refactoring hiểu tổng hợp phương pháp công cụ để tiến hành refactor phần mềm nói chung Như vậy, hiểu theo nghĩa refactor đơn giản dọn dẹp mã nguồn Tuy nhiên cách áp dụng phương pháp, công cụ refactoring, việc dọn dẹp mã nguồn hiệu đáng kể Cần phân biệt refactoring tối ưu hoá hiệu (performance optimization) Mục đích refactoring làm cho phần mềm dễ hiểu dễ sửa chữa Tối ưu hoá hiệu không làm thay đổi hành vi bên phần mềm (trừ tốc độ) mà thay đổi cấu trúc bên nhiên việc tối ưu hoá thường dẫn đến đoạn mã nguồn khó hiểu khó sửa chữa Một đặc tính quan trọng refactoring không thay đổi hành vi bên phần mềm Phần mềm phải thực chức giống hệt làm trước Người dùng, kể end user lập trình viên, nhận có vừa thay đổi 2.2 Hai mũ Kent Beck sử dụng hình ảnh hai mũ để trình phát triển phần mềm có refactor Bạn chia thời gian thành hai hoạt động tách biệt: thêm chức refactor Khi thêm chức năng, bạn không nên thay đổi đoạn mã có, bạn thêm vào khả Bạn đo tiến độ cách tạo test đảm bảo chạy Khi refactor, bạn không thêm chức mà tái cấu trúc mã nguồn Bạn không thêm test (trừ phát test bạn bỏ lỡ trước đó) thay đổi test thực cần thiết để phù hợp với thay đổi giao diện Page 2.3 Tại cần refactor? 2.3.1 Refactoring giúp cải thiện thiết kế Không có refactoring, thiết kế phần mềm phân rã (software decay) Khi mã nguồn thay đổi để thực hoá mục tiêu ngắn hạn thay đổi mà không hiểu đầy đủ thiết kế, mã nguồn dần cấu trúc Ngày khó nhận thiết kế cách đọc mã nguồn Refactoring giống xếp lại mã nguồn Bạn xếp lại không chỗ Sự cấu trúc mã nguồn có hiệu ứng tích luỹ Càng khó nhận thiết kế từ mã nguồn khó trì thiết kế Refactoring thường xuyên giúp mã nguồn giữ hình dạng Mã nguồn thiết kế không tốt thường chữa nhiều đoạn mã làm việc, thông thường mã nguồn hay làm việc chỗ khác Vì khía cạnh quan trọng cải tiến thiết kế xoá bỏ đoạn mã trùng lặp Tầm quan trọng việc nằm thay đổi mã nguồn tương lai Giảm lượng mã không giúp hệ thống chạy nhanh chút lại khiến việc sửa đổi dễ dàng nhiều Có mã cần phải hiểu cần sửa nơi thay đổi áp dụng toàn hệ thống 2.3.2 Refactoring giúp phần mềm dễ hiểu Lập trình giống trò chuyện với máy tính Bạn viết mã để bảo máy tính cần phải làm trả lời cách làm xác điều bạn bảo Bạn cần xoá bỏ khoảng cách điều bạn muốn máy tính làm với điều bạn nói với Lập trình theo cách hiểu đơn giản nói xác điều bạn muốn Tuy nhiên có người khác cần sử dụng mã nguồn bạn Ai thử đọc mã nguồn bạn thời gian vài tháng để sửa đổi vài chỗ Chúng ta dễ quên người sử dụng bổ sung đó, họ thực lại người quan trọng Ai bận tâm máy tính thêm vài xung nhịp để dịch? Nhưng khác biệt lớn lập trình viên tuần để thực sửa đổi vài hiểu mã nguồn bạn Bạn sử dụng refactoring cách để hiểu đoạn mã người khác Đọc vài dòng mã cố gắng thay đổi để phản ánh cách hiểu bạn sau thử chạy lại xem làm việc hay không Với cách làm bạn có hiểu biết chắn hệ thống việc trở lại đoạn mã refactoring dễ dàng nhiều 2.3.3 Refactoring giúp bạn lập trình nhanh Điều nghe nghịch lý Để nâng cao chất lượng mã nguồn, cần đầu tư thời gian vào việc refactoring, việc làm giảm suất? Page Thực tế chứng minh thiết kế tốt quan trọng tốc độ phát triển phần mềm Không có thiết kế tốt, bạn tiến nhanh lúc sau sớm chậm lại Bạn phải dành thời gian tìm sửa lỗi thay thêm chức Việc sửa đổi lâu bạn phải cố hiểu hệ thống tìm đoạn mã trùng lặp Thiết kế tốt điều kiện cần để trì tốc độ phát triển phần mềm refactoring giúp bạn chống lại phân rã (decay) thiết kế, chí cải thiện thiết kế 2.4 Khi nên refactor? 2.4.1 Nguyên tắc lần Lần bạn làm đó, làm Lần thứ hai bạn làm điều tương tự, bạn nhận lặp lại làm Lần thứ ba bạn làm điều tương tự, refactor 2.4.2 Refactor thêm chức Hoặc phần đoạn mã cần viết viết bạn nhận thấy việc thay đổi chút thiết kế giúp cài đặt chức nhanh chóng hơn, refactor Đừng bỏ qua sai sót thiết kế, refactor để công việc thuận lợi 2.4.3 Refactor sửa lỗi Lỗi báo cáo dấu hiệu cho thấy cần refactor Refactoring giúp bạn hiểu rõ mã nguồn tìm loại bỏ lỗi dễ dàng 2.4.4 Refactor xem lại mã nguồn (code review) Xem lại mã nguồn giúp lan truyền kiến thức nhóm phát triển, tạo hội cho lập trình viên cũ truyền kinh nghiệm cho lập trình viên Refactor khiến người review không tưởng tượng mã nguồn trông với đề nghị mà thực nhìn thấy Quá trình xem lại có kết rõ ràng hơn, không vài đề nghị mà đề nghị thực 2.5 Các vấn đề refactor 2.5.1 Cơ sở liệu Nhiều ứng dụng gắn chặt với lược đồ liệu hỗ trợ nó, lý khiến sở liệu khó thay đổi Một lý khác việc chuyển đổi liệu lâu nguy hiểm Với sở liệu phi đối tượng cách giải đặt tầng phần mềm mô hình đối tượng mô hình sở liệu Bằng cách bạn tách rời thay đổi hai mô hình Bạn không cần thiết phải tạo lớp riêng biệt từ đầu Bạn xây dựng lớp nhận mô hình đối tượng không ổn định Page Cơ sở liệu hướng đối tượng vừa hỗ trợ vừa cản trở Một vài sở liệu hướng đối tượng có khả chuyển đổi tự động từ phiên sang phiên khác đối tượng Nếu không, bạn phải cẩn thận chuyển đổi liệu tay Bạn thoải mái di chuyển hành vi với trường phải cần thận Có thể sử dụng hàm truy cập để tạo cảm giác liệu chuyển chắn thay đổi bạn thực di chuyển trường 2.5.2 Thay đổi giao diện Khi làm việc với đối tượng bạn tuỳ ý thay đổi nội dung bên miễn giao diện giữ nguyên Nếu cần thay đổi giao diện bạn thay đổi tất nơi sử dụng nó, bạn việc sửa tất đồng thời Tuy nhiên bạn có giao diện công bố, việc trở nên phức tạp nhiều Bạn sửa đoạn mã người khác viết sử dụng giao diện bạn Bạn cần quy trình phức tạp nhiều Khi refactor giao diện công bố, bạn cần giữ lại toàn giao diện cũ, người sử dụng phản ứng với thay đổi Nếu bạn đổi tên hàm, giữ lại hàm cũ cho gọi đến hàm Đừng chép thân hàm bạn lại thời gian xử lý trùng lặp mã nguồn Bạn nên sử dụng công cụ deprecate Java để thông báo chỗ bị phản đối Công bố giao diện có ích lợi gây nhiều khó khăn có thể, đừng công bố giao diện Tất nhiên bạn thiết kế thư viện lập trình, điều không tránh khỏi Nhưng bạn làm phần mềm với nhóm làm việc gồm ba người, đừng công bố giao diện từ người đến người Đơn giản mở mã nguồn sửa đổi 2.6 Refactoring với thiết kế Một số người ví thiết kế với vẽ kĩ sư lập trình với công việc thợ xây Tuy nhiên phần mềm khác với nhà cửa đường xá Alistair Cockburn nói, “Khi thiết kế nghĩ nhanh suy nghĩ đầy lỗ hổng nhỏ.” Một số khác tranh luận refactoring thay cho thiết kế Trong cách tiếp cận bạn hoàn toàn không thiết kế chút Bạn lập trình theo cách nghĩ ra, làm cho chạy sau refactor Thực tế cách làm thực cách hiệu Khi áp dụng refactoring, bạn không đặt áp lực lên thiết kế ban đầu Bạn không tìm kiếm giải pháp tốt mà chấp nhận giải pháp hợp lý Cùng với trình phát triển hiểu rõ toán bạn phát giải pháp hợp lý mà đưa vào hệ thống Một kết quan trọng refactoring đơn giản thiết kế Với cách thiết kế Page hoàn chỉnh từ đầu, bạn cần tìm giải pháp thật mềm dẻo để đáp ứng thay đổi yêu cầu Vấn đề thiết kế mềm dẻo phức tạp tốn thiết kế đơn giản Khi tiếp cận vấn đề với refactoring, bạn tự hỏi “Để refactor thiết kế đơn giản thành thiết kế mềm dẻo có khó không?” Nếu câu trả lời “khá dễ”, bạn việc cài đặt giải pháp đơn giản Như refactoring dẫn đến thiết kế đơn giản mà hy sinh mềm dẻo Khi bạn có nhận thức định refactor dễ dàng, bạn chí không nghĩ đến thiết kế mềm dẻo Chỉ việc xây dựng đơn giản làm việc Hầu hết thời gian bạn không cần dùng đến thiết kế mềm dẻo phức tạp 2.7 Refactoring với hiệu Mối quan ngại phổ biến với refactoring làm giảm hiệu chương trình Trong hầu hết trường hợp refactoring thực làm chương trình chậm Tuy nhiên bí mật chương trình chạy nhanh, trừ trường hợp nghiêm ngặt, trước tiên làm để dễ dàng tinh chỉnh, sau tinh chỉnh để đạt tốc độ mong muốn Một điều thú vị hiệu chương trình thường tốn nhiều thời gian vào phần nhỏ mã nguồn Do bạn tối ưu hoá toàn mã nguồn bạn lãng phí 90% công sức vào việc tối ưu hoá đoạn mã không chạy nhiều Áp dụng nhận xét bạn viết chương trình tốt mà không để ý nhiều đến hiệu Đến bắt đầu bước tối ưu hoá, thường muộn trình phát triển, bạn bắt đầu sử dụng chương trình profiler để phân tích đoạn mã tốn thời gian nhớ nhiều Tập trung vào điểm nóng này, bạn sửa đổi mã nguồn kiểm tra tiến hiệu đạt mục tiêu Refactoring giúp tối ưu hoá dễ dàng theo hai cách Thứ nhất, cài đặt nhanh hơn, bạn có nhiều thời gian để tối ưu hoá Thứ hai, mã nguồn chia nhỏ để dễ dàng phát điểm nóng dễ hiểu để bạn tối ưu hoá dễ dàng Page 10 5.3 Nhập phương thức (Inline method) 5.3.1 Tóm tắt Thân hàm rõ ràng tên Đặt trực tiếp thân phương thức vào nơi gọi xoá int getRating() { return (moreThanFiveLateDeliveries()) ? : 1; } boolean moreThanFiveLateDeliveries() { return _numberOfLateDeliveries > 5; } Được refactor thành: int getRating() { return (_numberOfLateDeliveries > 5) ? : 1; } 5.3.2 Động Một nguyên tắc lập trình sử dụng phương thức ngắn đặt tên cho thể mục đích phương thức giúp mã nguồn rõ ràng dễ đọc Nhưng bạn bắt gặp phương thức mà thân rõ ràng tên Hoặc bạn refactor đoạn mã thành phương thức rõ ràng tên Khi điều xảy ra, bạn nên loại bỏ phương thức Chỉ dẫn có ích, dẫn không cần thiết gây bực Trường hợp khác mà Nhập phương thức nên áp dụng bạn có nhóm phương thức bị phân chia không phù hợp Bạn nhập chúng lại thành phương thức lớn sau trích lại thành phương thức khác Bạn nên làm động tác trước áp dụng Thay phương thức đối tượng phương thức Bạn nhập lời gọi từ phương thức có hành động bạn mong muốn đối tượng phương thức Di chuyển phương thức dễ dàng phương thức phương thức sử dụng Đôi người ta sử dụng nhiều dẫn dường phương thức đơn giản uỷ quyền cho phương thức khác Trong trường hợp đó, số dẫn đáng giá tất Bằng cách Nhập phương thức, ta giữ lại phương thức hữu ích loại bỏ lại Page 20 5.4 Nhập biến tạm 5.4.1 Tóm tắt Bạn có biến tạm gán lần với biểu thức đơn giản gây cản trở refactoring khác Thay thể tất tham chiếu đến biến tạm biểu thức double basePrice = anOrder.basePrice(); return (basePrice > 1000) Trở thành: return (anOrder.basePrice() > 1000) 5.4.2 Động Trong phần lớn trường hợp Nhập biến tạm sử dụng phần Thay biến tạm truy vấn, động Trường hợp Nhập biến tạm sử dụng bạn thấy biến tạm gán giá trị trả phương thức Thường thường biến không gây hại bạn mặc kệ cách an toàn Nếu biến gây trở phương pháp refactoring, ví dụ Trích phương thức, đến lúc cần nhập 5.5 Di chuyển phương thức 5.5.1 Tóm tắt Một phương thức sử dụng lớp khác nhiều lớp mà định nghĩa Tạo phương thức với thân tương tự lớp sử dụng nhiều Hoặc chuyển phương thức cũ thành uỷ quyền xoá hẳn 5.5.2 Động Di chuyển phương thức phần tách rời refactoring Thường lớp có nhiều hành vi hay lớp tương tác nhiều, chúng bị gắn với (coupled) Bằng cách di chuyển vài phương thức, bạn làm cho lớp đơn giản hợp lý Sau bạn di chuyển trường đó, nhìn qua phương thức lớp để tìm phương thức truy cập đối tượng khác nhiều đối tượng mà đặt Khi bạn tìm thấy phương thức cần di chuyển, bạn nhìn vào phương thức gọi nó, phương thức gọi đến phương thức nạp chồng thừa kế Đánh giá có nên tiếp tục dựa đối tượng mà phương thức có nhiều tương Page 21 tác 5.5.3 Ví dụ Một lớp biểu diễn tài khoản minh hoạ cho kỹ thuật này: class Account double overdraftCharge() { if (_type.isPremium()) { double result = 10; if (_daysOverdrawn > 7) result += (_daysOverdrawn - 7) * 0.85; return result; } else return _daysOverdrawn * 1.75; } double bankCharge() { double result = 4.5; if (_daysOverdrawn > 0) result += overdraftCharge(); return result; } private AccountType _type; private int _daysOverdrawn; Giả sử bạn có vài loại tài khoản, loại có quy tắc riêng để tính tiền thấu chi (overdraft charge) Nên di chuyển hàm overdraftCharge() đến loại tài khoản Page 22 Chương Các công cụ refactor 6.1 Refactor công cụ Refactor sử dụng công cụ hiệu nhiều so với refactor tay Ngay bạn có bảo hiểm kiểm thử, refactor tay tốn thời gian nhiều Với hỗ trợ ngày cao công cụ, refactoring ngày tách rời khỏi lập trình Chúng ta không nói “bây lập trình” “bây refactor” mà nói “Trích phần phương thức, đẩy lên lớp cha sau gọi phương thức vừa tạo lớp mà làm việc” Vì bạn không kiểm thử sau thao tác refactor tự động hoá nên việc chuyển đổi hai mũ trở nên rõ ràng nhiều 6.2 Refactor mã nguồn Java Eclipse Ngày công cụ refactor cho ngôn ngữ định kiểu tĩnh đầy đủ Để bạn nắm refactor áp dụng thực tế nào, sử dụng Eclipse với ngôn ngữ Java để minh hoạ Dưới trình bày số công cụ thường dùng, danh sách đầy đủ công cụ hỗ trợ Eclipse Helios cho Phụ lục D Page 23 6.2.1 Thực đơn refactor Tại vị trí soạn thảo, nhấn phải chuột chọn refactor sử dụng tổ hợp phím Alt-Shift-T, bạn nhận thực đơn thao tác refactor Danh sách tuỳ thuộc vào nơi bạn đặt trỏ nên không cho thấy hết khả Eclipse 6.2.2 Đổi tên Đây thao tác hay dùng Khi đặt trỏ tên lớp, biến hay phương thức nhấn tổ hợp phím Alt-Shift-R, tên chọn đánh dấu tất nơi xuất cửa số soạn thảo thời Khi bạn nhập tên bạn mong muốn nhấn enter Tất tham chiếu đến đối tượng cửa sổ thời đổi theo Page 24 Bạn chọn tệp mã nguồn Java nhấn tổ hợp phím Alt-Shift-R nhấn phím F2 để đổi tên lớp bên tên với tệp 6.2.3 Trích phương thức Lựa chọn đoạn mã nhấn tổ hợp phím Alt-Shift-M kích hoạt thực đơn refactor chọn mục Extract method Trong hộp hội thoại, điền tên phương thức mới, bạn xếp thứ tự tham số thay đổi tên, kiểu tham số Page 25 6.2.4 Nhập phương thức Trong trỏ đặt tên phương thức, sử dụng tổ hợp phím Alt-Shift-I kích hoạt thực đơn refactor chọn Inline Page 26 6.2.5 h ậ p N biến tạm Trong trỏ đặt tên biến, nhấn tổ hợp phím Alt-Shift-I kích hoạt thực đơn refactor > Inline 6.2.6 i D chuyển phương thức Trong trỏ đặt tên mộ phương thức, nhấn tổ hợp phím Alt-Shift-V kích hoạt thực đơn refactor, chọn Move Page 27 Page 28 Phụ lục A Tài liệu tham khảo [1] Martin Fowler et al., Refactoring: Improving the Design of Existing Code, First Edition, 1999 [2] Bộ môn Công nghệ Phần mềm Đại học Bách Khoa Hà Nội, Slide giảng Nhập môn Công nghệ Phần mềm, 2001 [3] Wikipedia contributors, "Code refactoring," Wikipedia, The Free Encyclopedia, http://en.wikipedia.org/w/index.php?title=Code_refactoring&oldid=419442858 (accessed March 21, 2011) [4] Những người đóng góp vào Wikipedia, “Cải tiến mã nguồn,” Wikipedia, Bách khoa toàn thư mở, http://vi.wikipedia.org/w/index.php?title=C%E1%BA%A3i_ti %E1%BA%BFn_m%C3%A3_ngu%E1%BB%93n&oldid=4218952 (truy nhập ngày 21 tháng năm 2011) Page 29 Phụ lục A Danh sách “bad smells in code” Mã nguồn trùng lặp Phương thức dài Lớp lớn Danh sách tham số dài Thay đổi bất đồng Shotgun surgery Feature envy Data clumps Ám ảnh liệu nguyên thuỷ 10 Câu lệnh switch 11 Phân cấp thừa kế song song 12 Lớp lười biếng 13 Sự tổng quát để dành 14 Trường tạm 15 Chuỗi thông điệp 16 Trung gian 17 Thân mật không cách 18 Lớp thay với giao diện khác 19 Lớp thư viện không đầy đủ 20 Lớp liệu 21 Của thừa kế bị từ chối 22 Chú thích Page 30 Phụ lục A Danh sách phương pháp refactor Soạn thảo phương thức 1.1 Trích phương thức 1.2 Nhập phương thức 1.3 Nhập biến tạm 1.4 Thay biến tạm truy vấn 1.5 Tạo biến giải thích 1.6 Tách biến tạm 1.7 Bỏ phép gán tham số 1.8 Thay phương thức đối tượng phương thức 1.9 Thay giải thuật Di chuyển tính đối tượng 2.1 Di chuyển phương thức 2.2 Di chuyển trường 2.3 Trích lớp 2.4 Bỏ lớp 2.5 Giấu delegate 2.6 Xoá lớp trung gian 2.7 Tạo phương thức 2.8 Tạo phần mở rộng nội Tổ chức liệu 3.1 Đóng gói trường nội 3.2 Thay giá trị đối tượng 3.3 Đổi giá trị thành tham chiếu 3.4 Đổi tham chiếu thành giá trị 3.5 Thay mảng đối tượng 3.6 Nhân liệu 3.7 Đổi liên kết chiều thành liên kết hai chiều 3.8 Đổi liên kết hai chiều thành liên kết chiều Page 31 3.9 Thay giá trị đặc biệt đặt tên 3.10 Đóng gói trường 3.11 Đóng gói tập hợp 3.12 Thay ghi lớp liệu 3.13 Thay mã kiểu lớp 3.14 Thay mã kiểu lớp 3.15 Thay mã kiểu trạng thái, chiến lược 3.16 Thay lớp trường Đơn giản hoá biểu thức điều kiện 4.1 Phân ly điều kiện 4.2 Kết hợp biểu thức điều kiện 4.3 Kết hợp đoạn mã điều kiện 4.4 Xoá cờ điều khiển 4.5 Thay điều kiện lồng biểu thức canh 4.6 Thay điều kiện đa hình 4.7 Tạo đối tượng null 4.8 Tạo xác nhận (assertion) Khiến lời gọi hàm đơn giản 5.1 Đổi tên phương thức 5.2 Thêm tham số 5.3 Xoá tham số 5.4 Tách truy vấn khỏi thay đổi 5.5 Tham số hoá phương thức 5.6 Thay tham số phương thức tường minh 5.7 Giữ đối tượng nguyên vẹn 5.8 Thay tham số phương thức 5.9 Tạo đối tượng tham số 5.10 Xoá phương thức thiết lập 5.11 Giấu phương thức Page 32 5.12 Thay hàm tạo factory method 5.13 Đóng gói ép kiểu xuống 5.14 Thay mã lỗi ngoại lệ 5.15 Thay ngoại lệ kiểm tra Đương đầu với tổng quát hoá 6.1 Kéo lên trường 6.2 Kéo lên phương thức 6.3 Kéo lên thân hàm tạo 6.4 Đẩy xuống phương thức 6.5 Đẩy xuống trường 6.6 Trích lớp 6.7 Trích lớp cha 6.8 Trích giao diện 6.9 Thu gọn kế thừa 6.10 Tổ chức phương thức mẫu 6.11 Thay kế thừa uỷ quyền 6.12 Thay uỷ quyền kế thừa Refactoring lớn 7.1 Tách đôi thừa kế 7.2 Chuyển đổi thiết kế thủ tục thành đối tượng 7.3 Tách nghiệp vụ khỏi trình bày 7.4 Trích thừa kế Page 33 Phụ lục A Các công cụ refactor mã nguồn Java Eclipse Helios Rename (Đổi tên) Move (Di chuyển) Change method signature (Đổi chữ kí phương thức) Extract Method (Trích phương thức) Extract Local Variable (Trích biến cục bộ) Extract Constant (Trích hằng) Inline (Nhập phương thức, biến) Convert Anonymous Class to Nested (Chuyển lớp vô danh sang lớp lồng) Move Type to New File (Di chuyển kiểu sang tệp mới) 10 Convert Local Variable to Field (Chuyển biến nội thành trường) 11 Extract Superclass (Trích lớp cha) 12 Extract Interface (Trích giao diện) 13 Use Supertype Where Possible (Sử dụng lớp cha, giao diện có thể) 14 Push Down (Đẩy xuống) 15 Pull Up (Kéo lên) 16 Extract Class (Trích lớp) 17 Introduce Parameter Object (Tạo đối tượng tham số) 18 Introduce Indirection 19 Introduce Factory 20 Introduce Parameter (Tạo tham số) 21 Encapsulate Field (Bao đóng trường) 22 Generalize Declared Type (Tổng quát hoá) 23 Infer Generic Type Arguments Page 34 [...]... Page 27 Page 28 Phụ lục A Tài liệu tham khảo [1] Martin Fowler et al., Refactoring: Improving the Design of Existing Code, First Edition, 1999 [2] Bộ môn Công nghệ Phần mềm Đại học Bách Khoa Hà Nội, Slide bài giảng Nhập môn Công nghệ Phần mềm, 2001 [3] Wikipedia contributors, "Code refactoring, " Wikipedia, The Free Encyclopedia, http://en.wikipedia.org/w/index.php?title=Code _refactoring& oldid=419442858... 5.4.2 Động cơ Trong phần lớn trường hợp Nhập biến tạm được sử dụng như một phần của Thay biến tạm bằng truy vấn, đó là động cơ chính Trường hợp duy nhất Nhập biến tạm được sử dụng một mình là khi bạn thấy một biến tạm được gán giá trị trả về của một phương thức Thường thường biến này không gây hại và bạn có thể mặc kệ nó một cách an toàn Nếu biến này gây cả trở các phương pháp refactoring, ví dụ như... phải có bộ kiểm thử chắc chắn Ngay cả khi bạn có những công cụ có thể tự động hoá refactoring, bạn vẫn cần kiểm thử Sẽ còn rất lâu nữa trước khi mọi thao tác refactor đều có thể thực hiện bằng công cụ 4.1 Giá trị của mã kiểm thử Nếu bạn quan sát hầu hết các lập trình viên sử dụng thời gian của họ, bạn sẽ nhận ra rằng viết mã thực ra chỉ chiếm một phần nhỏ Một ít thời gian để tìm hiểu cần phải làm gì... result; } private AccountType _type; private int _daysOverdrawn; Giả sử bạn có một vài loại tài khoản, mỗi loại có quy tắc riêng để tính tiền thấu chi (overdraft charge) Nên di chuyển hàm overdraftCharge() đến các loại tài khoản đó Page 22 Chương 6 Các công cụ refactor 6.1 Refactor bằng công cụ Refactor sử dụng công cụ hiệu quả hơn nhiều so với refactor bằng tay Ngay cả khi bạn có bảo hiểm bằng bộ kiểm... gian để viết mã kiểm thử là một cách tiết kiệm thời gian và phát triển phần mềm nhanh hơn Thậm chí một số phương pháp phát triển phần mềm hiện đại yêu cầu viết mã kiểm thử trước khi viết chương trình Bằng việc viết ra các trường hợp có thể xảy ra, bạn hiểu rõ mình mong muốn điều gì ở tính năng sắp cài đặt Viết test cũng giúp bạn tập trung vào giao diện hơn là cài đặt (luôn luôn là thói quen tốt) Nó... chỉ dẫn không cần thiết chỉ gây bực mình Trường hợp khác mà Nhập phương thức nên được áp dụng là khi bạn có một nhóm các phương thức bị phân chia không phù hợp Bạn có thể nhập chúng lại thành một phương thức lớn sau đó trích lại thành các phương thức khác Bạn nên làm động tác này trước khi áp dụng Thay phương thức bằng đối tượng phương thức Bạn nhập các lời gọi từ phương thức có hành động bạn mong muốn... trong một thành phần Chẳng hạn “depositAmount” và “depositCurrency” có nhiều khả năng cùng thuộc về một thành phần Nói chung, chia sẻ một tiền tố hoặc hậu tố trong một tập con của các biến trong một lớp gợi ý cần một thành phần mới Nếu thành phần này thích hợp làm lớp con, bạn sẽ thấy Trích lớp con dễ thực hiện hơn Đôi khi một lớp không sử dụng tất cả các biến thể hiện của nó trong tất cả thời gian Nếu... khác Trong những trường hợp đó, một số chỉ dẫn là đáng giá nhưng không phải tất cả Bằng cách Nhập phương thức, ta có thể giữ lại những phương thức hữu ích và loại bỏ những gì còn lại Page 20 5.4 Nhập biến tạm 5.4.1 Tóm tắt Bạn có một biến tạm được gán một lần với một biểu thức đơn giản và nó gây cản trở các refactoring khác Thay thể tất cả tham chiếu đến biến tạm đó bằng một biểu thức double basePrice... refactor Hiểu thế nào là refactoring không có nghĩa là bạn đã biết nên refactor lúc nào và ở đâu Mục đích của chương này là đưa ra những chỉ dẫn để bạn nhận biết những vấn đề trong mã nguồn và biết cách khắc phục Các tác giả Martin Fowler và Kent Beck gọi chúng là “bad smells in code” (tạm dịch: mùi hôi trong mã nguồn) Đây không phải là những thước đo chuẩn để nói rõ đoạn mã nào có vấn đề và đoạn mã nào không,... Trích phương thức, đến lúc cần nhập nó 5.5 Di chuyển phương thức 5.5.1 Tóm tắt Một phương thức được sử dụng bởi một lớp khác nhiều hơn là lớp mà nó được định nghĩa Tạo một phương thức mới với thân tương tự trong lớp sử dụng nó nhiều nhất Hoặc chuyển phương thức cũ thành những sự uỷ quyền hoặc xoá hẳn nó đi 5.5.2 Động cơ Di chuyển phương thức là phần không thể tách rời của refactoring Thường khi lớp có ... triển công nghệ phần mềm, với phát triển mạnh mẽ phần cứng yêu cầu hiệu suất xử lý ngày quan trọng thay vào đó, tính dễ hiểu đề cao Do kỹ thuật refactoring ngày ý nhằm nâng cao chất lượng phần mềm. .. quy trình phát triển phần mềm v.v Để phần mềm vượt khỏi phạm vi tập lớn, đồ án môn học, đồ án tốt nghiệp tiếp tục phát triển thành sản phẩm thực tế thành công sống kỹ refactoring cần thiết... Tài liệu tham khảo [1] Martin Fowler et al., Refactoring: Improving the Design of Existing Code, First Edition, 1999 [2] Bộ môn Công nghệ Phần mềm Đại học Bách Khoa Hà Nội, Slide giảng Nhập môn