Gelecek prova kodu

Çalıştığım yerde geliştiriciler bana her zaman "Bunu gelecek için ekledim" ya da "Sanırım bunu yapmanın iyi bir fikir olduğunu düşünüyorum çünkü muhtemelen bir gün isteyecekler". Gelecekteki değişimleri önceden tahmin etmede proaktif olmalarının harika olduğunu düşünüyorum ama gereksiz olduğunu ve asla gerekli olmayacak kod yazmanın riskli olduğunu düşünmemize yardımcı olamıyorum, bu yüzden verimsiz (ayrıca bazı geliştiricilerin sadece bir şeyler denemek istediğini düşünüyorum) onun iyiliği için yeni). Yalnızca iyi ve temiz bir şekilde düzenlenmiş bir kod yazarsanız, ileride yapılacak provalara ilişkin argümanlar geçersiz midir?

Öncelikle, açıklığa kavuşturulması gereken bazı şeyler var:

• Gelecek provası bir şeyler eklemek değildir .
• Gelecekteki prova, mevcut işlevleri bozmadan kolayca kod / özellik ekleyebilmenizi sağlar.

Bu, "gelecekteki kanıt" kodunun yazılmasının, kodun gevşek bir şekilde, yeterince soyut değil, aynı zamanda soyutlama seviyelerini tamamen gizlemeyen bir kodla yazılmasını sağlaması anlamına gelir, bu nedenle her zaman daha düşük soyutlama seviyelerine gitmenin bir yolu vardır. Eğer gerekliyse.

Gelecekteki ispat kodunun yazılması başlı başına bir sanattır ve bileşen sürümleme, endişelerin ayrılması, işlevsellik katmanlaması ve soyutluğa yönelik SOLID uygulamalarıyla sıkı sıkıya bağlıdır. Gelecekteki provaların zamanın önündeki özelliklerin eklenmesiyle bir ilgisi yoktur, ancak mevcut kod / kütüphanelerin iyi tasarımıyla gelecekte özellikleri eksiz bir şekilde ekleyebilirsiniz .

Benim 2c

Uzun süre kullanılmayacak kodları yazmayın. Büyük olasılıkla o sırada ihtiyaçlarınızı karşılamayacağından (tanımı gereği henüz bilmediğiniz) faydasız olacaktır.

Kodun zarif bir şekilde kurtarılmasını veya hızlı bir şekilde kurtarılmasını sağlayan beklenmeyen sorun durumlarına karşı dayanıklı olmasını sağlayın, ancak gelecekteki olası kullanımlar için kod yazmayın.

Bunu sağlamanın iyi bir yolu, test odaklı tasarım ve geliştirme kullanmaktır. Test durumları şartname ve kullanım durumlarından türetilmiştir. Tüm kod bir test geçişi yapmalıdır. Gereksiz kodlar yazılmamalıdır. Bu şekilde yaparak, gerekli olup olmadığını belirlemek kolaydır.

Gelecekte kodun kanıtlanması ve gelecekte ihtiyaç duyulması halinde kod yazmanın iki farklı şey olduğunu anlamak önemlidir . İlki iyi bir uygulama için çok önemlidir, daha az genellikle iyi kodlama uygulaması değildir.

• Benim için, kodu geleceğe dair kanıtlamak, gelişen teknolojilerle etkileşime girebilecek şekilde yazıyor. Bu, kodunuzu modülerleştirmeyi içerir, böylece uygulamanızın her bir kısmı, uygulamanın dili ve teknolojisinden bir bütün olarak bağımsız olarak etkileşime girebilir. Buna güzel bir örnek, uygulamanın farklı bölümleri arasında veri iletmek için XML veya JSON kullanmak olabilir. Ancak teknoloji geliştikçe, XML ve JSON'u her zaman okuyabileceği çok muhtemeldir.

• Yukarıdakilere benzer şekilde, uygulamanızın bir bölümünü bir SOAP veya REST API üzerinden göstermek de aynı şeyi sağlar. Hangi teknolojiler geliştiyse gelişsin, uygulamanın her bölümünü tekrar yazmana gerek kalmayacak, çünkü yeni teknolojiler eskiyle iletişim kurabilecektir.

• Gerekirse kod yazma noktasında kodun çok az test yapması veya hiç test yapmaması muhtemel olduğu için çok tehlikeli olduğunu düşünüyorum.

Bu nedenle, elbette, gelecekteki kodların kanıtını yapın (NASA hala Fortran kullanarak uzay gemileri gönderir), ancak 'sadece durumda' kodunu yazmayın.

Bir üretim ortamında ne kadar süre boyunca kodun bir kodunu etkinleştirdiğinizi ve "2 yıl önce yazdığın için şükürler olsun!" Diye düşünün.

Kod kolayca değiştirilebilir / genişletilebilir olmalıdır. Hemen gerekmeyen bir kod eklemeyin, çünkü bu çok yanlış bir güvenlik hissi verir ve değişen gereksinimler dünyasında geliştirme / test kaynaklarını boşa harcar.

Diğer cevapların çoğu daha büyük tasarım konularını ele alıyor ya da oldukça soyut. Gelecekte ne olacağını düşünürseniz , kodu geleceğe hazırlamanıza yardımcı olacak bazı açık teknikleri tanımlayabilirsiniz .

Öncelikle gelecekte kodun bir özellik eklemeye çalışacağını veya kodunuzu başka bir yerde tekrar kullanmaya çalışacağını düşünün. Ayrıca koddaki bir özelliği düzeltmeyi deneyebilirler. Açıkçası, sadece iyi temiz kodlara sahip olmak gerekli bir başlangıç ​​noktasıdır, ancak yapılabilecek bazı özel teknikler de vardır.

