Ngăn chặn mã không dùng nữa để biên dịch sau khi đến hạn chót [đã đóng]

Trong nhóm của tôi, chúng tôi đã dọn dẹp rất nhiều thứ cũ trong một dự án nguyên khối lớn (toàn bộ lớp học, phương pháp, v.v.).

Trong quá trình làm sạch đó, tôi đã tự hỏi liệu có một loại chú thích hay thư viện nào lạ hơn bình thường không @Deprecated. Điều này @FancyDeprecatedsẽ ngăn việc xây dựng dự án thành công nếu bạn chưa xóa mã cũ không sử dụng sau khi một ngày cụ thể trôi qua.

Tôi đã tìm kiếm trên Internet và không tìm thấy bất cứ thứ gì có khả năng được mô tả dưới đây:

• phải là một chú thích, hoặc một cái gì đó tương tự, để đặt vào mã bạn định xóa trước một ngày cụ thể
• trước ngày đó mã sẽ biên dịch và mọi thứ sẽ hoạt động bình thường
• sau ngày đó mã sẽ không được biên dịch và nó sẽ cho bạn một thông báo cảnh báo bạn về vấn đề này

Tôi nghĩ rằng tôi đang tìm kiếm một con kỳ lân ... Có công nghệ tương tự cho bất kỳ ngôn ngữ chương trình nào không?

Như một kế hoạch BI đang nghĩ đến khả năng tạo ra phép thuật với một số bài kiểm tra đơn vị về mã dự định sẽ bị xóa mà bắt đầu thất bại ở "thời hạn". Bạn nghĩ gì về điều này? Còn ý tưởng nào hay hơn không?

Tôi không nghĩ rằng đây sẽ là một tính năng hữu ích khi nó thực sự cấm biên dịch. Khi vào ngày 01/06/2018, phần lớn mã sẽ không được biên dịch vào ngày hôm trước, nhóm của bạn sẽ nhanh chóng xóa chú thích đó một lần nữa, mã có được dọn sạch hay không.

Tuy nhiên, bạn có thể thêm một số chú thích tùy chỉnh vào mã như

@Deprecated_after_2018_07_31

và xây dựng một công cụ nhỏ để quét các chú thích đó. (Một lớp lót đơn giản trong grep sẽ làm điều đó, nếu bạn không muốn sử dụng sự phản chiếu). Trong các ngôn ngữ khác ngoài Java, có thể sử dụng một nhận xét được tiêu chuẩn hóa phù hợp cho "grepping" hoặc định nghĩa tiền xử lý.

Sau đó chạy công cụ đó ngay trước hoặc sau ngày cụ thể và nếu nó vẫn tìm thấy chú thích đó, hãy nhắc nhở nhóm dọn dẹp các phần mã đó một cách khẩn cấp.

Điều này sẽ tạo thành một tính năng được gọi là một quả bom hẹn giờ . KHÔNG TẠO BOMBS THỜI GIAN.

Mã, cho dù bạn cấu trúc và ghi chép nó tốt đến đâu, sẽ biến thành một hộp đen gần như không hiểu được nếu nó sống quá một độ tuổi nhất định. Điều cuối cùng mà bất cứ ai trong tương lai cần là một chế độ thất bại kỳ lạ khác khiến họ hoàn toàn bất ngờ, vào thời điểm tồi tệ nhất có thể, và không có một biện pháp khắc phục rõ ràng. Hoàn toàn không có lý do cho việc cố ý tạo ra một vấn đề như vậy.

Nhìn vào nó theo cách này: nếu bạn có tổ chức và nhận thức được cơ sở mã của mình đủ để bạn quan tâm đến sự lỗi thời và theo dõi nó, thì bạn không cần một cơ chế trong mã để nhắc nhở bạn. Nếu bạn không, rất có thể là bạn cũng không cập nhật về các khía cạnh khác của cơ sở mã và có thể sẽ không thể trả lời báo động kịp thời và chính xác. Nói cách khác, bom hẹn giờ không phục vụ mục đích tốt cho bất cứ ai. Chỉ cần nói không!

