Ekibim yeniden düzenleme sonrasında sık sık yapılan hataları nasıl önleyebilir?

Size biraz bilgi vermek için: Yaklaşık on iki Ruby on Rails geliştiricisine (+/- stajyer) sahip bir şirkette çalışıyorum. Uzaktan çalışma yaygındır. Ürünümüz iki parçadan oluşur: oldukça şişman bir çekirdek ve üzerine inşa edilmiş büyük müşteri projelerine kadar incedir. Müşteri projeleri genellikle çekirdeği genişletir. Önemli özelliklerin üzerine yazma gerçekleşmez. Çekirdeğin acil olarak yeniden düzenleme ihtiyacı olan bazı oldukça kötü kısımları olduğunu ekleyebilirim. Teknik özellikler var, ancak çoğunlukla müşteri projeleri için. Çekirdeğin en kötü kısmı test edilmemiştir (olması gerektiği gibi değil ...).

Geliştiriciler, her sprint için bir veya iki PO ile çalışan iki takıma ayrılır. Genellikle, bir müşteri projesi kesinlikle ekiplerden ve PO'lardan biriyle ilişkilidir.

Şimdi sorunumuz: Sık sık birbirimizin eşyalarını kırıyoruz. A Ekibi'nden biri, temel Y özelliğini genişletir veya yeniden düzenler ve B Takımının müşteri projelerinden biri için beklenmedik hatalara neden olur. Çoğunlukla, değişiklikler takımlar üzerinde duyurulmaz, bu nedenle böcekler neredeyse her zaman beklenmedik bir şekilde çarptı. PO dahil B takımı, Y özelliğinin kararlı olduğunu düşündü ve değişikliklerden habersiz, serbest bırakmadan önce test etmedi.

Bu problemlerden nasıl kurtuluruz? Bana ne tür bir 'duyuru tekniği' önerebilirsin?

Michael C. Feathers'ın Eski Kod ile Etkili Çalışmasını okumanızı tavsiye ederim . Gerçekten otomatik testlere ihtiyacınız olduğunu, bunları nasıl kolayca ekleyebileceğinizi, henüz sahip değilseniz ve hangi kodun "refactor'a" hangi şekilde koktuğunu "açıklar.

Bunun yanı sıra, durumunuzdaki bir başka temel sorun da iki ekip arasında iletişim eksikliği gibi görünüyor. Bu takımlar ne kadar büyük? Farklı birikmiş işler üzerinde çalışıyorlar mı?

Takımları mimarinize göre ayırmak neredeyse her zaman kötü bir uygulamadır. Örneğin çekirdek bir ekip ve çekirdek olmayan bir ekip. Bunun yerine, fonksiyonel alanda ekipler oluşturacağım, ancak çapraz bileşen oluşturacağım.

Çekirdeğin en kötü kısmı test edilmemiştir (olması gerektiği gibi ...).

Sorun bu. Verimli yeniden düzenleme büyük ölçüde otomatik test paketine bağlıdır. Bunlara sahip değilseniz, tanımladığınız sorunlar ortaya çıkmaya başlar. Parametreleri yöntemlere geçirmeyle ilgili temel hataları yakalamak için derleyici bulunmayan Ruby gibi dinamik bir dil kullanıyorsanız bu özellikle önemlidir.

Sizi daha iyi birim testlerine yönlendiren önceki yanıtlar iyidir, ancak adreslenmesi gereken daha temel sorunların olabileceğini hissediyorum. Müşteri projeleri kodundan temel koda erişmek için net arayüzlere ihtiyacınız vardır. Bu şekilde , arayüzlerde gözlemlenen davranışı değiştirmeden çekirdek kodu yeniden düzenlerseniz , diğer takımın kodu kırılmaz. Bu, neyin "güvenli" olarak yeniden düzenlenebileceğini ve neyin, muhtemelen arayüz kırılması, yeniden tasarlanması gerektiğini bilmeyi kolaylaştıracaktır.

