İzci Kuralını ve Fırsatçı Yenileme'yi Kod İncelemeleriyle Uzlaştırmak

Ben büyük bir mümini izci Kuralı :

Bir modülü her zaman temizleyiciden kontrol ettiğinizden daha fazla kontrol edin. "Asıl yazarın kim olduğu önemli değil, ya da ne kadar küçük olursa olsun, modülü geliştirmek için her zaman biraz çaba sarfedersek. Sonuç ne olurdu? hepsi bu basit kuralı uyguladıktan sonra, yazılım sistemlerimizin acımasız bozulmasının sonunu görecektik, bunun yerine, sistemlerimiz gittikçe gittikçe daha iyi ve daha iyi olacaklardı. sadece kendi küçük küçük parçalarına bakan bireylerden daha çok.

Ayrıca, Fırsatçı Refactoring'in ilgili fikrine büyük bir inanç duyuyorum :

Bazı zamanlanmış yeniden düzenleme çabaları için yerler olmasına rağmen, yeniden düzenlemeyi, ne zaman ve nerede olursa olsun, kodun ne zaman ve nerede temizlenmesi gerektiğine göre, fırsatçı bir aktivite olarak teşvik etmeyi tercih ederim. Bunun anlamı, herhangi bir zamanda birisinin olması gerektiği kadar net olmayan bazı kodlar gördüğü, hemen orada ve sonra - ya da en azından birkaç dakika içinde düzeltmek için fırsatını kullanması gerektiğidir.

Özellikle, yeniden düzenleme makalesinden aşağıdaki alıntıyı not edin:

Fırsatçı yeniden yapılanma için sürtünmeye neden olan geliştirme uygulamalarına karşı temkinliyim ... Anladığım kadarıyla, çoğu ekip yeniden yapılanmaya yetmiyor, bu yüzden insanları bunu yapmaktan caydıran herhangi bir şeye dikkat etmek önemlidir. Bunu gidermek için küçük bir yeniden düzenleme yapmaktan çekindiğiniz zaman, farkında olunca bir veya iki dakika alacağınızdan emin olun. Bu tür herhangi bir engel, konuşmaya yol açması gereken bir koku. Öyleyse, cesaret kırıcılığını not edin ve ekibiyle birlikte ortaya çıkarın. En azından bir sonraki retrospektifiniz boyunca tartışılmalıdır.

Çalıştığım yerde, ağır sürtünmeye neden olan bir geliştirme uygulaması var - Kod İnceleme (CR). “Görevim” kapsamında olmayan bir şeyi ne zaman değiştirirsem, gözden geçirenlerin gözden geçirmesini zorlaştırdığım için gözden geçirenler tarafından azarlanırım. Bu, yeniden yapılanma söz konusu olduğunda özellikle geçerlidir, çünkü "satır satır" fark karşılaştırmasını zorlaştırır. Bu yaklaşım burada standarttır; bu, fırsatçı yeniden yapılanmanın nadiren yapıldığı ve yalnızca “planlı” yeniden yapılanmanın (genellikle çok az, çok geç) olduğu anlamına gelir.

Avantajların buna değer olduğunu ve 3 gözden geçirenin biraz daha fazla çalışacağını iddia ediyorum (satırların değiştiği dar kapsamına bakmak yerine, kodu gerçekten önce ve sonra anlamak - gözden geçirmenin tek başına daha iyi olacağını düşünüyorum. ) böylece sonraki 100 geliştiricinin kodu okuyup sürdürmesi fayda sağlayacaktır. Bu tartışmayı gözden geçirenlerime sunduğumda, aynı CR’de olmadığı sürece refactoring ile bir problemleri olmadığını söylüyorlar. Ancak bunun bir efsane olduğunu iddia ediyorum:

(1) Çoğu zaman, ödevinizin ortasındayken, yeniden neyi yansıtmak istediğinizi ancak ne zaman gerçekleştirdiğinizi fark edersiniz. Martin Fowler’ın söylediği gibi:

İşlevselliği ekledikçe, eklediğiniz bazı kodların, bazı kodların bir çoğaltması içerdiğini fark edersiniz, bu nedenle işleri temizlemek için varolan kodu yeniden etkinleştirmeniz gerekir ... Bir şeyin çalışmasını sağlayabilirsiniz, ancak bunun olacağını Mevcut sınıflarla etkileşimin değişmesi halinde daha iyi. Kendinizi yapmayı düşünmeden önce bunu yapmak için bu fırsatı kullanın.

(2) Yapmanız gerekmeyen "yeniden canlandırma" CR'lerini salıverdiğinizde kimse size olumlu bakmayacak. Bir CR'nin belirli bir ek yükü vardır ve yöneticiniz yeniden yapılanmada "zamanınızı boşa harcamanızı" istemez. Yapmanız gereken değişiklikle bir araya geldiğinde, bu sorun en aza indirilir.

