54: “Tuổi thọ” của các giải pháp tạm thời

Tại sao chúng ta tạo ra các giải pháp tạm thời?

Thông thường nếu có một vấn đề, chúng ta sẽ giải quyết nó ngay. Điều này có thể đến từ nội bộ của nhóm phát triển, một số công cụ được thêm vào trong một chuỗi công cụ. Nó có thể là từ bên ngoài, hiển thị cho người dùng cuối, chẳng hạn như thêm một chức năng bị thiếu.

Trong hầu hết các nhóm và hệ thống, bạn sẽ tìm thấy một số phần mềm được tách riêng ra, nó được coi là chương trình nhất thời để thay thế khi không tuân theo các tiêu chuẩn và phần còn lại của code. Chắc chắn bạn sẽ nghe các nhà phát triển phàn nàn về điều này. Lý do cho sự “sáng tạo” của họ rất nhiều và đa dạng, nhưng điều mấu chốt để sử dụng các giải pháp tạm thời: Vì nó hữu ích.

Tuy nhiên, các giải pháp tạm thời có được “quán tính” (hoặc động lượng, tùy thuộc vào quan điểm của bạn). Bởi vì nó vẫn hoạt động âm thầm, cuối cùng mới phát huy lợi ích và được chấp nhận rộng rãi, không cần phải làm gì ngay lập tức. Bất cứ khi nào một bên liên quan phải quyết định xem hành động nào hiệu quả nhất, họ sẽ phải xếp trên việc tích hợp một giải pháp tạm thời. Lý do vì sao? Bởi vì nó hoạt động âm thầm cho đến khi được chấp nhận. Nhược điểm duy nhất là nó không tuân theo các tiêu chuẩn và các hướng dẫn đã chọn — ngoại trừ một vài thị trường ngách (niche markets), đây không được coi là một lực lượng đáng kể.

Vì vậy, giải pháp tạm thời vẫn còn ở đó. Mãi mãi là như vậy.

Và nền có lỗi phát sinh với giải pháp tạm thời đó, sẽ khó có một bản cập nhật phù hợp với chất lượng sản xuất. Phải làm sao để một bản cập nhật tạm thời nhanh chóng phát huy tác dụng và được chấp nhận. Nó thể hiện những điểm mạng tương tự như giải pháp đầu tiên nhưng nó chỉ cập nhật mới hơn.

Đây có phải là vấn đề?

Câu trả lời phụ thuộc vào dự án của bạn và số vốn cá nhân trong các tiêu chuẩn sản xuất code. Khi hệ thống chứa quá nhiều giải pháp tạm thời, độ phức tạp và tính lộn xộn sẽ tăng lên làm cho khả năng bảo trì sẽ giảm đi. Tuy nhiên, có lẽ việc đặt câu hỏi là sai. Hãy nhớ rằng chúng ta đang nói về một giải pháp. Nó có thể không phải là giải pháp ưu tiên của bạn nhưng động lực để thực hiện lại giải pháp này là rất thấp.

Vậy chúng ta có thể làm gì nếu thấy có lỗi?

• Tránh tạo ra một giải pháp tạm thời ngay từ đầu.
• Thay đổi các yếu tố ảnh hưởng đến quyết định của người quản lý dự án.
• Hãy để yên nó như vậy.

Hãy xem xét các tùy chọn này kỹ càng hơn:

Tránh việc chức năng không hoạt động ở hầu hết các trường hợp. Có một vấn đề thực sự cần giải quyết và các tiêu chuẩn đề ra lại quá hạn chế. Bạn có thể dành một chút sức lực của mình để cố gắng thay đổi các tiêu chuẩn đó. Một nỗ lực đáng trân trọng dù là tẻ nhạt và hiệu quả… không đến ngay lập tức để giải quyết vấn đề của bạn.

Sự ảnh hưởng bắt nguồn từ văn hóa dự án, trong đó có sự ngăn cản việc thay đổi. Nó có thể sẽ thành công trong một dự án nhỏ chỉ có bạn và bạn chỉ tình cờ “dọn dẹp” mớ hỗn độn mà không cần thông qua ai. Nó cũng có thể thành công trong một dự án có nhiều vấn đề đến mức đình trệ và buộc phải dành nhiều thời gian tìm ra cách giải quyết.

Tính năng động sẽ được áp dụng nếu tùy chọn trước đó không có.

Bạn sẽ tạo ra nhiều giải pháp, một trong số chúng sẽ chỉ là tạm thời nhưng hầu hết lại hữu ích. Cách tốt nhất để bảo qua các giải pháp tạm thời là làm cho chúng trở nên thừa thãi, qua đó cung cấp một giải pháp hiệu quả hơn. Tôi mong rằng bạn có được sự thoải mái để chấp nhận những điều bạn không thể thay đổi, can đảm thay đổi những điều bạn có thể và có khả năng để biết được sự khác biệt.