Diğer cevaplar önemli noktaları vurguladı (daha fazla birim testi, özellik takımları, çekirdek bileşenlere temiz arayüzler), ancak eksik bulduğum bir nokta var, versiyonlama.

Bir sürüm ¹ yaparak çekirdeğinizin davranışını dondurursanız ve bu sürümü özel bir artefakt yönetim sistemi ^2'ye koyarsanız, herhangi bir müşteri projesi çekirdek sürüm X'e bağımlılığını beyan edebilir ve bir sonraki sürüm X tarafından kırılmaz. + 1 .

"Duyuru politikası" daha sonra her sürümle birlikte bir DEĞİŞİKLİK dosyasına veya her yeni çekirdek sürümün tüm özelliklerini duyurmak için bir ekip toplantısına gitmeyi azaltır.

Ayrıca, neyin "çekirdek" ve bunun alt kümesinin "anahtar" olduğunu daha iyi tanımlamanız gerektiğini düşünüyorum. "Anahtar bileşenler" üzerinde birçok değişiklik yapmaktan (doğru) kaçıyorsunuz, ancak "çekirdek" te sık değişikliklere izin veriyorsunuz. Bir şeye güvenmek için onu istikrarlı tutmalısınız; bir şey istikrarlı değilse, çekirdek olarak adlandırmayın. Belki ona "yardımcı" bileşenler demeyi önerebilirim?

DÜZENLEME : Anlamsal Sürüm Oluşturma sistemindeki kuralları izlerseniz , çekirdeğin API'sındaki uyumsuz değişiklikler büyük bir sürüm değişikliği ile işaretlenmelidir . Yani, daha önce var olan çekirdeğin davranışını değiştirdiğinizde veya bir şeyi kaldırdığınızda, sadece yeni bir şey eklemeyin. Bu kural ile, geliştiriciler '1.1' sürümünden '1.2' sürümüne güncelleme yapmanın güvenli olduğunu bilirler, ancak '1.X' den '2.0' sürümüne geçmek risklidir ve dikkatle gözden geçirilmelidir.