Sorun Değişiklikten eklediğiniz her yeni dosya olarak, resharper tarafından şiddetlenir (ve dosyalar değişmiş sona ereceğini tam olarak önceden bilemeyiz) genellikle edilir çevrili hataları ve önerileri ile - spot ve tamamen hak çoğu sabitleme.

Sonuçta korkunç kod görüyorum ve sadece orada bırakıyorum. İronik olarak, böyle bir kodu düzeltmenin sadece puanlarımı iyileştirmekle kalmayacağını değil, aynı zamanda onları düşürdüğünü ve beni işini yapmak yerine kimsenin umursamadığı şeyleri düzeltmek için zaman harcayan "odaklanmamış" bir adam olarak boyadığını hissediyorum. Bu konuda kendimi kötü hissediyorum, çünkü gerçekten kötü kodu küçümsüyorum ve izlemeye dayanamıyorum, kendi yöntemlerinden bile aradım!

Bu durumu nasıl çözebileceğim hakkında bir fikriniz var mı?

Tamam, şimdi burada bir yorum için uygun olandan daha fazlası var.

tl; Dr.

Yapmanız gereken şey hakkındaki sezginiz (ilerledikçe yeniden düzenleme) doğru.

Bunu yapma konusundaki zorluğunuz - kötü bir kod inceleme sistemi etrafında çalışmak zorunda olmanız şartıyla - kaynak kodunuzu ve VCS’yi yönetme zorluğunuzdan kaynaklanıyor. Birden fazla kişi , değişikliklerinizi (hatta dosyaların içinde bile) birden fazla sözleşmeye ayırabileceğinizi ve yapmanız gerektiğini söyledi , ancak buna inanmakta zorluk çekiyorsunuz.

Bunu gerçekten yapabilirsin . Yani gerçekten söylüyoruz. Sen gerçekten olmalıdır düzenleme, kaynak manipülasyon ve sürüm kontrolü araçları en iyi şekilde öğrenirler. Onları iyi kullanmayı öğrenmek için zaman harcarsanız, hayatı daha da kolaylaştırır.

İş akışı / ofis politikaları sorunları

Temelde GlenH7 ile aynı tavsiyede bulunacağımı, iki taahhüt yarattığınızı söyleyebilirim;

Eğer buluyoruz eğer olsa yararlı olabilir sürü tek CR içinde düzeltmek için hata Tek bir kategoriyi seçmek, hataların. Sonra "dedupe code", "fix type-X error" ya da her neyse gibi bir yorumunuz var. Bu, muhtemelen birden fazla yerde tek bir değişiklik yaptığından, incelenmesi önemsiz olmalıdır . Bu bulduğunuz her hatayı düzeltemeyeceğiniz anlamına gelir, ancak kaçakçılığı daha az acı verici hale getirebilir.

VCS sorunları

Çalışma kaynağınızda yapılan değişiklikleri birden fazla komisyona bölmek zor olmamalıdır. Ne kullandığını söylemedin, ama olası iş akışları:

1. Git kullanıyorsanız, bunun için mükemmel araçlara sahip

   • git add -iKomut satırından etkileşimli evreleme için kullanabilirsiniz
   • git guiaşama yapmak için bireysel topakları ve satırları kullanabilir ve seçebilirsiniz (bu aslında komut satırına tercih ettiğim birkaç VCS ile ilgili GUI araçlarından biridir, diğeri ise 3 yollu bir birleştirme editörüdür)
   • çok sayıda küçük taahhütte bulunabilir (bireysel değişiklikler veya aynı hata sınıfını birden fazla yerde düzeltmek) ve sonra bunları yeniden sıralamak, birleştirmek veya bölmek rebase -i

2. Git'i kullanmıyorsanız, VCS'niz hala bu tür bir alete sahip olabilir, ancak hangi sistemi kullandığınızı bilmeden tavsiye edemem.

   TFS kullandığını ve TFS2013'ten beri git ile uyumlu olduğuna inanıyorum. Çalışmak için reponun yerel bir git klonunu kullanarak denemeye değer olabilir. Bu devre dışı bırakılmışsa veya sizin için çalışmazsa, kaynağı hala bir yerel git reposuna alabilir, orada çalışabilir ve kullanabilirsiniz. son taahhütlerini ver.

