Kaldırılan kodun bir son tarihe ulaştıktan sonra derlemesini engelleyin [kapalı]

Ekibimde büyük bir yekpare projede (tüm sınıflar, yöntemler vb.) Birçok eski şeyi temizliyoruz.

Bu temizlik işleri sırasında normalden bir çeşit ek not mu yoksa kütüphane meraklısı mı olduğunu merak ediyordum @Deprecated. Bu @FancyDeprecated, belirli bir tarih geçtikten sonra eski kullanılmayan kodu temizlemediyseniz, projenin oluşturulmasının başarılı olmasını engellemelidir.

İnternette arama yapıyorum ve aşağıda açıklanan özelliklere sahip hiçbir şey bulamadım:

• Belirli bir tarihten önce silmeyi planladığınız koda yerleştirmek için bir ek açıklama veya benzeri bir şey olmalıdır
• bu tarihten önce kod derlenecek ve her şey normal şekilde çalışacaktır
• Bu tarihten sonra kod derlenmeyecek ve size sorun hakkında sizi uyaracak bir mesaj verecektir.

Tek boynuzlu at arıyorum düşünüyorum ... Herhangi bir program dili için benzer bir teknoloji var mı?

Bir plan olarak BI, "son tarih" de başarısız olmaya başlayan, kaldırılması amaçlanan kodun bazı birim testleriyle sihir yapma olasılığını düşünüyorum. Bunun hakkında ne düşünüyorsun? Daha iyi bir fikrin var mı?

Derlemeyi yasakladığında bunun yararlı bir özellik olacağını sanmıyorum. 01/06/2018 tarihinde, bir gün önce derlenen kodun büyük bölümleri derlenmezse, ekibiniz bu açıklamayı tekrar kaldıracak, kod temizlenmiş veya temizlenmeyecek.

Ancak, gibi koda bazı özel açıklamalar ekleyebilirsiniz.

@Deprecated_after_2018_07_31