^{1: Sanırım bu Ruby 2 dünyasında mücevher olarak adlandırılıyor
: Java'daki Nexus veya Python'daki PyPI'ye eşdeğer}

Diğer insanların söylediği gibi, iyi bir birim test paketi sorununuzu çözmez: her takım test paketi geçse bile değişiklikleri birleştirirken sorun yaşarsınız.

TDD için de aynı şey geçerli. Bunu nasıl çözebileceğini görmüyorum.

Çözümünüz teknik değil. "Temel" sınırları açıkça tanımlamanız ve başrol veya mimar olsun, birine "gözcü köpek" rolü atamanız gerekir. Çekirdekteki herhangi bir değişiklik bu bekçi köpeğinden geçmelidir. Tüm takımlardan elde edilen her çıktının çok fazla teminat zararı olmadan birleştirilmesini sağlamaktan sorumludur.

Daha uzun vadeli bir düzeltme olarak, ekipler arasında daha iyi ve daha zamanında iletişime ihtiyacınız vardır. Örneğin, Y çekirdek özelliğini kullanacak olan her takımın, bu özellik için planlanan test örneklerinin oluşturulmasında yer alması gerekir. Bu planlama, kendi başına, iki takım arasında Y özelliğinde bulunan farklı kullanım durumlarını vurgulayacaktır. Özelliğin nasıl çalışması gerektiğine karar verildiğinde ve test senaryoları uygulandıktan ve üzerinde anlaşıldıktan sonra, uygulama şemanızda gerekli olan ek bir değişiklik var. Özelliği serbest bırakan ekip, kullanmak üzere olan takımı değil, test çantasını çalıştırmak için gereklidir. Çarpışmalara neden olması gereken görev, her iki takımdan da yeni bir test çantasının eklenmesi. Bir ekip üyesi test edilmeyen özelliğin yeni bir yönünü düşündüğünde, kendi sanal alanlarına geçtiğini doğruladıkları bir testcase ekleyebilirler. Bu şekilde, meydana gelecek olan tek çarpışmalar niyet düzeyinde olacaktır ve yeniden düzenlenmiş özellik vahşi hayata bırakılmadan önce çivilenmelidir.

Her sistem etkili test paketlerine (diğer şeylerin yanı sıra otomasyon anlamına gelir) ihtiyaç duysa da ve bu testler etkili bir şekilde kullanılırsa, bu çatışmaları şimdiye kadar olduğundan daha çabuk yakalayacak olsa da, bu altta yatan sorunları ele almaz.

Soru, en az iki temel sorunu ortaya koyuyor: bireysel müşteriler için gereksinimleri karşılamak için 'çekirdek' modifiye etme uygulaması ve ekiplerin değişiklik yapma niyetlerini iletişim kurma ve koordine etmemeleri. Bunların hiçbiri kök neden değildir ve bunu düzeltmeden önce neden yapıldığını anlamanız gerekir.

Belirlenecek ilk şeylerden biri, hem geliştiricilerin hem de yöneticilerin burada bir sorun olduğunu fark edip etmedikleri. En azından bazıları yaparsa, neden bu konuda hiçbir şey yapamayacaklarını düşündüklerini ya da yapmamayı seçtiklerini öğrenmeniz gerekir. Yapmayanlar için, mevcut eylemlerinin gelecekteki problemleri nasıl yaratabileceğini tahmin etme yeteneklerini artırmaya veya bunları yapabilecek insanlarla değiştirmeye çalışabilirsiniz. İşlerin nasıl yanlış gittiğinin farkında olan bir iş gücünüz olana kadar, sorunu çözme ihtimaliniz düşüktür (ve belki de o zaman bile, en azından kısa vadede).

Sorunu soyut terimlerle analiz etmek zor olabilir, en azından başlangıçta, bir soruna neden olan belirli bir olaya odaklanın ve nasıl olduğunu belirlemeye çalışın. İlgili kişilerin savunmacı olmaları muhtemel olduğundan, gerçekten neler olduğunu bulmak için self servis ve hoc sonrası gerekçeler konusunda uyanık olmanız gerekir.

Bahsetmekten çekinme ihtimalim var, çünkü bu pek olası değil: müşterilerin gereksinimleri o kadar farklı ki ortak çekirdek kodunu haklı çıkarmak için yeterli ortaklık yok. Bu durumda, aslında birden fazla ayrı ürününüz var ve bunları böyle yönetmeli ve aralarında yapay bir bağlantı oluşturmamalısınız.

Hepimiz biliyoruz ki, birim testleri bir yol. Ancak, bunları bir çekirdeğe gerçekçi bir şekilde takmanın zor olduğunu da biliyoruz.

İşlevselliği genişletirken sizin için yararlı olabilecek belirli bir teknik, geçici ve yerel olarak mevcut işlevselliğin değiştirilmediğini doğrulamaya çalışmaktır. Bu şu şekilde yapılabilir:

Orijinal sözde kod:

def someFunction
   do original stuff
   return result
end

Geçici yerinde test kodu:

def someFunctionNew
   new do stuff
   return result
end

def someFunctionOld
   do original stuff
   return result
end

def someFunction
   oldResult = someFunctionOld
   newResult = someFunctionNew
   check oldResult = newResult
   return newResult
end

Bu sürümü var olan sistem düzeyi testlerinden geçirin. Her şey yolundaysa, şeyleri kırmadığınızı biliyorsunuz ve daha sonra eski kodu kaldırmaya devam edebilirsiniz. Eski ve yeni sonuç eşleşmesini kontrol ettiğinizde, hata düzeltmesi gibi amaçlanan bir değişiklik nedeniyle farklı olması gerektiğini düşündüğünüz yakalama durumlarındaki farklılıkları analiz etmek için kod da ekleyebilirsiniz .

"Çoğunlukla, değişiklikler takımlar üzerinden duyurulmuyor, bu yüzden hatalar neredeyse her zaman beklenmedik bir şekilde çarptı"

İletişim sorun mu var? Peki (diğer herkesin daha önce işaret ettiklerine ek olarak, sıkı testler yapmanız gerektiğini) doğru iletişim olduğundan emin olun? İnsanların yazacakları arayüzün bir sonraki sürümde değişeceğinden ve bu değişikliklerin ne olacağından haberdar edildiğini?
Ve kendi kodlarını yazmaya başlayabilmeleri için geliştirme sırasında mümkün olan en kısa zamanda en azından bir kukla etkileşime (boş uygulama ile) erişmelerini sağlayın.

Tüm bunlar olmadan, birim testler, son aşamalarda, sistemin parçaları arasında yıpranma dışında bir şey olduğuna dikkat çekmek dışında pek bir şey yapmaz. Bunu bilmek istiyorsunuz, ancak bunu erken, çok erken ve ekiplerin birbirleriyle konuşmasını, çabaları koordine etmesini ve aslında diğer ekibin yaptığı işe sık sık erişmesini istiyorsunuz (çok büyük taahhütler değil, düzenli taahhütler) birkaç hafta veya ay sonra taahhüt, teslimattan 1-2 gün önce).
Hatanız kodda DEĞİL, kesinlikle karşı yazdığınız arayüzle uğraştığınızı bilmeyen diğer takımın kodunda değil. Hatanız gelişim sürecinizde, insanlar arasındaki iletişim ve işbirliği eksikliğindedir. Farklı odalarda oturmanız, kendinizi diğer insanlardan soyutlamanız gerektiği anlamına gelmez.

