Hiểu về nguyên tắc DRY - Don't Repeat Yourself

Nguyên tắc cơ bản trong phát triển phần mềm, tránh lặp lại code bằng cách trừu tượng hóa các mẫu chung để tái sử dụng.
Please wait 0 seconds...
Scroll Down and click on Go to Link for destination
Congrats! Link is Generated

Một cảm giác rất phổ biến trong khi viết code là déjà vu. Nó là cảm giác lạ lùng (uncanny - kỳ lạ, sensation - cảm giác, sự khích động) rằng bạn đã gặp phải (come across - băng qua) đoạn code này trước đó. Đến một lúc nào đó (at some point), khi viết một ứng dụng, bạn sẽ cần phải triển khai một vài logic kinh doanh mà bạn đã từng sử dụng trước đó. Điều này là không thể tránh khỏi (inevitable) khi một dự án mở rộng, và nó là một vấn đề thường xuyên xuất hiện (crops up - mọc lên) trong các mã nguồn lớn. Phương thuốc (remedy) cho nỗi lo lắng (dilemma - lưỡng lự, tình trạng khó xử) phổ biến này là nguyên tắc DRY - Đừng lặp lại chính mình.

Trong bài viết này, chúng ta sẽ khám phá quy tắc này bằng cách xem xét các tình huống (scenarios - kịch bản) phổ biến của sự lặp lại. Bạn sẽ tìm hiểu các vẫn đề liên quan đến sự lặp lại và xem xét các phương pháp kiểm tra để giải quyết những vấn đề này. Ở cuối bài viết, chúng ta sẽ xem xét những lời chỉ trích phổ biến của DRY và thảo luận về các nguyên tắc tương tự để lưu ý (keep in mind - ghi nhớ) khi giải quyết (tackling) các vấn đề như vậy.

Hãy bắt đầu từ những điều cơ bản trước.

DRY Là Gì?

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

Mỗi mảnh kiến thức phải có một biểu diễn duy nhất, rõ ràng và có uy tín (authoritative - có thẩm quyền) trong một hệ thống.

Andy HuntDave Thomas đã định nghĩa nguyên tắc này một cách chính thức vào năm 1999 trong cuốn sách của họ The Pragmatic Programmer. Đây là một trong số ít các ý tưởng áp dụng qua tất cả các giai đoạn và cấp độ của quá trình phát triển phần mềm và thậm chí còn trong các lĩnh vực kiến thức khác. Vấn đề cốt lõi mà nó hướng tới giải quyết là vấn đề sao chép kiến thức.

Các tình huống phổ biến cần DRY?

Một số lượng lớn sự lặp lại xảy ra trong quá trình thiết kế các class. Chúng ta kết thúc việc triển khai cùng một logic kinh doanh trong nhiều phần (portions - phần ăn, sự phân chia) khác nhau của mã. Một giải pháp đơn giải là trừu tượng hóa chức năng chung và chỉ triển khai các phần khác biệt.

Một ví dụ phổ biến khác là sự giải thích logic của code trong các chú thích. Việc viết mã đọc được hơn thường loại bỏ (eliminates) việc cần phải viết chú thích.

Hay về sự trùng lặp xảy ra khi lưu dữ liệu. Chúng ta kết thúc việc tạo ra các thuộc tính không cần thiết trong bảng của mình. Thường chúng ta có thể suy ra (derive - lấy được, do ở đâu) được các thuộc tính này từ các thuộc tính khác bởi vì chúng phụ thuộc lẫn nhau (mutually - hỗ trợ, giúp lẫn nhau). 

Những vấn đề của Sự trùng lặp

Nguyên nhân gốc rễ của tất cả những vấn đề này là việc tạo ra các biễn diễn trùng lặp của kiến thức (duplicate representations of knowledge). Những kiến thức này có thể thay đổi - nói cách khác (in other words), có thể thay đổi. Và ngay khi nó thay đổi, chúng ta cần thay đổi tất cả các biểu diễn của nó.

Việc thực hiện thay đổi đòi hỏi sự thận trọng (diligence - siêng năng, chuyên cần). Ngược lại (in contrast), việc không thực hiện các thay đổi một các đúng đắn (properly - đúng đắn) sẽ dẫn đến sự trái ngược (contradictory - mâu thuẫn) trong việc biểu diễn của cùng một kiến thức.