Trong C #, bạn sẽ sử dụng ObsoleteAttributetheo cách sau:

• Trong phiên bản 1, bạn gửi tính năng này. Một phương thức, lớp học, bất cứ điều gì.
• Trong phiên bản 2, bạn gửi một tính năng tốt hơn nhằm thay thế tính năng ban đầu. Bạn đặt thuộc tính Lỗi thời trên tính năng, đặt thành "cảnh báo" và gửi cho nó một thông báo "Tính năng này không được chấp nhận. Thay vào đó, hãy sử dụng tính năng tốt hơn. Trong phiên bản 3 của thư viện này, sẽ được phát hành như vậy một ngày, việc sử dụng tính năng này sẽ là một lỗi. " Bây giờ người dùng của tính năng vẫn có thể sử dụng nó, nhưng có thời gian để cập nhật mã của họ để sử dụng tính năng mới.
• Trong phiên bản 3, bạn cập nhật thuộc tính là lỗi thay vì cảnh báo và cập nhật thông báo để nói "Tính năng này không được chấp nhận. Thay vào đó, hãy sử dụng tính năng tốt hơn. Trong phiên bản 4 của thư viện này, sẽ được phát hành như vậy một ngày, tính năng này sẽ ném. " Người dùng không chú ý đến cảnh báo trước đó của bạn vẫn nhận được một thông báo hữu ích cho họ biết cách khắc phục sự cố và họ phải khắc phục vì giờ mã của họ không được biên dịch.
• Trong phiên bản 4, bạn thay đổi tính năng để nó ném một số ngoại lệ nghiêm trọng và thay đổi thông báo để nói rằng tính năng này sẽ bị xóa hoàn toàn trong phiên bản tiếp theo.
• Trong phiên bản 5, bạn loại bỏ hoàn toàn tính năng này và nếu người dùng phàn nàn, thì, bạn đã cho họ ba chu kỳ phát hành cảnh báo công bằng và họ luôn có thể tiếp tục sử dụng phiên bản 2 nếu họ cảm thấy mạnh mẽ về nó.

Ý tưởng ở đây là tạo ra một thay đổi đột phá không gây đau đớn nhất có thể cho người dùng bị ảnh hưởng và để đảm bảo rằng họ có thể tiếp tục sử dụng tính năng này cho ít nhất một phiên bản của thư viện.

Bạn đã hiểu nhầm "deprecated" nghĩa là gì. Phương tiện không dùng nữa:

có thể sử dụng được nhưng được coi là lỗi thời và tốt nhất nên tránh, điển hình là vì nó đã được thay thế.

_{Từ điển Oxford}

Theo định nghĩa, một tính năng không dùng nữa sẽ vẫn được biên dịch.

Bạn đang tìm cách loại bỏ tính năng này vào một ngày cụ thể. Tốt rồi. Cách bạn làm là bạn loại bỏ nó vào ngày đó .

Cho đến lúc đó, đánh dấu là không tán thành, lỗi thời hoặc bất cứ điều gì ngôn ngữ lập trình của bạn gọi nó. Trong tin nhắn, bao gồm ngày nó sẽ bị xóa và thứ thay thế nó. Điều này sẽ tạo ra các cảnh báo, chỉ ra rằng các nhà phát triển khác nên tránh sử dụng mới và nên thay thế việc sử dụng cũ bất cứ khi nào có thể. Những nhà phát triển đó sẽ tuân thủ hoặc bỏ qua nó, và ai đó sẽ phải giải quyết hậu quả của điều đó khi nó bị xóa. (Tùy thuộc vào tình huống, có thể là bạn hoặc có thể là nhà phát triển sử dụng nó.)