Öncelikle, bir iletişim probleminiz var (muhtemelen bir ekip oluşturma problemiyle de bağlantılı ), bu yüzden davanıza bir çözüm geliştirme tekniklerine değil ... iletişim üzerine odaklanmalıdır.

Bir müşteri projesine başlarken çekirdek modülün dondurulmasının veya çatallanmasının mümkün olmadığını kabul ediyorum (aksi takdirde şirketinize çekirdek modülü güncellemeyi amaçlayan müşteri ile ilgili olmayan bazı projeleri programlamanız yeterlidir).

Böylece takımlar arasındaki iletişimi geliştirmeye çalıştık. Bu iki şekilde ele alınabilir:

• insanlarla. Bu, şirketinizin kodun kalitesinden ve kullanılabilirliğinden sorumlu olacak birini çekirdek modül mimarı (ya da üst yönetim için iyi olan her ne olursa olsun) olarak adlandırdığı anlamına gelir . Bu kişi çekirdeği enkarne edecektir. Böylece, tüm takımlar tarafından paylaşılacak ve aralarında uygun senkronizasyon sağlanacaktır. Ayrıca, tutarlılığını korumak için çekirdek modüle bağlı bir kod inceleyicisi olarak hareket etmelidir;
• araçları ve iş akışları ile. Çekirdeğe Sürekli Entegrasyon uygulayarak , çekirdek kodun kendisini iletişim ortamı haline getireceksiniz. Bu önce biraz çaba gerektirecektir (üzerine otomatik test paketleri ekleyerek), ancak gece CI raporları çekirdek modülün brüt durum güncellemesi olacaktır.

Burada iletişim süreci olarak CI hakkında daha fazla bilgi bulabilirsiniz .

Son olarak, şirket düzeyinde ekip çalışması eksikliği ile ilgili bir sorununuz var. Ekip oluşturma etkinliklerinin büyük bir hayranı değilim, ancak bu yararlı olabilecekleri bir durum gibi görünüyor. Düzenli olarak geliştirici çapında toplantılarınız var mı? Diğer ekiplerden insanları proje retrospektiflerine davet edebilir misiniz? Veya bazen Cuma akşamı bira içebilir misiniz?