2010-09-01 18 views
9

Hiện tại chúng tôi đang di chuyển từ Visual Studio 2005 sang Visual Studio 2010 (sử dụng C/C++ không được quản lý). Điều này có nghĩa là khoảng một nửa số nhà phát triển của chúng tôi đã sử dụng Visual Studio 2010, trong khi nửa còn lại vẫn đang sử dụng Visual Studio 2005. Gần đây, tôi đã gặp phải một tình huống có thể được viết một cách rõ ràng trong Visual Studio 2010, nhưng đòi hỏi mã nguồn kém sạch trong Visual Studio 2005. bởi vì không phải tất cả các nhà phát triển có đã Visual Studio 2010 trên máy tính của họ, tôi phải viết mã như thế này:Có thể có mã nguồn 'time out' (trở thành không hợp lệ sau một thời điểm nhất định) không?

#if _MSC_VER >= 1600 
    // clean version of the source code 
#else 
    // less clean version 
    // of the source code 
    // requiring multiple lines of code 
    // and requiring some dirty static_casts 
#endif 

Vì tất cả các nhà phát triển sẽ chuyển sang Visual Studio 2010 cuối năm nay, tôi muốn mã này tự động biến mất sau một thời điểm nhất định. Việc giữ 'phiên bản ít sạch hơn' trong mã nguồn sẽ dẫn đến mã nguồn không đọc được trong thời gian dài.

Tất nhiên, tôi biết mã đó không tự động biến mất, vì vậy tôi thực sự muốn có chuông báo thức tự động sau một thời điểm nhất định. Một cái gì đó như thế này:

#if _MSC_VER >= 1600 
    // clean version of the source code 
#else 
    // less clean version 
    // of the source code 
    // requiring multiple lines of code 
    // and requiring some dirty static_casts 
#endif 
#if compilation_date is after 1 november 2010 
# error "Remove Visual Studio 2005 compatibility code from this file" 
#endif 

Bằng cách đó, nếu chúng ta quên về vấn đề này, chúng tôi sẽ tự động được thông báo về điều này sau khi ngày 1 tháng 11 năm 2010.

Thủ thuật này có thể đòi hỏi việc sử dụng các NGÀY, nhưng vì nhu cầu này để được xử lý bởi trình biên dịch trước, bạn không thể thực hiện thao tác chuỗi hoặc sử dụng các hàm ngày/giờ C.

Tôi cũng coi ý tưởng thay thế là chỉ gửi cho mình một thư bị trì hoãn, nhưng tôi đã tự hỏi nếu không có giải pháp nào có thể được tích hợp trong mã nguồn.

+1

Có vẻ như việc dọn dẹp có thể được viết khá dễ dàng, vì vậy tôi sẽ không bận tâm với việc chèn các cảnh báo bổ sung để nhắc nhở các nhà phát triển loại bỏ mã dự phòng. –

Trả lời

6

Cá nhân, tôi sẽ chọn không tin rằng mọi người sẽ thực sự di chuyển trước ngày dự kiến. Ngay cả khi tôi tự tin rằng nó sẽ xảy ra, tôi không muốn tạo thêm công việc cho bất cứ ai, hoặc ngăn họ làm việc, trong trường hợp tôi sai.

Nếu không có gì khác, bản dựng phải được tái sản xuất. Điều gì sẽ xảy ra nếu, vào tháng 12, bạn nhận ra rằng bạn cần tạo lại bản dựng từ tháng 10? Bạn không thể (ít nhất, không phải không có bashing đồng hồ trên máy xây dựng), bởi vì nó sẽ không biên dịch nữa.

Vì vậy, tôi muốn làm điều này:

support2005.h 
------------- 

// empty file 

source file 
----------- 

#include "support2005.h" 
#if _MSC_VER >= 1600 
    // clean version of the source code 
#else 
    // less clean version 
    // of the source code 
    // requiring multiple lines of code 
    // and requiring some dirty static_casts 
#endif 

Khi mọi người đều có VS 2010, sự thay đổi support2005.h chứa #error "Remove Visual Studio 2005 compatibility code from this file".

Thực ra cá nhân tôi sẽ không kiểm tra thay đổi đó, vì nó sẽ ngăn không cho bất kỳ ai thực hiện bất kỳ công việc nào cho đến khi hỗ trợ VS 2005 bị xóa. Loại bỏ mã chết thực sự là nhiệm vụ ưu tiên cao nhất mà công ty bạn có thể có vào sáng ngày 1 tháng 11? Và nó đòi hỏi tất cả tay trên boong để làm điều đó? Thay vào đó, tôi sẽ kiểm tra, xóa các tập tin, làm một xây dựng đầy đủ, tiếp tục loại bỏ mã tương thích cho đến khi tất cả mọi thứ xây dựng một lần nữa, và kiểm tra toàn bộ điều trong như, "loại bỏ VS 2005 hỗ trợ".

