Mã chứng minh trong tương lai

Nơi tôi làm việc, các nhà phát triển luôn nói với tôi rằng "Tôi đã thêm điều này chỉ trong trường hợp cho tương lai" hoặc "Tôi nghĩ rằng đó là một ý tưởng tốt để làm điều này bởi vì họ có thể sẽ muốn nó một ngày nào đó". Tôi nghĩ thật tuyệt khi họ chủ động cố gắng dự đoán những thay đổi trong tương lai nhưng tôi không thể nghĩ rằng nó không cần thiết và có nguy cơ viết mã không bao giờ cần thiết và do đó không hiệu quả (tôi cũng nghĩ rằng một số nhà phát triển chỉ muốn thử một cái gì đó mới vì lợi ích của nó). Các đối số cho việc chứng minh trong tương lai có hợp lệ không nếu bạn chỉ viết mã được tổ chức tốt, sạch sẽ?

Vâng, trước hết, có một số điều cần làm rõ:

• Bằng chứng trong tương lai là không thêm công cụ.
• Việc kiểm chứng trong tương lai là đảm bảo bạn có thể dễ dàng thêm mã / tính năng mà không phá vỡ chức năng hiện có.

Điều này có nghĩa là việc viết mã "bằng chứng trong tương lai", đảm bảo rằng mã được viết theo cách ghép lỏng lẻo, đủ trừu tượng, nhưng cũng là mã không hoàn toàn che giấu các mức độ trừu tượng, vì vậy luôn có cách để đi đến các mức độ trừu tượng thấp hơn Nếu cần.

Viết mã bằng chứng trong tương lai là một nghệ thuật của chính nó và được kết hợp chặt chẽ với các thực tiễn RẮN để phiên bản thành phần, tách các mối quan tâm, phân lớp và trừu tượng của chức năng. Việc chứng minh trong tương lai không liên quan gì đến việc thêm các tính năng trước thời hạn, nhưng với việc đảm bảo bạn có thể thêm các tính năng trong tương lai theo cách không phá vỡ , thông qua thiết kế tốt của mã / thư viện hiện có.

2c của tôi

Không viết mã sẽ không được sử dụng trong một thời gian dài. Nó sẽ vô dụng vì rất có thể nó sẽ không phù hợp với nhu cầu tại thời điểm đó (mà theo định nghĩa mà bạn chưa biết).

Làm cho mã mạnh mẽ chống lại các tình huống sự cố không mong muốn cho phép phục hồi duyên dáng hoặc không nhanh, nhưng không viết mã để sử dụng trong tương lai.

Một cách tốt để đảm bảo rằng, là sử dụng thiết kế và phát triển dựa trên thử nghiệm. Các trường hợp thử nghiệm có nguồn gốc từ các trường hợp đặc điểm kỹ thuật và sử dụng. Tất cả các mã phải thực hiện một thử nghiệm vượt qua. Mã không cần thiết không nên được viết. Bằng cách này, thật đơn giản để xác định xem nó có cần thiết hay không.

Điều quan trọng là nhận ra rằng việc tạo mã bằng chứng trong tương lai và viết mã trong trường hợp cần thiết trong tương lai là hai điều rất khác nhau. Cái trước là rất quan trọng đối với một ứng dụng tốt, ít hơn thường không phải là thực hành mã hóa tốt.

• Đối với tôi, việc chứng minh mã trong tương lai, đang viết nó theo cách mà nó sẽ có thể tương tác với các công nghệ phát triển. Điều này liên quan đến việc mô đun hóa mã của bạn, để mỗi phần trong ứng dụng của bạn có thể tương tác độc lập với toàn bộ ngôn ngữ và công nghệ của ứng dụng. Một ví dụ điển hình cho việc này sẽ là sử dụng XML hoặc JSON để truyền dữ liệu giữa các phần khác nhau của ứng dụng. Tuy nhiên, công nghệ phát triển, rất có khả năng nó sẽ luôn có thể đọc XML và JSON.