Đừng quên rằng bạn cần giữ lại khả năng xây dựng và gỡ lỗi các phiên bản mã cũ hơn để hỗ trợ các phiên bản phần mềm đã được phát hành. Phá hủy một bản dựng sau một ngày nhất định có nghĩa là bạn cũng có nguy cơ ngăn cản bản thân thực hiện công việc bảo trì và hỗ trợ hợp pháp trong tương lai.

Ngoài ra, có vẻ như một cách giải quyết tầm thường để đặt lại đồng hồ của máy tôi một hoặc hai năm trước khi biên dịch.

Hãy nhớ rằng, "không dùng nữa" là một cảnh báo rằng một cái gì đó sẽ biến mất trong tương lai. Khi bạn muốn ngăn chặn mọi người sử dụng API đó một cách mạnh mẽ, chỉ cần xóa mã liên quan . Không có điểm nào để lại mã trong cơ sở mã nếu một số cơ chế làm cho nó không sử dụng được. Xóa mã cung cấp cho bạn các kiểm tra thời gian biên dịch mà bạn đang tìm kiếm và không có cách giải quyết tầm thường.

Chỉnh sửa: Tôi thấy bạn đề cập đến "mã không sử dụng cũ" trong câu hỏi của bạn. Nếu mã thực sự không được sử dụng , sẽ không có điểm nào phản đối nó. Chỉ cần xóa nó.

Tôi chưa bao giờ thấy một tính năng như vậy trước đây - một chú thích bắt đầu có hiệu lực sau một ngày cụ thể.

Có @Deprecatedthể là đủ, tuy nhiên. Nắm bắt các cảnh báo trong CI và làm cho nó từ chối chấp nhận bản dựng nếu có. Điều này chuyển trách nhiệm từ trình biên dịch sang đường ống xây dựng của bạn, nhưng có lợi thế là bạn có thể (bán) dễ dàng thay đổi đường ống xây dựng bằng cách thêm các bước bổ sung.

Lưu ý rằng câu trả lời này không giải quyết được hoàn toàn vấn đề của bạn (ví dụ: bản dựng cục bộ trên máy của nhà phát triển vẫn sẽ thành công, mặc dù có cảnh báo) và giả định rằng bạn có đường ống CI được thiết lập và chạy.

Bạn đang tìm kiếm lịch hoặc danh sách việc cần làm .

Một cách khác là sử dụng các cảnh báo trình biên dịch tùy chỉnh hoặc thông báo trình biên dịch, nếu bạn quản lý để có một vài cảnh báo trong cơ sở mã của bạn. Nếu bạn có quá nhiều cảnh báo, bạn sẽ cần tốn thêm công sức (khoảng 15 phút?) Và phải nhận cảnh báo trình biên dịch trong báo cáo bản dựng mà tích hợp liên tục của bạn cung cấp cho mỗi bản dựng.

Nhắc nhở rằng mã cần được sửa là tốt và cần thiết. Đôi khi những lời nhắc này có thời hạn thực tế nghiêm ngặt, vì vậy việc đặt chúng vào một bộ đếm thời gian cũng có thể cần thiết.

Mục tiêu là liên tục nhắc nhở mọi người rằng vấn đề tồn tại và cần được khắc phục trong một khung thời gian nhất định - một tính năng đơn giản phá vỡ bản dựng tại một thời điểm cụ thể không chỉ không làm điều đó, mà chính tính năng đó là vấn đề cần phải làm được cố định với một khung thời gian nhất định.

Một cách để nghĩ về điều này là những gì bạn có nghĩa là theo thời gian / ngày ? Máy tính không biết những khái niệm này là gì: chúng phải được lập trình bằng cách nào đó. Nó khá phổ biến để biểu thị thời gian theo định dạng UNIX của "giây kể từ thời đại" và thông thường để cung cấp một giá trị cụ thể vào chương trình thông qua các cuộc gọi của hệ điều hành. Tuy nhiên, cho dù mức độ sử dụng phổ biến này như thế nào, điều quan trọng cần nhớ là đó không phải là thời gian "thực tế": nó chỉ là một biểu diễn logic.

