Eski Kod ile Etkili Çalışmanın Anahtar Noktaları nelerdir? [kapalı]

Eski Kod ile Etkili Çalışma kitabını birkaç kez tavsiye ettim . Bu kitabın kilit noktaları nelerdir?

Eski kodlarla başa çıkmak için birim / entegrasyon testleri eklemek ve sonra yeniden düzenleme yapmaktan daha fazlası var mı?

Eski kodla ilgili en önemli sorun, test olmamasıdır. Bu yüzden biraz eklemek gerekir (ve daha sonra ...).

@ Mattnz'ın belirttiği gibi, bu kendi başına çok fazla çalışma gerektirecektir. Ancak eski kodların özel sorunu, asla test edilebilir olması için tasarlanmamış olmasıdır . Bu nedenle tipik olarak, küçük parçaların ünite testine tabi tutulmasının çok zor veya düpedüz olarak imkansız olduğu, çok geniş bir kıvrımlı spagetti kodu karmaşasıdır. Bu nedenle , birim testinden önce, daha test edilebilir hale getirmek için kodu yeniden yapılandırmanız gerekir .

Ancak, güvenli bir şekilde yeniden inceltmek için, değişikliklerinizle ilgili hiçbir şey kırmadığınızı doğrulamak için birim testlerine sahip olmalısınız ... Bu, eski kodların 22'sidir.

Kitap, sadece ilk ünite testlerini mümkün kılmak için kodda mutlak minimum, en güvenli değişiklikleri yaparak bu yakalamanın nasıl çözüleceğini öğretir. Bunlar tasarımı daha güzel kılmak değil, yalnızca ünite testlerini mümkün kılmak içindir. Aslında, bazen tasarımı çirkin veya daha karmaşık hale getirirler. Bununla birlikte, testler yazmanıza izin verir - ve birim testleri gerçekleştirdikten sonra, tasarımı daha iyi hale getirmekte özgürsünüz.

Kodu test edilebilir hale getirmek için birçok püf noktası var - bazıları açık, bazıları hiç değil. Kitabı okumadan kendim hakkında asla düşünmediğim yöntemler var. Ancak daha da önemlisi, Tüylerin bir kod birimini kesin olarak test edilebilir kılan şeyin ne olduğunu açıklamasıdır . Bağımlılıkları azaltmanız ve kodunuza engeller eklemeniz gerekir, ancak iki farklı nedenden dolayı:

• algılama - bir kod parçasının yürütülmesinin etkilerini kontrol etmek ve doğrulamak için ve
• Ayırma - Öncelikle belirli bir kod parçasını bir test donanımına sokmak için.

Bağımlılık güvenli bir şekilde kesme zor olabilir. Arayüzler, alaylar ve Bağımlılık Enjeksiyonu tanıtımı, hedef olarak temiz ve güzeldir, ancak bu noktada yapılması kesinlikle güvenli değildir. Bu yüzden bazen normalde örneğin bir DB'ye doğrudan bir istek başlatacak bazı metotları geçersiz kılmak için test altındaki sınıfı alt sınıfa koymak zorundayız. Diğer zamanlarda, bağımlılık sınıfını / kavanozunu test ortamında sahte bir taneyle değiştirmemiz bile gerekebilir ...

Bana göre, Tüylerin getirdiği en önemli kavram dikişlerdir . Bir kod, kodun kendisini değiştirmeden programınızın davranışını değiştirebileceğiniz kodda bir yerdir . Kodları içine dikiş yapmak, test edilen kod parçasını ayırmayı sağlar , ancak doğrudan yapmak zor veya imkansız olsa bile test altındaki kodun davranışını hissetmenizi sağlar (örneğin, çağrı başka bir nesnede veya alt sistemde değişiklik yaptığı için) , durumu doğrudan test yöntemi içinden sorgulamak mümkün değildir.

Bu bilgi, en kötü kod yığınında test edilebilirlik tohumlarını fark etmenize ve oraya ulaşmanız için en az, en yıkıcı, en güvenli değişiklikleri bulmanıza olanak sağlar. Başka bir deyişle, fark etmeden kodu kırma riski taşıyan "belirgin" yeniden düzenlemeler yapmaktan kaçınmak için - çünkü bunu algılamak için birim testlerine henüz sahip değilsiniz .