Có những lý do phổ biến cho những loại trùng lặp này không?

  • Một ai đó đã mắc sai lầm trong quá trình thiết kế, và sai lầm đó lan rộng (progagate - tuyên truyền) đến các giai đoạn sau của quá trình phát triển.  Nếu bạn phát hiện kịp thời, nó có thể được cứu vãn (salvage - cứu hộ) mà không quá tốn kém (significant cost - chi phí đáng kể).
  • Đôi khi các dự án có thời hạn nghiêm ngặt (strict - chính xác, nghiêm ngặt) khiến các nhà phát triển bị áp lực (pressure - áp lực, sự áp chế). Sớm muộn gì, việc sử dụng các phím tắt sẽ trở nên hấp dẫn hơn (tempting - hấp dẫn) so với việc viết code sạch.
  • Có thể có các sự trùng lặp không mong muốn ở nơi mà các nhà phát triển thậm chí không nhận ra rằng họ đang lặp lại thông tin. Điều này phổ biến hơn trong các tổ chức lớn, nơi toàn bộ các chức năng có thể bị trùng lặp. Lý do phố biến lớn nhất cho điều này là sự thiếu hợp tác giữa các nhóm.
  • Đôi khi môi trường đòi hỏi sự trùng lặp mã, và nhà phát triển cần phải khéo léo (ingenuity - khéo léo, ngây thờ, thật thà) để tránh sự trùng lặp đó.
Bây giờ bạn đã biết tại sao lại có sự trùng lặp xảy ra, vậy bạn có thể làm gì với nó?

Các phương pháp giải quyết Sự trùng lặp bằng DRY

DRY chỉ là một quy tắc. Các nhà phát triển hoặc các quản lý dự án có quyền lựa chọn cách họ triển khai quy tắc này. Các triển khai có thể đa dạng (diverse - phong phú) tùy thuộc vào các trường hợp sử dụng của họ. Hãy thảo luận ngắn gọn về ba phương pháp phổ biến nhất.

Abstractions

Đây là phương phát thường được sử dụng khi thiết kế các lớp. Khi nhiều lớp chia sẻ một vài logic kinh doanh chung, chúng ta đơn giản là trừu tượng hóa logic vào trong một lớp cơ sở, mà mỗi lớp sau đó kế thừa. Lập trình hướng đối tượng tiêu chuẩn có rất nhiều thực tiễn khuyến khích (encourage) sử dụng nguyên tắc DRY để viết mã đọc được, có thể tái sử dụng, và có thể bảo trì. Hơn nữa, có các phương pháp thay thế như sự hợp thành (composition - thành phần, chất kết hợp) giải quyết các hạn chế của việc sử dụng tính kế thừa và cho các lập trình viên nhiều sự linh hoạt hơn.

Automation

Đây là trường hợp của sự nhận thức dự án (awareness - nhận thức, sự đoán trước, phòng bị) từ các nhà phát triển. Các nhóm nên có tính chất chuyên ngày chéo () để đảm bảo sự giao tiếp giữa các nhà phát triển. Quản lý nên khuyến khích sự giao tiếp này để các nhà phát triển không bao giờ lặp lại công việc đã hoàn thành và có thể thảo luận về các vấn đề chung của họ (mutual - qua lại, cộng đồng, lẫn nhau).

Loại bỏ sự trùng lặp khi nó xuất hiện là không đủ. Thay vào đó, nó phải là một quá trình hoạt động. Nếu thiếu hệ thống và giám sát phù hợp (oversight - giám sát), vấn đề này sẽ tiếp tục tồn tại và tiếp tục làm hại cho tổ chức (plague - tai họa, thiên tai, làm phiền).

Normalization

Trường hợp đối với việc thiết kế cơ sở dữ liệu. Sự trùng lặp thường xuyên xuất hiện trong nhiều biểu diễn dữ liệu. Tuy nhiên, điều này tạo ra dữ liệu dư thừa (redundant), khó khăn trong việc bảo trì.

Thay vào đó, hãy trích xuất các bản sao ra khỏi một thực thể riêng biệt. Nguồn sau đó tham chiếu đến thực thể này.

Mục tiêu của sự chuẩn hóa là đảm bảo dữ liệu nhất quán và sự phân phối đúng cách (properly - đúng cách, riêng biệt). Nó cũng giúp duy trì tính toàn vẹn dữ liệu và tạo một nguồn sự thật duy nhất. Hơn nữa, chuẩn hóa dữ liệu loại bỏ những sự dư thừa (redundancies) trong dữ liệu, điều đó giúp cơ sở dữ liệu linh hoạt hơn và có khả năng mở rộng hơn.

Điều cần ghi nhớ

Đây không phải là những phương pháp nghiêm ngặt. Thay vào đó, chúng là những điểm hữu ích cần ghi nhớ để vượt qua những cạm bẫy quen thuộc (pitfall - cạm bẫy) mà các nhà phát triển thường rơi vào. 

