An Phan

AHA Programming

An Phan
An Phan
Feb 23, 2023
category
tech
locale
vi
date
Feb 23, 2023
isGuest
isGuest
audio
slug
aha-programming
status
Published
tags
Tech
summary
Nguy hiểm của DRY, mạng lưới của WET, sự tuyệt vời của AHA.
type
Post
source
glink
Đây là bản dịch của bài viết gốc AHA Programming của Kent C. Dodds.

DRY

DRY (viết tắt của "Don't Repeat Yourself"), là một nguyên tắc phần mềm cũ mà Wikipedia tóm tắt như sau:
Mỗi mảnh kiến thức phải có một biểu diễn duy nhất, rõ ràng, có uy quyền trong một hệ thống
Đây là một thực hành tốt nói chung mà tôi thường đăng ký (tuy không nghiêm ngặt như định nghĩa đó dường như khuyến khích). Vấn đề lớn nhất mà tôi đã gặp với sao chép mã (còn gọi là copy/paste, đó là ngược lại của DRY) là phát hiện ra một lỗi ở một nơi, sửa chữa nó, sau đó nhận ra rằng cùng một lỗi đó còn tồn tại ở một nơi khác và phải sửa chữa nó ở đó.
Một lần, tôi thừa kế một cơ sở mã mà sử dụng rất nhiều mã sao chép và một lần tôi phải sửa một lỗi ở tám nơi khác nhau! 😱 Nói về mức độ khó chịu! Việc trừu tượng hóa mã đó thành một hàm có thể được gọi bất cứ nơi nào nó được yêu cầu sẽ giúp ích rất nhiều.

WET

Có một khái niệm khác mà mọi người thường đề cập đến là lập trình WET, viết tắt của "Write Everything Twice." Đó cũng tương tự như DRY, quá nghiêm ngặt và quá định kiến. Conlin Durbin đã định nghĩa như sau:
Bạn có thể tự hỏi "Tôi đã viết phần này trước đó chưa?" hai lần, nhưng không bao giờ là ba lần.
Trong cùng cơ sở mã trên, có một số trừu tượng hóa quá mức gây hại hơn cả sự sao chép. Đó là mã AngularJS và đối với một số bộ điều khiển AngularJS, mã đã truyền "this" vào một hàm sẽ "monkey-patch" các phương thức và thuộc tính vào "this" một cách tăng cường cho trường hợp bộ điều khiển. Một loại giả thừa kế gì đó. Nó cực kỳ khó hiểu, khó theo dõi và tôi sợ khi phải thay đổi bất cứ thứ gì ở khu vực mã đó.
được sử dụng nhiều hơn ba lần, nhưng trừu tượng hóa quá mức là tệ và tôi muốn mã đó đã bị sao chép thay vì trừu tượng hóa.

AHA 💡

AHA (phát âm là "Aha!" như bạn vừa tìm ra một khám phá) là một từ viết tắt tôi được từ Cher Scarlett có nghĩa là
Tránh Trừu Tượng Hóa Vội Vàng
Cách tôi nghĩ về nguyên tắc này được mô tả đẹp bởi Sandi Metz mà đã viết:
ưu tiên sao chép mã hơn là trừu tượng hóa sai
Đây là một viên ngọc vàng của khôn ngoan mà tôi muốn bạn đọc lại, sau đó đọc bài đăng trên blog của Sandi về chủ đề này: The Wrong Abstraction. Nó tuyệt vời.
Đây là một nguyên tắc liên quan quan trọng khác mà tôi muốn thêm vào:
Tối ưu cho sự thay đổi trước
Tôi nghĩ điều quan trọng là chúng ta không biết tương lai của mã sẽ như thế nào. Chúng ta có thể dành nhiều tuần để tối ưu mã cho hiệu suất hoặc tạo ra API tốt nhất cho trừu tượng hóa mới của chúng ta, chỉ để phát hiện ra ngày mai rằng chúng ta đã đưa ra giả định sai và API cần được hoàn toàn thay đổi hoặc tính năng mã được viết cho không còn cần thiết nữa. Chúng ta không chắc chắn. Tất cả những gì chúng ta có thể thực sự chắc chắn là rằng các thứ có thể thay đổi, và nếu chúng không bao giờ thay đổi thì chúng ta sẽ không chạm vào mã nó nhìn như thế nào?
Bây giờ, đừng hiểu lầm, tôi không đề xuất vô trị. Tôi chỉ đề xuất rằng chúng ta nên suy nghĩ về việc chúng ta không thực sự biết yêu cầu sẽ được đặt trên mã của chúng ta trong tương lai.
Vì vậy, tôi ủng hộ sao chép mã cho đến khi bạn cảm thấy khá tự tin về các trường hợp sử dụng cho mã sao chép đó. Phần nào của mã khác nhau sẽ tạo ra các đối số tốt cho chức năng của bạn? Sau khi bạn có một vài nơi mà mã đó đang chạy, những điểm chung sẽ được cải thiện để trừu tượng hóa và bạn sẽ có tâm lý đúng để cung cấp trừu tượng hóa đó.
Nếu bạn trừu tượng hóa sớm, bạn sẽ nghĩ rằng hàm hoặc thành phần đó hoàn hảo cho trường hợp sử dụng của bạn và vì vậy bạn chỉ cần uốn cong mã để phù hợp với trường hợp sử dụng mới của bạn. Điều này tiếp diễn một vài lần cho đến khi trừu tượng hóa trở thành toàn bộ ứng dụng của bạn trong các câu lệnh if và vòng lặp 😂😭
Vài năm trước, tôi được thuê để xem xét cơ sở mã của một công ty và tôi đã sử dụng một công cụ được gọi là jsinspect để xác định các đoạn mã sao chép để cho thấy cơ hội trừu tượng hóa. Họ đã có một số mã sao chép và từ quan điểm của tôi nhìn vào, rõ ràng những trừu tượng hóa sẽ như thế nào.
Tôi nghĩ điều quan trọng để lấy đi về "Lập trình AHA" là bạn không nên định kiến về khi nào bắt đầu viết trừu tượng hóa mà thay vào đó viết trừu tượng hóa khi nó thấy đúng và đừng sợ sao chép mã cho đến khi bạn đến được đó.

Kết luận

Tôi cảm thấy một phương pháp đo lường và thực dụng đối với các nguyên tắc phần mềm rất quan trọng. Đó là lý do tại sao tôi ưa thích AHA hơn DRY hoặc WET. Nó được dùng để giúp bạn suy nghĩ về trừu tượng hóa một cách chủ động mà không đưa ra các quy tắc cứng nhắc về khi nào là OK hoặc không OK để trừu tượng hóa một số mã thành một hàm hoặc module.
Tôi hy vọng điều đó hữu ích cho bạn. Nếu bạn thấy mình đắm mình trong trừu tượng hóa xấu, hãy mạnh dạn! Sandi cung cấp cho bạn một số bước tốt để thoát khỏi đó! Chỉ cần đọc bài đăng của cô ấy. Chúc may mắn!

Về Tác Giả

Xin chào các bạn! Tôi là An Phan, một Indie hacker và Lập trình viên phần mềm. Chào mừng bạn đến với ngôi nhà online của tôi, nơi tôi chia sẻ về cách quản lý, đầu tư và kiếm tiền một cách khôn ngoan.


© An Phan 2020 - 2024. All rights reserved.