Eski Yasayı İyileştirme Sorumluluğumuz Var mı?

Yazdığım bazı eski kodlara bakıyordum. Çalışıyor, ama harika bir kod değil. Şu anda bildiğimden daha fazla şey biliyorum, o yüzden onu daha iyi hale getirebilirim. Bu mevcut bir proje değil, ama mevcut, çalışıyor, üretim kodu. Geri dönüp geçmişte yazmış olduğumuz kodu iyileştirme sorumluluğumuz var mı, yoksa "kırılmadıysa, düzeltmeyin" şeklindeki doğru tutum mu? Şirketim birkaç yıl önce bir kod inceleme sınıfına sponsor oldu ve en büyük paket servislerden biri, bazen yeterince iyi olmasıydı; Devam et.

Öyleyse, bir noktada yeterince iyi çağırmalı ve devam etmeli mi, yoksa daha iyi olacağını düşündüğünüzde eski kodu geliştirmek için projeleri zorlamaya mı çalışmalısınız?

Hataları düzeltmek veya özellikler eklemek için bu "eski kod" da değişiklik yapmadığınız sürece, sadece bunun uğruna iyileştirme konusunda canınızı sıkmazdım. Sonunda geliştirmek istiyorsanız, yeniden düzenlemeye başlamadan önce kodu test edecek birim testlerinin yapıldığından emin olun.

Daha iyi uygulamaları öğrenmek için "eski kodu" kullanabilirsiniz. Bunu yaparsanız, yarı zamanlı bir öğrenme deneyimidir ve bu kodun şu anda serbest bırakılmış veya müşteriler / müşteriler tarafından dağıtılanları değiştirmesini beklememelisiniz.

Refactor en sık değiştirmek istediğiniz kod alanlarını yeniden düzenleyin . Bu bölgeleri sık sık ziyaret ettiğiniz için, yeniden yapılandırma, onları tekrar ziyaret etmeniz gerektiğinde kod ve okunabilirlik hakkındaki bilgilerinizi geliştirir, ancak yeniden inceleme kodunun başka hiç kimsenin bakmayacağı bir şey yoktur.

Üstelik, yalnızca kod alanlarını değiştirmeniz gerektiğinde onları yeniden yapılandırmanız durumunda, yeniden yapılandırmanızın gerilemeye neden olması durumunda size geçerli bir bahane verir . Tabii ki, yeniden yapılanmalarınızı birim testleriyle örtmeye çalışın, ancak bu her zaman mümkün değildir, özellikle de eski kodla ve büyük yeniden yapılanmaların her seferinde gerileme yaratmasını beklemelisiniz.

Özellikler eklemeniz gerekiyorsa ve tasarımınız sizi yavaşlatıyor veya çoğaltmaya neden oluyorsa, yeniden düzenleyici yapın . Kod tasarladığımda, gelecekte hiçbir zaman tam olarak hangi değişikliklerin gerekli olacağını tahmin etmiyorum. Ancak, yeni özellikler eklediğimde, genellikle paylaşılan kodu yeniden düzenlemeyi bırakıyorum. Zamana, üçüncü bir özellik / yeniden düzenleme döngüsü ekledim, yeniden düzenleme işlemim zaten kendisi için para ödüyor ve paylaşılan kodum oldukça kararlı.

TLDR: Gerektiğinde refraktör, hiçbir zorunluluk yoktur.

Yaptığın her şeyin bir bedeli var. Programlamak için sınırlı zamanın var. Programlamada yaptığınız her şeye, "Bunu yapmanın faydası nedir?" A bakmalısınız. ve "Başka bir şey yapmanın faydası nedir?"

Fırsat maliyetini hesaba katmazsanız (Başka bir şey yapmanın maliyeti nedir?), Kalite ücretsizdir. Kodunuzu geliştirmek daha iyidir. Bir şey öğreneceksin. Daha iyi çalışacak. Daha fazla satar.

Asıl soru, zamanınızla yapabileceğiniz en iyi şey nedir? Ve sonra takas yaptın.

Yazılımın daha fazlasını satacak mı?

Daha az baş ağrısının desteklenmesine neden olur mu?

Ne öğreneceksin?

