DRY viết tắt của từ Don’t Repeat Yourself - hiểu nôm na là đừng lặp lại chính mình.
Theo wiki thuật ngữ này suất phát từ nguyên lý trong việc phát triển phần mềm với mục tiêu giảm tối đa việc lặp đi lặp lại trong quá trình xây dựng phần mềm.
Nguyên lý này cũng có thể áp dụng trong đời sống
Có bao giờ bạn tự hỏi mình vẫn phải luôn lặp đi lại những công việc hằng ngày như: tắm rửa, giặt giũ, ăn ba bữa (sáng, trưa, tối), đi làm, tập thể dục, và lên giường đi ngủ mõi tối?
Trong công việc cũng vậy có rất nhiều công việc ngày qua ngày lặp đi lặp lại hằng ngày mà mỗi người chúng ta đều đang đảm nhận. Từ công nhân trong nhà máy, xí nghiệp đến những nhân viên văn phòng, nhà báo, vận động viên thể thao.
Bạn có thể thấy rằng càng những công việc đòi hỏi sự sáng tạo hay cần nhiều nỗ lực thì thường cần linh hoạt, ít lặp đi lặp lại và thường là những công việc mang lại nhiều giá trị nhất.
Trong nghành phát triển phần mềm thì DRY lại càng quan trọng, vậy cụ thể nó quan trọng ra sao? Hay nó chỉ là thuật ngữ đao to búa lớn với mà mấy ông senior dev đem ra nói với mấy ông junior.
Hiểu một cách đơn giản thì mục tiêu phát triển phần mềm là cốgắng làm sao để có thể đưa ra được sản phẩm đáp ứng được chính xác yêu cầu được đề ra trong thời gian ngắn nhất với ít nguồn lực nhất. Do đó để đạt được mục tiêu ấy thì việc tránh phải lặp đi lặp lại nhiều công việc phát triển mà nhẽ ra có thể tối ưu và tự động hóa được là một cách hiệu quả.
Ngay chính thuật ngữ “Phần mềm” cũng đã nói nên những đoạn mã, chương trình hoạt động trên máy tính và giúp giải quyết những vấn đề của đời sống con người. Nghành công nghiệp phần mềm đã phát triển không ngừng và tham gia vào mọi mặt đời sống. Thay thế con người trong rất nhiều công việc và đóng góp và quá trình phát triển vĩ đại của loại người.
Cộng đồng developers các công ty luôn đưa ra các giải pháp, frameworks, dịch vụ để giúp developers có thể sử dụng và phát triển phần mềm nhanh hơn, ít lỗi hơn, và mang lại nhiều giá trị hơn cho khách hàng:
Vậy không lí gì mà bản thân tôi và các bạn đặc biệt là những bạn làm trong nghành IT lại đứng ngoài thói quen DRY khi phát triển phần mềm.
DRY không phải là nguyên lý phức tạp hay khó áp dụng. Nhưng nó lại là câu chuyện muôn thủa của anh em devs khi làm trong 1 dự án. Cũng như việc hình thành thói quen ngăn lắp. Bạn có thể dễ dàng sắp xếp mọi thứ gọn hàng sau vài phút, nhưng rồi có thể vài tiếng sau mọi thứ lại đâu vào đấy. Tôi cá nhà nhiều bạn cũng như tôi :)
Lý do rất đơn giản là chúng ta luôn muốn bắt đầu với những thứ đơn giản, nhỏ. Do đó việc quản lý nó cũng sẽ dễ dàng. Nó chỉ phức tạp khi hệ thống có thêm nhiều tính năng - tương ứng với việc thêm code. Và nếu không sắp xếp, tổ chức code ngăn nắp hay đề ra những guide line để chỉ dẫn việc sắp xếp code ngăn nắp thì trước sau nó cũng sẽ thành một mớ hỗn độn. Đến một ngưỡng nào đấy mỡ hỗn độn đó không được giải quyết và nó dần trở thành bãi rác.
Khi việc thêm mới tính năng vào code đối với các lập trình viên mà nói họ thà viết thêm code mới để phát triển cho tính năng mới hơn là tái sử dụng code cũ với lý do họ không biết code cũ hoạt động ra sao. Và vì những tính năng cũ đang chạy ổn định, việc sửa code cũ đối với họ là điều cấm kị. Vì rất có thể họ sẽ làm hỏng những tính năng cũ. Chính những điều không chắc chắn đó đã thúc đẩy những người đến sau tiếp tục xả rác và rồi khi đống rác quá to. Việc sửa lỗi tốn quá nhiều thời gian so với việc phát triển thêm tính năng mới thì có một công việc đơn giản mà anh em rất thích đó là đập đi, xây lại. Câu chuyện nghe có vẻ bi quan nhưng tôi nghĩ nó vẫn đang diễn ra hằng ngày. Khi code của chúng ta viết ra nhưng chưa được trau chuốt, hay không có thời gian để trau chuốt thì đáng buồn thay vòng đời của nó cũng ngắn ngủi như cái cách mà bạn đến công ty và đi trong vài tháng hay 1,2 năm :(.
Okie. Vậy thì tôi sẽ cố gắng tổ chức code mạch lạc hơn, ít nhất là tái sử dụng lại các hàm có sẵn do tôi viết ra. Vậy là tôi có thể dễ dàng sửa đổi và thêm tính năng cho nó trong tương lai dễ dàng.
Câu chuyện có thể giải quyết đơn giản nếu như bạn tham gia vào nó và bạn chịu trách nhiệm hoàn toàn cho kết quả mà bạn đạt được. Bạn có thể đưa ra các nguyên tắc để khiến code của mình DRY hơn. Problem Solved.
Vấn đề sẽ phức tạp hơn khi không chỉ có riêng bạn tham gia vào phát triển phần mềm. Bạn thậm chí phải làm việc với 2,3 người hoặc thập chí 10 người hay lớn hơn đến cả 100 người cho 1 dự án. Vậy lúc này việc quản lý và vận hành code càng trở nên quan trọng hơn bao giờ.
Ví dụ đơn giản với dự án có 2,3 người tham gia cách để mọi người trong team có thể cùng làm việc theo một quy trình đòi hỏi nhiều nỗ lực, không phải developers nào cũng có phong cách lập trình hay cách tư duy giống nhau do đó luôn có một sai khác nhất định trong cách viết code hay cách tư duy giải quyết vấn đề của mỗi người. Khi code của bạn viết ra khiến cho đồng nghiệp khó để hiểu được bạn đã gián tiếp thúc đẩy việc những người khác dễ dàng tạo ra mã code của riêng họ để giải quyết cùng vấn đề mà bạn đã giải quyết. Điều này ban đầu cảm tưởng là rất nhỏ. Vì có lẽ mất vài dòng code là có thể xử lý được vấn đề và chúng ta dễ dàng áp dụng cách tiếp cận nhanh gọn này để hoàn thành công việc đúng tiến độ. ==> Tech debt xuất hiện từ đây.
Vậy làm cách nào để tránh việc viết nhiều code thừa?
Có rất nhiều cuốn sách mà tôi nghĩ ít nhất 1 trong số đó bạn cũng đã nghe tên và đọc qua: như cuốn Clean Code, Clean Coder, Code Refactoring, Design Pattern. Chính những thứ được đề cập trong cuốn sách là cách để lập trình viên có thể áp dụng vào quá trình phát triển phần mềm. Và chúng cũng tạo ra 1 cộng đồng cùng hiểu và áp dụng những kiến thức đó vào phát triển phần mềm. Từ đó tạo ra những lập trình viên chuyên nghiệp có thể làm việc cộng tác với nhau trên nhiều project.
Đây là một câu hỏi mà tôi nghĩ nhiều anh em cũng hay tự hỏi. Bản thân tôi nghĩ câu hỏi này cũng không có cậu trả lời chính xác. Giống như việc bạn đặt ra những câu hỏi như “Yêu như vậy đủ chưa?”, “ABC xyz như vậy đủ lâu chưa?”
Nói một cách đơn giản thì mục tiêu là giúp cho quá trình phát triển phần mềm diễn ra nhanh hơn và đạt kết quả tốt hơn về tổng thể. Vậy thì những yếu tố như thời gian phát triển (tuần, tháng, năm hay nhiều năm), độ phức tạp của hệ thống, số người tham gia vào hệ thống và khả năng mở rộng của hệ thống. Từ những yêu tố đó bạn có thể cân nhắc được việc áp dụng DRY vào ở một mức độ bạn nghĩ là hợp lý. Và một ngưỡng nào đó bạn vẫn có thể chấp nhận việc hệ thống tồn tại code thừa, code lặp trong quá trình phát triển.
Đến đây hi vọng bạn cũng hiểu một phần nào câu chuyện DRY dưới góc nhìn của cá nhân mình. Hi vọng bạn cũng có cùng những suy nghĩ như tôi.
Hãy để lại bình luận và chúng ta sẽ cùng thảo luận thêm vào phía dưới nhé!
Trong bài tiếp theo tôi sẽ chia sẻ những kinh nghiệm thực thế và những bài học tôi học được khi làm dự án thực tế. Keep it DRY bạn nhé!