DRY - đừng lặp lại những việc mà nhẽ ra có thể tự động được.

Published in Web Development

January 09, 2021

14 min read

January 09, 2021

14 min read

DRY là gì?

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?

Cuộc sống vội vã và mỗi người đều có 24h nhưng chúng ta vẫn luôn phải lặp đi lặp những công việc cần thiết để sinh tồn. Và rồi chúng ta cảm thấy có ít thời gian để làm nhiều việc khác.
Chúng ta mong muốn có nhiều thời gian hơn để làm việc, để sáng tạo để vui chơi. Rồi con người phát minh ra nhiều thứ để tự động hóa những công việc hằng ngày đó như: máy giặt, máy rửa bát, máy hút bụi tự động. Hay nếu ai không có thời gian để đun nấu thì luôn có nhà hàng để bạn có thể đến thưởng thức, hay nhờ shipper giao hàng tận nhà cho bạn. Thậm chí nếu bạn là người có thu nhập ổn định hoặc cao thì bạn hoàn toàn có thể thuê người giúp việc, thư ký lo giúp cho bạn những công việc thường ngày đó. (Tất nhiên ăn, ngủ hay sinh hoạt vui chơi thì bạn phải tự túc rù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.

Công nhân trong nhà máy: tôi nghĩ đây là những công việc mang tính chân tay và thủ công nhất. Cũng như mang lại thu nhập thấp nhất. Bạn có thể nghĩ là vì công việc của họ lặp đi lặp lại hằng ngày và không đòi hỏi nhiều chát xám, họ được yêu cầu làm 1 công việc đã được lên quy trình sẵn và nhiệm vụ của những người này là thao tác tay chân để hoàn thành công việc theo như yêu cầu ban đầu đưa ra. Tôi cũng đồng ý rằng bản thân công việc đó có tính chất lặp lại rất cao và giá trị bạn mang lại chính xác bằng thời gian bạn bỏ ra theo giờ, ngày qua ngày. Không hơn không kém.
Những người làm văn phòng, hay những người có kiến thức thì đảm nhận những công việc đòi hỏi vận động trí óc nhiều hơn. Công việc của những người này đôi khi cũng lặp đi lặp lại như những người quản lý hàng hóa, nhập liệu. Hay những công việc đòi hỏi sự sáng tạo như ca sĩ, nhạc sĩ, thiết kế và lập trình viên.

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.

DRY trong lập trình

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.

Vậy anh em đã DRY ra sao khi phát triển phần mềm?

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:

Nếu quay trở lại 10 năm trước vào 2005 thì việc xây dựng tựa game, hay 1 website có thể rất vất vả khi sử dụng javascript thuần, thao tác dom. Rồi jquery ra đời giúp cho lập trình viên bớt khổ hơn, code nhanh hơn 2,3 lần để giải quyết cùng một bài toán nếu trước đó không có jquery. Chưa dừng lại ở đó Wordpress là một công cụ giúp người ko biết code có thể tạo được website chỉ bằng việc cài đặt và đọc hướng dẫn sử dụng. Wordpress đã gián tiếp cưới đi một lượng lớn công việc của anh em devs nhưng bằng cách nào đó lại tạo ra 1 thị trường mới nơi mọi người, nhà nhà đều tham gia vào cuộc đua tạo website để quảng bá sản phẩm, tin tức…
Framwork, nền tảng mới mang lại cho cộng đồng devs rất nhiều giá trị. Giúp cho việc phát triển phần mềm tiết kiệm thời gian hơn, và tận dụng được những giá trị đã được những người đi trước sáng tạo ra. Thật là khó tưởng tượng nếu như không có open source thì thế giới công nghệ giờ sẽ ra sao. Rất nhiều những dự án những nghiên cứu nhiều triệu đô la được các ông lớn như microsoft, google, facebook cung cấp miễn phí cho cộng đồng devs để họ tham gia trực tiếp vào việc phát triển sản phẩm dựa trên các nền tảng framework đó. Tôi nghĩ đây chính là một bước tiến lớn của nghành công nghiệp phần mềm. Khi mà một sinh viên thậm chí có thể áp dụng các mô hình máy học phức tạp nhất, những kết quả nghiên cứu mới nhất của những bộ óc thiên tài vào đồ án tốt nghiệp của mình về AI như nhận diện hình ảnh, hay lái xe tự động. Điều mà nhẽ ra chỉ có thể những tổ chức lớn với tập hợp hàng trăm con người giày công nghiên cứu nhiều năm mới có được.

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.

Lessons learned

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.

DRY như vậy đã đủ chưa?

Đâ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.