Estetik olarak daha hoş olacak mı?

Şöhretinizi artıracak mı?

Kuyruğunuzdaki bu ve diğer etkinlikler için bu soruları (ve sizinle ilgili olan diğer kişileri) isteyin; bu, düzeltmeye değer olup olmadığını yanıtlamaya yardımcı olacaktır. Bu değişimler ekonominin programcılar için önemli olmasının nedenidir. Joel benden önce söyledi ve yaşlı bir akıl hocası Joel'den önce bile bana söyledi.

Veya daha basit bir cevap istiyorsanız kodu düzeltene kadar TV izlemeyi bırakın. :-)

Bence kendinize kaçırılmış gibi görünen bir soruyu sorarak başlamalısınız. Kod hangi şekilde bozuk? Bu sayede, kendinize gerçekten aşağıdakileri soruyorsunuz:

• Kod yapması gerekeni yapmıyor mu?
• Yazılımı sürdürürken kod size sorun yaratıyor mu?
• Kod tamamen kendi içinde mi?
• Öngörülebilir bir gelecekte kodu herhangi bir zamanda güncellemek veya değiştirmek için planlarınız var mı?
• İlgilendiğiniz kodu güncellemek için yapabileceğiniz sağlam bir iş vakası var mı?

Yıllar boyunca öğrendiğim bir şey varsa, bu gerçeği gördükten sonra kendinizi ikinci kez tahmin edemezsiniz. Koddaki bir sorunu her çözdüğünüzde, bir şey öğrenirsiniz ve muhtemelen çözümünüzün (veya benzer bir şeyin) yıllar önce farklı şekilde çözdüğünüz bir soruna daha iyi bir çözüm olabileceğini göreceksiniz. Bu iyi bir şey, çünkü deneyimlerinizden öğrendiğinizi gösteriyor. Ancak asıl soru, daha önce yazdığınız kodun zaman içinde ele alınması zorlaşan eski bir sorun haline gelip gelmediğidir.

Burada gerçekten bahsettiğimiz şey, sizi rahatsız eden kodun bakımı kolay mı yoksa zor mu olduğu ve zaman geçtikçe bu bakımın ne kadar maliyetli olacağıdır. Bu aslında Teknik Borç ile ilgili bir soru ve şimdi biraz cerrahi bakım kullanarak bu borcu ödemeye değer mi, yoksa borcun bir süre daha kaymasına izin verecek kadar küçük mü.

Bunlar, şu andaki ve gelecekteki iş yükünüze karşı gerçekten tartmanız gereken sorulardır ve kaynaklarınızı nereye yatıracağınız ve eski kodunuzun değerli olup olmadığı hakkında daha iyi bir anlayışa sahip olmak için yönetiminiz ve ekibinizle birlikte uzunca tartışılmalıdır. harcamak gerekebilir - hiç değilse. Değişimi sağlamak için iyi bir iş davası açabilirseniz, o zaman elbette yapın, ancak kodla düzeltmek için dürtüyle karşı karşıya kalırsanız, yazdığınız yoldan utandığınızı hissederseniz, eski kodların muhafaza edilmesi söz konusu olduğunda kişisel gurur odasına sahip. Çalışır ya da yapmaz, ya bakımı kolaydır ya da bakımı kolaydır, ve bugünün tecrübesi dün sizin için mevcut değildi çünkü hiçbir zaman iyi ya da kötü değildir.

Kesinlikle onu geliştirmek yok sadece onu geliştirmeye uğruna. Diğerlerinin dediği gibi (ve sağduyulu), zaman geçtikçe hepimiz daha iyi oluruz (bir miktar "daha iyi" için). Bununla birlikte, kodun (resmi ya da gayrı resmi olarak) gözden geçirilmesi, sıklıkla, gün ışığını bir daha asla görmemeyi arzu ettiğimiz parçaları ve parçaları aydınlatmaktadır.

Temelde kırılmayan, güvensiz veya kullanımdan kaldırılmış bir / EOL listesindeki özelliklere bağlı olan kodu geri alma ve iyileştirme sorumluluğumuza inanmamasına rağmen , geçmişte bu durumda yaptığım bazı şeyler :

