Tuần trước, tôi đã viết về các phương pháp có giá trị trả lại nhất quán và cách chúng sẽ làm cho mã của bạn đơn giản hơn. Nhưng điều đó xảy ra như thế nào? Làm cách nào để tái cấu trúc đúng cách giúp mã của bạn làm việc dễ dàng hơn? Điều gì làm cho trừu tượng tốt trở nên tốt và trừu tượng xấu là xấu? Ý tôi là, bạn không thể chỉ sắp xếp lại mã của mình một cách mù quáng và kết thúc bằng phần mềm chất lượng.
Nếu bạn có thể tìm hiểu tại sao những kỹ thuật này hoạt động, bạn sẽ có thể hiểu rõ hơn nơi mã của bạn cần trợ giúp. Và bạn sẽ có thể sử dụng các công cụ phù hợp ở những nơi chúng quan trọng nhất.
Vấn đề khó nhất trong phát triển phần mềm là gì?
“Chỉ có hai vấn đề khó khăn trong Khoa học máy tính:vô hiệu hóa bộ nhớ cache và đặt tên cho mọi thứ.”
- Phil Karlton
Chắc chắn, câu trích dẫn đó ở mọi nơi . Nhưng thực sự có một vấn đề khó hơn trong phát triển phần mềm trong thế giới thực:quản lý độ phức tạp. Sự phức tạp trong phát triển phần mềm có một vài định nghĩa khác nhau. Tuy nhiên, về cốt lõi của nó, mức độ phức tạp của một chương trình là số lượng nội dung bạn phải lưu giữ trong đầu khi đang làm việc với nó.
Khi bạn viết nhiều phần mềm hơn, bạn sẽ có thể lưu giữ nhiều thứ hơn trong đầu mình cùng một lúc. Nhưng ngay cả những nhà phát triển giỏi nhất cũng có giới hạn. Nếu dự án của bạn quá phức tạp, bạn sẽ làm quá tải những gì mà trí óc của bạn có thể xử lý và bạn sẽ bắt đầu quên đi các lĩnh vực khác nhau trong chương trình của mình. Và những lỗi tồi tệ nhất xuất hiện khi bạn thực hiện thay đổi trong một phần của dự án mà không nhận ra sự thay đổi đó sẽ ảnh hưởng như thế nào đến phần hoàn toàn khác của cùng một dự án.
Đơn giản hóa thông qua các giả định
Nếu bạn có bộ nhớ chụp ảnh và có thể nhớ tất cả các phần khác nhau trong chương trình của bạn khớp với nhau như thế nào, bạn sẽ có ít lỗi hơn, phải không? Bộ nhớ có thể khó xây dựng. Nhưng bạn có thể nhận được nhiều lợi ích tương tự khi có thể tập trung vào một việc tại một thời điểm.
Nhiều phương pháp hay nhất trong phát triển phần mềm là giảm số lượng những thứ bạn phải ghi nhớ cùng một lúc. Một vài ví dụ:
-
Tính nhất quán trong các giá trị trả lại của bạn có nghĩa là bạn chỉ phải suy nghĩ về cách xử lý một loại dữ liệu, thay vì các loại dữ liệu khác nhau trong các tình huống khác nhau.
-
Tóm tắt là một cách để ẩn mã đằng sau một giao diện đơn giản hơn. Với những nội dung trừu tượng tốt, bạn chỉ có thể nghĩ về cách nên trừu tượng hành động và bạn không phải lo lắng về cách nó hoạt động bên trong.
-
Thử nghiệm có thể giúp bạn không vô tình phá mã ở một khu vực trong khi bạn đang làm việc ở một khu vực khác. Bạn có thể cho rằng bất cứ thứ gì bạn vô tình làm vỡ sẽ bị mắc lại. Điều này có nghĩa là bạn có thể chỉ tập trung vào mã bạn đang làm việc và sửa mọi thứ bạn bị hỏng sau đó.
-
Phát triển theo hướng thử nghiệm sẽ giúp bạn viết mã hoạt động theo cách bạn mong đợi. Bạn có thể tập trung vào việc viết ra cách triển khai đơn giản nhất có thể của phương pháp của bạn để vượt qua các bài kiểm tra. Nếu nó quá đơn giản và không thực sự hoạt động như bạn mong đợi, các thử nghiệm của bạn sẽ bắt kịp.
Khi bạn sử dụng những kỹ thuật này đúng cách, bạn có thể tạo ra một số giả định tốt. Với những giả định này, bạn không cần phải giữ bất cứ nơi nào gần như trong tâm trí của mình. Bạn có thể viết mã tốt hơn, đáng tin cậy hơn, vì bạn không phải lo lắng về những hậu quả gần như vô hạn mà mã của bạn có thể gây ra trên hệ thống.
Mặt khác, việc sử dụng các kỹ thuật này không đúng chỗ sẽ ẩn nấp mã mà bạn thực sự cần xem. Bằng cách ẩn mã, các giả định bạn đưa ra đôi khi sẽ sai. Điều này làm cho nó thậm chí còn nhiều hơn nữa có khả năng bạn sẽ phá vỡ nó!
Đó là lý do tại sao các phần trừu tượng tồi tệ hơn là không có phần trừu tượng nào cả và tại sao bạn không thể chỉ ném "phương pháp trích xuất" vào mã cho đến khi nó trở nên tốt một cách kỳ diệu.
Tái cấu trúc đúng chỗ, đúng chỗ
Mã rõ ràng là mã thông báo trước về những gì nó đang làm. Hiển thị những gì bạn cần biết cũng quan trọng như che giấu những gì bạn không cần biết. Khi bạn thực hiện tái cấu trúc hoặc sử dụng một phương pháp hay nhất về phần mềm, bạn nên nghĩ về mã mà bạn kết thúc và nó đã giúp bạn giảm độ phức tạp tốt như thế nào. Bạn có đang giúp phần còn lại của mã thực hiện tốt, đơn giản hóa các giả định không? Hay bạn đang chôn vùi kiến thức cần thiết đằng sau một giao diện quá đơn giản?