Bạn nói rằng bạn đang lo lắng bạn có thể quên, nhưng nếu bạn làm thế, vậy thì sao? Mã chết không làm tổn thương ai cả. Bạn sẽ nhớ nó khi bạn xem bất kỳ tệp nào trong lần tiếp theo hoặc vào lần tiếp theo bạn thấy "support2005.h" trong danh sách tệp, biểu đồ phụ thuộc tiêu đề, v.v. Vì vậy, không phải là "làm cho mã nguồn không đọc được trong thời gian dài ", bởi vì bất kỳ ai nhìn thấy nó lâu dài đều có thể bỏ qua hoặc xóa nó. Nếu bạn có bất kỳ loại phần mềm theo dõi vấn đề nào, bạn có thể tìm thấy cột mốc đầu tiên được nhắm mục tiêu sau 2010-11-01 và đính kèm một nhiệm vụ vào đó, "loại bỏ hỗ trợ VS 2005 và loại bỏ support2005.h", kèm theo ghi chú rằng điều này hiện đang bị chặn bởi các nhà phát triển vẫn đang sử dụng VS 2005.

Nếu bạn thực sự muốn 2010-11-01 trở thành thời hạn khó, sau đó mã sẽ bị hỏng, sau đó chỉ ở lại đến nửa đêm vào đêm Halloween và kiểm tra phá vỡ thay đổi sau đó. Nó không thực sự phá vỡ các mã, như bạn yêu cầu, nhưng nó phá vỡ bất cứ ai làm mới từ kiểm soát nguồn, và do đó có lẽ nó phá vỡ xây dựng. Quan trọng nhất, nó rất dễ dàng đảo ngược, hoặc có thể bị đàn áp cục bộ, nếu nó quay ra để ngăn chặn một người nào đó nhận được công việc làm.

+0

Đối số đẹp. Bạn chắc chắn có một điểm về "xây dựng nên được tái sản xuất". Tôi không đồng ý với cách tiếp cận "mã chết không làm tổn thương ai". Mã chết có thể/sẽ gây nhầm lẫn cho các nhà phát triển. Gần đây, chúng tôi đã gặp sự cố với ai đó đang sửa đổi mã chết để làm cho nó hoạt động với những thay đổi trong cấu trúc dữ liệu nội bộ. Vì vậy, tôi nghĩ rằng mã chết phải được loại bỏ (mặc dù ngày 1 tháng 11 có lẽ không phải là một khoảnh khắc tốt). Ý tưởng "support2005.h" đưa ra một ý tưởng tốt hơn: tại sao không sử dụng/D_SUPPORT2005 để xác định biểu tượng _SUPPORT2005, và để biên dịch thất bại nếu biểu tượng này không có ở đây, nhưng mã cũ vẫn là. – Patrick

+0

Đủ công bằng, tôi đã giả định rằng nó sẽ được biết đến rộng rãi trong tổ chức của bạn rằng sự hỗ trợ tạm thời năm 2005 này là cần thiết. Nếu vậy, sau đó một khi nó không còn cần thiết, nó * không nên * gây nhầm lẫn bất cứ ai hoặc gây ra công việc không cần thiết, bởi vì bất cứ ai nghĩ đến việc sửa đổi nó thay vào đó có thể loại bỏ nó. Tôi đồng ý rằng nói chung mã chết nên được loại bỏ vì những lý do bạn nói. –

+0

Điều gì sẽ xảy ra nếu ai đó xóa mã cũ nhưng không xóa tiêu đề. Lần tới khi họ thấy lỗi, họ sẽ không biết phải làm gì, bởi vì tất cả mã cũ đã biến mất! – Lazer

2

Tôi chỉ sử dụng bộ tiền xử lý xác định như #ifdef WARN_OLD_COMPAT. Với thư bị trì hoãn, bạn sẽ nhớ bạn định nghĩa điều này.

Kiểm tra xem ngày biên dịch có trễ hơn <X> không thể theo các cách khác.

1

Tại sao không chỉ thực hiện kiểm tra khi chạy trong các bản dựng của nhà phát triển? Chắc chắn bạn kiểm tra mã của bạn, do đó, lần đầu tiên một người nào đó kiểm tra nó sau ngày, bạn sẽ nhận được thông báo.

+1

Tôi thích kiểm tra mọi thứ tại thời gian biên dịch hơn là vào thời gian chạy. – Patrick

+0

Như tôi, nhưng trong trường hợp này, không có hại trong việc kiểm tra khi chạy. –

15

Trong trường hợp của GNU make tôi muốn làm điều đó như thế này:

CFLAGS + = -DCURDATE = $ (ngày vỏ +% Y% m% d)

Nó sẽ thêm macro CURDATE để cờ trình biên dịch, có chứa thời gian hiện tại ở định dạng YYYYMMDD.

Vì vậy, trong nguồn bạn có thể làm một cái gì đó như thế này:

#if CURDATE > 20101101 
#error "Do whatever you have to do" 
#endif 

Bạn có thể làm điều gì đó như thế này trong VS?

+0

Ý tưởng hay, cảm ơn. – Patrick

+0

+1, rất thông minh. –

Các vấn đề liên quan