Như những người khác đã chỉ ra, nếu bạn thực hiện một "thời hạn" bằng cách sử dụng cơ chế này, thì việc cho ăn trong một thời điểm khác và phá vỡ "thời hạn" đó là chuyện nhỏ. Điều tương tự cũng xảy ra đối với các cơ chế phức tạp hơn như yêu cầu máy chủ NTP (thậm chí qua kết nối "an toàn", vì chúng ta có thể thay thế chứng chỉ của chính mình, cơ quan cấp chứng chỉ hoặc thậm chí vá các thư viện tiền điện tử). Lúc đầu, có vẻ như các cá nhân đó có lỗi khi làm việc xung quanh cơ chế của bạn, nhưng có thể đó là trường hợp được thực hiện tự động và vì lý do chính đáng . Ví dụ: nên có các bản dựng có thể lặp lại và các công cụ để giúp việc này có thể tự động đặt lại / chặn các cuộc gọi hệ thống không xác định như vậy. libfaketime thực hiện chính xác điều đó,đặt tất cả dấu thời gian của tệp thành 1970-01-01 00:00:01, tính năng ghi / phát lại của Qemu làm giả mọi tương tác phần cứng, v.v.

Điều này tương tự như luật của Goodhart : nếu bạn thực hiện hành vi của chương trình phụ thuộc vào thời gian logic, thì thời gian logic sẽ không còn là thước đo tốt cho thời gian "thực tế". Nói cách khác, mọi người thường sẽ không gây rối với đồng hồ hệ thống, nhưng họ sẽ làm nếu bạn cho họ một lý do.

Có những cách biểu thị logic khác về thời gian: một trong số đó là phiên bản của phần mềm (ứng dụng của bạn hoặc một số phụ thuộc). Đây là một đại diện mong muốn cho "thời hạn" hơn là thời gian UNIX, vì nó cụ thể hơn với điều bạn quan tâm (thay đổi bộ tính năng / API) và do đó ít có khả năng chà đạp lên các mối quan tâm trực giao (ví dụ như thay đổi thời gian UNIX thành làm việc xung quanh thời hạn của bạn có thể sẽ phá vỡ các tệp nhật ký, công việc định kỳ, bộ nhớ cache, v.v.).

Như những người khác đã nói, nếu bạn kiểm soát thư viện và muốn "thúc đẩy" thay đổi này, bạn có thể đẩy một phiên bản mới làm mất tính năng (gây ra cảnh báo, để giúp người tiêu dùng tìm và cập nhật việc sử dụng), sau đó một phiên bản mới khác sẽ loại bỏ tính năng hoàn toàn. Bạn có thể xuất bản chúng ngay lập tức sau khi bạn thích, vì (một lần nữa) phiên bản chỉ là sự thể hiện logic của thời gian, chúng không cần phải liên quan đến thời gian "thực tế". Phiên bản ngữ nghĩa có thể giúp ở đây.

Mô hình thay thế là "kéo" sự thay đổi. Điều này giống như "kế hoạch B" của bạn: thêm một bài kiểm tra vào ứng dụng tiêu thụ, kiểm tra xem phiên bản của sự phụ thuộc này ít nhất là giá trị mới. Như thường lệ, red / green / refactor để truyền sự thay đổi này thông qua cơ sở mã. Điều này có thể phù hợp hơn nếu chức năng không "xấu" hoặc "sai", nhưng chỉ là "phù hợp xấu cho trường hợp sử dụng này".

