Hãy làm cho code nhỏ hơn

Bài viết được dịch từ blog Coding Horror

Trừ khi bạn lên núi tu trong mấy năm qua, còn nếu không thì có lẽ bạn đã nghe nói về trò game Katamari Damacy. Gameplay của nó chẳng gì khác hơn là lăn một quả bóng cuộn qua các đồ vật để cho kích thước quả bóng ngày càng tăng lên. Đó thực sự là tất cả những gì bạn cần phải làm. Bạn bắt đầu bằng cách lăn lên những thứ nhỏ như que diêm, tấm lót, đinh ghim, v.v… Khi quả bóng trở nên lớn hơn, bạn sẽ lăn nó qua các đồ vật lớn hơn. Và cứ thế, cuối cùng quả bóng Katamari của bạn trở nên quá lớn để bạn lăn qua các thành phố, ngọn núi, đám mây khác– cuối cùng là toàn bộ các hành tinh. Nó mang lại niềm vui không ngờ, và hoàn toàn mê hoặc.

Sau khi tôi chơi được một thời gian, tôi nhận ra rằng Katamari Damacy là một trò game về sự mở rộng quy mô của cuộc sống.

Cảnh trong trò game Katamari Damacy.Cảnh trong trò game Katamari Damacy.


Như Bob Koss đã chỉ ra, code cũng có xu hướng tự nhiên để trở thành một quả bóng Katamari khổng lồ của “nhiều thứ”:

Tôi đã đi rất nhiều và đến thăm nhiều công ty khác nhau. Không quan trọng việc công ty đó ở trong ngành công nghiệp nào hoặc ngôn ngữ lập trình nào mà họ đang sử dụng, có một điểm chung trong tất cả các phần code mà tôi nhìn thấy là các class thì quá lớn và các phương thức thì quá dài.

Những lập trình viên chúng ta cần phải đưa vấn đề này vào tầm kiểm soát và trở thành bậc thầy trong lĩnh vực của mình. Nếu chúng ta không hành động, mọi thứ sẽ trở nên lớn hơn và lớn hơn cho đến khi chúng ta có một mớ hỗn độn thực sự trong tay mình.

Bài viết của Bob nói về việc quản lý sự mở rộng code của bạn:

Khái niệm về việc phá vỡ một class thành nhiều phần nhỏ hơn là hoàn toàn trái ngược với những gì tôi đã được học ở trường về OO (hướng đối tượng). Quay trở lại lúc đó, người ta tin rằng một class nên đóng gói tất cả mọi thứ liên quan đến nó. Một lớp Customer sẽ biết các quy tắc nghiệp vụ của việc trở thành một Customer cũng như làm thế nào để truy lục chính nó từ cơ sở dữ liệu và hiển thị dữ liệu của nó. Đó là một ý tưởng tốt, cung cấp lược đồ cơ sở dữ liệu, phần hiển thị, hoặc các quy tắc nghiệp vụ chẳng bao giờ thay đổi. Nếu bất kỳ một trong những trách nhiệm đó thay đổi, chúng ta có nguy cơ cao phá vỡ những thứ khác gắn liền với nó.

Vì vậy, nhiều khía cạnh của phát triển phần mềm có thể được tóm tắt thành nhỏ là đẹp:

  • Tỷ lệ cá cược về sự thất bại cho một dự án phần mềm tỷ lệ thuận với kích thước của dự án. Việc chia một dự án lớn thành nhiều tiểu dự án nhỏ hơn là cách trực tiếp nhất để tăng cơ hội thành công cho dự án của bạn.
  • Mối quan hệ giữa các dòng code và bug là hoàn toàn tuyến tính. Càng ít code hơn nghĩa là ít bug hơn.
  • Code nhỏ hơn tránh được hội chứng TL; DR (Too Long; Didn’t Read). Code ít hơn thì tỷ lệ mà một ai đó sẽ thực sự đọc nó cũng sẽ cao hơn.
  • Nếu bạn giữ cho các dependencies của bạn ở mức tối thiểu, code của bạn sẽ đơn giản và dễ hiểu hơn.

Chúng ta phải chống lại xu hướng tự nhiên của bất kỳ dự án nào trở thành một hòn tuyết lăn và trở thành một quả bóng code Katamari khổng lồ. Hãy làm cho code nhỏ hơn!

Các bài viết liên quan:

Về tác giả bài viết:

Jeff_atwood_coding_horrorJeff Atwood là một chuyên gia công nghệ tại Mỹ, hiện đang sinh sống và làm việc tại Berkeley, CA. Anh là một kỹ sư phần mềm chuyên về công nghệ Microsoft .NET, và là một blogger nổi tiếng trong cộng đồng công nghệ với blog Coding Horror, anh là người sáng lập và kiêm Giám đốc điều hành (CEO) của trang web hỏi đáp uy tín Stack Overflow và cũng là đồng sáng lập của Stack ExchangeDiscourse.

Advertisements

Trả lời

Mời bạn điền thông tin vào ô dưới đây hoặc kích vào một biểu tượng để đăng nhập:

WordPress.com Logo

Bạn đang bình luận bằng tài khoản WordPress.com Log Out / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Log Out / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Log Out / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Log Out / Thay đổi )

Connecting to %s