• Ekipte gerçekten geriye dönüp kod geliştirmeyi kuran insanları, bir beyin temizliği veya hoş, ısırık büyüklüğünde bir başarı hissi veren bir görev olarak tanımlayın ve programda düzenli olarak yapmaları için zaman ayırın. Bir takımda bu tür insanlardan her zaman en az birine sahip oldum ve bu yaklaşım aynı zamanda hepimiz moralsiz veya moralsiz bir dönemdeysek morali de artırabilir.

• Bir öğrenme alıştırması için temel olarak kullanın. Stajyerler, öğrenciler veya takımın yeni / küçük üyeleri için, eski kodun takımın kıdemli üyelerinden yönlendirilerek yeniden düzenlenmesi, onlara yeni takım üyeleriyle iletişim kurma, sistem hakkında daha fazla bilgi edinme ve yazma alışkanlığı kazanma fırsatı verir. birim testlerinin güncellenmesi ve sürekli entegrasyonla çalışmak. Bu alıştırmanın rehberlikle yapıldığını ve kodu daha iyi hale getirmek için mevcut standartlara / normlara uymadığı için açıkça bir alıştırma olarak çerçevelendirildiğine dikkat etmek önemlidir .

Yani, bunu düzeltmek için sorumluluk yok, ama bu eski şeyler gerçekten yararlı olabilir. Ve birim testleri ve CI senin arkadaşların!

Şart değil. Bununla birlikte, kod bakımı yapıyorsanız ve daha iyi olabilecek bir şeyin üzerine yanarsanız, bir regresyon oluşturmadığınızdan emin olmak için uygun birim testlerini yaptırmanız koşuluyla, durumu değiştirebilirsiniz.

Eğer böyle bir test yapılmazsa ve tam olarak olması gerektiği gibi davranacağından emin olamazsanız, yalnız bırakmaktan daha iyi olursunuz.

Bir mühendis açısından, daha fazla geliştirilemeyecek hale gelinceye kadar eski kod üzerinde çalışmak istediğimden eminim. Ancak bunun için bir iş davası var mı? Günün sonunda, kod, iş yerinizin kârlılığına, sonuç satırına katkıda bulunmak için var. Değilse, sadece bırakın.

Büyük bir uyarı var, eğer kodu geliştirerek, bir böceğin oluşmasını engelleyecekseniz, (büyük Y2K toplarını burada düşünerek ..) Kesinlikle daha yukarı birisine, belki de işletme müdürünüze getiririm. ve kodu geliştirmenin sonuçlarını tartışır.

Bana gelince, soru yeniden ifade edilip genelleştirilebilir: “Bu somut kod parçası şimdi iyi çalışıyorsa, neden birileri daha fazla kaynak harcamalı (zaman, para, zihinsel vb.)? Bu bir kaynak israfı değil mi? ?"

Her zaman eski bir kod bulduğumda, önemli görünen bazı şeyleri düşünüyorum.

1. Ne için değişiklik yapacağım?
2. Bu kodu desteklememe gerek var mı? Ne kadar sürede olabilir (yakın / uzak gelecek)?
3. Bu kod çalışmak için yeterince rahat mı? (Şimdi)
4. Yaptığım tüm değişikliklerin güvenli olduğundan emin olabilir miyim? Farklı testler genellikle bu soruyu cevaplamaya yardımcı olur.
5. Kod değişikliği sırasında hata yaparsam hangi sonuçları karşılayabilirim? Değişikliklerimi hızlı bir şekilde geri almak mümkün mü? Bu zaman kaybı olur mu?
6. ...

Aslında kendine çok soru sormalısın. Bunların tam ve nihai listesi yoktur. Cevapları yalnızca siz ve muhtemelen ekip arkadaşlarınız bulabilir.

PS Kodu çok sık tekrar yazma eğiliminde olduğumu fark ettim, oysa arkadaşım ve takım arkadaşım el değmeden bırakma eğiliminde. Çünkü bu sorulara farklı cevaplar veriyoruz. Ve onlara çok yanlış cevap verdiğimizi söylemeliyim ... çünkü geleceği tahmin edemiyoruz.