3. diffve gibi temel araçlara erişiminiz varsa, herhangi bir VCS'de manuel olarak yapabilirsiniz patch. Daha acı verici, ama kesinlikle mümkün. Temel iş akışı şöyle olacaktır:

   1. tüm değişikliklerinizi yapın, test edin, vb.
   2. kullanmak diffişlemek son beri tüm değişiklikleri içeren bir (bağlam veya birleşik) yama dosyası oluşturmak için
   3. iki dosyaya bölümleme: yeniden düzenleme işlemleri içeren bir düzeltme eki dosyası ve bir de işlevsel değişiklikler olacak
      • bu tamamen önemsiz değildir - emacs diff modu gibi araçlar yardımcı olabilir
   4. her şeyi yedekle
   5. son işleme geri dön, patchdüzeltme eki dosyalarından birini tekrar oynat, bu değişiklikleri yap
      • NB. Yama temiz bir şekilde uygulanmadıysa, başarısız parçaların manuel olarak düzeltilmesi gerekebilir.
   6. ikinci yama dosyası için 5'i tekrarla

Şimdi, değişiklikleriniz uygun şekilde bölümlendirilmiş olarak iki taahhüdünüz var.

Not Bu yama yönetimini kolaylaştırmak için muhtemelen araçlar vardır - Git benim için yaptığı için bunları kullanmıyorum.

Şirketinizde Değişiklik İsteklerinin büyük ve resmi olduğunu varsayacağım. Olmazsa, değişiklikleri (mümkünse) birçok küçük komisyona yapın (olması gerektiği gibi).

Bu durumu nasıl çözebileceğim konusunda bir fikriniz var mı?

Ne yapıyorsan devam et.

Demek istediğim, tüm düşünceleriniz ve çıkarımlarınız tamamen doğru. Gördüğün şeyleri düzeltmelisin. İnsanlar yeterince refactoring yapmayı planlamıyor. Ve tüm gruba sağlanan bu fayda, bir kaçını rahatsız etmekten daha önemlidir.

Yardımcı olabilecek daha az savaşçı olmaktır. Kod incelemeleri savaşçı olmamalı, "Neden bunu yaptın?", İşbirlikçi olmalı "Hey millet, ben buradayken bütün bunları düzelttim!". Bu kültürü değiştirmek için (mümkünse / yöneticinizle birlikte) çalışmak kültürü zordur, ancak yüksek işleyen bir geliştirme ekibi oluşturmak için çok önemlidir.

Bu fikirlerin önemini meslektaşlarınızla birlikte ilerletmek için çalışabilir (eğer mümkünse / yöneticinizle). “Neden kaliteyi önemsemiyorsunuz?” Diye sormaya çalışın. onların yerine "neden hep bu işe yaramaz şeyleri yapıyorsun?" diye soruyorlardı.

Durumunuz için çok fazla sempati duyuyorum, ancak çok az somut önerim var. Başka bir şey olmazsa, belki sizi durumun kötü olduğu konusunda daha da kötü olabileceğine ikna edeceğim. Her zaman daha kötü olabilir. :-)

Birincisi, kültürünüzle (en azından) yalnızca bir değil, iki probleminiz olduğunu düşünüyorum. Sorunlardan biri, yeniden yapılanma yaklaşımı, ancak kod incelemeleri belirgin bir sorun gibi görünüyor. Düşüncelerimi ayırmaya çalışacağım.

Kod Yorumları

HATED kod incelemelerini içeren bir gruptaydım. Grup, şirketin ayrı bölümlerinden iki grubu birleştirerek kuruldu. Birkaç yıldan beri kod incelemeleri yapan gruptan geldim, genelde iyi sonuçlarla. Birçoğumuz kod incelemelerinin zamanımızın iyi bir kullanımı olduğuna inanıyordu. Daha büyük bir gruba katıldık ve söyleyebildiğimiz kadarıyla "diğer" grubun kod incelemelerini hiç duymamıştı. Şimdi hepimiz "onların" kod tabanı üzerinde çalışıyorduk.

Birleşdiğimizde işler iyi değildi. Yeni özellikler her yıl 6-12 ay gecikti. Böcek biriktirme, büyük, büyüyen ve hayat boşalıyordu. Kod sahipliği, özellikle en kıdemli "guru" lar arasında Güçlü'dü. "Özellik dalları" bazen yıllarca sürdü ve birkaç sürüm yayıldı; bazen NOBODY, ancak tek bir geliştirici ana şubeye basmadan önce kodu gördü. Aslında "özellik dalı" yanıltıcıdır, çünkü kodun depoda bir yerde olduğunu öne sürer. Daha sık, sadece geliştiricinin bireysel sistemindeydi.

Yönetim, kalite kabul edilemez bir şekilde düşmeden önce “bir şeyler yapmamız” gerektiğine karar verdi. :-) Onların cevabı Kod İncelemeleri idi. Kod İncelemeleri, her check-in işleminden önce resmi bir "Thou Shalt" maddesi haline geldi. Kullandığımız araç Gözden Geçirme Kuruluydu.

Tanımladığım kültürde nasıl çalıştı? Hiçbir şey yapmamaktan iyidir, ancak acı vericiydi ve minimum düzeyde bir uyum düzeyine ulaşmak bir yıldan fazla sürdü. Gözlemlediğimiz bazı şeyler:

