Công nghệ phần mềm Tìm hiểu về Refactoring

BÁO CÁO CÔNG NGHỆ PHẦN MỀM Đề Tài: Tìm Hiểu Về Refactoring   Mục Lục Chương 1. Giới thiệu 5 Chương 2. Các nguyên lý về refactoring 6 2.1. Định nghĩa refactoring 6 2.2. Tại sao cần refactor? 6 2.2.1. Refactoring giúp cải thiện thiết kế 6 2.2.2. Refactoring giúp phần mềm dễ hiểu hơn 7 2.2.3. Refactoring giúp bạn lập trình nhanh hơn 7 Chương 3. Tiêu chí đánh giá source code tiêu chuẩn và thời điểm thích hợp để refactoring. 9 3.1. Source code là gì ? 9 3.2. Tiêu chí đánh giá source code đạt tiêu chuẩn ? 9 3.2.1. Code chạy được chạy được chạy được 9 3.2.2. Code chạy đứng 9 3.2.3. Giải quyết được vấn đề khách hàng yêu cầu 10 3.2.4. Code có thể mở rộng 10 3.3. Thời điểm tốt để refactoring code ? 10 3.3.1. Khi thêm chức năng mới vào source cũ 10 3.3.2. Khi tiến hành xem lại code và nâng cấp, tối ưu code 11 3.3.3. Khi cần bàn giao lại 11 Chương 4. Các kỹ thuật Refactoring 12 4.1. Composing Methods 12 4.1.1. Kỹ thuật này dùng để làm gì ? 12 4.1.2. Các kỹ thuật chính trong nhóm này 12 4.1.3. Khi nào nên dùng kỹ thuật này ? 12 4.2. Moving features between objects 13 4.2.1. Kỹ thuật này dùng để làm gì ? 13 4.2.2. Các kỹ thuật chính trong nhóm này 13 4.2.3. Khi nào nên dùng kỹ thuật này ? 14 4.3. Organizing data 14 4.3.1. Kỹ thuật này dùng để làm gì ? 14 4.3.2. Các kỹ thuật chính trong nhóm này 14 4.3.3. Khi nào nên dùng kỹ thuật này ? 15 4.4. Simplifying Conditional Expressions 16 4.4.1. Kỹ thuật này dùng dể làm gì? 16 4.4.2. Các kỹ thuật chính của nhóm này 16 4.4.3. Khi nào nên sử dụng kỹ thuật này ? 17 4.5. Simplifying Method Calls 17 4.5.1. Kỹ thuật này dùng để làm gì? 17 4.5.2. Các kỹ thuật chính của nhóm này 17 4.5.3. Khi nào nên sử dụng kỹ thuật này ? 18 4.6. Dealing With Generalizations 19 4.6.1. Kỹ thuật này làm gì? 19 4.6.2. Các kỹ thuật chính của nhóm này 19 4.6.3. Khi nào nên sử dụng kỹ thuật này ? 20 Chương 5. Các công cụ Refactoring và Demo 21 5.1. Tại sao cần sử dụng công cụ để Refactoring 21 5.2. Giới thiệu các công cụ Refactoring được tích hợp sẵn vào các IDEs 22 5.2.1. Đối với IDEs Inteliji IDEA 22 5.2.1.a. Gọi chức năng Refactoring 22 5.2.2. Đối với IDE Visual Studio Code 25 5.2.3. Đối với IDE Visual Studio 26 5.3. Các Plugin hay sử dụng trong cac IDE 27 5.3.1. Một số Plugin cho IDE Visual Studio Code 28 5.3.2. Một số Plugin cho IDE Visual Studio 29 5.4. Nhược điểm của các công cụ Refactoring 29 Chương 1. Giới thiệu Refactoring là quá trình thay đổi một hệ thống phần mềm nhằm cái tiến cấu trúc bên trong nhưng không làm biến đổi hành vi bên ngoài của nó. Refactoring là việc dọn dẹp mã nguồn một cách có tổ chức sao cho tối thiểu hoá khả năng gây ra lỗi. Về bản chất refactoring là nâng cấp thiết kế của mã nguồn sau khi nó đã được viết ra. Trong những hiểu biết thông thường về công nghệ phần mềm, chúng ta thiết kế trước sau đó mới cài đặt. Cần có thiết kế tốt trước sau đó mới có cài đặt tốt. Qua thời gian, mã nguồn bị sửa đổi và sự nhất quán của hệ thống, cấu trúc của nó theo thiết kế, dần dần mờ nhạt. Quá trình cài đặt chuyển dần từ chế tạo sang chắp vá. Refactoring là cách làm ngược lại. Khi refactor bạn có thể lấy một thiết kế tồi, thậm chí là hỗn loạn, và làm lại để nó trở thành một mã nguồn được thiết kế tốt. Mỗi bước đều đơn giản, thậm chí rất đơn giản. Bạn chỉ chuyển một trường từ lớp này sang lớp khác, lấy vài đoạn mã ra khỏi phương thức để tạo ra phương thức riêng và đẩy vài đoạn mã lên hay xuống cây thừa kế. Tuy nhiên tác động tích luỹ của những thay đổi nhỏ đó có thể cái thiện đáng kể thiết kế. Đó là sự đảo ngược của khái niệm software decay. Khi refactor bạn sẽ nhận thấy sự phân phối công việc thay đổi. Thiết kế thay vì diễn ra đầu tiên, lại diễn ra liên tục trong suốt quá trình phát triển. Bạn học được cách cải tiến thiết kế từ việc xây dựng hệ thống. Kết quả của sự tương tác này dẫn đến một chương trình với thiết kế luôn tốt khi quá trình phát triển tiếp diễn. Qua quá trình phát triển của công nghệ phần mềm, cùng với sự phát triển mạnh mẽ của phần cứng thì yêu cầu về hiệu suất xử lý ngày càng ít quan trọng thay vào đó, tính dễ hiểu được đề cao. Do đó các kỹ thuật refactoring cũng ngày càng được chú ý nhằm nâng cao chất lượng phần mềm. Thực tế học tập của sinh viên Việt Nam cho thấy các phần mềm được viết trên ghế nhà trường thường không có được thiết kế tốt ngay từ ban đầu. Dẫn đến tình trạng này có rất nhiều nguyên nhân chủ quan lẫn khách quan như thiếu kinh nghiệm, thiếu thời gian, chưa chú trọng đến quy trình phát triển phần mềm v.v... Để những phần mềm này vượt ra khỏi phạm vi của những bài 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ế và thành công trong cuộc sống thì kỹ năng refactoring là rất cần thiết. Chương 2. Các nguyên lý về refactoring 2.1. Định nghĩa refactoring Thuật ngữ refactoring được phát minh bởi Ward Cunningham và Kent Beck vào khoảng những năm 1980 khi làm việc với ngôn ngữ Smalltalk. Trong cuốn sách “Refactoring: Improving the Design of Existing Code” cung cấp hai định nghĩa như sau: Refactoring (danh từ): một sự thay đổi ở cấu trúc bên trong của phần mềm giúp nó dễ hiểu và dễ sửa đổi hơn mà không làm thay đổi hành vi bên ngoài. Refactor (động từ): tái cấu trúc phần mềm bằng cách áp dụng một loạt thao tác refactoring mà không làm thay đổi hành vi bên ngoài. Trong một số tài liệu tiếng Việt, refactoring được chuyển ngữ thành “cải tiến mã nguồn” tuy nhiên cách nói này khá dài dòng và cũng không diễn tả được hết ý nghĩa của thuật ngữ. Tài liệu này sẽ để nguyên thuật ngữ tiếng Anh với hai dạng như trên, ngoài ra refactoring cũng được hiểu là tổng hợp các phương pháp và công cụ để tiến hành refactor phần mềm nói chung. Như vậy, hiểu theo nghĩa nào đó refactor chỉ đơn giản là dọn dẹp mã nguồn. Tuy nhiên bằng cách áp dụng những phương pháp, công cụ của refactoring, việc dọn dẹp mã nguồn sẽ hiệu quả hơn đáng kể. Cần phân biệt refactoring và tối ưu hoá hiệu năng (performance optimization). Mục đích của refactoring là làm cho phần mềm dễ hiểu và dễ sửa chữa hơn. Tối ưu hoá hiệu năng cũng không làm thay đổi hành vi bên ngoài của phần mềm (trừ tốc độ) mà chỉ thay đổi cấu trúc bên trong tuy nhiên việc tối ưu hoá thường dẫn đến những đoạn mã nguồn khó hiểu và khó sửa chữa. Một đặc tính quan trọng nữa của refactoring là không thay đổi hành vi bên ngoài của phần mềm. Phần mềm vẫn phải thực hiện những chức năng giống hệt những gì nó làm trước đó. Người dùng, kể cả end user và lập trình viên, không thể nhận ra rằng có gì đó vừa thay đổi. 2.2. Tại sao cần Refactor? 2.2.1. Refactoring giúp cải thiện thiết kế Không có refactoring, thiết kế của phần mềm sẽ phân rã (software decay). Khi mã nguồn được thay đổi để hiện thực hoá những mục tiêu ngắn hạn hoặc thay đổi mà không hiểu đầy đủ thiết kế, mã nguồn mất dần cấu trúc. Ngày càng khó nhận ra thiết kế bằng cách đọc mã nguồn. Refactoring giống như sắp xếp lại mã nguồn. Bạn xếp lại những gì không ở đúng chỗ của nó. Sự mất cấu trúc của mã nguồn có hiệu ứng tích luỹ. Càng khó nhận ra thiết kế từ mã nguồn thì càng khó duy trì thiết kế đó. Refactoring thường xuyên có thể giúp mã nguồn giữ được hình dạng. Mã nguồn được thiết kế không tốt thường chữa nhiều đoạn mã làm cùng một việc, thông thường là do mã nguồn hay làm cùng một việc ở những chỗ khác nhau. Vì thế một khía cạnh quan trọng của cải tiến thiết kế là xoá bỏ những đoạn mã trùng lặp. Tầm quan trọng của việc này nằm ở những thay đổi mã nguồn trong tương lai. Giảm lượng mã không giúp hệ thống chạy nhanh hơn chút nào nhưng lại khiến việc sửa đổi dễ dàng hơn rất nhiều. Có ít mã cần phải hiểu hơn và chỉ cần sửa ở một nơi sự thay đổi sẽ được áp dụng trên toàn bộ hệ thống. 2.2.2. Refactoring giúp phần mềm dễ hiểu hơn Lập trình giống như cuộc 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 gì và nó sẽ trả lời bằng cách làm chính xác điều bạn bảo. Bạn cần xoá bỏ khoảng cách giữa điều bạn muốn máy tính làm với điều bạn nói với nó. Lập trình theo cách hiểu này chỉ đơn giản là nói chính xác điều bạn muốn. Tuy nhiên còn có những người khác cần sử dụng mã nguồn của bạn. Ai đó sẽ thử đọc mã nguồn của bạn trong thời gian vài tháng để có thể sửa đổi vài chỗ. Chúng ta dễ quên mất người sử dụng bổ sung đó, trong khi họ thực ra lại là những người quan trọng nhất. Ai bận tâm nếu máy tính mất thêm vài xung nhịp để dịch? Nhưng sự khác biệt sẽ rất lớn nếu một lập trình viên mất một tuần để thực hiện một sự sửa đổi trong khi đáng lẽ mất vài giờ nếu anh ta hiểu mã nguồn của bạn. Bạn cũng có thể sử dụng refactoring như một cách để hiểu những đoạn mã của người khác. Đọc một vài dòng mã và cố gắng thay đổi nó để phản ánh đúng hơn cách hiểu của bạn sau đó thử chạy lại xem nó còn làm việc hay không. Với cách làm này dần dần bạn sẽ có hiểu biết chắc chắn về hệ thống và việc trở lại những đoạn mã đã được refactoring sẽ dễ dàng hơn nhiều. 2.2.3. Refactoring giúp bạn lập trình nhanh hơn Điều này nghe như một nghịch lý. Để nâng cao chất lượng mã nguồn, chúng ta cần đầu tư thời gian vào việc refactoring, chẳng phải việc đó sẽ làm giảm năng suất? Thực tế chứng minh rằng thiết kế tốt là rất quan trọng đối với tốc độ phát triển phần mềm. Không có một thiết kế tốt, bạn có thể tiến nhanh một lúc nhưng sau đó sẽ sớm chậm lại. Bạn phải dành thời gian tìm và sửa lỗi thay vì thêm chức năng mới. Việc sửa đổi lâu hơn vì bạn phải cố hiểu hệ thống và tìm những đoạn mã trùng lặp. Thiết kế tốt là điều kiện cần để duy trì tốc độ phát triển phần mềm và refactoring giúp bạn chống lại sự phân rã (decay) của thiết kế, thậm chí còn cải thiện thiết kế nữa. Chương 3. Tiêu chí đánh giá source code tiêu chuẩn và thời điểm thích hợp để refactoring. 3.1. Source code là gì ? Source code hay mã nguồn là những bộ mã chương trình được tạo ra bởi lập trình viên khi sử dụng ngôn ngữ lập trình. Chúng ta thường thấy source code được hiển thị ở dưới dạng văn bản. Trong source code sẽ tập hợp những dòng lệnh để tạo nên một thao tác nào đó trên website. Website quảng bá được coi như là bộ mặt của công ty nên các công ty thường không ngại chi một khoản không nhỏ để phát triển source code riêng của họ. Nói đến đây thì chúng ta đã hiểu được tầm quan trọng của source code. 3.2. Tiêu chí đánh giá source code đạt tiêu chuẩn ? Để tạo nên những phần mềm ứng dụng cho công việc và đời sống, hơn hết những dòng code phải thật sự chất lượng và những người viết code cũng thật sự hiểu chúng. Để đánh giá một source code tốt hay xấu, bằng cảm tính có thể thấy dễ dàng khi chạy phần mềm. Dưới đây là một số quy tắc định tính để đánh giá source code có đạt tiêu chuẩn hay không? 3.2.1. Code chạy được chạy được chạy được Điều quan trọng phải nhắc đến 3 lần, “chạy được” là vấn đề tiên quyết để khẳng định sự tồn tại của phần mềm.Nếu viết một chương trình dài 1000m trên không nhưng bị lỗi cơ bản như: lỗi biên dịch, tràn bộ nhớ,… thì tất nhiên công sức code cũng tan thành mây khói. Là người phát triển phần mềm, hơn ai hết, chúng ta đều hy vọng code chạy được. Để hy vọng không thành “tuyệt vọng” thì phải trải qua khổ luyện và kinh nghiệm nghiên cứu và thực hành để sửa các lỗi. 3.2.2. Code chạy đứng Đúng ở đây là đúng với mục đích người code muốn đạt được. Để đạt được điều này, người lập trình phải nắm vững các kiến thức cơ bản và nâng cao về chuyên môn của họ. Không phải ngẫu nhiên, những nền móng cơ bản cho người lập trình là cấu trúc dữ liệu, phân tích và thiết kế giải thuật, cơ sở dữ liệu, … Đó là nền tảng cơ bản để người lập trình có được tư duy logic hay nói cách khác là điều khiển được code của mình chạy đúng ý mình. 3.2.3. Giải quyết được vấn đề khách hàng yêu cầu Code chạy đúng ý của người viết ra code nhưng mục tiêu viết ra phần mềm là hướng tới người dùng. Những yêu cầu của khách hàng là những bài toán bắt buộc chúng ta phải có lời giải đúng và chính xác nhất. Để thực sự đáp ứng được nghiệp vụ mà khác hàng yêu cầu. Làm rõ những thắc mắc và thực hiện những trao đổi giữa các bên liên quan (khách hàng, dev, tester, … ) để tất cả cùng hiểu đúng “đầu ra” của sản phẩm. 3.2.4. Code có thể mở rộng Một phần mềm khi được viết ra thường được sử dụng cho mục đích hiện tại và cả trong tương tai luôn luôn có sự thay đổi. Vì thế quy mô phần mềm thường lớn dần đòi hỏi người lập trình cũng phải mở rộng code của mình. Những phần mềm luôn luôn duy trì hoạt động nâng cấp và mở rộng từng phút từng giờ như Facebook, Google, Twitter,… Vậy nên tiêu chí đánh giá code có thể dễ mở rộng là tiêu chí quan trọng để đánh giá một source code có thực sự tốt hay không? 3.3. Thời điểm tốt để refactoring code ? Với những tiêu chí đánh giá code như trên thì việc refactoring code là vô cùng quan trọng để ngày càng tiệm cận với độ hoàn hảo đạt được các tiêu chí. Vậy chúng ta có thể refactoring khi nào và thời điểm nào là hoàn hảo nhất để thực hiện refactoring? Câu trả lời là bất cứ lúc nào, bạn cũng có thể refactoring code của mình để code mình trông dễ hiểu, dễ sử dụng. Sau đây là một vài thời điểm “vàng” để refactoring. 3.3.1. Khi thêm chức năng mới vào source cũ Ứng với tiêu chí đánh giá thứ tư của một source code đạt tiêu chuẩn: code dễ mở rộng thì việc thêm một chức năng mới vào source cũ là thời điểm tốt để refactoring. Yêu cầu khách hàng thường chỉ có tăng chứ không giảm. Bất chợt đang sắp hoàn thành sản phẩm nhưng khách hàng yêu cầu thêm 1 tác vụ, 1 chức năng nữa thì bạn phải viết thêm code. Hoặc một source code bạn viết sẵn đã lâu không đụng đến, nay phải lôi ra và viết thêm 1 chức năng mới gì đấy. Đây là thời điểm bạn phải đọc lại source code cũ để dễ hiêu và thêm vào 1 phần mới, có thể phần mới này sẽ ảnh hưởng cả đến những phần source cũ thi đây là thời điểm thích hợp để refactoring. 3.3.2. Khi tiến hành xem lại code và nâng cấp, tối ưu code Ứng với tiêu chí đánh giá thứ nhất và thứ hai của một source code đạt tiêu chuẩn: việc tiến hành xem lại code, và tối ưu code là thời điểm tốt để refactoring. Lắm lúc chúng ta muốn code không bị cồng kềnh, cần tối ưu, thu gọn code của mình thì điều đầu tiên đặt ra là vẫn phải hoàn thiện tiêu chí “chạy được” và “chạy đúng”. Có thể xảy ra vài trường hợp khá bực tức là sau khi thu gọn, tối ưu thì các chức năng đã viết bị ảnh hưởng dẫn đến việc mất đi mối liên kết của phần mềm với người dùng. Do đó, đây cũng là thời điểm tốt để refactoring code. Làm cho code trở nên đơn giản nhưng vẫn giữ được bản chất, chức năng vốn có của phần mềm. 3.3.3. Khi cần bàn giao lại Ứng với tiêu chí thứ 3 của một source code đạt tiêu chuẩn: luôn luôn hướng đến khách hàng. Sản phẩm thì luôn đến tay người tiêu dùng. Vậy khách hàng phải là người hiểu và biết cách sử dụng cũng như tự canh chỉnh, thay đổi để thuận tiện việc quản lí và sử dụng. Có những đoạn code rắc rối, phức tạp chỉ người viết hiểu nên khi bàn giao lại cho khách hàng, người mới sử dụng sẽ gây khó khăn nên đây là thời điểm tốt để refactoring. Đây là vấn đề thường gặp của các bên thứ ba, bán và mua phần mềm để phục vụ cho doanh nghiệp, công ty,… Chương 4. Các kỹ thuật Refactoring Có rất nhiều kỹ thuật refactoring khác nhau, mỗi kỹ thuật đôi khi chỉ làm thay đổi một chút nho nhỏ mã nguồn, nhưng những thay đổi nhỏ đó được tích luỹ dần theo thời gian thì tạo nên một ảnh hưởng rất lớn, giúp cho hệ thống của chúng ta trở nên tốt hơn.Dưới đây là các nhóm kỹ thuật dùng để refactoring. 4.1. Composing Methods 4.1.1. Kỹ thuật này dùng để làm gì ? Trong hầu hết các trường hợp, các phương thức quá dài là gốc rễ của mọi vấn đề phát sinh (exception,bug... ). Những phương thức này khiến cho chương trình trở nên khó hiểu, che giấu tính logic, thứ tự thực hiện, khó khăn cho công tác bảo trì. Nhóm kỹ thuật này để hợp lý hóa các phương thức, loại bỏ sự trùng lặp code, mở đường cho các cải tiến trong tương lai. 4.1.2. Các kỹ thuật chính trong nhóm này • Extract Method (Tách phương thức) • Inline Method (Gộp phương thức) • Extract Variable (Tách biến) • Inline Temp (Gộp biến tạm thời) • Substitute Algorithm (Thay thế thuật toán) • Replace Temp with Query (Thay biến tạm bằng phương thức) • Split Temporary Variable (Tách biến tạm) • Remove Assignments to Parameters (Không thay đổi tham số) • Replace Method with Method Object (Thay phương thức bằng phương thức của đối tượng) 4.1.3. Khi nào nên dùng kỹ thuật này ?  Nếu phương thức của bạn quá dài do gộp quá nhiều tác vụ vào, gây mơ hồ khi đọc => Dùng kỹ thuật Extract Method.  Nếu phần thân của phương thức rõ ràng hơn tên của nó => Dùng kỹ thuật Inline Method  Nếu bạn có những biểu thức khó hiểu => Dùng kỹ thuật Extract Variable  Nếu bạn có một biến tạm thời được gán cho một phương thức đơn giản => Dùng kỹ thuật Inline Temp  Nếu bạn muốn một kết quả dùng được cho nhiều phương thức thay vì một phương thức => Dùng kỹ thuật Replace Temp with Query  Nếu bạn chỉ có một biến tạm để lưu kết quả cho tất cả các biểu thức => Dùng kỹ thuật Split Temporary Variable  Nếu bạn muốn tránh việc thay đổi tham số truyền vào => Dùng kỹ thuật Remove Assignments to Parameters  Nếu bạn có một phương thức quá dài với những biến cục bộ đan xen mà không thể dùng kỹ thuật Extract Method => Dùng kỹ thuật Replace Method with Method Object.  Nếu bạn muốn thay đổi thuật toán hiện tại => Dùng kỹ thuật Substitute Algorithm 4.2. Moving features between objects 4.2.1. Kỹ thuật này dùng để làm gì ? Mặc dù bạn có thể dùng chung các phương thức cho các class khác nhau nhưng trong một số trường hợp, việc này không phải là cách tốt nhất. Nhóm kỹ thuật này chỉ ra cách di chuyển các feature giữa các class một cách an toàn, tạo các lớp mới và ẩn các triển khai chi tiết khỏi các truy cập công khai. 4.2.2. Các kỹ thuật chính trong nhóm này • Move Method (Di chuyển phương thức) • Move Field (Di chuyển trườngthuộc tính) • Extract Class (Tách lớp) • Inline Class (Gộp lớp) • Hide Delegate (Ẩn uỷ quyền) • Remove Middle Man (Loại bỏ trung gian) • Introduce Foreign Method (Giới thiệu phương thức ngoài) • Introduce Local Extension (Giới thiệu tiện ích nội bộ) 4.2.3. Khi nào nên dùng kỹ thuật này ?  Nếu một phương thức được sử dụng ở class khác nhiều hơn class chứa nó => Dùng kỹ thuật Move Method  Nếu một trường được sử dụng ở class khác nhiều hơn class chứa nó => Dùng kỹ thuật Move Field  Nếu một class làm 2 việc trở lên => Dùng kỹ thuật Extract Class  Nếu một class hầu như không chịu trách nhiệm bất cứ việc gì mà chỉ ủy quyền cho class khác => Dùng kỹ thuật Inline Class  Nếu bạn không muốn cho client biết về chuỗi kết nối giữa các class => Dùng kỹ thuật Hide Delegate  Nếu bạn thấy việc gọi class này thông qua class khác là không cần thiết => Dùng kỹ thuật Remove Middle Man  Nếu một lớp tiện ích hay lớp được định nghĩa trước(predefined class) không có phương thức bạn cần, mà bạn không thể thêm phương thức này vào lớp đó => Dùng kỹ thuật Introduce Foreign Method  Nếu một lớp tiện ích hay lớp được định nghĩa trước không có một số phương thức bạn cần nhưng bạn không thể thêm các phương thức này vào lớp đó => Dùng kỹ thuật Introduce Local Extension 4.3. Organizing data 4.3.1. Kỹ thuật này dùng để làm gì ? Các kỹ thuật tái cấu trúc này giúp xử lý dữ liệu, thay thế các nguyên thủy bằng method class phong phú. Một kết quả quan trọng khác là gỡ rối các liên kết giữa các class, điều này làm cho các class linh động hơn và có thể tái sử dụng. 4.3.2. Các kỹ thuật chính trong nhóm này • Change Value to Reference (Thay đổi giá trị thành tham chiếu) • Change Reference to Value (Thay đổi tham chiếu thành giá trị) • Duplicate Observed Data (Trùng lặp dữ liệu quan sát) • Self Encapsulate Field (Trường tự đóng gói) • Replace Data Value with Object (Thay thế dữ liệu bằng đối tượng) • Replace Array with Object (Thay thế mảng bằng đối tượng) • Change Unidirectional Association to Bidirectional (Thay đổi liên kết một chiều thành hai chiều) • Change Bidirectional Association to Unidirectional (Thay đổi liên kết hai chiều thành một chiều) • Encapsulate Field (Đóng gói trường) • Encapsulate Collection (Đóng gói bộ) • Replace Magic Number with Symbolic Constant (Thay thế số bằng hằng số) • Replace Type Code with Class (Thay thế loại mã bằng lớp) • Replace Type Code with Subclasses (Thay thế loại mã bằng lớp con) • Replace Type Code with StateStrategy (Thay thế loại mã bằng trạng thái) • Replace Subclass with Fields (Thay thế lớp con bằng trường) 4.3.3. Khi nào nên dùng kỹ thuật này ?  Nếu bạn có nhiều trường hợp giống hệt nhau trong 1 class mà bạn cần thay thế chung bằng một đối tượng duy nhất => Dùng kỹ thuật Change Value to Reference  Nếu bạn có một đối tượng tham chiếu quá nhỏ và không thường xuyên được thay đổi để phù hợp với việc quản lý vòng đời của đối tượng đó => Dùng kỹ thuật Change Reference to Value  Nếu dữ liệu được lưu trữ các lớp chịu trách nhiệm về GUI => Dùng kỹ thuật Duplicate Observed Data  Nếu bạn sử dụng truy cập trực tiếp đến các thuộc tính riêng tư => Dùng kỹ thuật Self Encapsulate Field  Nếu một class (hoặc một nhóm các class) chứa một trường dữ liệu mà trường đó có hành vi riêng tư và dữ liệu liên quan => Dùng kỹ thuật Replace Data Value with Object.  Nếu bạn có một mảng chứa nhiều kiểu dữ liệu => Dùng kỹ thuật Replace Array with Object.  Nếu bạn có 2 class mà mỗi class cần sử dụng tính năng của class kia nhưng liên kết giữa chúng chỉ là một chiều => Dùng kỹ thuật Change Unidirectional Association to Bidirectional.  Nếu bạn có 2 class mà liên kết giữa chúng là 2 chiều nhưng chỉ có một class cần sử dụng tính năng của class kia => Dùng kỹ thuật Change Bidirectional Association to Unidirectional  Nếu bạn có các trườngthuộc tính công khai => Dùng kỹ thuật Encapsulate Field  Nếu có một class chứa một trường tập hợp và một getter và setter đơn giản để làm việc với tập hợp => Dùng kỹ thuật Encapsulate Collection.  Nếu bạn có một số có ý nghĩa và muốn thay đổi thành hằng số => Dùng kỹ thuật Replace Magic Number with Symbolic Constant.  Nếu một class có một thuộc tính chứa mã kiểu. Các giá trị của loại này không được sử dụng trong các điều kiện của toán tử và không ảnh hưởng đến hoạt động của chương trình => Dùng kỹ thuật Replace Type Code with Class  Nếu bạn có kiểu được mã hóa ảnh hưởng trực tiếp đến hành vi của chương trình (các giá trị của trường này kích hoạt nhiều mã khác nhau trong điều kiện) => Dùng kỹ thuật Replace Type Code with Subclass  Nếu có một loại được mã hóa ảnh hưởng đến hành vi nhưng bạn không thể sử dụng các subclass để loại bỏ nó => Dùng kỹ thuật Replace Type Code with StateStrategy.  Nếu có các lớp con chỉ khác nhau về phương thức( trả về không đổi) => Dùng kỹ thuật Replace Subclass with Fields. 4.4. Simplifying Conditional Expressions 4.4.1. Kỹ thuật này dùng dể làm gì? Các điều kiện có xu hướng ngày càng trở nên phức tạp hơn trong logic của chúng và kỹ thuật này dùng để chống lại điều này. 4.4.2. Các kỹ thuật chính của nhóm này • Consolidate Conditional Expression (Hợp nhất biểu thức có điều kiện) • Consolidate Duplicate Conditional Fragments (Hợp nhất các đoạn điều kiện trùng lặp) • Decompose Conditional (Phá hủy điều kiện) • Replace Conditional with Polymorphism (Thay thế điều kiện bằng tính đa hình) • Remove Control Flag (Loại bỏ cờ điều khiển) • Replace Nested Conditional with Guard Clauses (Thay thế điều kiện lồng nhau bằng các điều khoản bảo vệ) • Introduce Null Object (Giới thiệu đối tượng rỗng) • Introduce Assertion (Giới thiệu khẳng định) 4.4.3. Khi nào nên sử dụng kỹ thuật này ?  Nếu có nhiều điều kiện dẫn đến cùng một hành động hoặc kết quả => Dùng Consolidate Conditional Expression.  Nếu có các đoạn mã giống hệt nhau được tìm thấy trong các nhánh điều kiện => Dùng Consolidate Duplicate Conditional Fragments  Nếu có những điều kiện quá phức tạp => Dùng Decompose Conditional  Nếu bạn có các điều kiện thực hiện những hành động khác nhau dựa vào kiểu đối tượng hoặc thuộc tính => Dùng kỹ thuật Replace Conditional with Polymorphism.  Nếu có 1 biến boolean hành động như cờ điều khiển cho nhiều biểu thức Boolean.  Nếu có một nhóm các điều kiện lồng nhau và khó xác định quy trình thực thi mã bình thường.  Nếu bạn không muốn trả về null mà trả về đối tượng null thể hiện hành vi mặc định => Dùng kỹ thuật Introduce Null Object  Nếu bạn muốn các điều kiện hoặc giá trị đều phải dung => Dùng kỹ thuật Introduce Assertion. 4.5. Simplifying Method Calls 4.5.1. Kỹ thuật này dùng để làm gì? Kỹ thuật này khiến cho việc gọi phương thức trở nên đơn giản và dễ hiểu hơn. Điều này làm đơn giản hóa giao diện cho sự tương tác giữa các class. 4.5.2. Các kỹ thuật chính của nhóm này • Add Parameter (Thêm tham số) • Remove Parameter (Xóa tham số) • Rename Method (Đổi tên phương thức) • Separate Query from Modifier (Tách truy vấn khỏi công cụ sửa đổi ) • Parameterize Method (Tham số hóa) • Introduce Parameter Object (Giới thiệu đối tượng tham số) • Preserve Whole Object (Giữ toàn bộ đối tượng) • Remove Setting Method (Loại bỏ phương thức cài đặt) • Replace Parameter with Explicit Methods (Thay thế tham số bằng rõ ràng) • Replace Parameter with Method Call (Thay thế tham số bằng phương thức gọi) • Hide Method (Ẩn phương thức) • Replace Constructor with Factory Method (Thay thế phương thức khởi tạo bằng phương thức nhà máy) • Replace Error Code with Exception (Thay thế code lỗi bằng ngoại lệ) • Replace Exception with Test (Thay thế ngoại lệ bằng kiểm tra) 4.5.3. Khi nào nên sử dụng kỹ thuật này ?  Nếu một phương thức không có đủ dữ liệu để thực hiện các hành động nhất định => Dùng kỹ thuật Add Parameter  Nếu một tham số không được sử dụng trong phương thức => Dùng kỹ thuật Remove Parameter  Nếu tên của phương thức không giải thích được điều nó thực sự làm => Dùng kỹ thuật Rename Method  Nếu bạn có một phương thức trả về một giá trị nhưng bên trong nó có một thứ gì đó bị thay đổi => Dùng kỹ thuật Separate Query from Modifier  Nếu có phương thức chỉ khác nhau về giá trị, số hoặc phép toán => Dùng kỹ thuật Parameterize Method  Nếu phương thức của bạn chứa nhóm tham số lặp => Dùng kỹ thuật Introduce Parameter Object  Nếu bạn nhận một số giá trị từ 1 đổi tượng và sau đó chuyển chúng dưới dạng tham số cho một phương thức => Dùng kỹ thuật Preserve Whole Object  Nếu bạn muốn xóa các phương thức đặt thuộc tính => Dùng kỹ thuật Remove Setting Method.  Nếu có một phương thức được chia thành nhiều phần và mỗi phần hành động dựa vào giá trị của tham số => Dùng kỹ thuật Replace Parameter with Explicit Methods  Nếu gọi một phương thức truy vấn và truyền kết quả của nó như một tham số cho phương thức khác, trong khi phương thức đó có thể gọi truy vấn trực tiếp => Dùng kỹ thuật Replace Parameter with Method Call  Nếu một phương thức không được sử dụng bởi các lớp khác hoặc chỉ được sử dụng trong hệ thống phân cấp lớp của chính nó => Dùng kỹ thuật Hide Method.  Nếu bạn có một phương thức khởi tạo phức tạp không chỉ là thiết lập các giá trị tham số trong các thuộc tính => Dùng kỹ thuật Replace Constructor with Factory Method.  Nếu có một phương thức trả về một lỗi => Dùng kỹ thuật Replace Error Code with Exception.  Nếu bạn ném một ngoại lệ đến nơi kiểm tra ngoại lệ đó => Dùng kỹ thuật Replace Exception with Test. 4.6. Dealing With Generalizations 4.6.1. Kỹ thuật này làm gì? Trừu tượng có một nhóm kỹ thuật tái cấu trúc riêng, chủ yếu liên quan đến việc di chuyển chức năng dọc theo hệ thống phân cấp kế thừa lớp, tạo ra các lớp và giao diện mới, đồng thời thay thế kế thừa bằng ủy quyền và ngược lại. 4.6.2. Các kỹ thuật chính của nhóm này • Pull Up Field (Đẩy thuộc tính lên) • Pull Up Method (Đẩy phương thức lên) • Pull Up Constructor Body (Đẩy hàm khởi tạo lên) • Push Down Field (Đẩy thuộc tính xuống) • Push Down Method (Đẩy phương thức xuống) • Extract Subclass (Tách lớp con) • Extract Superclass (Tách lớp cha) • Extract Interface (Tách interface) • Collapse Hierarchy (Gộp biểu mẫu phân tách) • Form Template Method (Phương thức mẫu thay thế) • Replace Inheritance with Delegation (Thay thế kế thừa bằng ủy quyền) • Replace Delegation with Inheritance (Thay thế ủy quyền bằng kế thừa) 4.6.3. Khi nào nên sử dụng kỹ thuật này ?  Nếu 2 lớp có cùng thuộc tính => Dùng kỹ thuật Pull Up Field.  Nếu các lớp con có các phương thức hoạt động như nhau => Dùng kỹ thuật Pull Up Method.  Nếu các lớp con có các hàm khởi tạo với các mã hầu như giống nhau => Dùng kỹ thuật Pull Up Constructor Body.  Nếu chỉ có một lớp con sử dụng thuộc tính này => Dùng kỹ thuật Push Down Field.  Nếu một phương thức chỉ được sử dụng trong một lớp con => Dùng kỹ thuật Push Down Method.  Nếu một lớp có chức năng chỉ được sử dụng trong một số trường hợp nhất định => Dùng kỹ thuật Extract Subclass.  Nếu có 2 lớp có trường và phương thức chung => Dùng kỹ thuật Extract Superclass.  Nếu nhiều máy khách đang sử dụng cùng 1 phần của lớp giao diện hoặc một phần của lớp giao diện trong 2 lớp là như nhau => Dùng kỹ thuật Extract Interface.  Nếu bạn có một hệ thống phân cấp trong đó một lớp con giống với lớp cha => Dùng kỹ thuật Collapse Hierarchy,  Nếu các lớp con triển khai các thuật toán chứa các bước tương tự theo cùng một thứ tự => Dùng kỹ thuật Form Template Method.  Nếu có một lớp con chỉ sử dụng một phần các phương thức của lớp cha(hoặc không thể kể thừa dữ liệu của lớp cha) => Dùng kỹ thuật Replace Inheritance with Delegation.  Nếu có một lớp chứa nhiều phương thức đơn giản ủy quyền cho các phương thức khác => Dùng kỹ thuật Replace Delegation with Inheritance. Chương 5. Các công cụ Refactoring và Demo 5.1. Tại sao cần sử dụng công cụ để Refactoring Như chúng ta đã biết, kĩ thuật Refactoring loại bỏ những “Code Smells” khỏi mã nguồn của dự án. Nó có rất nhiều lợi ích cho kế hoạch lâu dài của dự án. Khi thực hiện Refactoring cho dự án, chúng ta cần chỉnh sửa rất nhiều mã lệnh. Nếu chúng ta theo một trong những quy chuẩn Refactoring như trên thì ta phải sửa rất nhiều vị trí mà các vị trí đó có cách sửa như nhau. Vậy nên các công cụ Refactoring được sinh ra để xử lí các tác vụ Refactoring nhanh hơn, chính xác hơn, tránh sai sót cho người phát triển dự án. Như hình trên, chương trình nguồn của dự án tồn tại rất nhiều lỗi (Bad Smells) mà con người không thể tìm ra hết để xử lí. Các công cụ Refactoring can thiệp trực tiếp vào môi trường phát triển ứng dụng (IDEs) để thực hiện chức năng Refactoring. Ứng với từng môi trường phát triển ứng dụng sẽ có các công cụ Refactoring được phát triển, giúp cho quá trình Refactoring trên các môi trường thuận tiện và hiệ quả. Khi sử dụng các công cụ Refactoring, nó có thể chỉ ra trong chương trình nguồn đó các vị trí mà nên Refactoring với các kĩ thuật Refactoring theo quy chuẩn và được cập nhật mới nhất, phục vụ cho việc Refactoring trở nên nhanh hơn, chính xác hơn, hiệu quả hơn. Các công cụ Refactoring được phân thành hai nhóm chính: • Các công cụ Refactoring được tích hợp sẵn vào các IDEs do nhà phát triển IDEs cung cấp. • Các công cụ Refactoring do bên thứ 3 phát triển (Plugin) 5.2. Giới thiệu các công cụ Refactoring được tích hợp sẵn vào các IDEs Hiện nay, có rất nhiều IDEs được sử dụng cho nhiều dự án với các ngôn ngữ khác nhau. Trong bài báo cáo này sẽ giới thiệu một số công cụ Refactoring được tích hợp sẵn trong các IDEs phổ biến như: Inteliji IDEA, Visual Studio Code, Visual Studio. 5.2.1. Đối với IDEs Inteliji IDEA 5.2.1.a. Gọi chức năng Refactoring 1. Chọn phần code cần refactoring (có thể chọn các files, các thư mục trong dự án hoặc các đoạn lệnh, dòng lệnh trong IDE) 2. Nhấn phím tắt Ctrl + Alt + T để mở danh sách các chức năng Refactoring do nhà cung cấp viết sẵn. Hình ảnh sau khi gọi chức năng Refactoring của IDE Inteliji IDEA 5.2.1.b. Xem trước thay đổi sau khi Refactoring 1. Để xem thay đổi, bấm vào nút Preview trong cửa sổ Refactoring. Cửa sổ Refactoring 2. Trong khi xem trước những thay đổi sau khi Refactoring, bạn có thể xoá (sử dụng phím Delete) hoặc di chuyển (sử dụng tổ hợp phím Ctrl + X) những thành phần đang có vấn đề. Xem trước những thay đổi code sau khi Refactoring 3. Sau khi xem xong những thay đổi, bạn kích vào Do Refactor để thực hiện Refactoring với những thay đổi như khi xem trước. 5.2.1.c. Xử lí xung đột code khi Refactoring Khi thực hiện Refactoring, có lúc sẽ xuất hiện một vài xung đột code. Inteliji đã hỗ trợ phần xử lí xung đột khi Refactoring. Cửa sổ xử lí xung đột khi Refactoring 1. Lựa chọn Continue để bỏ qua xung đột. Code Refactoring sẽ ghi đè code cũ mặc dù sẽ có vấn đề ở đó. 2. Lựa chọn Show Conflics in View để xem các nơi code bị xung đột bằng công cụ Find. Sau đó bạn có thể sửa lại những vùng đó cho phù hợp. Cửa sổ xem các nới bị xung đột code bằng công cụ Find 3. Lựa chọn Cancel để huỷ bỏ Refactoring. Code của bạn sẽ giữ nguyên và không có Refactoring xảy ra. 5.2.1.d Thiết lập cài đặt Refactoring Bạn có thể sửa lại cách mà công cụ Refactoring trong IDE Inteliji cung cấp hoạt động. 5.2.2. Đối với IDE Visual Studio Code Trong Visual Studio Code, có một chức năng tương tự như Refactoring như của Inteliji, gọi là Code Actions. Nó hỗ trợ Refactoring và Quickfix (dùng để sửa nhanh những vấn đề đơn giản). 5.2.2.a. Gọi chức năng Refactoring Cách 1: Bạn có thể gọi chức năng Code Actions (Code Actions bao gồm cả chức năng Refactoring) bằng tổ hợp phím Ctrl + . hoặc nhấn vào biểu tượng bóng đèn gần nơi muốn Refactoring. Code Actions trong VS Code Cách 2: Bạn chỉ dùng chức năng Refactoring thì nhấn tổ hợp phím Ctrl + Shift + R. 5.2.2.b. Thực hiện Refactoring 1. Tách hàm, tách biến Chọn đoạn code mà bạn muốn refactoring. Sau đó gọi chức năng Refactoring, bạn sẽ nhìn thấy các tuỳ chọn Refactoring có sẵn trong đó có các chức năng tách hàm (Extract to function), tách biến (Extract variable). 5.2.2.c. Đổi tên biến Chọn biến cần đổi tên, sau đó nhấn phím F2. Nhập tên biến mới vào rồi nhần Enter. IDE sẽ tự lựa chọn tất cả các biến có tên liên quan để đổi sang tên mới. Chức năng này có thể đổi tên biến giữa các file có liên quan với nhau. 5.2.3. Đối với IDE Visual Studio 5.2.3.a. Đổi tên biến, tên hàm 1. Chọn tên biến cần đổi 2. Chọn chức năng Quick Actions and Refactorings rồi chọn mục Change Signature. Sau đó đổi tên mới rồi nhấn OK. Đổi tên biến 5.2.3.b. Tách hàm 1. Chọn đoạn code cần tách hàm 2. Chọn chức năng Quick Actions and Refactorings rồi chọn mục Extract Method. Sau đó đổi tên mới rồi nhấn OK. 5.3. Các Plugin hay sử dụng trong cac IDE Hiện nay, nhiều nhà phát triển đã tạo ra những Plugin phục vụ cho quá trình Refactoring chạy trên môi trường của các IDE để lập trình viên dễ dàng sử dụng. 5.3.1. Một số Plugin cho IDE Visual Studio Code 5.3.2. Một số Plugin cho IDE Visual Studio 5.4. Nhược điểm của các công cụ Refactoring • Đôi khi, các công cụ Refactoring thay đổi ngữ nghĩa của code không mong muốn. • Đôi khi, các công cụ Refactoring thay đổi ngữ nghĩa của code không mong muốn. • Cần phải bỏ ra thời gian để học cách sử dụng các công cụ mới. • Một số công cụ hướng tới Refactoring theo một cách nào đó nhưng không phù hợp với hiện tại. • Nhiều công cụ phải trả phí để dùng. • Trong một dự án, nếu muốn dùng một công cụ Refactoring nào đó, cần phải có sự thống nhất giữa mọi người trong nhóm. Tài Liệu Tham Khảo 1 https:www.jetbrains.comhelpidearefactoringsourcecode.html 2 https:code.visualstudio.comdocseditorrefactoring 3 https:docs.microsoft.comenusvisualstudioiderefactoringinvisualstudio?view=vs2019 4 https:marketplace.visualstudio.com 5 https:marketplace.visualstudio.com