• Tương tự như trên, việc hiển thị một phần ứng dụng của bạn thông qua API SOAP hoặc REST đạt được điều tương tự. Dù công nghệ phát triển là gì, bạn không nhất thiết phải viết lại mọi phần của ứng dụng vì các công nghệ mới vẫn có thể giao tiếp với cũ.

• Về quan điểm viết mã trong trường hợp cần thiết , tôi nghĩ rằng nó rất nguy hiểm vì mã có thể có ít hoặc không có thử nghiệm.

Vì vậy, bằng mọi cách, hãy tạo mã bằng chứng trong tương lai (NASA vẫn gửi tàu vũ trụ lên bằng Fortran), nhưng không viết mã 'chỉ trong trường hợp'.

Hãy suy nghĩ về việc bạn đã kích hoạt một đoạn mã trong bao nhiêu lần trong môi trường sản xuất và nghĩ, "Cảm ơn chúa tôi đã viết cách đây 2 năm!".

Mã phải được sửa đổi / mở rộng dễ dàng. Đừng thêm mã không cần thiết ngay lập tức, vì điều này mang lại cảm giác an toàn rất sai lầm và lãng phí tài nguyên dev / test trong một thế giới thay đổi yêu cầu.

Rất nhiều câu trả lời khác giải quyết loại vấn đề thiết kế lớn hơn, hoặc khá trừu tượng. Nếu bạn nghĩ về những gì sẽ xảy ra trong tương lai, bạn có thể xác định một số kỹ thuật rõ ràng để giúp đỡ chứng minh mã trong tương lai .

Chủ yếu nghĩ rằng trong tương lai ai đó sẽ cố gắng thêm một tính năng vào mã hoặc sẽ cố gắng sử dụng lại mã của bạn ở một nơi khác. Họ cũng có thể cố gắng sửa một tính năng trong mã. Rõ ràng chỉ cần có mã sạch tốt là một điểm khởi đầu bắt buộc, nhưng cũng có một số kỹ thuật cụ thể có thể được thực hiện.

Lập trình phòng thủ : Thực hiện kiểm tra đầu vào vượt quá những gì ứng dụng hiện tại của bạn thực sự cần. Bất cứ khi nào bạn gọi API, hãy chắc chắn kiểm tra xem đầu vào của chúng có phải là thứ bạn mong đợi không. Trong tương lai mọi người sẽ trộn lẫn các phiên bản mã mới với nhau, vì vậy phạm vi lỗi và trả về API sẽ thay đổi so với hiện tại.

Elliminate Hành vi không xác định : Rất nhiều mã có hành vi chỉ là loại tiến hóa từ hư không. Một số kết hợp đầu vào dẫn đến đầu ra nhất định mà không ai thực sự có ý định, nhưng chỉ có như vậy xảy ra. Bây giờ chắc chắn sẽ có người dựa vào hành vi đó, nhưng không ai biết về nó vì nó không được xác định. Bất cứ ai cố gắng thay đổi hành vi trong tương lai sẽ vô tình phá vỡ mọi thứ. Sử dụng kiểm tra an toàn ngay bây giờ và cố gắng xóa / chặn tất cả các sử dụng mã không xác định.

Bộ kiểm tra tự động : Tôi chắc chắn bạn có thể tìm thấy các tập viết về nhu cầu kiểm tra đơn vị. Tuy nhiên, liên quan đến việc chứng minh trong tương lai, đây là một điểm quan trọng trong việc cho phép ai đó tái cấu trúc mã. Tái cấu trúc là điều cần thiết để duy trì mã sạch, nhưng nếu thiếu một bộ kiểm tra tốt, bạn không thể tái cấu trúc một cách an toàn.