1. Kullandığınız araç, kod incelemelerine belirli şekillerde odaklanma eğilimindedir. Bu bir problem olabilir. İnceleme Kurulu size güzel, renkli satır satır farkları verir ve satır satırına yorumlar eklemenizi sağlar. Bu, çoğu geliştiricinin değişmeyen tüm çizgileri görmezden gelmesini sağlar. Küçük, yalıtılmış değişiklikler için sorun değil. Büyük değişiklikler, büyük yeni kod parçaları veya 10 satırlık yeni işlevsellikle karıştırılmış yeniden adlandırılmış bir işlevin 500 örneğine sahip kod için o kadar iyi değil.
2. Daha önce hiç incelenmemiş eski, hasta bir kod tabanında bulunmamıza rağmen, bir gözden geçirenin bir değişiklik çizgisi olmayan bir şey hakkında yorum yapması, hatta bariz bir hatayı işaret etmesi bile “kaba” oldu. "Beni rahatsız etme, bu önemli bir check-in ve hataları düzeltmek için zamanım yok."
3. "Kolay" bir yorumcu için alışveriş yapın. Bazı insanlar 2000 dakika boyunca değiştirilen 2000 satırlı 10 dosya incelemesine bakacak ve "Gönder!" Herkes hızlı bir şekilde bu insanların kim olduğunu öğrenir. Kodunuzu ilk etapta gözden geçirmek istemiyorsanız, "kolay" bir gözden geçirene gönderin. Check-in işlemi yavaşlamayacak. İyiliğini, kodu için "kolay" bir yorumcu haline getirerek iade edebilirsiniz.
4. Kod incelemelerinden nefret ediyorsanız, İnceleme Kurulundan aldığınız e-postaları yoksaymanız yeterlidir. Ekip üyelerinizden takipleri görmezden gelin. Haftalarca. Kuyruğunuzda 3 düzine açık inceleme görene kadar ve adınız birkaç kez grup toplantılarında karşınıza çıkıyor. Ardından "kolay" bir yorumcu olun ve öğle yemeğinden önce tüm yorumlarınızı silin.
5. Kodunuzu "zor" bir denetleyiciye göndermekten kaçının. (Bunun gibi bir soruyu soran veya yanıtlayan geliştirici türü.) Herkes hızlıca "zor" hakemlerin kim olduğunu öğrenir, tıpkı kolay olanları öğrendikleri gibi. Kod incelemeleri Zaman Kaybı (™) ise, KENDİ kodunuz hakkında detaylı geri bildirim okumak hem Kayıp Zaman (™) hem de hakarettir.
6. Kod incelemeleri acı verici olduğunda, insanlar bunları ortadan kaldırır ve daha fazla kod yazmaya devam eder. Daha az kod incelemesi alıyorsunuz, ancak her biri BÜYÜK. Daha fazla, daha küçük kod incelemelerine ihtiyacınız var, bu da takımın onları mümkün olduğunca acısız hale nasıl getireceğini çözmesi gerektiği anlamına geliyor.

Kod İncelemeleri hakkında bir kaç paragraf yazacağımı sanıyordum, ama daha çok kültür hakkında yazıyordum. Sanırım buna bağlıyor: kod incelemeleri bir proje için iyi olabilir, ancak bir ekip yalnızca kazanmayı hak ettiği avantajları elde eder.

yeniden düzenleme

Grubum yeniden düzenlemeyi, kod incelemelerinden nefret ettiğinden daha fazla aşağıladı mı? Tabii ki! Bahsedilen tüm açık nedenlerden dolayı. Zamanımı büyük bir kod incelemesiyle boşa harcıyorsunuz ve bir özellik ekleyemiyor veya bir hatayı düzeltmiyorsunuz bile!

Ancak kod hala umutsuz bir şekilde yeniden düzenlemeye ihtiyaç duyuyordu. Nasıl devam edilir?