Một câu hỏi quan trọng với phương pháp "kéo" là liệu phiên bản phụ thuộc có được tính là "đơn vị" ( của chức năng ) hay không, và do đó xứng đáng được thử nghiệm; hoặc cho dù đó chỉ là một chi tiết triển khai "riêng tư", chỉ nên được thực hiện như một phần của các bài kiểm tra đơn vị thực tế ( về chức năng ). Tôi muốn nói: nếu sự khác biệt giữa các phiên bản của phụ thuộc thực sự được tính là một tính năng của ứng dụng của bạn, thì hãy thực hiện kiểm tra (ví dụ: kiểm tra xem phiên bản Python có> = 3.x) không. Nếu không, thì đừngthêm bài kiểm tra (vì nó sẽ dễ vỡ, không chính xác và quá hạn chế); nếu bạn điều khiển thư viện thì đi xuống tuyến đường "đẩy". Nếu bạn không kiểm soát thư viện thì chỉ cần sử dụng bất kỳ phiên bản nào được cung cấp: nếu các bài kiểm tra của bạn vượt qua thì không đáng để tự giới hạn; nếu họ không vượt qua thì đó là "thời hạn" của bạn ngay tại đó!

Có một cách tiếp cận khác, nếu bạn muốn không khuyến khích sử dụng một số tính năng của phụ thuộc (ví dụ: gọi một số chức năng nhất định không hoạt động tốt với phần còn lại của mã), đặc biệt nếu bạn không kiểm soát phụ thuộc: cấm các tiêu chuẩn mã hóa của bạn / không khuyến khích việc sử dụng các tính năng này và thêm kiểm tra cho chúng cho kẻ nói dối của bạn.

Mỗi trong số này sẽ được áp dụng trong các trường hợp khác nhau.

Bạn quản lý này ở cấp độ gói hoặc thư viện. Bạn kiểm soát một gói và kiểm soát tầm nhìn của nó. Bạn được tự do rút lại tầm nhìn. Tôi đã thấy điều này trong nội bộ tại các công ty lớn và nó chỉ có ý nghĩa trong các nền văn hóa tôn trọng quyền sở hữu các gói ngay cả khi các gói là nguồn mở hoặc miễn phí sử dụng.

Điều này luôn luôn lộn xộn vì các nhóm khách hàng đơn giản là không muốn thay đổi bất cứ điều gì, vì vậy bạn thường cần một số vòng danh sách trắng - chỉ khi bạn làm việc với các khách hàng cụ thể để đồng ý về thời hạn di chuyển, có thể cung cấp hỗ trợ cho họ.

Một yêu cầu là đưa một khái niệm về thời gian vào bản dựng. Trong C, C ++ hoặc các ngôn ngữ / hệ thống xây dựng khác sử dụng bộ tiền xử lý giống như C ¹ , người ta có thể đưa ra dấu thời gian thông qua định nghĩa cho bộ tiền xử lý tại thời điểm xây dựng : CPPFLAGS=-DTIMESTAMP()=$(date '+%s'). Điều này có thể sẽ xảy ra trong một makefile.

Trong mã người ta sẽ so sánh mã thông báo đó và gây ra lỗi nếu hết thời gian. Lưu ý rằng việc sử dụng macro chức năng sẽ bắt được trường hợp mà ai đó không xác định TIMESTAMP.

#if TIMESTAMP() == 0 || TIMESTAMP() > 1520616626
#   error "The time for this feature has run out, sorry"
#endif

Ngoài ra, người ta có thể chỉ cần "xác định" mã được đề cập khi thời gian đến. Điều đó sẽ cho phép chương trình biên dịch, miễn là không ai sử dụng nó. Giả sử, chúng tôi có một tiêu đề xác định một api, "api.h" và chúng tôi không cho phép gọi old()sau một thời gian nhất định:

//...
void new1();
void new2();
#if TIMESTAMP() < 1520616626
   void old();
#endif
//...

Một cấu trúc tương tự có thể sẽ loại bỏ phần old()thân của hàm khỏi một số tệp nguồn.

Tất nhiên đây không phải là bằng chứng ngu ngốc; người ta có thể chỉ cần định nghĩa một cái cũ TIMESTAMPtrong trường hợp xây dựng khẩn cấp tối thứ sáu được đề cập ở nơi khác. Nhưng đó là, tôi nghĩ, khá thuận lợi.