Eski Kodla Etkili Çalışmanın anahtar noktalarını hızlıca elde etmenin hızlı yolları

• Kitaptan 2 yıl önce yazılan Michael Feathers'ın 12 sayfalık PDF'sini okuyun .
• Michael Feathers'ın sunumuna bakın: 68 slayt
• Michael Feathers ile bir podcast röportajını dinleyin. Örneğin bu 30 dakikalık Hanselminutes bölümü .

Bazıları 1980'lerden kalma milyonlarca kod satırında çalışıyorum. Bu sadece bir yazılımdır, bu yüzden birkaç ünite testi yazmaktan ibarettir, bu yüzden gidip tekrar gözden geçirebilir ve daha iyi hale getirebilirsiniz.

Buradaki anahtar kelime, sadece - eski sistemler üzerinde çalışanlar dışında, herhangi bir programcının kelime haznesine ait olmayan dört harfli bir kelimedir.

Bir saatlik test geliştirme, bir saatlik geliştirme çabasını test etmenin ne kadar zaman alacağını düşünüyorsunuz? Tartışma aşkına, başka bir saat diyelim.

20 milyon yıllık bu eski miras sistemine milyonlarca zaman harcanıyor? Diyelim ki, 20 yıl boyunca 20 geliştirici 2000 saat / yıl (oldukça çalıştılar). Şimdi bir sayı seçelim - yeni bilgisayarlarınız ve yeni araçlarınız var, ve ilk başta% $ ^^ yazısını yazanlardan çok daha zekisin - en önemlisi de onlardan biri olduğunuzu varsayalım. 40 erkeğin var mı?

Yani sorunuzun cevabı çok daha fazlası var. Örneğin, 1000 satırlık rutin (5000'den fazla olan birkaç tane var), aşırı karmaşık ve bir parça spagetti. Sadece (yine dört harfli bir kelime) birkaç 100 satır rutini ve birkaç 20 satır yardımcısına yeniden katmak için birkaç gün alacak, değil mi? YANLIŞ. Bu 1000 satırda gizli olan her biri belgelenmemiş bir kullanıcı gereksinimi ya da belirsiz bir uç durum olan 100 hata düzeltmesidir. Bu 100 satırdır, çünkü orijinal 100 satırlık rutin iş yapmadı.

Zihin seti ile birlikte çalışmanız gerekir ( eğer kırılmazsa, düzeltmeyin) . Kırıldığı zaman, tamir ederken çok dikkatli olmalısınız - daha iyi yaptıkça, yanlışlıkla başka bir şeyi değiştirmemeniz gerekir. "Kırdı" nın sisteme ve kullanımına bağlı olarak sürdürülemez ancak doğru çalışan bir kod içerebileceğini unutmayın. "Bunu mahvedip daha da kötüleştirirsem ne olur" diye sor, çünkü bir gün bunu yapacaksın ve patronlarına neden bunu yapmayı seçtiğini söylemelisin.

Bu sistemler her zaman daha iyi hale getirilebilir. Çalışmak için bir bütçe, bir zaman çizelgesi, her neyse. Eğer yapmazsan - git ve bir tane yap. Para / zaman tükendiğinde daha iyi yapmayı bırak. Bir özellik ekleyin, biraz daha iyi hale getirmek için kendinize zaman verin. Bir hatayı düzeltin - yine biraz daha fazla zaman harcayın ve düzeltin. Asla başladığındakinden daha kötü teslim etme.

Kitaptan almak için iki önemli nokta var.

1. Eski kod, test kapsamı içermeyen herhangi bir koddur.
2. Eski kodu değiştirmek istediğinizde, kapsamı dahil olduğundan emin olmalısınız.

Diğer cevaplayıcıların da belirttiği gibi, mevcut eski kodunuzu önleyici olarak güncellemeye çalışmak bir aptalın işidir . Bunun yerine, eski kodda değişiklik yapmanız gerektiğinde (yeni bir özellik veya hata düzeltmesi için), eski durumunu kaldırmak için zaman ayırın.

Gerçek bir somun kabuğunda - testler ve yeniden düzenleme yapmak her şeyiyle ilgili.

Ancak kitap, güvenli bir şekilde test edilmesi ve düzeltilmesi çok zor olan kodlarla bunu yapmak için size birçok farklı teknik sunar.