1. Bir yeniden yapılanma değişimini asla işlevsel bir değişiklikle karıştırmayın. Bu noktadan çok sayıda insan bahsetti. Kod incelemeleri bir sürtünme noktasıysa, sürtünmeyi artırmayın. Daha fazla iş, ancak ayrı bir inceleme ve ayrı bir check-in yapmayı planlamalısınız.
2. Küçük başla. Çok küçük. Bundan daha küçük. Yavaş yavaş refaktör ve kod incelemeleri saf şeytan olmadığını insanlara öğretmek için çok küçük refactorings kullanın. Çok fazla acı çekmeden haftada bir kez küçük bir yeniden ateşlemede gizlice girebilirseniz, birkaç ay içinde haftada iki kişi ile kaçabilirsiniz. Ve biraz daha büyük olabilirler. Hiç yoktan iyidir.
3. Temelde NO birim testi yaptık. Yeniden yapılanma yasaktır, değil mi? Şart değil. Bazı değişiklikler için, derleyici sizin birim testinizdir. Test edebileceğiniz yeniden yapılanmaya odaklanın. Test edilemiyorsa değişikliklerden kaçının. Belki de zaman harcayarak ünite testleri geçiriyorsun.
4. Bazı geliştiriciler, TÜM kod değişikliklerinden korktukları için yeniden denetlemekten korkuyorlar. Bu tür tanımak için uzun zaman aldı. Kodun bir kısmını yazın, "çalışana kadar" onunla dolaşın ve ASLA değiştirmek istemeyin. NEDEN çalıştığını anlamıyorlar. Değişim risklidir. HERHANGİ bir değişiklik yapmak için kendilerine güvenmezler ve kesinlikle size güvenmezler. Yeniden yapılanmanın davranışları değiştirmeyen küçük, güvenli değişikliklerle ilgili olduğu varsayılmaktadır. “Davranışı değiştirmeyen bir değişiklik” fikrinin düşünülemez olduğu geliştiriciler var . Bu durumlarda ne önereceğimi bilmiyorum. Bence onların ilgilenmediği alanlarda çalışmayı denemek zorundasın. Bu türün çok uzun sürdüğünü öğrendiğimde şaşırdım.

Neden ikisini birden yapmıyorsun, ama ayrı bir komisyonla?

Akranlarının bir anlamı var. Bir kod incelemesi başkası tarafından değiştirilen kodu değerlendirmelidir. Bir başkası için incelediğiniz koda dokunmamanız gerekir; bu nedenle, gözden geçiren olarak rolünüze önyargılı olur.

Ancak birkaç göze batan sorunla karşılaşırsanız, takip edebileceğiniz iki seçenek vardır.

1. Kod incelemesi başka türlü iyi değilse, incelediğiniz bölümün taahhüt edilmesine izin verin ve daha sonra ikinci bir check-in sırasında kodu tekrar gözden geçirin.

2. Kod incelemesinde düzeltilmesi gereken sorunlar varsa, geliştiriciden Yeniden Uyumluluk önerilerini esas alarak yeniden yönlendirici isteyin.

Şahsen işlem sonrası kod incelemeleri yapma fikrinden nefret ediyorum. Kod değişiklikleri yaparken kod incelemesi yapılmalıdır. Elbette burada bahsettiğim ikili programlama. Eşleştirdiğinizde, incelemeyi ücretsiz olarak alırsınız ve daha iyi bir kod incelemesi alırsınız. Şimdi, burada fikrimi ifade ediyorum, başkalarının da bunu paylaştığını biliyorum, muhtemelen bunu ispatlayan çalışmalar var.

Kod gözden geçirenlerinizin sizinle eşleşmesini sağlayabiliyorsanız, kod incelemesinin savaşçı öğesi buharlaşmalıdır. Anlaşılmayan bir değişiklik yapmaya başladığınızda, soru, değişim noktasında gündeme gelebilir, tartışılabilir ve keşfedilen alternatifler daha iyi yeniden yansıtmalara yol açabilir. Parite, değişimin daha geniş kapsamını anlayabildiğinden ve yan yana kod karşılaştırması ile elde ettiğiniz satır satır değişikliklerine o kadar fazla odaklanmayacağınız için daha yüksek kalitede bir kod incelemesi alacaksınız.

Elbette bu, yeniden yapılanmaların üzerinde çalışılan değişimin kapsamı dışında olma sorununa doğrudan bir cevap değildir, ancak akranlarınızın, değişikliği yaptığınız yerde bulundukları yerde değişikliklerin arkasındaki gerekçeyi daha iyi anlamaları beklenir.

Bir kenara, TDD veya bir tür kırmızı yeşil refactor yaptığınızı varsayalım, akranınızdan nişan almanızı sağlamanın bir yolu, ping pong eşleştirme tekniğini kullanmaktır. Basitçe, sürücü RGR döngüsünün her adımı için döndürüldüğü için açıklanmıştır, yani çift 1 başarısız bir test yazar, çift 2 bunu düzeltir, çift 1 refactors, çift 2 başarısız testini yazar ... vb.

Muhtemelen bu problem örgüt kültürüyle ilgili daha büyük bir sorunu yansıtmaktadır. İnsanlar ürünü daha iyi yapmaktan ziyade "işini" yapmakla daha fazla ilgileniyor gibi görünüyor, muhtemelen bu şirketin ortak bir kültür yerine "suçlama" kültürü var ve insanlar ürün / şirket vizyonuna sahip olmaktan çok kendisini ilgilendiren görünüyor .