Microsoft'un pencereleri güncellemesi gerekiyor mu? Tüm * nix Distros'un gelişmeye devam etmesi gerekiyor mu? Veya daha pratik bir örnek, herkes hala 1970'lerin otomobillerini kullanıyor mu?

Normalde ikinci kez daha iyi kod yazabilirsiniz; alan adı hakkında başlangıçta yazarak daha fazla şey öğrendiniz.

Yeniden değerlemeye değip değmeyeceği konusunda basit bir cevap yok. Genelde, a) sizin için iyi bir öğrenme alıştırması olmadığı sürece yapmamalısınız veya b) uzun vadede daha iyi kodla zaman kazanacaksınız. Unutmayın ki her değişiklik hatalara yol açar.

Bir yan not olarak, birim testlerini şiddetle savunurum. Özellikle otomatik dinlendirmelerle açıkça belirtilen mevcut bir davranışa sahip değilseniz yeniden taramayı yapmak çok kolaydır.

Bugün alabileceğimiz en iyi kodu yazma sorumluluğum olduğuna inanıyorum. Bu, geçmişte öğrendiklerimizi kullanmak ve tasarımımızda kısa yollara girmeyi reddetmek anlamına geliyor. Eğer program baskıları bir şeyin kesilmesine neden olursa, yazılımın kalitesinin bile göz önünde bulundurulması gerektiğine inanmıyorum;

Şimdi çalışıyorsanız ve etkileşime girmeniz gereken kodu şu anda yazabildiğiniz düzeye kadar yazmıyorsa, o zaman kontrollü bir yöntemle yapabiliyorsanız düzeltmeniz makul olacaktır. Ben şahsen (neredeyse herkes?) Herkes gibi (bu şekilde her şeyi değiştirip dua etmesini sağlar) ve yeterince kötü bir şekilde ısırmaya başladım. Martin Fowler'in konuyla ilgili tartışmalarını ( kitabını ya da birçok makalesinden birini ) incelemeyi öneririm . Süreç hakkındaki mevcut düşüncelerin çoğuna ilham vermiş görünüyor.

Elbette bazen kodu istediğiniz gibi temizleyemeyebilirsiniz. Joel Spolsky, kodunuzu yeniden düzenlemek için neden birkaç hafta ayırmak isteyebileceğiniz konusunda bir makale yazdı. Buradan okuyun ve evet, biraz eski, ancak bilgilerin hala alakalı olduğunu düşünüyorum.

umarım bu yardımcı olur

Eski kodu yeniden düzenlemenin / iyileştirmenin programcının kendisini tanımladığını hissediyorum. Bir yıl önce yazdığınız kodu geliştirmek istemeniz yalnızca ilerlemenizi gösterir ve uygulamayı daha iyi hale getirirse ve geliştirmek için yeteneğiniz, zamanınız ve onayınız varsa, bunu yapın.

Daha iyi / gelişmiş, çok eksenli bir karşılaştırmadır. Daha hızlı, daha küçük, daha kaynak verimli, daha okunaklı, daha faydalı bilgiler, daha kesin sonuçlar, daha esnek, daha genel, daha fazla sistemde çalışabilir, ayrı bir ürüne bağımlılığı ortadan kaldırabileceğinizi düşünüyor musunuz?

Şirketiniz neden yeni kod yazmak veya başka bir kod parçasını yeniden yazmak yerine, bu kodu yeniden yazmak için zaman harcamak zorunda kalıyor?

Fırsatın ortaya koyduğu şekilde iyileştirmeler yapmalısınız, ancak fırsat, ya zaten kod üzerinde çalışıyor olmanız ya da değişikliği yapmak için bir iş nedeni belirlemiş olmanız anlamına gelir.

Üretime bir değişiklik yapmak, sıfır olmayan şeyleri kırma şansını doğurur (ünite ve fonksiyonel testler yalnızca bu şansı azaltır, ortadan kaldırmazlar) ve yalnızca beklenen fayda riski aştığında yapılmalıdır.

