ENTROPY PHẦN MỀM

Nguồn:

The Pragmatic Programmer – From Journeyman to Master
- Chapter 1. A Pragmatic Philosophy
  - Software Entropy

Trong khi quá trình phát triển phần mềm không chịu ảnh hưởng từ hầu hết các định luật vật lý, hiện tượng entropy lại ảnh hưởng mạnh mẽ đến chúng ta. Entropy là một thuật ngữ trong vật lý, chỉ đến mức độ “mất trật tự, ngẫu nhiên hoặc không chắc chắn” trong một hệ thống. Thật không may, các định luật của nhiệt động lực học khẳng định rằng entropy trong vũ trụ có xu hướng tăng lên tối đa. Khi sự mất trật tự tăng lên trong phần mềm, người lập trình gọi đó là “sự mục nát của phần mềm (software rot).”

Có nhiều yếu tố có thể góp phần vào sự mục nát của phần mềm. Một yếu tố quan trọng nhất dường như là tâm lý hoặc văn hóa làm việc trong dự án. Ngay cả khi bạn là một đội ngũ chỉ có một người, tâm lý của dự án của bạn cũng có thể là một điều rất mong manh. Dù có kế hoạch tốt nhất và những người tốt nhất, một dự án vẫn có thể trải qua sự suy tàn và hủy hoại trong quãng thời gian của nó. Tuy nhiên, cũng có những dự án mặc cho những khó khăn lớn và thất bại liên tục, vẫn chiến đấu thành công chống lại xu hướng tự nhiên của sự mất trật tự và vẫn quản lý hoạt động khá tốt.

Điều gì tạo ra sự khác biệt?

Ở các thành phố nội đô, có những tòa nhà đẹp và sạch sẽ, trong khi những tòa nhà khác thì đang bị hỏng hóc. Tại sao lại như vậy? Các nhà nghiên cứu trong lĩnh vực tội phạm và suy thoái đô thị đã khám phá ra một cơ chế kích thích đầy hấp dẫn, một cơ chế biến một tòa nhà sạch sẽ, nguyên vẹn và có người ở thành một không gian hoang tàn và bị bỏ hoang.

Một cửa sổ hỏng.

Một cửa sổ hỏng, nếu để không sửa chữa trong một khoảng thời gian đủ lâu, gieo vào trong người dân của tòa nhà một cảm giác bị bỏ rơi – một cảm giác rằng những người có quyền lực không quan tâm đến tòa nhà đó. Do đó, một cửa sổ khác bị hỏng. Người ta bắt đầu làm bẩn. Graffiti xuất hiện. Sự hỏng hóc cấu trúc nghiêm trọng bắt đầu. Trong một khoảng thời gian tương đối ngắn, tòa nhà trở nên hỏng hóc quá nhiều, vượt quá khả năng và ý chí của chủ sở hữu để sửa chữa, và cảm giác bị bỏ rơi trở thành hiện thực.

“Lý thuyết Cửa Sổ Hỏng” (Broken Window Theory) đã truyền cảm hứng cho các đội cảnh sát ở New York và các thành phố lớn khác để đàn áp các vi phạm nhỏ nhẹ nhàng để ngăn chặn các vấn đề lớn. Nó đã hoạt động: việc giữ gìn cửa sổ hỏng, graffiti và các vi phạm nhỏ khác đã giảm thiểu mức độ tội phạm nghiêm trọng.

Không Sống Chung Với Cửa Sổ Hỏng

Đừng để lại những “cửa sổ hỏng” (thiết kế kém, quyết định sai lầm hoặc mã nguồn kém chất lượng) chưa được sửa chữa. Hãy sửa chúng ngay khi chúng được phát hiện. Nếu không có đủ thời gian để sửa chúng một cách đúng cách, thì hãy che chắn chúng đi. Có thể bạn sẽ comment code gây lỗi, hoặc hiển thị thông báo “Chưa Được Thực Hiện”, hoặc sử dụng dữ liệu giả mạo thay thế. Hãy thực hiện một hành động nào đó để ngăn chặn hỏng hóc tiếp theo và để cho thấy bạn đang kiểm soát tình hình.

Chúng ta đã thấy các hệ thống sạch sẽ, hoạt động xuống cấp nhanh chóng khi có “cửa sổ hỏng” xuất hiện. Có các yếu tố khác có thể góp phần vào sự mục nát của phần mềm, và chúng ta sẽ đề cập đến một số trong những nơi khác, nhưng sự lơ là tăng tốc quá trình suy thoái hơn bất kỳ yếu tố nào khác.

Có thể bạn đang nghĩ rằng không ai có thời gian để đi xung quanh dọn dẹp tất cả các mảnh kính vỡ của một dự án. Nếu bạn tiếp tục nghĩ như vậy, thì bạn nên dự định có một xe rác hoặc chuyển đến một khu phố khác. Đừng để entropy chiến thắng.

Dập Lửa

Ngược lại, có một câu chuyện về một người bạn giàu có của Andy. Nhà anh ta được trang trí tinh tế, đẹp đẽ, đầy đủ với những tác phẩm nghệ thuật và đồ cổ vô giá. Một ngày nọ, một tấm thảm treo quá gần lò sưởi trong phòng khách của anh ta bắt lửa. Đội cứu hỏa đã đến kịp thời để cứu ngôi nhà vàng của anh ta. Nhưng trước khi họ kéo ống dẫn nước lớn và bẩn vào nhà, họ dừng lại – dù lửa đang cháy dữ dội – để trải một chiếc thảm ra giữa cửa trước và nguồn lửa.

Họ không muốn làm bẩn chiếc thảm.

Đó là một trường hợp khá cực đoan, nhưng đó chính là cách phải làm với phần mềm. Một “cửa sổ hỏng” – một đoạn mã thiết kế kém, một quyết định quản lý không tốt mà đội ngũ phải sống chung trong suốt dự án – đó là đủ để bắt đầu quá trình suy giảm. Nếu bạn phát hiện mình đang làm việc trên một dự án có nhiều “cửa sổ hỏng,” rất dễ để rơi vào tâm lý “Toàn bộ mã nguồn này đều là rác, tôi chỉ cần đi theo như vậy.” Không quan trọng dự án đã tiến triển tốt đẹp đến đâu. Trong thí nghiệm gốc về “Lý thuyết Cửa Sổ Hỏng,” một chiếc xe bị bỏ quên nằm không chuyển động trong một tuần. Nhưng khi một cửa sổ bị vỡ, chiếc xe bị phá hủy và bị lật úp chỉ trong vài giờ.

Theo cùng một quan điểm, nếu bạn thấy mình đang ở trong một nhóm và một dự án mà mã nguồn rất đẹp – được viết sạch sẽ, thiết kế tốt và tinh tế – có lẽ bạn sẽ chú ý đặc biệt để không làm rối lên nó, giống như các lính cứu hỏa. Ngay cả khi có một đám cháy bùng cháy (hạn chót, ngày phát hành, triển lãm thương mại, v.v.), bạn không muốn là người đầu tiên tạo ra một tình huống hỗn độn.