Bence, tamamen haklısın, kodunuzu gözden geçiren insanlar, şikayetleriniz varsa tamamen yanlıştır, çünkü “göreviniz” dışındaki şeylere dokunduğunuzda, bu insanları ikna etmeye çalışın, ancak asla sizin ilkelerinize aykırı olun, çünkü bu benim için. gerçek bir profesyonelin en önemli kalitesi.

Ve eğer doğru şey size aptal bir şirket yolunda işinizi değerlendirmek için kötü rakamlar veriyorsa, sorun nedir ?, kim bu değerlendirme oyununu çılgın bir şirkette "kazanmak" ister ?, değiştirmeye çalışın! yorgunsun, başka bir yer bul, ama asla, asla ilkelerine karşı olma, sahip olduğun en iyisi değil.

Bazen yeniden yapılanma kötü bir şeydir. Yine de, kod gözden geçirenlerin verdiği nedenlerden dolayı değil; onlar gerçekten kod kalitesi hakkında umurumda değil ve sen gibi geliyor yapmak müthiş bakımı. Ancak sizi yeniden yönlendirmekten alıkoymak için iki neden vardır : 1. Otomatik testlerle yaptığınız değişiklikleri (ünite testleri veya herhangi bir şekilde) test edemezsiniz veya 2. Çok anlayamadığınız bazı kodlarda değişiklikler yapıyorsunuz iyi; yani, hangi değişiklikleri yapmanız gerektiğini bilmek için alana özel bilgiye sahip değilsiniz .

1. Otomatik sınamalarla yaptığınız değişiklikleri test edemediğinizde yeniden yönlendirme yapmayın.

Kod incelemenizi yapan kişinin, yaptığınız değişikliklerin işe yarayan hiçbir şeyi bozmadığından emin olması gerekir. Bu, çalışma kodunu yalnız bırakmak için en büyük sebep. Evet, 1000 hat uzunluğundaki işlevi (bu gerçekten de abomination!) Bir dizi fonksiyona yeniden katmak kesinlikle daha iyi olurdu, ancak testlerinizi otomatik hale getiremiyorsanız, başkalarını her şeyi yaptığınıza ikna etmek gerçekten zor olabilir. sağ. Kesinlikle bu hatayı daha önce yaptım.

Yeniden yapılanmaya başlamadan önce, birim testlerinin yapıldığından emin olun. Ünite testi yoksa, bir kısmını yaz! Daha sonra yeniden ateşlenmeden uzaklaşın ve kod gözden geçirenlerinizin üzülmek için hiçbir meşru mazereti olmayacak.

Sahip olmadığınız bir alana özgü bilgi gerektiren kod parçalarını yeniden gözden geçirmeyin.

Çalıştığım yerin çok fazla kimya mühendisliği ağırlıklı kodu var. Kod tabanı, kimya mühendisleri için ortak olan deyimleri kullanır. Asla bir alana aptalca değişiklikler yapmayın. Adlı bir değişken yeniden adlandırmak için harika bir fikir gibi görünebilir xiçin molarConcentrationama ne oldu? Gelen tüm kimya metinlerinde molar konsantrasyonu ile temsil edilir x. Yeniden adlandırmak, bu alandaki insanlar için kodda gerçekte neler olup bittiğini bilmek zorlaştırır.

Deyimsel değişkenleri yeniden adlandırmak yerine, sadece ne olduklarını açıklayan yorumlar koyun. Böyle bir durumda değil deyimsel, onları adlandırmak ediniz. Bırakmayın i, j, k, x, y, vb daha iyi isimler çalışacaktır zaman etrafında yüzen.

Kısaltmalar için temel kural: insanlar konuşurken, bir kısaltma kullanıyorlarsa, bu kısaltmayı kodda kullanmak uygun olur. İşyerindeki kod tabanından örnekler:

Onlardan bahsederken her zaman kısaltdığımız aşağıdaki kavramlara sahibiz: "Endişeli Alan" "AOC" olur, "Buhar bulutu patlaması" VCE olur, bunun gibi şeyler. Kod tabanımızda, birileri aoc olarak AreaOfConcern'e, VCE'den vaporCloudExplosion'a, nPlanes confiningPlanesCount ... 'a yeniden adlandırılan tüm örnekleri yeniden düzenledi; Ben de böyle şeyler yapmaktan suçlu oldum.

Bu aslında sizin durumunuzda geçerli olmayabilir, ancak konuyla ilgili düşüncelerim var.

Bu sorunun artık iki ayrı sorunu var - kod incelemelerindeki değişiklikleri gözden geçirme kolaylığı ve yeniden yapılanmaya harcanan zaman.

Çalıştığım yerde, ağır sürtünmeye neden olan bir geliştirme uygulaması var - Kod İnceleme (CR). “Görevim” kapsamında olmayan bir şeyi ne zaman değiştirirsem, gözden geçirenlerin gözden geçirmesini zorlaştırdığım için gözden geçirenler tarafından azarlanırım.