Cách ly và phân chia : Đóng gói và mô đun hóa phù hợp là một nguyên tắc thiết kế tốt, nhưng bạn cần phải vượt qua điều đó. Bạn sẽ thường thấy rằng bạn cần sử dụng thư viện hoặc API hoặc sản phẩm có thể có tương lai đáng ngờ. Có thể do mối quan tâm về chất lượng, vấn đề cấp phép hoặc tiếp tục phát triển của các tác giả. Trong những trường hợp này cần thêm thời gian để đặt một lớp giữa bạn và mã này. Cắt API xuống chỉ những gì bạn cần để khớp nối rất thấp để cho phép thay thế dễ dàng hơn trong tương lai.

Mã tốt, sạch sẽ, được tổ chức tốt là bằng chứng trong tương lai theo nghĩa là nó làm cho các thay đổi và bổ sung dễ dàng thực hiện chính xác hơn.

"Bằng chứng tương lai" tốt nhất có nghĩa là "thiết kế kết nối lỏng lẻo". 80% thời gian mọi người có nghĩa là "linh hoạt" khi họ nói "bằng chứng trong tương lai". Đôi khi họ nói nó để thử và âm thanh tuyệt vời. Nhưng ít nhất họ đang cung cấp một cái gì đó đúng thời gian.

"Bằng chứng tương lai" tồi tệ nhất là vô nghĩa. 20% thời gian, đó là một lý do để lãng phí thời gian nghiên cứu các công nghệ thay thế thay vì chỉ đơn giản là cung cấp một cái gì đó. Họ không cung cấp bất cứ điều gì (hoặc những gì họ đang cung cấp quá phức tạp cho vấn đề hiện tại.)

Có hai trường hợp cạnh.

1. Tầm nhìn xa trông rộng. Một người thực sự có thể dự đoán tương lai chính xác. Trong trường hợp này, vui lòng áp dụng tầm nhìn xa mạnh mẽ này để chứng minh mã trong tương lai. Tốt hơn, áp dụng tầm nhìn xa không dự đoán để dự đoán xu hướng thị trường và nghỉ hưu sớm và ngừng mã hóa.

2. Một là "lái" tương lai. Đó là, người ta có một số công nghệ mới sẵn sàng để triển khai trong tương lai sẽ yêu cầu viết lại thứ được giao ngay bây giờ. Thật kỳ lạ khi người ta không triển khai thứ tương lai tuyệt vời này trước tiên.

   Chúng tôi phải phân phối dự án "A", biết rằng dự án "B" sẽ dẫn đến việc viết lại ngay lập tức "A". Chỉ trong trường hợp này, chúng tôi có thể chứng minh "A" trong tương lai.

YAGNI = Bạn không cần đến nó .

Bản năng của bạn là chính xác: mã của họ là không cần thiết, thêm gánh nặng bảo trì và thử nghiệm và lãng phí thời gian vào những thứ không có giá trị kinh doanh cụ thể.

Xem thêm: Mạ vàng .

Bỏ qua tiêu đề của câu hỏi và đưa ra ý chính về việc "đặt nội dung vào vì ai đó có thể muốn nó vào một ngày nào đó" ...

Câu trả lời là không. Không bao giờ. Đừng viết một đoạn mã bạn không cần hôm nay. Đây là lý do tại sao:

1. Chương trình bây giờ phức tạp hơn mức cần thiết.
2. Bạn có thể không bao giờ cần tính năng này, vì vậy bạn đã lãng phí thời gian của mình.
3. Bạn không biết các yêu cầu cho tính năng này sẽ là gì nếu có ai từng yêu cầu tính năng này trong tương lai. Vì vậy, bạn sẽ phải tìm ra nó và sửa đổi nó bằng mọi cách.

Tôi nghĩ rằng điểm đầu tiên là quan trọng nhất. Nếu bạn đã từng làm việc với một hệ thống được sử dụng mã chung cho các khách hàng khác nhau hoặc có đầy đủ tính năng với những thứ bạn không cần thì bạn sẽ biết cần thêm bao nhiêu thời gian và công sức để duy trì hoặc mở rộng chức năng vì cái đó. Vì vậy, tránh bằng mọi giá.