Giảng viên hướng dẫn: Nguyễn Thanh Bình BÁO CÁO CƠNG NGHỆ PHẦN MỀM Đề Tài: Tìm Hiểu Về Refactoring SVTH: Dương Thanh Dũng (102180060), Nguyễn Lê Anh Minh(102180083), Nguyễn Bá Vũ(102180109), Nguyễn Nhật Minh(102180029) Giảng viên hướng dẫn: Nguyễn Thanh Bình Mục Lục Chương 1.Giới thiệu .5 Chương 2.Các nguyên lý refactoring .6 2.1 Định nghĩa refactoring .6 2.2 Tại cần refactor? 2.2.1 Refactoring giúp cải thiện thiết kế .6 2.2.2 Refactoring giúp phần mềm dễ hiểu .7 2.2.3 Refactoring giúp bạn lập trình nhanh Chương 3.Tiêu chí đánh giá source code tiêu chuẩn thời điểm thích hợp để refactoring 3.1 Source code ? 3.2 Tiêu chí đánh giá source code đạt tiêu chuẩn ? 3.2.1 Code chạy được! chạy được! chạy được! .9 3.2.2 Code chạy đứng 3.2.3 Giải vấn đề khách hàng yêu cầu 10 3.2.4 Code mở rộng 10 3.3 Thời điểm tốt để refactoring code ? .10 3.3.1 Khi thêm chức vào source cũ .10 3.3.2 Khi tiến hành xem lại code nâng cấp, tối ưu code 11 3.3.3 Khi cần bàn giao lại 11 Chương 4.Các kỹ thuật Refactoring 12 4.1 Composing Methods 12 SVTH: Dương Thanh Dũng (102180060), Nguyễn Lê Anh Minh(102180083), Nguyễn Bá Vũ(102180109), Nguyễn Nhật Minh(102180029) Giảng viên hướng dẫn: Nguyễn Thanh Bình 4.1.1 Kỹ thuật dùng để làm ? 12 4.1.2 Các kỹ thuật nhóm 12 4.1.3 Khi nên dùng kỹ thuật ? 12 4.2 Moving features between objects 13 4.2.1 Kỹ thuật dùng để làm ? 13 4.2.2 Các kỹ thuật nhóm 13 4.2.3 Khi nên dùng kỹ thuật ? 14 4.3 Organizing data 14 4.3.1 Kỹ thuật dùng để làm ? 14 4.3.2 Các kỹ thuật nhóm 14 4.3.3 Khi nên dùng kỹ thuật ? 15 4.4 Simplifying Conditional Expressions 16 4.4.1 Kỹ thuật dùng dể làm gì? 16 4.4.2 Các kỹ thuật nhóm 16 4.4.3 Khi nên sử dụng kỹ thuật ? 17 4.5 Simplifying Method Calls 17 4.5.1 Kỹ thuật dùng để làm gì? 17 4.5.2 Các kỹ thuật nhóm 17 4.5.3 Khi nên sử dụng kỹ thuật ? 18 4.6 Dealing With Generalizations 19 4.6.1 Kỹ thuật làm gì? 19 4.6.2 Các kỹ thuật nhóm 19 4.6.3 Khi nên sử dụng kỹ thuật ? 20 Chương 5.Các công cụ Refactoring Demo 21 SVTH: Dương Thanh Dũng (102180060), Nguyễn Lê Anh Minh(102180083), Nguyễn Bá Vũ(102180109), Nguyễn Nhật Minh(102180029) Giảng viên hướng dẫn: Nguyễn Thanh Bình 5.1 Tại cần sử dụng công cụ để Refactoring 21 5.2 Giới thiệu công cụ Refactoring tích hợp sẵn vào IDEs 22 5.2.1 Đối với IDEs Inteliji IDEA 22 5.2.1.a Gọi chức Refactoring .22 5.2.2 Đối với IDE Visual Studio Code 25 5.2.3 Đối với IDE Visual Studio 26 5.3 Các Plug-in hay sử dụng cac IDE 27 5.3.1 Một số Plug-in cho IDE Visual Studio Code .28 5.3.2 Một số Plug-in cho IDE Visual Studio .29 5.4 Nhược điểm công cụ Refactoring .29 SVTH: Dương Thanh Dũng (102180060), Nguyễn Lê Anh Minh(102180083), Nguyễn Bá Vũ(102180109), Nguyễn Nhật Minh(102180029) Giảng viên hướng dẫn: Nguyễn Thanh Bình 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 ngồi 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 Q 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ế ln tốt q trình phát triển tiếp diễn Qua q 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 khơng có 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 SVTH: Dương Thanh Dũng (102180060), Nguyễn Lê Anh Minh(102180083), Nguyễn Bá Vũ(102180109), Nguyễn Nhật Minh(102180029) Giảng viên hướng dẫn: Nguyễn Thanh Bình Chương 2.1 Các nguyên lý refactoring Đị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 ngồi 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 hố 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, khơng thể nhận có vừa thay đổi 2.2 Tại cần Refactor? 2.2.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á SVTH: Dương Thanh Dũng (102180060), Nguyễn Lê Anh Minh(102180083), Nguyễn Bá Vũ(102180109), Nguyễn Nhật Minh(102180029) Giảng viên hướng dẫn: Nguyễn Thanh Bình 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.2.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ị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 cịn 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.2.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? 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 SVTH: Dương Thanh Dũng (102180060), Nguyễn Lê Anh Minh(102180083), Nguyễn Bá Vũ(102180109), Nguyễn Nhật Minh(102180029) Giảng viên hướng dẫn: Nguyễn Thanh Bình 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ịn cải thiện thiết kế SVTH: Dương Thanh Dũng (102180060), Nguyễn Lê Anh Minh(102180083), Nguyễn Bá Vũ(102180109), Nguyễn Nhật Minh(102180029) Giảng viên hướng dẫn: Nguyễn Thanh Bình Chương 3.1 Tiêu chí đánh giá source code tiêu chuẩn thời điểm thích hợp để refactoring Source code ? Source code hay mã nguồn mã chương trình tạo lập trình viên sử dụng ngơn ngữ lập trình Chúng ta thường thấy source code hiển thị dạng văn Trong source code tập hợp dòng lệnh để tạo nên thao tác website Website quảng bá coi mặt công ty nên công ty thường không ngại chi khoản không nhỏ để phát triển source code riêng họ Nói đến hiểu tầm quan trọng source code 3.2 Tiêu chí đánh giá source code đạt tiêu chuẩn ? Để tạo nên phần mềm ứng dụng cho công việc đời sống, hết dòng code phải thật chất lượng người viết code thật hiểu chúng Để đánh giá source code tốt hay xấu, cảm tính thấy dễ dàng chạy phần mềm Dưới số quy tắc định tính để đánh giá source code có đạt tiêu chuẩn hay khơng? 3.2.1 Code chạy được! chạy được! chạy được! Điều quan trọng phải nhắc đến lần, “chạy được” vấn đề tiên để khẳng định tồn phần mềm.Nếu viết chương trình dài 1000m khơng bị lỗi như: lỗi biên dịch, tràn nhớ,… tất nhiên cơng sức code tan thành mây khói Là người phát triển phần mềm, hết, hy vọng code chạy Để hy vọng khơng thành “tuyệt vọng” phải trải qua khổ luyện kinh nghiệm nghiên cứu thực hành để sửa lỗi 3.2.2 Code chạy đứng Đúng với mục đích người code muốn đạt Để đạt điều này, người lập trình phải nắm vững kiến thức nâng cao chuyên môn họ Không phải ngẫu nhiên, móng cho người lập trình cấu trúc liệu, phân tích thiết kế giải thuật, sở liệu, … Đó tảng để người lập trình có tư logic hay nói cách khác điều khiển code chạy ý SVTH: Dương Thanh Dũng (102180060), Nguyễn Lê Anh Minh(102180083), Nguyễn Bá Vũ(102180109), Nguyễn Nhật Minh(102180029) Giảng viên hướng dẫn: Nguyễn Thanh Bình 3.2.3 Giải vấn đề khách hàng yêu cầu Code chạy ý người viết code mục tiêu viết phần mềm hướng tới người dùng Những yêu cầu khách hàng toán bắt buộc phải có lời giải xác Để thực đáp ứng nghiệp vụ mà khác hàng yêu cầu Làm rõ thắc mắc thực trao đổi bên liên quan (khách hàng, dev, tester, … ) để tất hiểu “đầu ra” sản phẩm 3.2.4 Code mở rộng Một phần mềm viết thường sử dụng cho mục đích tương tai ln ln có thay đổi Vì quy mơ phần mềm thường lớn dần địi hỏi người lập trình phải mở rộng code Những phần mềm ln ln trì hoạt động nâng cấp mở rộng phút Facebook, Google, Twitter,… Vậy nên tiêu chí đánh giá code dễ mở rộng tiêu chí quan trọng để đánh giá source code có thực tốt hay không? 3.3 Thời điểm tốt để refactoring code ? Với tiêu chí đánh giá code việc refactoring code vơ quan trọng để ngày tiệm cận với độ hoàn hảo đạt tiêu chí Vậy refactoring thời điểm hoàn hảo để thực refactoring? Câu trả lời lúc nào, bạn refactoring code để code trơng dễ hiểu, dễ sử dụng Sau vài thời điểm “vàng” để refactoring 3.3.1 Khi thêm chức vào source cũ Ứng với tiêu chí đánh giá thứ tư source code đạt tiêu chuẩn: code dễ mở rộng việc thêm chức vào source cũ thời điểm tốt để refactoring Yêu cầu khách hàng thường có tăng khơng giảm Bất hồn thành sản phẩm khách hàng yêu cầu thêm tác vụ, chức bạn phải viết thêm code Hoặc source code bạn viết sẵn lâu không đụng đến, phải lôi viết thêm chức Đây thời điểm bạn phải đọc lại source code cũ để dễ hiêu thêm vào phần mới, phần ảnh hưởng đến phần source cũ thi thời điểm thích hợp để refactoring 10 SVTH: Dương Thanh Dũng (102180060), Nguyễn Lê Anh Minh(102180083), Nguyễn Bá Vũ(102180109), Nguyễn Nhật Minh(102180029) Giảng viên hướng dẫn: Nguyễn Thanh Bình  Rename Method (Đổi tên phương thức)  Separate Query from Modifier (Tách truy vấn khỏi công cụ sửa đổi )   Parameterize Method (Tham số hóa) Introduce Parameter Object (Giới thiệu đối tượng tham số)  Preserve Whole Object (Giữ toàn đối tượng)  Remove Setting Method (Loại bỏ phương thức cài đặt)  Replace Parameter with Explicit Methods (Thay tham số rõ ràng)   Replace Parameter with Method Call (Thay tham số phương thức gọi) Hide Method (Ẩn phương thức)  Replace Constructor with Factory Method (Thay phương thức khởi tạo phương thức nhà máy)  Replace Error Code with Exception (Thay code lỗi ngoại lệ)  Replace Exception with Test (Thay ngoại lệ kiểm tra) 4.5.3 Khi nên sử dụng kỹ thuật ?  Nếu phương thức khơng có đủ liệu để thực hành động định => Dùng kỹ thuật Add Parameter  Nếu tham số không sử dụng phương thức => Dùng kỹ thuật Remove Parameter  Nếu tên phương thức khơng giải thích điều thực làm => Dùng kỹ thuật Rename Method  Nếu bạn có phương thức trả giá trị bên có thứ bị thay đổi => Dùng kỹ thuật Separate Query from Modifier  Nếu có phương thức khác giá trị, số phép toán => Dùng kỹ thuật Parameterize Method  Nếu phương thức bạn chứa nhóm tham số lặp => Dùng kỹ thuật Introduce Parameter Object 19 SVTH: Dương Thanh Dũng (102180060), Nguyễn Lê Anh Minh(102180083), Nguyễn Bá Vũ(102180109), Nguyễn Nhật Minh(102180029) Giảng viên hướng dẫn: Nguyễn Thanh Bình  Nếu bạn nhận số giá trị từ đổi tượng sau chuyển chúng dạng tham số cho phương thức => Dùng kỹ thuật Preserve Whole Object  Nếu bạn muốn xóa phương thức đặt thuộc tính => Dùng kỹ thuật Remove Setting Method  Nếu có phương thức chia thành nhiều phần phần hành động dựa vào giá trị tham số => Dùng kỹ thuật Replace Parameter with Explicit Methods  Nếu gọi phương thức truy vấn truyền kết tham số cho phương thức khác, phương thức gọi truy vấn trực tiếp => Dùng kỹ thuật Replace Parameter with Method Call  Nếu phương thức không sử dụng lớp khác sử dụng hệ thống phân cấp lớp => Dùng kỹ thuật Hide Method  Nếu bạn có phương thức khởi tạo phức tạp khơng thiết lập giá trị tham số thuộc tính => Dùng kỹ thuật Replace Constructor with Factory Method  Nếu có phương thức trả lỗi => Dùng kỹ thuật Replace Error Code with Exception  Nếu bạn ném ngoại lệ đến nơi kiểm tra ngoại lệ => Dùng kỹ thuật Replace Exception with Test 4.6 Dealing With Generalizations 4.6.1 Kỹ thuật làm gì? Trừu tượng có nhóm kỹ thuật tái cấu trúc riêng, chủ yếu liên quan đến việc di chuyển chức dọc theo hệ thống phân cấp kế thừa lớp, tạo lớp giao diện mới, đồng thời thay kế thừa ủy quyền ngược lại 4.6.2  Các kỹ thuật nhóm Pull Up Field (Đẩy thuộc tính lên) 20 SVTH: Dương Thanh Dũng (102180060), Nguyễn Lê Anh Minh(102180083), Nguyễn Bá Vũ(102180109), Nguyễn Nhật Minh(102180029) Giảng viên hướng dẫn: Nguyễn Thanh Bình  Pull Up Method (Đẩy phương thức lên)  Pull Up Constructor Body (Đẩy hàm khởi tạo lên)  Push Down Field (Đẩy thuộc tính xuống)   Push Down Method (Đẩy phương thức xuống) Extract Subclass (Tách lớp con)  Extract Superclass (Tách lớp cha)  Extract Interface (Tách interface)   Collapse Hierarchy (Gộp biểu mẫu phân tách) Form Template Method (Phương thức mẫu thay thế)  Replace Inheritance with Delegation (Thay kế thừa ủy quyền)  Replace Delegation with Inheritance (Thay ủy quyền kế thừa) 4.6.3 Khi nên sử dụng kỹ thuật ?  Nếu lớp có thuộc tính => Dùng kỹ thuật Pull Up Field  Nếu lớp có phương thức hoạt động => Dùng kỹ thuật Pull Up Method  Nếu lớp có hàm khởi tạo với mã giống => Dùng kỹ thuật Pull Up Constructor Body  Nếu có lớp sử dụng thuộc tính => Dùng kỹ thuật Push Down Field  Nếu phương thức sử dụng lớp => Dùng kỹ thuật Push Down Method  Nếu lớp có chức sử dụng số trường hợp định => Dùng kỹ thuật Extract Subclass  Nếu có lớp có trường phương thức chung => Dùng kỹ thuật Extract Superclass 21 SVTH: Dương Thanh Dũng (102180060), Nguyễn Lê Anh Minh(102180083), Nguyễn Bá Vũ(102180109), Nguyễn Nhật Minh(102180029) Giảng viên hướng dẫn: Nguyễn Thanh Bình  Nếu nhiều máy khách sử dụng phần lớp giao diện phần lớp giao diện lớp => Dùng kỹ thuật Extract Interface  Nếu bạn có hệ thống phân cấp lớp giống với lớp cha => Dùng kỹ thuật Collapse Hierarchy,  Nếu lớp triển khai thuật toán chứa bước tương tự theo thứ tự => Dùng kỹ thuật Form Template Method  Nếu có lớp sử dụng phần phương thức lớp cha(hoặc kể thừa liệu lớp cha) => Dùng kỹ thuật Replace Inheritance with Delegation  Nếu có lớp chứa nhiều phương thức đơn giản ủy quyền cho phương thức khác => Dùng kỹ thuật Replace Delegation with Inheritance 22 SVTH: Dương Thanh Dũng (102180060), Nguyễn Lê Anh Minh(102180083), Nguyễn Bá Vũ(102180109), Nguyễn Nhật Minh(102180029) Giảng viên hướng dẫn: Nguyễn Thanh Bình Chương 5.1 Các cơng cụ Refactoring Demo Tại cần sử dụng công cụ để Refactoring Như biết, kĩ thuật Refactoring loại bỏ “Code Smells” khỏi mã nguồn dự án Nó có nhiều lợi ích cho kế hoạch lâu dài dự án Khi thực Refactoring cho dự án, cần chỉnh sửa nhiều mã lệnh Nếu theo quy chuẩn Refactoring ta phải sửa nhiều vị trí mà vị trí có cách sửa Vậy nên công cụ Refactoring sinh để xử lí tác vụ Refactoring nhanh hơn, xác hơn, tránh sai sót cho người phát triển dự án Như hình trên, chương trình nguồn dự án tồn nhiều lỗi (Bad Smells) mà người khơng thể tìm hết để xử lí Các công cụ Refactoring can thiệp trực tiếp vào môi trường phát triển ứng dụng (IDEs) để thực chức Refactoring Ứng với môi trường phát triển ứng dụng có cơng cụ Refactoring phát triển, giúp cho q trình Refactoring mơi trường thuận tiện hiệ Khi sử dụng công cụ Refactoring, chương trình nguồn vị trí mà nên Refactoring với kĩ thuật Refactoring theo quy chuẩn cập nhật nhất, phục vụ cho việc Refactoring trở nên nhanh hơn, xác hơn, hiệu 23 SVTH: Dương Thanh Dũng (102180060), Nguyễn Lê Anh Minh(102180083), Nguyễn Bá Vũ(102180109), Nguyễn Nhật Minh(102180029) Giảng viên hướng dẫn: Nguyễn Thanh Bình Các cơng cụ Refactoring phân thành hai nhóm chính:  Các cơng cụ Refactoring tích hợp sẵn vào IDEs nhà phát triển IDEs cung cấp  Các công cụ Refactoring bên thứ phát triển (Plug-in) 5.2 Giới thiệu cơng cụ Refactoring tích hợp sẵn vào IDEs Hiện nay, có nhiều IDEs sử dụng cho nhiều dự án với ngôn ngữ khác Trong báo cáo giới thiệu số cơng cụ Refactoring tích hợp sẵn IDEs phổ biến như: Inteliji IDEA, Visual Studio Code, Visual Studio 5.2.1 Đối với IDEs Inteliji IDEA 5.2.1.a Gọi chức Refactoring Chọn phần code cần refactoring (có thể chọn files, thư mục dự án đoạn lệnh, dòng lệnh IDE) Nhấn phím tắt Ctrl + Alt + T để mở danh sách chức Refactoring nhà cung cấp viết sẵn Hình ảnh sau gọi chức Refactoring IDE Inteliji IDEA 24 SVTH: Dương Thanh Dũng (102180060), Nguyễn Lê Anh Minh(102180083), Nguyễn Bá Vũ(102180109), Nguyễn Nhật Minh(102180029) Giảng viên hướng dẫn: Nguyễn Thanh Bình 5.2.1.b Xem trước thay đổi sau Refactoring Để xem thay đổi, bấm vào nút Preview cửa sổ Refactoring Cửa sổ Refactoring Trong xem trước thay đổi sau Refactoring, bạn xố (sử dụng phím Delete) di chuyển (sử dụng tổ hợp phím Ctrl + X) thành phần có vấn đề Xem trước thay đổi code sau Refactoring 25 SVTH: Dương Thanh Dũng (102180060), Nguyễn Lê Anh Minh(102180083), Nguyễn Bá Vũ(102180109), Nguyễn Nhật Minh(102180029) Giảng viên hướng dẫn: Nguyễn Thanh Bình Sau xem xong thay đổi, bạn kích vào Do Refactor để thực Refactoring với thay đổi xem trước 5.2.1.c Xử lí xung đột code Refactoring Khi thực Refactoring, có lúc xuất vài xung đột code Inteliji hỗ trợ phần xử lí xung đột Refactoring Cửa sổ xử lí xung đột Refactoring Lựa chọn Continue để bỏ qua xung đột Code Refactoring ghi đè code cũ có vấn đề Lựa chọn Show Conflics in View để xem nơi code bị xung đột cơng cụ Find Sau bạn sửa lại vùng cho phù hợp Cửa sổ xem nới bị xung đột code công cụ Find 26 SVTH: Dương Thanh Dũng (102180060), Nguyễn Lê Anh Minh(102180083), Nguyễn Bá Vũ(102180109), Nguyễn Nhật Minh(102180029) Giảng viên hướng dẫn: Nguyễn Thanh Bình Lựa chọn Cancel để huỷ bỏ Refactoring Code bạn giữ ngun khơng có Refactoring xảy 5.2.1.d Thiết lập cài đặt Refactoring Bạn sửa lại cách mà công cụ Refactoring IDE Inteliji cung cấp hoạt động 5.2.2 Đối với IDE Visual Studio Code Trong Visual Studio Code, có chức tương tự Refactoring Inteliji, gọi Code Actions Nó hỗ trợ Refactoring Quickfix (dùng để sửa nhanh vấn đề đơn giản) 5.2.2.a Gọi chức Refactoring Cách 1: Bạn gọi chức Code Actions (Code Actions bao gồm chức Refactoring) tổ hợp phím Ctrl + nhấn vào biểu tượng bóng đèn gần nơi muốn Refactoring Code Actions VS Code Cách 2: Bạn dùng chức Refactoring nhấn tổ hợp phím Ctrl + Shift + R 27 SVTH: Dương Thanh Dũng (102180060), Nguyễn Lê Anh Minh(102180083), Nguyễn Bá Vũ(102180109), Nguyễn Nhật Minh(102180029) Giảng viên hướng dẫn: Nguyễn Thanh Bình 5.2.2.b Thực Refactoring Tách hàm, tách biến Chọn đoạn code mà bạn muốn refactoring Sau gọi chức Refactoring, bạn nhìn thấy tuỳ chọn Refactoring có sẵn có chức tách hàm (Extract to function), tách biến (Extract variable) 5.2.2.c Đổi tên biến Chọn biến cần đổi tên, sau nhấn phím F2 Nhập tên biến vào nhần Enter IDE tự lựa chọn tất biến có tên liên quan để đổi sang tên Chức đổi tên biến file có liên quan với 5.2.3 Đối với IDE Visual Studio 5.2.3.a Đổi tên biến, tên hàm Chọn tên biến cần đổi Chọn chức Quick Actions and Refactorings chọn mục Change Signature Sau đổi tên nhấn OK Đổi tên biến 5.2.3.b Tách hàm Chọn đoạn code cần tách hàm 28 SVTH: Dương Thanh Dũng (102180060), Nguyễn Lê Anh Minh(102180083), Nguyễn Bá Vũ(102180109), Nguyễn Nhật Minh(102180029) Giảng viên hướng dẫn: Nguyễn Thanh Bình Chọn chức Quick Actions and Refactorings chọn mục Extract Method Sau đổi tên nhấn OK 5.3 Các Plug-in hay sử dụng cac IDE Hiện nay, nhiều nhà phát triển tạo Plug-in phục vụ cho q trình Refactoring chạy mơi trường IDE để lập trình viên dễ dàng sử dụng 29 SVTH: Dương Thanh Dũng (102180060), Nguyễn Lê Anh Minh(102180083), Nguyễn Bá Vũ(102180109), Nguyễn Nhật Minh(102180029) Giảng viên hướng dẫn: Nguyễn Thanh Bình 5.3.1 Một số Plug-in cho IDE Visual Studio Code 30 SVTH: Dương Thanh Dũng (102180060), Nguyễn Lê Anh Minh(102180083), Nguyễn Bá Vũ(102180109), Nguyễn Nhật Minh(102180029) Giảng viên hướng dẫn: Nguyễn Thanh Bình 5.3.2 5.4 Một số Plug-in cho IDE Visual Studio Nhược điểm công cụ Refactoring  Đôi khi, công cụ Refactoring thay đổi ngữ nghĩa code không mong muốn  Đôi khi, công cụ Refactoring thay đổi ngữ nghĩa code không mong muốn  Cần phải bỏ thời gian để học cách sử dụng công cụ  Một số cơng cụ hướng tới Refactoring theo cách không phù hợp với  Nhiều công cụ phải trả phí để dùng  Trong dự án, muốn dùng cơng cụ Refactoring đó, cần phải có thống người nhóm 31 SVTH: Dương Thanh Dũng (102180060), Nguyễn Lê Anh Minh(102180083), Nguyễn Bá Vũ(102180109), Nguyễn Nhật Minh(102180029) Giảng viên hướng dẫn: Nguyễn Thanh Bình Tài Liệu Tham Khảo [1] https://www.jetbrains.com/help/idea/refactoring-source-code.html [2] https://code.visualstudio.com/docs/editor/refactoring [3] https://docs.microsoft.com/en-us/visualstudio/ide/refactoring-in-visual-studio?view=vs-2019 [4] https://marketplace.visualstudio.com/ [5] https://marketplace.visualstudio.com/ 32 SVTH: Dương Thanh Dũng (102180060), Nguyễn Lê Anh Minh(102180083), Nguyễn Bá Vũ(102180109), Nguyễn Nhật Minh(102180029) Giảng viên hướng dẫn: Nguyễn Thanh Bình 33 SVTH: Dương Thanh Dũng (102180060), Nguyễn Lê Anh Minh(102180083), Nguyễn Bá Vũ(102180109), Nguyễn Nhật Minh(102180029)