Điều này rõ ràng chỉ hoạt động khi thư viện được biên dịch lại - sau đó mã lỗi thời không còn tồn tại nữa trong thư viện. Nó sẽ không ngăn chặn mã máy khách liên kết đến các tệp nhị phân lỗi thời.

Trong Visual Studio, bạn có thể thiết lập một tập lệnh dựng sẵn gây ra lỗi sau một ngày nhất định. Điều này sẽ ngăn chặn việc biên dịch. Đây là tập lệnh đưa ra lỗi vào hoặc sau ngày 12 tháng 3 năm 2018 ( lấy từ đây ):

@ECHO OFF

SET CutOffDate=2018-03-12

REM These indexes assume %DATE% is in format:
REM   Abr MM/DD/YYYY - ex. Sun 01/25/2015
SET TodayYear=%DATE:~10,4%
SET TodayMonth=%DATE:~4,2%
SET TodayDay=%DATE:~7,2%

REM Construct today's date to be in the same format as the CutOffDate.
REM Since the format is a comparable string, it will evaluate date orders.
IF %TodayYear%-%TodayMonth%-%TodayDay% GTR %CutOffDate% (
    ECHO Today is after the cut-off date.
    REM throw an error to prevent compilation
    EXIT /B 2
) ELSE (
    ECHO Today is on or before the cut-off date.
)

Hãy chắc chắn đọc các câu trả lời khác trên trang này trước khi sử dụng tập lệnh này.

Tôi hiểu mục tiêu của những gì bạn đang cố gắng làm. Nhưng như những người khác đã đề cập, hệ thống xây dựng / trình biên dịch có lẽ không phải là nơi thích hợp để thực thi điều này. Tôi muốn đề xuất lớp tự nhiên hơn để thực thi chính sách này là SCM hoặc biến môi trường.

Nếu bạn thực hiện sau, về cơ bản hãy thêm một cờ tính năng đánh dấu một lần chạy trước khấu hao. Mỗi khi bạn xây dựng lớp không dùng nữa hoặc gọi một phương thức không dùng nữa, hãy kiểm tra cờ tính năng. Chỉ cần xác định một hàm tĩnh duy nhất assertPreDeprecated()và thêm hàm này vào mọi đường dẫn mã không dùng nữa. Nếu nó được đặt, bỏ qua các cuộc gọi khẳng định. Nếu nó không ném vào một ngoại lệ. Khi ngày trôi qua, bỏ đặt cờ tính năng trong môi trường thời gian chạy. Bất kỳ cuộc gọi không được chấp nhận kéo dài tới mã sẽ hiển thị trong nhật ký thời gian chạy.

Đối với giải pháp dựa trên SCM, tôi sẽ cho rằng bạn đang sử dụng git và git-Flow. (Nếu không, logic có thể dễ dàng thích ứng với các VCS khác). Tạo một nhánh mới postDeprecated. Trong nhánh đó xóa tất cả các mã không dùng nữa và bắt đầu làm việc với bất kỳ tham chiếu nào cho đến khi nó biên dịch. Bất kỳ thay đổi bình thường tiếp tục thực hiện cho masterchi nhánh. Tiếp tục hợp nhất mọi thay đổi mã không liên quan mastertrở lại postDeprecatedđể giảm thiểu các thách thức tích hợp.

Sau khi ngày khấu hao kết thúc, tạo một preDeprecatedchi nhánh mới từ master. Sau đó hợp nhất postDeprecatedtrở lại vào master. Giả sử bản phát hành của bạn rời khỏi masterchi nhánh, bây giờ bạn sẽ sử dụng chi nhánh sau đó không dùng nữa sau ngày. Nếu có trường hợp khẩn cấp hoặc bạn không thể cung cấp kết quả kịp thời, bạn luôn có thể quay lại preDeprecatedvà thực hiện bất kỳ thay đổi cần thiết nào trên chi nhánh đó.