(Bài này dựa trên bài tôi gửi mailing list vài tháng trước. Để đọc thêm hàng tuần, đăng ký ở đây!)
Trong "Using a Little Bit of Convenience to Save Your Programming Flow", tôi nói về abstraction đơn giản nhất làm codebase vui làm việc hơn.
Nhưng abstraction tệ thì sao?
Bạn mò tài liệu API mỗi lần để hiểu method chắc chắn nên tên leaderboard thực ra tên gì. Bạn thử refactor quanh nó, nhưng một phần cho structured data, phần kia cho raw text. Mỗi lần chạm code, thứ gì đó vỡ, bạn đốt ngày debug. Vì bạn tweak position, nhưng quên update score cùng lúc.
Làm sao xây abstraction tốt, mà tránh xa abstraction tệ?
Dùng metaphor tốt để viết code rõ ràng
Abstraction tốt xuất phát từ metaphor tốt.
Một metaphor miêu tả thứ gì đó trong hệ thống bằng cách liên hệ đến khái niệm đã có trong đầu bạn. Ví dụ:
-
Nhiều command line dùng metaphor pipe (ống).
Đưa data vào đầu ống, nó ra đầu kia. Dễ tưởng tượng, dễ dùng.
-
Trong concurrent programming, lock (khóa) là metaphor tốt.
Không cần biết lock hoạt động bên trong như thế nào, bạn biết resource bị khóa là không dùng được. Phải đợi unlock.
-
Trong OOP, message passing (truyền tin) gợi hình ảnh cụ thể: Object truyền cho object khác một message. Object thứ hai làm gì đó với message hoặc chuyển cho người khác.
Không cần biết implementation để hiểu ý (và nó làm proxy pattern dễ hiểu hơn).
Metaphor tốt là then chốt. Nếu thấy abstraction dựa trên metaphor tốt, bạn hiếm khi phải đọc docs hoặc mò source để hiểu code. Metaphor càng tốt, càng dễ miêu tả hệ thống cho người khác, và càng dễ làm việc trên hệ thống sau này.
Làm sao ra metaphor tốt?
Metaphor tốt là cụ thể, tự chứa, và tạo hình ảnh tâm trí sinh động về thứ nó miêu tả. Không chừa chỗ hiểu lầm, và khớp hành vi code càng sát càng tốt. Nếu ai đó giả định về code dựa trên hiểu metaphor của họ, giả định đó nên đúng.
Tìm metaphor tốt khó. Bạn thường qua vài metaphor rò rỉ trước khi tìm được đúng, và đó là ổn! Sẽ dễ hơn với thực hành. Nhưng quy trình này giúp tôi:
Nghĩ về cái gì code làm, không nghĩ cách nó làm. Hình ảnh gì nổi lên? Code khác dùng nó như thế nào? Nếu phải miêu tả trong một hai từ, từ nào? Ghi lại.
Sau đó, nghĩ về hình ảnh đó. Nó khớp cách code hoạt động không? Edge case nào rò rỉ qua metaphor? Có thứ gì ngoài metaphor contributor mới phải hiểu trước khi dùng code? Khi nghĩ metaphor, hình ảnh trong đầu rõ ràng hay mờ?
Đây là dấu hiệu metaphor không khớp code đủ chặt. Nhưng càng gần metaphor tốt, càng ít nhảy cầu để đến đó.
Cuối cùng, dùng nó trong câu. "Code này là một (cái gì), vì…" Bạn có thể giải thích metaphor cho người không chuyên kỹ thuật, và họ hiểu nó làm gì? Càng ít background cần để hiểu metaphor, metaphor càng hữu ích.
Gần đúng mà chưa đủ, tra thesaurus. Sự khác biệt tinh tế giữa từ tương tự có thể là chênh lệch giữa metaphor ổn và metaphor hoàn hảo.
Metaphor và OOP
OOP cơ bản dựa trên metaphor. Đó là nguồn sức mạnh! Class thiết kế tốt không chỉ giấu implementation khỏi class khác, chúng giấu implementation khỏi bạn.
Với metaphor tuyệt vời, bạn nên chỉ từ tên class biết cách dùng object. Nếu class đặt tên tốt, và gợi hình ảnh đúng, bạn không cần mò implementation để hiểu.
Vậy bây giờ, hãy nghĩ về class trong code bạn vừa làm. Có class nào có metaphor đặc biệt rõ ràng? Class nào bạn cảm thấy làm việc cùng nó, chứ không phải chống lại nó? Bạn mò vào chúng bao nhiêu lần để biết cách dùng?
Tôi rất muốn nghe bạn phát hiện gì. Comment cho tôi biết.
Để trở thành developer giỏi nhanh, bạn phải suy nghĩ có ý thức về code viết và quy trình theo đuổi. Và tôi có thể giúp.
Tải miễn phí mẫu 32 trang của Practicing Rails, học cách thử ý tưởng như này quy mô nhỏ, không bị choáng.