ve bu ek açıklamaları taramak için küçük bir araç oluşturun. (Eğer yansıma kullanmak istemiyorsanız, grep'teki basit bir astar bunu yapacaktır). Java dışındaki dillerde, "grepping" için uygun standart bir yorum ya da önişlemci tanımı kullanılabilir.

Ardından bu aracı belirli bir tarihten kısa bir süre önce veya sonra çalıştırın ve yine de bu açıklamayı bulursa, ekibe derhal bu kod bölümlerini temizlemesini hatırlatın.

Bu, saatli bomba olarak bilinen bir özelliktir . ZAMAN BOMBALARI OLMAYIN.

Kod olursa olsun yapılandırmak ve bunu belgelemek ne kadar iyi, olacak belli yaştan sonra yaşıyorsa bir kötü anlaşılmış neredeyse mitolojik kara kutu dönüşür. Gelecekte ihtiyaç duyan herhangi birinin ihtiyacı olan son şey, onları tamamen şaşırtan, en kötü zamanda ve bariz bir çare olmadan tamamen yakalayan başka bir garip başarısızlık modudur. Kasıtlı olarak böyle bir sorun üretmenin hiçbir bahanesi yoktur.

Şuna şöyle bak: Eğer eskimeye değer verdiğin ve onu takip edebileceğin kadar kod temelinin farkında ve örgütlüysen, sana hatırlatmak için kodun içinde bir mekanizmaya ihtiyacın yok . Olmazsa, olasılıklar, kod tabanının diğer yönleri hakkında da güncel olmamanızdır ve muhtemelen alarma zamanında ve doğru şekilde yanıt veremeyeceksiniz. Başka bir deyişle, saatli bombalar kimse için iyi bir amaca hizmet etmiyor. Sadece hayır de!

C # ObsoleteAttribute'da aşağıdaki şekilde kullanırsınız:

• Sürüm 1'de, özelliği gönderirsiniz. Bir yöntem, sınıf, her neyse.
• Sürüm 2'de, orijinal özelliği değiştirmeyi amaçlayan daha iyi bir özellik sunarsınız. Özelliğe bir Obsolete niteliği koydunuz, "uyarı" olarak ayarladınız ve "Bu özellik kullanımdan kaldırılmış. Bunun yerine daha iyi bir özellik kullanın. Bu kitaplığın 3. sürümünde, böyle bir sürümde çıkacak bir tarih, bu özelliğin kullanımı bir hata olacaktır. " Artık özellik kullanıcıları hala kullanabilir, ancak yeni özelliği kullanmak için kodlarını güncellemek için zamanları var.
• Sürüm 3’de, bir uyarı yerine bir hata olarak özniteliği günceller ve "Bu özellik kullanım dışıdır. Bunun yerine daha iyi bir özellik kullanın." Bu kitaplığın 4. sürümünde, bu tür bir sürümde yayınlanacak Bir tarih, bu özellik atar. " Önceki uyarınıza aldırmayan kullanıcılar hala, sorunu nasıl çözeceklerini söyleyen yararlı bir mesaj almaya devam ediyor ve düzeltmeleri gerekiyor çünkü kodları derlenmiyor.
• 4. sürümde, özelliği bazı önemli istisnalar atacak şekilde değiştirirsiniz ve özelliğin bir sonraki sürümde tamamen kaldırılacağını söylemek için mesajı değiştirirsiniz.
• 5. sürümde, bu özelliği tamamen kaldırırsınız ve kullanıcılar şikayet ederse, iyi hey, onlara üç sürüm adil uyarı döngüsü verdiniz ve güçlü bir şekilde hissediyorlarsa sürüm 2'yi kullanmaya devam edebilirler.

Buradaki fikir, etkilenen kullanıcılar için mümkün olduğunca acısız bir kırılma değişikliği yapmak ve bu özelliği kütüphanenin en az bir sürümü için kullanmaya devam edebilmelerini sağlamaktır.

"Onaylanmayan" ın ne anlama geldiğini yanlış anladınız. Kullanımdan kaldırılmış demektir:

Kullanılabilir olmak, ancak eski haline getirilmiş olması nedeniyle eski ve en iyi şekilde kaçınılması olarak kabul edilir.

_{Oxford Sözlükleri}

Tanımı gereği, kullanımdan kaldırılmış bir özellik yine de derlenir.

Özel bir tarihte özelliği kaldırmak istiyor . Bu iyi. Bunu yapma şekliniz, o tarihte kaldırmanızdır .

O zamana kadar kullanımdan kaldırılmış, eski veya programlama diliniz ne diyorsa onu işaretleyin. Mesaja, çıkartılacağı tarihi ve yerini alacak olanı ekleyin. Bu, diğer geliştiricilerin yeni kullanımlardan kaçınmaları ve mümkün olduğunca eski kullanımların yerine geçmesi gerektiğini belirten uyarılar üretecektir. Bu geliştiriciler buna uyacak ya da görmezden gelecekler ve biri çıkarıldığında bunun sonuçlarını ele almak zorunda kalacak. (Duruma bağlı olarak, siz olabilir veya onu kullanan geliştiriciler olabilir.)

Unutmayın, daha önce piyasaya sürülen yazılım sürümlerini desteklemek için kodun eski sürümlerini oluşturma ve hata ayıklama özelliğini elinizde bulundurmanız gerekir. Belirli bir tarihten sonra bir yapının sabote edilmesi, ayrıca gelecekte meşru bakım ve destek çalışmaları yapmanıza engel olacağınız anlamına gelir.

Ayrıca, derleme işlemimden önce makinemin saatini bir veya iki yıl öncesine ayarlamak çok basit bir çözüm gibi görünüyor.

Unutmayın, "itiraz", gelecekte bir şeylerin ortadan kalkacağına dair bir uyarıdır. İnsanların bu API'yi kullanmalarını zorla önlemek istediğinizde , ilgili kodu kaldırmanız yeterlidir . Bazı mekanizmalar kullanılmaz hale gelirse kod tabanında kod bırakmanın anlamı yoktur. Kodun kaldırılması, aradığınız derleme zamanı denetimlerini size verir ve önemsiz bir geçici çözüm bulunmaz.

Düzenleme: Sorunuzda "eski kullanılmayan kod" bölümüne bakın. Eğer kod gerçekten kullanılmamışsa , kullanımdan kaldırmanın anlamı yoktur. Sadece sil.

Daha önce böyle bir özellik görmemiştim - belirli bir tarihten sonra yürürlüğe giren bir açıklama.

Ancak @Deprecated, bu yeterli olabilir. CI'deki uyarıları yakalayın ve varsa yapıyı kabul etmeyi reddetmesini sağlayın. Bu, sorumluluğu derleyiciden derleme hattınıza kaydırır, ancak ek adımlar ekleyerek derleme hattınızı kolayca değiştirebilmeniz (yarı) yapabilirsiniz.

Bu yanıt unutmayın gelmez (örneğin yerel uyarılarla rağmen, yine de başarılı olur geliştiricinin makinasında üzerine inşa) tam sorunu çözmek ve bir CI boru hattı kurmak ve çalışır durumda olduğunu varsayar.

Takvimler veya yapılacaklar listesi arıyorsunuz .

Başka bir alternatif, kod tabanınızda herhangi bir uyarı varsa çok azına sahip olmayı başarırsanız, özel derleyici uyarıları veya derleyici mesajları kullanmaktır. Çok fazla uyarınız varsa, ilave çaba harcamanız (yaklaşık 15 dakika?) Ve sürekli entegrasyonunuzun her bir yapıda sağladığı derleme raporunda derleyici uyarısını almanız gerekir .

Kodun düzeltilmesi gerektiği hatırlatmaları iyi ve gerekli Bazen bu hatırlatıcıların gerçek dünyadaki son tarihleri ​​katıdır, bu yüzden onları bir zamanlayıcıya koymak da gerekli olabilir.

Amaç, insanlara konunun var olduğunu ve belirli bir zaman diliminde düzeltilmesi gereken şeyleri sürekli olarak hatırlatmaktır - yapıyı belirli bir zamanda basitçe bozan bir özellik, yalnızca bunu yapmakla kalmaz belirli bir zaman diliminde düzeltilmek.

Bunu düşünmenin bir yolu, zaman / tarih ile ne demek istediğinizi ? Bilgisayarlar bu kavramların ne olduğunu bilmiyor: bir şekilde programlanmaları gerekiyor. Bu oldukça yaygındır temsil "Dönemden beri saniye" nin UNIX formatında kez ve OS görüşmesi ile bir programa belirli bir değer beslemek için yaygındır. Ancak, bu kullanım ne kadar yaygın olursa olsun, "gerçek" zaman olmadığını unutmamak önemlidir: bu sadece mantıklı bir sunumdur.

Diğerlerinin de belirttiği gibi, bu mekanizmayı kullanarak bir "son tarih" koyduysanız, farklı bir zamanda beslemek ve bu "son tarihi" kırmak önemsizdir. Aynı şey, NTP sunucusuna soru sorma gibi daha ayrıntılı mekanizmalar için de geçerlidir ("güvenli" bir bağlantı üzerinden bile, çünkü kendi sertifikalarımızı, sertifika otoritelerini değiştirebilir veya kripto kütüphanelerini ekleyebiliriz). İlk başta, bu tür bireylerin mekanizmanız üzerinde çalışmak için hatalı oldukları görünebilir, ancak otomatik olarak yapılması ve iyi nedenlerden dolayı olabilir . Örneğin, yeniden üretilebilir yapılara sahip olmak ve bunun deterministik olmayan sistem çağrılarını otomatik olarak sıfırlayabilmesi / engellemesine yardımcı olacak araçlar olması iyi bir fikirdir . libfaketime tam olarak bunu yapar,tüm dosyanın zaman damgalarını ayarlar 1970-01-01 00:00:01; Qemu'nun kayıt / tekrar oynatma özelliği tüm donanım etkileşimlerini vb. taklit eder.

Bu, Goodhart yasasına benzer : bir programın davranışını mantıksal zamana bağlı olarak yaparsanız, mantıksal zaman "gerçek" zamanın iyi bir ölçütü olmaktan çıkar. Başka bir deyişle, insanlar genellikle sistem saatiyle uğraşmazlar, ancak onlara bir sebep verirseniz derler.

Zamanın başka bir mantıksal temsili vardır: bunlardan biri yazılımın sürümüdür (uygulamanız veya bazı bağımlılıklar). Bu, örneğin UNIX zamanından daha "son tarih" için daha çok istenen bir temsildir, çünkü önemsediğiniz şeye özgüdür (özellik kümelerini / API'leri değiştirme) ve bu nedenle ortogonal kaygıları çiğneme olasılığı daha düşüktür (örneğin, UNIX zamanına uyma gibi) son teslim tarihini aşmak, günlük dosyalarının, cron işlerinin, önbelleklerin vb.

Diğerlerinin dediği gibi, kütüphaneyi kontrol ediyorsanız ve bu değişikliği "zorlamak" istiyorsanız, özellikleri kullanımdan kaldıran yeni bir sürümü (tüketicilerin kullanımlarını bulmasına ve güncellemesine yardımcı olmak için uyarılara neden olur) itip, tamamen özellikleri. İsterseniz (hemen sonra) sürümler yalnızca zamanın mantıksal bir gösterimi olduğundan, "gerçek" zamanla ilgili olmaları gerekmiyorsa, bunları hemen sonra yayınlayabilirsiniz. Anlamsal versiyonlama burada yardımcı olabilir.

Alternatif model, değişikliği "çekmek" tir. Bu sizin "B planınız" gibidir: Tüketici uygulamasına bir test ekleyin; bu bağımlılık sürümünün en azından yeni değer olduğunu kontrol eder. Her zamanki gibi, bu değişikliği kod tabanından yaymak için kırmızı / yeşil / refactor. İşlevsellik "kötü" veya "yanlış" değilse, sadece "bu kullanım durumu için uygun" ise, bu daha uygun olabilir.

"Çekme" yaklaşımıyla ilgili önemli bir soru, bağımlılık sürümünün bir "birim" ( işlevsellik ) olarak sayılıp sayılmadığıdır ve bu nedenle test etmeyi hak eder; ya da sadece gerçek birim ( işlevsellik ) testlerinin bir parçası olarak yapılması gereken sadece “özel” bir uygulama detayı olup olmadığı . Diyelim ki: Bağımlılığın sürümleri arasındaki fark gerçekten uygulamanızın bir özelliği olarak sayılıyorsa, testi yapın (örneğin, Python sürümünün> = 3.x olduğunu kontrol edin). Eğer değilse, o zaman yapmatesti ekleyin (kırılgan, bilgisiz ve aşırı kısıtlayıcı olacağından); Kütüphaneyi kontrol ediyorsanız "basma" rotasından aşağı inin. Kütüphaneyi kontrol etmezseniz, sağlanan sürümleri kullanın: testleriniz başarılı olursa kendinizi sınırlandırmaya değmez; eğer geçemezlerse, işte oradaki "son tarihin" budur!

Bir bağımlılığın özelliklerinin belirli kullanımlarından vazgeçmek istiyorsanız (örneğin, kodunuzun geri kalanıyla iyi çalışmayan bazı işlevleri arama), özellikle bağımlılığı kontrol etmiyorsanız başka bir yaklaşım daha vardır: kodlama standartlarınızı yasaklayın. / bu özelliklerin kullanımını engeller ve onlar için linter'ınıza kontroller ekler.

Bunların her biri farklı durumlarda geçerli olacaktır.

Bunu paket veya kütüphane düzeyinde yönetiyorsunuz. Bir paketi kontrol ediyorsun ve görünürlüğünü kontrol ediyorsun. Görünürlüğü geri çekmekte özgürsün. Bunu dahili olarak büyük şirketlerde gördüm ve yalnızca açık kaynak kodlu veya kullanımı ücretsiz olsa bile, paketlerin sahipliğine saygı duyan kültürlerde mantıklı geliyor.

Bu her zaman dağınıktır çünkü müşteri ekipleri hiçbir şeyi değiştirmek istemez, bu nedenle çoğu zaman yalnızca belirli listeye ihtiyaç duyarsınız - yalnızca belirli müşterilerle birlikte çalışmak için son tarih konusunda uzlaşmak için anlaşırsınız, muhtemelen onlara destek sunar.

Bir gereklilik, yapıya bir zaman kavramı getirmektir. C, C ++, ya da diğer diller / C benzeri bir önişlemci kullanan sistemleri kurmak ¹ , tek bir yapı anda önişlemci için tanımlayıp aracılığıyla bir zaman damgası getirebilir: CPPFLAGS=-DTIMESTAMP()=$(date '+%s'). Bu büyük olasılıkla bir makefile olur.

Kodda biri belirteçle karşılaştırır ve zaman doluysa hataya sebep olur. Bir işlev makrosu kullanmanın birinin tanımlamadığı durumu yakaladığını unutmayın TIMESTAMP.

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

Alternatif olarak, kişi zamanı geldiğinde söz konusu kodu "tanımlayabilir". Bu, hiç kimsenin kullanmaması şartıyla programın derlenmesini sağlayacaktır. Diyelim ki, api, "api.h" yi tanımlayan bir başlığımız var ve old()belirli bir süre sonra arama yapmaya izin vermiyoruz :

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

Benzer bir yapı muhtemelen old()işlev gövdesini bir kaynak dosyadan kaldırır .

Tabii ki bu aptal kanıtı değil; Birisi, TIMESTAMPbaşka bir yerde bahsedilen Cuma gecesi acil durum inşaatı durumunda eskileri tanımlayabilir . Fakat bence oldukça avantajlı.

Bu açıkça, yalnızca kitaplık yeniden derlendiğinde çalışır - bundan sonra eski kod yalnızca kitaplıkta bulunmaz. O olur değil ama eskimiş ikili bağlantı istemci kodu engeller.

Visual Studio'da, belirli bir tarihten sonra hata veren bir derleme öncesi komut dosyası oluşturabilirsiniz. Bu derlemeyi önleyecektir. İşte 12 Mart 2018 (veya sonrasında bir hata atar bir senaryo burada alınan ):

@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.
)

Bu betiği kullanmadan önce bu sayfadaki diğer cevapları okuduğunuzdan emin olun.

Yapmaya çalıştığın şeyin amacını anlıyorum. Ancak diğerlerinin de belirttiği gibi, derleme sistemi / derleyici muhtemelen bunu uygulamak için doğru yer değildir. Bu politikayı uygulamak için daha doğal bir katmana SCM veya ortam değişkenleri olduğunu söyleyebilirim.

İkincisini yaparsanız, temel olarak bir amortisman öncesi çalışmasını işaretleyen bir özellik bayrağı ekleyin. Kullanımdan kaldırılmış sınıfı oluşturduğunuzda veya kullanımdan kaldırılmış bir yöntem çağırdığınızda, özellik bayrağını kontrol edin. Tek bir statik işlev tanımlayın assertPreDeprecated()ve bunu kullanımdan kaldırılan her kod yoluna ekleyin. Ayarlandıysa, assert aramalarını yoksayın. Bir istisna atmazsa. Tarih geçtikten sonra, çalışma zamanı ortamında özellik bayrağını ayarlayın. Kodda kalan herhangi bir kullanımdan kaldırılmış çağrı, çalışma zamanı günlüklerinde görünecektir.

SCM tabanlı bir çözüm için git ve git-flow kullandığınızı varsayacağım. (Değilse, mantık kolayca diğer VCS'lere uyarlanabilir). Yeni bir dal oluşturun postDeprecated. Bu dalda tüm kullanımdan kaldırılan kodu silin ve derleninceye kadar tüm başvuruları kaldırma üzerinde çalışmaya başlayın. Herhangi bir normal değişiklik masterdalda yapmaya devam eder . Entegrasyon zorluklarını en aza indirmek için kullanımdan kaldırılmayan tüm ilgili kod değişikliklerini mastertekrar birleştirmeye devam edin postDeprecated.

İtiraz tarihi sona erdikten sonra, içinden yeni bir preDeprecateddal oluşturun master. Sonra postDeprecatedtekrar birleştirmek master. Serbest bırakılmanın masterşubeden ayrıldığını varsayarsak, artık tarihten sonra kullanımdan kaldırılan şubeyi kullanıyor olmalısınız. Acil bir durum varsa veya sonuçları zamanında teslim edemezseniz, her zaman geri dönebilir preDeprecatedve bu dalda gerekli değişiklikleri yapabilirsiniz.