Dikkate alınması gereken başka nokta hangisidir - bu değişikliği üretime mi yoksa basitçe geliştirme koluna mı itiyorsunuz? İki senaryo için çubuk tamamen farklıdır. Yalnızca geliştirme dalına giriyorsa ve asla üretime geçemiyorsa, fırsat temel olarak bir nedenden dolayı koda bakıyorsunuz demektir ve bunu yapmak zaman alıcı değildir. Eğer bir itme gerçekleşirse, gerektiği gibi gözden geçirilebilir ve o zaman izinsiz olarak kabul edilirse bırakılabilir . Öte yandan, şimdi üretime gidiyor, yukarıda belirttiğim gibi, bu değişikliğin maliyete değip değmeyeceğini göz önünde bulundurmalısınız: zorlamak için harcanan zaman ve yeni kodu kullanmanın yararları.

Kuralların iyi bir kuralı, kodun ne yaptığını anlamak için zaman aldıysanız ve bu süre iyi seçilmiş bazı yeniden yapılanmalar tarafından ileri sürülecekse azaltılabilirse, o zaman işin ve ekibinizin ihtiyaçlarına cevap veriyor olmanızdır. bu adımları atıyorum.

Kod, analizinizden fayda sağlamazsa, alan adları kodun amacını açıklamazsa ve yöntemler okunabilir parçalara ayrılmazsa, işletme değerli bir şey kaybetti: anlama durumunuz. Visual Studio ve ReSharper gibi araçlarla, bu tür yeniden yapılandırmalar güvenli, mantık açısından nötr ve gelecekteki geliştirici üretkenliğinde ve güveninde potansiyel olarak büyük değer taşıyor.

Bob Martin Amca'nın dediği gibi, "Kampı her zaman bulduğundan daha temiz bırak."

Bu, şirketinizdeki yönetime sormanız gereken bir soru.

Geri dönüp eski kodda değişiklik yapmak için gerekli zamana ve kaynaklara sahip misiniz?

Bir QA ekibinin TEST'inin kırılmadığından emin olmak için neyi değiştirdiğini belirlemek için zamanınız ve kaynaklarınız var mı?

Bir hatayı düzelten bir modülde olacağımdan önce bu tuzağa düştüm ve bir ya da başka birinin yazdığı kodu görmedim ya da inelegant oldum, değiştirdim ve başa çıkmamdan daha fazla sorunla karşılaştım. düzeltmem gereken görevimi.

Değişir.

Söz konusu kod gerçekten kırılmışsa, kaçınılmaz olarak bir noktada yüzeye çıkacak hatalar içerecek şekilde (örneğin, bir noktada taşacak ve kötü sorunlara neden olacak bir sayaç), o zaman bunları düzeltmek için çaba gösterebilirsiniz - ama eğer yapın, yeni hatalar ortaya koymaktan kaçınmak için ilk önce olası tüm önlemleri alın: dokunduğunuz her şeyi kapsayan anlamlı birim testleriniz olduğundan emin olun, tüm değişikliklerinizi yetkili bir kişi tarafından gözden geçirin, iyice test etmek için ısrar edin, eskilere geri döndüğünüzden emin olun herhangi bir zamanda sürüm, üretime girmeden önce tüm verileri yedekleyin, önce bir kabul ortamına dağıtın ve gerçek kullanıcılar tarafından test edilmesini sağlayın, vb. Ayrıca, devam etmeden önce onay almak isteyebilirsiniz: hata gerçekten bir saatli bomba ise ve menajerin biraz yetenekli,onu düzeltmenize izin vermesi için ikna edebileceksiniz (ve onay alamazsanız, o zaman belki de bu yanlış olduğunuzu gösteren bir işaret).

OTOH, şikayetiniz sadece kod zarafeti eksikliği ise, o zaman ona dokunmaya cüret etme. Uzun süredir üretimde sadık hizmet veriyordu, kodu değiştirmek sadece sizi tatmin edecek, ancak herhangi bir değer katmayacak ve her değişiklik gibi, bir şeyi bozma riskiniz de var. Bilmeseniz bile, zamanınız değerlidir (kelimenin tam anlamıyla: yaptığınız iş için para alıyorsunuz, bu nedenle zamanınızın her dakikası paraya mal oluyor) ve gerçek bir değer katmadığınızdan, böyle bir değişiklik şirket ve proje için net zarar.