Defansif Programlama : Mevcut uygulamanın gerçekten ihtiyaç duyduğu şeyin ötesinde giriş kontrolü yapın. API'leri her çağırdığınızda, girişlerinin beklediğiniz bir şey olup olmadığını kontrol ettiğinizden emin olun. Gelecekte insanlar yeni kod sürümlerini bir araya getirecekler, bu nedenle hataların ve API iadelerinin kapsamı şu anki durumdan farklı olacaktır.

Tanımsız Davranışı Ortadan Kaldır : Pek çok kod, bir şekilde gelişen bir davranışa sahiptir. Bazı girdi kombinasyonları, hiç kimsenin gerçekten istemediği ancak gerçekleşen kesin çıktıya yol açar. Şimdi kaçınılmaz olarak birileri bu davranışa güvenecek, ancak tanımlanmadığı için kimse bunu bilemeyecek. Gelecekte davranışını değiştirmeye çalışan herkes, istemeden bir şeyleri bozacaktır. Şimdi güvenlik kontrollerini kullanın ve kodun tanımsız tüm kullanımlarını kaldırmaya / engellemeye çalışın.

Otomatik Test Paketi : Ünite testlerine duyulan ihtiyaç hakkında yazılmış birimler bulabileceğinize eminim. Ancak gelecekteki provalara atıfta bulunmak suretiyle, birisinin kodu yeniden düzenlemesine izin vermede kritik bir nokta vardır. Yeniden düzenleme, temiz kodu sağlamak için gereklidir, ancak iyi bir test paketi yoksa, güvenli bir şekilde yeniden denetleyici kuramazsınız.

Yalıtım ve Ayrıştırma : Kapsülleme ve uygun modülerleştirme iyi bir tasarım ilkesidir, ancak bunun ötesine geçmeniz gerekir. Genellikle, şüpheli bir geleceği olabilecek bir kütüphane veya API veya ürün kullanmanız gerektiğini göreceksiniz. Belki de kalite kaygıları, lisans sorunları veya yazarların geliştirmeye devam etmeleri nedeniyle. Bu durumlarda, siz ve bu kod arasına bir katman koymak için ekstra zaman ayırın. İhtiyacınız olan şey için API'yi aşağı kaydırın, böylece gelecekte daha kolay bir değişim sağlamak için bağlantı çok düşüktür.

İyi, temiz, iyi organize edilmiş kod , değişikliklerin ve eklemelerin doğru şekilde uygulanmasını kolaylaştırması açısından geleceğe yöneliktir.

En iyi ihtimalle "Gelecek Kanıtı", "gevşek bağlantılı tasarım" anlamına gelir. İnsanların zamanının% 80'i "gelecek kanıtı" derken "esnek" anlamına geliyor. Bazen kulağa hoş geldiğini söylemeye çalışıyorlar. Ama en azından işe yarayan zamanında bir şeyler veriyorlar.

En kötü ihtimalle "Gelecek Kanıtı" anlamsız. Zamanın% 20'si, basitçe bir şey sunmak yerine alternatif teknolojileri araştırmakla zaman kaybetmek için bir bahane. Hiçbir şey teslim etmiyorlar (ya da teslim ettikleri şey eldeki sorun için çok karmaşık.)

İki kenar davası var.

1. Başarısız öngörü. İnsan aslında geleceği doğru şekilde tahmin edebilir . Bu durumda, lütfen kodu geleceğe gösteren bu güçlü öngörüyü uygulayın. Daha iyisi, piyasa trendlerini tahmin etmek ve erken emekli olmak ve kodlamayı durdurmak için başarısız olan öngörüleri uygulayın.

2. Biri geleceği "sürmek". Diğer bir deyişle, gelecekte dağıtılmaya hazır olan şeylerin yeniden yazılmasını gerektirecek yeni teknolojiler mevcut. İlk önce bu güzel gelecek olayını konuşmamak çok garip.

   "A" projesinin derhal "A" nın yeniden yazılmasına yol açacağını bilerek "A" projesini teslim etmeliyiz. Sadece bu durumda, gelecekte "A" ispatını yapabiliriz.

YAGNI = İhtiyacınız olmayacak .

İçgüdüleriniz doğrudur: kodları gereksizdir, bir bakım ve test yükü ekler ve somut bir iş değeri olmayan şeylere zaman harcar.

Ayrıca Bakınız: Altın Kaplama .

Sorunun başlığını görmezden gelmek ve "bir gün birileri isteyebileceği için bir şeyler koymak" konusunda asıl konuya dikkat çekmek ...

Cevap hayır. Asla. Bugün ihtiyacınız olmayan bir kod dikiş yazmayın. İşte nedeni:

1. Program şimdi olması gerekenden daha karmaşık.
2. Özelliğe asla ihtiyacınız olmayabilir, bu yüzden zamanınızı boşa harcarsınız.
3. Gelecekte birileri bunun için sorarsa, bu özelliğin gereksinimlerinin ne olacağını bilmiyorsunuz. Bu yüzden, onu anlamak ve değiştirmek zorunda kalacaksınız.

Bence ilk nokta en önemlisi. Farklı müşteriler için genel kodla bağdaştırılmış bir sistemle çalıştıysanız veya gerek duymadığınız özelliklerle doluysa, o zaman işlevselliği korumak veya genişletmek için ne kadar zaman ve emek harcayacağınızı bilirsiniz. söyledi. Bu yüzden ne pahasına olursa olsun kaçının.