Diğer cevapların söylediği gibi, yeniden yapılanma girişlerini kod değişikliği girişlerinden (mutlaka ayrı yorumlar olarak değil) ayırabilir misiniz? Kod incelemesi yapmak için kullandığınız araca bağlı olarak, yalnızca belirli revizyonlar arasındaki farkları görebilmelisiniz (Atlassian's Crucible kesinlikle bunu yapar).

(2) Yapmanız gerekmeyen "yeniden canlandırma" CR'lerini salıverdiğinizde kimse size olumlu bakmayacak. Bir CR'nin belirli bir ek yükü vardır ve yöneticiniz yeniden yapılanmada "zamanınızı boşa harcamanızı" istemez. Yapmanız gereken değişiklikle bir araya geldiğinde, bu sorun en aza indirilir.

Yeniden düzenleme basitse ve kodun anlaşılmasını kolaylaştırırsa (yalnızca yeniden düzenleme yapıyorsa tek yapmanız gereken şey), kod incelemesinin tamamlanması çok uzun sürmemeli ve en az bir ek yük olduğunda maça geri dönmelidir. Gelecekte tekrar gelip kodu tekrar incelemek zorundasınız. Patronlarınız bunu başaramazsa, onları İzci Kuralının neden kodunuzla daha verimli bir ilişkiye götürdüğünü tartışan bazı kaynaklara doğru hafifçe dürtmeniz gerekebilir. Onları “zamanınızı boşa harcayacağınız” ifadesinin şimdi bu kod üzerinde daha fazla iş yapmak için geri döndüğünüzde iki, beş ya da on kez tasarruf edeceğine inanıyorsanız, o zaman probleminiz çözülmelidir.

Değişime eklediğim her yeni dosya (ve tam olarak hangi dosyaların sonlanacağını önceden bilemiyorum) genellikle çoğunun hak ettiği ve tamamen hak ettiği gibi, sorun Resharper tarafından daha da şiddetleniyor sabitleme.

Bu sorunları meslektaşlarınızın dikkatine sunmaya ve neden düzeltmeye değer olduklarını tartışmaya çalıştınız mı? Ve bunlardan herhangi biri otomatik olarak düzeltilebilir mi (otomatik yeniden düzenleme ile ilgili herhangi bir sorun yaşamadığınızı doğrulamak için yeterli test kapsamına sahip olduğunuz varsayılarak)? Bazen gerçekten niteleyen şeyler ise, yeniden yapılanma yapmak için "zaman ayırmaya değmez". Tüm ekibiniz ReSharper kullanıyor mu? Varsa, hangi uyarıların / kuralların uygulandığına dair ortak bir politikanız var mı? Olmazlarsa, belki de aracın kodun gelecekteki acı kaynaklarının muhtemel alanları olan alanları belirlemenize yardımcı olduğunu göstermelisiniz.

25 yıl ya da daha önce, başka amaçlar için üzerinde çalıştığım kodun "temizlediğini" hatırlıyorum, çoğunlukla kodu temiz ve daha kolay anlaşılması için yorum bloklarını ve sekme / sütun hizalamalarını yeniden biçimlendirerek (gerçek işlevsel değişiklikler olmadan) . Ben ne gibi düzgün ve iyi düzenlenmiş bulunuyor kodu. Kıdemli geliştiriciler çok sinirlendi. Dosyanın kişisel kopyalarına neyin değiştiğini görmek için bir çeşit dosya karşılaştırması (fark) kullandıkları ortaya çıktı ve şimdi her türlü yanlış pozitif veriyordu. Kod kütüphanemizin bir ana bilgisayar üzerinde olduğunu ve sürüm kontrolünün olmadığını söylemeliyim - temelde ne varsa onu yazdın, o kadar.

Hikayenin ahlaki mi? Bilmiyorum. Sanırım bazen kendin dışında kimseyi memnun edemezsin. Ben (gözlerimde) vakit değildi - temizledik kod oldu Kolay okunması ve anlaşılması. Sadece, başkaları tarafından kullanılan ilkel değişim kontrol araçlarının üzerlerinde bazı ekstra vuruş çalışmaları yapmasıdır. Araçlar, alanı / sekmeyi ve yeniden yapılan yorumları görmezden gelmek için çok ilkeldi.

İstenen değişikliği ve talep edilmeyen refaktörün, @Useless, @Telastyn ve diğerleri tarafından belirtildiği gibi (birçok) ayrı komisyona bölünmesi durumunda, yapabileceğiniz en iyi şey budur. Hala bir "yeniden düzenleme" yaratmanın idari ek yükü olmadan tek bir CR üzerinde çalışacaksınız. Taahhütlerini küçük tut ve odaklan.

Size bunun nasıl yapılacağına ilişkin bazı tavsiyeler vermek yerine, sizi bir uzmandan çok daha büyük bir açıklama (aslında bir kitap) olarak belirtmeyi tercih ederim. Bu sayede daha fazlasını öğrenebileceksiniz. Eski Kod ile Etkili Çalışmayı okuyun (Michael Feathers tarafından) . Bu kitap, yeniden yapılanmanın nasıl yapıldığını, fonksiyonel değişikliklerle bir araya getirildiğini öğretebilir.

Kapsanan konular şunlardır:

• Yazılım değişiminin mekaniğini anlamak: özellikler eklemek, hataları düzeltmek, tasarımı iyileştirmek, performansı optimize etmek
• Test koduna eski kodu alma
• Sizi yeni sorunların ortaya çıkmasına karşı koruyan testler yazmak
• Herhangi bir dil veya platformla kullanılabilecek teknikler - Java, C ++, C ve C # örnekleriyle
• Kod değişikliklerinin nerede yapılması gerektiğini doğru bir şekilde belirlemek
• Nesne yönelimli olmayan eski sistemlerle başa çıkmak
• Herhangi bir yapıya sahip olmayan uygulamaları kullanma

Bu kitap ayrıca, program öğeleriyle yalıtılmış bir şekilde çalışmanıza ve daha güvenli değişiklikler yapmanıza yardımcı olan yirmi dört bağımlılık kırma tekniklerinden oluşan bir katalog içerir.

Ben de The Boyscout Kural ve Fırsatçı Refactoring'e büyük bir inancım var. Sorun genellikle yönetimin satın almasıdır. Yeniden düzenleme, hem risk hem de maliyetle birlikte gelir. Yönetimin sıklıkla gözardı ettiği şey, teknik borcun da olmasıdır.

Bu insan doğası. Gerçek problemlerle uğraşmaya alışkınız, onları önlemeye çalışmıyoruz. Tepkiseliz, proaktif değiliz.

Yazılımlar manevidir ve bir araç gibi servis gerektirmesi gerektiğini anlamak zordur. Hiçbir makul insan araba satın alamaz ve asla servis yapmaz. Bu tür bir ihmalin ömrünü azaltacağını ve uzun vadede daha maliyetli olacağını kabul ediyoruz.

Birçok yöneticinin bunu anlamasına rağmen, üretim kodunda değişiklik yapmaktan sorumlu tutulurlar. Yeterince yalnız bırakmayı kolaylaştıran politikalar var. Genelde inandırıcı olan kişi aslında yöneticinizin üzerindedir ve “harika fikirlerinizi” üretime sokmak için savaşmak istemez.

Dürüst olmak gerekirse, yöneticiniz her zaman başvurunuzun aslında sizin düşündüğünüz kadar iyi olduğuna ikna olmamıştır. (Yılan yağı?) Bir satıcılık var. Onun yararını görmesine yardım etmek senin işin.

Yönetim önceliklerinizi paylaşmaz. Yönetim şapkanı tak ve yönetim gözleriyle gör. Doğru açıyı daha büyük olasılıkla bulacaksınız. Kalıcı ol. İlk olumsuz cevabın sizi caydırmasına izin vermeyerek daha fazla değişiklik yapacaksınız.

İstenen değişikliği ve talep edilmeyen başvuru sahibini @ GlenH7 tarafından belirtildiği gibi iki ayrı değişiklik isteğine bölebilirseniz, yapabileceğiniz en iyi şey budur. O zaman “zaman harcayan adam” değil, “iki kat fazla çalışan adam” dır.

Sık sık durumda kendinizi bulursanız istenen iş şimdi derlemek için unrequested Refactor gerektiğinden, bu siz standartları kodlama için otomatik kontrol araçları olan ben ısrar öneririm, onları ayıramam burada özetlenen argümanları kullanarak (Resharper uyarıları kendi başlarına iyi bir aday olabilir, ben buna aşina değilim). Bu argümanların hepsi geçerlidir, ancak sizin avantajınıza kullanabileceğiniz bir ekstra daha vardır: bu testleri yaptırmak her işi yaptığınız testleri geçmeyi sizin göreviniz haline getirir .

Şirketiniz "yeniden yapılandırmada zaman kaybetmek" istemezse (kendi taraflarında zayıf bir işaret), o zaman size artık rahatsız edilmemeniz için bir "uyarı bastırma" dosyası (her aracın kendi mekanizması vardır) sağlamalıdır. bu tür uyarılar. Bunu size farklı senaryolar için seçenekler sunmak için, hatta en kötü durum için söylüyorum. Her iki tarafın da açık varsayımlarından ziyade, kendinizle firmanız arasında beklenen kod kalitesinde de açıkça anlaşmalar yapılması daha iyi olacaktır.