# 61: One Binary

Tôi đã từng xem qua một vài project mà đội ngũ thiết kế phải viết lại một vài phần của source code để tạo ra một chương trình dành riêng cho từng môi trường nhất định. Điều này khiến mọi việc trở nên phức tạp hơn, và có khả năng khiến team gặp khó khăn trong xử lý các phiên bản trên từng cài đặt. Chí ít thì nó liên quan đến việc xây dựng nhiều bản copy gần giống hệt nhau của phần mềm, và mỗi bản phải được chuyển đến đúng nơi mà nó thuộc về. Điều này có nghĩa là chúng ta phải thực hiện công tác di chuyển nhiều hơn bình thường, song điều này khiến cho khả năng xảy ra sai sót cao hơn.

Tôi từng làm việc chung với team mà mỗi sự thay đổi tính năng đều phải được kiểm tra thật kỹ lưỡng trước khi bước vào chu kỳ xây dựng chính. Chính vì thế mà tester được giữ lại chờ đợi bất cứ khi nào họ cần chỉnh sửa một vài thay đổi nhỏ (Tôi đã từng nhắc đến việc xây dựng toàn bộ sẽ mất thời gian quá lâu chưa?). Tôi cũng làm việc với team sẵn sàng xây dựng lại mọi thứ từ đầu cho quá trình sản xuất(sử dụng cách thức cũ như chúng tôi đã làm). Điều này có nghĩa là chúng ta chả có bằng chứng nào về việc phiên bản trong quá trình sản xuất đã được kiểm tra kỹ lưỡng. Và nhiều thứ nữa.

Quy tắc rất đơn giản: hãy xây dựng một chương trình duy nhất mà bạn có thể xác định và thúc đẩy chúng thông qua tất cả các giai đoạn của quá trình phát hành. Hãy giữ chi tiết tối ưu cho từng môi trường trong môi trường của chúng. Ví dụ như là giữ chúng trong nơi chứa thành phần nhất định trong một file đã biết hoặc đường dẫn nào đó.

Nếu team bạn có một bản code chứa tất cả mọi thứ hoặc lưu trữ nhưng cài đặt quan trọng trong code điều này cho thấy không một ai đã suy nghĩ kĩ càng về việc thiết kế để chia các tính năng mà quan trọng đối với ứng dụng, cái nào dành cho các môi trường nhất định. Hoặc tệ hơn, team đó biết phải làm gì nhưng lại không thể quan trọng hóa nó để thực hiện các thay đổi.

Tất nhiên là sẽ có những trường hợp ngoại lệ ⚠. Bạn có thể phát triển cho đối tượng mà có sự khác biệt rõ rệt trong ràng buộc tài nguyên, nhưng nó không ảnh hưởng lớn đến những người mà viết ứng dụng truy xuất database liên tục. Hoặc là bạn đang ăn nằm với một vài mốt rắc rối đã cũ mà chúng quá khó để sửa chữa ngay bây giờ. Trong những trường hợp như thế này, bạn phải từng bước tiến dần giải quyết chúng nhưng hãy bắt đầu càng sớm càng tốt.

Và một điều nữa: hãy giữ cho những thông tin về môi trường bạn cần luôn được cập nhật. Không việc gì có thể tệ hơn việc phá huỷ các thiết lập của môi trường và không thể biết được rằng chúng đã thay đổi những gì. Những thông tin về chúng luôn phải được cập nhật tách biệt khỏi code, bởi chính thay đổi ở những khoản khác nhau và thay đổi bởi nhiều lý do khác nhau. Chính vì thế các team nên dùng những hệ thống version control như là bazzar hay Git, bởi chúng khiến cho việc thay đổi môi trường sản phẩm trở nên dễ dàng hơn rất nhiều, và cũng đừng quên lưu lại chúng.