Tạm biệt, Clean Code

Tram Ho

Đó là vào buổi tối muộn và đồng nghiệp của tôi vừa viết xong mã trong tuần. Chúng tôi đang làm việc trên canvas của trình chỉnh sửa đồ họa và họ đã triển khai khả năng thay đổi kích thước các hình dạng như hình chữ nhật và hình bầu dục bằng cách kéo các chốt nhỏ ở các cạnh của chúng.

Mã đã hoạt động, nhưng nó lặp đi lặp lại. Mỗi hình dạng có một bộ tay cầm khác nhau và việc kéo từng tay cầm theo các hướng khác nhau đã thay đổi vị trí và kích thước của hình dạng theo một cách khác. Nếu người dùng giữ phím Shift, chúng tôi phải đảm bảo giữ tỷ lệ của hình dạng trong khi thay đổi kích thước. Điều này đòi hỏi rất nhiều toán học.

Mã trông giống như thế này:

Tôi đã cảm thấy thất vọng vì tôi phải làm rất nhiều phép toán rất giống nhau. Hầu hết sự lặp lại là giữa các tác vụ tương tự, chẳng hạn như thay đổi kích thước bên trái của hình bầu dục hoặc tiêu đề. Cũng có một số trùng lặp giữa các nhiệm vụ cho các hình dạng khác nhau, như hình bầu dục và hình chữ nhật.

Tôi có ý tưởng nhóm mã lại với nhau để loại bỏ sự trùng lặp:

và sau đó soạn các hành vi của họ:

Mã tôi đã thay đổi có kích thước bằng một nửa so với trước đây và tất cả phần trùng lặp đã bị xóa. Nó sạch hơn và dễ hiểu hơn nhiều. Nếu chúng tôi muốn thay đổi hành vi cho một hướng hoặc hình dạng cụ thể, chúng tôi có thể thực hiện việc đó ở một nơi thay vì phải cập nhật các phương thức ở nhiều nơi. Tôi rất tự hào về công việc của mình và đi ngủ sau khi lưu các thay đổi của mình vào phiên bản chính.

Sáng hôm sau

… không diễn ra như mong đợi.

Sếp của tôi yêu cầu tôi hoàn tác một thay đổi mà tôi đã thực hiện trong một cuộc trò chuyện riêng. Tôi đã bị sốc vì nghĩ rằng thay đổi của mình là một cải tiến so với mã cũ. Mặc dù tôi không hài lòng về điều đó, nhưng tôi đã thay đổi lại và cuối cùng nhận ra rằng sếp của tôi đã đúng.

Đó là một giai đoạn

Nhiều người trong chúng ta đã trải qua một khoảng thời gian mà chúng ta tập trung rất nhiều vào việc viết “mã sạch” và loại bỏ bất kỳ phần trùng lặp nào. Khi chúng ta không cảm thấy chắc chắn về mã của mình, chúng ta có thể muốn liên kết lòng tự trọng và niềm tự hào về công việc của mình với một thứ gì đó có thể đo lường được, chẳng hạn như một bộ quy tắc nghiêm ngặt để định dạng, một cách cụ thể để đặt tên cho mọi thứ, một cách tổ chức tệp nhất định và không trùng lặp.

Không thể sử dụng máy tính để tự động loại bỏ mã trùng lặp, nhưng việc này sẽ trở nên dễ dàng hơn khi thực hành. Bạn thường có thể biết liệu có ít hay nhiều trùng lặp sau khi thực hiện các thay đổi. Điều này tạo cảm giác như bạn đang cải thiện mã theo một cách nào đó. Thật không may, nó cũng có thể khiến mọi người cảm thấy họ không giỏi viết mã sạch, điều này có thể mạnh mẽ như bất kỳ hình thức tự lừa dối nào.