Tip 1: Làm cho việc tái sử dụng trở nên dễ dàng

Sự trừu tượng phải được khuyến khích sử dụng. Các nhà phát triển sẽ gần như bỏ qua sự trừu tượng nếu họ thấy chúng khó hiểu và có hại cho năng suất của họ (obscure - mơ hồ; harmful - có hại). Chúng ta cần làm cho những sự trừu tượng trở nên dễ sử dụng hơn và được tài liệu đầy đủ để cho phép các nhà phát triển khác hưởng lợi từ chúng thay vì coi chúng như một chướng ngại (perceiving - cảm nhận, nhận thức; roadblock - rào cản).

Tip 2: Các phím tắt tạo ra sự chẫm chễ lâu dài

Hầu hết các trường hợp lặp lại trong quá trình phát triển là kết quả của sự lười biếng của một bộ phận nhà phát triển. Đối với những dự án có thời hạn, nó gần như dễ dàng hơn để đẩy một cái gì đó "chỉ cần hoạt động là được". Trong hầu hết các tình huống khi một nhà phát triển sử dụng một lối tắt (resort to - dùng đến, thường đi đến nơi nào), nó cuối cùng sẽ giới thiệu nợ kỹ thuật (technical dept) sau này. Nếu nợ kỹ thuật bị phát hiện sau trong quá trình, chi phí để giải quyết vấn đề có thể bị gấp mười lần hoặc trăm lần số giờ công so với nếu như nhóm đã giải quyết nó khi nó xuất hiện lần đầu tiên.

Tip 3: Tập trung vào giao tiếp tích cự và nhận thức dự án

Trong một tổ chức lớn với nhiều nhóm làm việc với các dự án khác nhau song song (parallel), nó rất khó để duy trì nhận thức về tất cả mọi thứ đang diễn ra. Để giải quyết vấn đề đó, các nhà phát triển nên nhận thức được các dự án khác trong công ty, được biệt là các dự án liên quan đến họ. Điều này cho phép các nhà phát triển tái sử dụng công việc mà các nhà phát triển khác đã đẩy. Ngoài ra, nó cho họ cơ hội đóng góp của riêng mình cho người khác.

Sử dụng DRY quá nhiều?

(Overuse - lạm dụng)

Mỗi dòng code được viết không cần phải là duy nhất. Các nhà phát triển đôi khi có một nỗi sợ về việc làm lại và lãng phí và coi (perceive - nhận thức) chúng như điển hình (epitome - hình ảnh thu nhỏ) của hành vi không hiệu quả. Nhưng việc sử dụng DRY quá mức thật sự ngăn chúng ta viết mã sạch.

Mỗi quy tắc cần phải được áp dụng tùy thuộc vào ngữ cảnh. Đôi khi sự lặp lại code phù hợp với môi trường. Việc loại bỏ nó có thể giới thiệu sự liên kết hoặc phức tạp không cần thiết vào hệ thống từ đầu. Trong những tình huống như vậy, sống chung với một ít sự lặp lại có thể không phải là điều tồi tệ nhất.

Tối ưu hóa sớm (premature - sinh non) cũng là một vấn đề phổ biến đối với những nhà phát triển mới. Như một quy luật chung, các nhà phát triển nên tránh áp dụng các tổng quát (generalization - khái quát hóa) cho chức năng trước khi nó được lặp lại. Những vấn đề thực tế và cấp bách hơn được ưu tiên (precedence - quyền ưu tiên, tính ở trên), và việc giải quyết những vấn đề đó trước tiên là hết sức quan trọng (paramount - tối quan trọng, tối thượng).

Tóm lại

Việc sao chép code dễ dàng, nhưng nỗi đau đến khi phải bảo trì. Tránh việc lặp lại sớm ở giai đoạn phát triển thường cứu chúng ta khỏi nợ kỹ thuật trong tương lai. Tuy nhiên, lạm dụng quy tắc giống như DRY thường dẫn điễn nhiều chi phí trước mắt (upfront - trả trước) không cần thiết trong một vài tình huống. Cần có một sự cân bằng giữa hai điều này.

DRY không chỉ là một quy tắc cho việc lưu trữ dữ liệu và viết code. Nó đôi khi chúng ta có thể áp dụng trong mỗi giai đoạn của dự án. DRY là một công cụ giúp chúng ta tối ưu hóa quy trình, sự hợp tác, và sản phẩm của chúng ta. Nó là một công cụ mà chúng ta cần phải điều chỉnh để phù hợp với nhu cầu của mình, áp dụng khi phù hợp, và từ bỏ khi không cần thiết.

Đăng nhận xét

Tham gia cuộc trò chuyện