Một khi chúng ta hiểu cách làm cho mọi thứ trở nên đơn giản hơn bằng cách chia nhỏ chúng thành các phần nhỏ hơn, chúng ta sẽ dễ dàng bị cuốn theo và tạo ra các bản tóm tắt cho bất kỳ mã nào trông giống nhau. Sau một thời gian, chúng ta bắt đầu thấy các khuôn mẫu ở khắp mọi nơi và có cảm giác như mình có một khả năng đặc biệt. Nếu ai đó nói với chúng ta rằng sự trừu tượng là một điều tốt, chúng ta sẽ tin họ và bắt đầu chỉ trích người khác vì đã không viết mã một cách gọn gàng và có tổ chức.

Bây giờ tôi thấy rằng việc “tái cấu trúc” của tôi là một thảm họa theo hai cách:

  • Tôi đã không nói chuyện với người đã viết mã trước khi tôi thay đổi và gửi nó. Ngay cả khi tôi nghĩ rằng đó là một cải tiến, đây là một cách tồi để làm điều đó. Một nhóm kỹ sư tốt cần phải tin tưởng lẫn nhau. Thay đổi mã của ai đó mà không nói chuyện với họ trước tiên sẽ làm hỏng khả năng làm việc cùng nhau của nhóm trên cùng một mã.
  • Không có gì đến mà không phải trả giá. Tôi đã từ bỏ khả năng thay đổi các yêu cầu để đổi lấy ít trùng lặp hơn trong mã của mình, nhưng đó không phải là một quyết định đúng đắn. Ví dụ: chúng tôi cần các hành vi khác nhau cho các hình dạng và cách xử lý khác nhau, điều này sẽ khiến mã của tôi phức tạp hơn nhiều. Tuy nhiên, với phiên bản “lộn xộn” ban đầu, việc thực hiện những thay đổi này là rất dễ dàng.

Bạn đang gợi ý rằng tôi không nên viết mã “bẩn”? Không. Tôi khuyên bạn nên suy nghĩ cẩn thận về ý nghĩa của bạn khi bạn nói “sạch” hay “bẩn”. Bạn có cảm thấy tức giận, chính đáng, xinh đẹp hay thanh lịch? Bạn có chắc chắn rằng bạn có thể đặt tên cho các kết quả kỹ thuật cụ thể đến từ những phẩm chất này không? Làm thế nào để những phẩm chất này ảnh hưởng đến cách mã được viết và thay đổi?

Tôi đã không suy nghĩ cẩn thận về bất kỳ điều gì trong số đó. Tôi tập trung hơn vào việc mã trông như thế nào hơn là cách nó hoạt động với một nhóm người.

Viết mã là một quá trình học hỏi và phát triển. Hãy nghĩ xem bạn đã cải thiện được bao nhiêu kể từ khi viết dòng mã đầu tiên. Có lẽ rất thú vị khi thấy cách chia vấn đề thành các phần nhỏ hơn hoặc tổ chức lại một nhóm hướng dẫn có thể làm cho mã phức tạp trở nên dễ hiểu hơn. Nếu bạn tự hào về công việc của mình, bạn có thể muốn giữ mã của mình gọn gàng và ngăn nắp. Hãy thử một lúc và xem nó diễn ra như thế nào.

Đừng chỉ tập trung vào việc viết mã sạch. Mã sạch không phải là mục tiêu cuối cùng. Đó là một cách để hiểu các hệ thống phức tạp mà chúng ta làm việc cùng. Đó là một cách để bảo vệ chính chúng ta khi chúng ta không chắc một sự thay đổi sẽ ảnh hưởng đến mã như thế nào và chúng ta cần trợ giúp trong một tình huống không quen thuộc.

Viết mã của bạn một cách rõ ràng và có tổ chức, nhưng đừng quá gắn bó với nó. Hãy để mã sạch hướng dẫn bạn. Sau đó để nó đi.

Nguồn

Chia sẻ bài viết ngay

Nguồn bài viết : Viblo