Rastgele refactoring kodu scrum izin verilir

Arka fon

• Takımım scrum kullanıyor
• Şu anda atanmış bir görevim yok
• Biriktirme listesinde artık bekleyen görev yok
• Bugün müvekkilim için İşçi Bayramı .

Bugün yapacak çok işim yok. Üzerinde çalıştığım projede görmeye devam ettiğim bazı kodları yeniden düzenlemeye başlamak istedim, ancak şu anda herhangi bir büyük ölçekli yeniden düzenleme yapmak için herhangi bir sprint görevine atanmadım.

Tamam içinde mi Scrum ben rastgele ben ve hep beni rahatsız fakat diğer günler atamalarının düzeltmek için zamanı Diğer günleri yok yazmadım o kodu üstlenmeden başlamadan olur?

Sprintler arasında boş vaktim olan diğer günler.

Aslında sürekli yeniden yapılanmaya inanırım. Her zaman bir hikaye tayin ettiğimde çalıştığım kod parçaları üzerinde yapıyorum ama şu anda üzerinde çalışmakta olduğum şeyle ilgili olmayan gördüğüm başka bir kod ne olacak?

Gerçekten diğer cevaplara saldırmak istemem ama burada başka kimse otomatik testler yazmıyor mu? İşte 'uygun yazılım mühendisliği uygulamaları olmadan Scrum yapıyor herkes için Martin Fowler yılına ait bir eğlenceli. Robert C. Martin de bu konuda çok şey söylüyor burada .

Yani, cevabım için ... Kısacası, böyle gider:

Evet, “rastgele” yeniden düzenleme koduna, takım yapılması gerektiğine karar verdiği sürece Scrum'da izin verilir . (Sonuçta, kendi kendini organize ediyor)

Ve şimdi uzun cevap için:

Her Sprint'ten sonra giderek daha fazla teknik borç bırakmanın felaket için bir reçete olduğu açıktır. Yakında, herkes kod yavaşlaştıkça yavaşlar; Her değişikliğin yapılması daha zor olacaktır çünkü kod o kadar karışık ve dağınıktır ki, değişecek noktaları bulmak gerçek değişikliği yapmaktan daha uzun sürer. Hakkında hiçbir şey bilmediğiniz büyük ve dağınık bir modülde değişiklik yapmanız gerekirse, projeye insanları eklerken / değiştirirken verim elde etmek / sürdürmek imkansız hale gelirse daha da kötüleşir.

Bir ekip hızını sabit tutmak istiyorsa, yazılımı sürekli olarak artırmak için kod tabanını temiz tutabilmelidir. Yeniden projelendirme, projenin yaşam döngüsü boyunca hızınızı korumak istiyorsanız ve projeye kişi ekleme / değiştirme riskini azaltmak istiyorsanız ve hiçbir şey bilmediğiniz modüllerdeki değişiklikleri yapabilmeniz için zorunlu bir uygulamadır. hakkında, vb.

Ancak yeniden yapılanma çok tehlikeli bir faaliyettir. Tekrar ediyorum - bu çok tehlikeli bir faaliyet. Diğer bir deyişle, kod tabanını güvenli ve özgürce değiştirebilecek yeterli test kapsamı yoksa. Hiçbir şeyin kırılıp kırılmadığını kontrol etmek için bir düğmeye basarsanız, yeniden yapılanma çok güvenli bir etkinlik olur; Öyle ki, aslında, ilk başta böyle bir test takımı yaratmanıza izin veren pratik olan TDD döngüsünün bir parçası .

Ancak, Scrum'daki takımlar kendi kendini organize ettiği için, sonunda takımınız yapılacak doğru şeyin ne olduğuna karar vermelidir. Birilerini ikna etmek zorunda kalmanız durumunda size bazı argümanlar sunmayı umuyorum. (Birinci paragraftaki bağlantılara ve işaret ettikleri diğer her makaleye özel dikkat gösterin)

Scrum yeniden düzenlemeyle ilgili hiçbir şey söylemiyor.

Scrum'ın söylediği şey, sprint içinde çalışmak için herhangi bir göreviniz yoksa, sprint hedefine ulaşmak için ekibinizin geri kalanını desteklemeniz gerektiğidir. Bu onlar için kahve almak bile olsa.
Ekibiniz kodu yeniden düzenlemenin en iyi yöntem olduğunu kabul ederse (ve yeniden yapılandırmanın çok fazla yeni hata getirmemesini sağlamak için altyapının yerinde olmasını da içerir) kabul ederse, o zaman elbette bunun için gidin.

Hayır derdim, değil. Bu, çalışma türünden (yeniden düzenleme vb.) Bağımsızdır.

Asgari olarak, görevler yaratılmalı ve mevcut süratinize itilmelidir. Zaman izlemenin amacı, gelecekteki sprint'leri etkin bir şekilde çizebilmek için hızınızı yakalamaktır. Onları izlemeden şeyler üzerinde çalışıyorsanız, hızı etkileyeceksiniz ve doğru izleme ile olması gerektiği gibi zamanla daha iyi olmayacak (muhtemelen düzenli olarak yeterli çalışmaya sahip olmayacaksınız, çünkü öngörülen hızınız gerçek hızınızdan daha azdır) ).

Kendi içinde yeniden yapılanma çalışmasına gelince, bunun hakkında bir tirate geçebilirim, ancak cevaplamaya çalıştığınız temel soru olduğunu sanmıyorum.

Ben de hayır diyeceğim. Yeniden faktoring, doğru şekilde yönetilmezse, istenmeyen hatalara neden olur.

Genel Müdür olarak, periyodik olarak herkesi başka bir projeye koyardım ve bir hafta boyunca kod incelemeleri yapmak / yeniden faktoring yapmak / yeniden adlandırmak ve bir projeye ilişkin sözleşmeleri uygulamak için harcardım. Bu yeniden faktoring sprintleri neredeyse her zaman doğada kozmetik olacaktır. Herhangi bir işlevsel yeniden faktoring, önceden planlanacak ve orijinal geliştiriciyi kapsayacaktır.

Fonksiyonel yeniden faktoring, her zaman scrum sürecinin bir parçası olarak planlanmalı ve koordine edilmelidir, böylece zaman izlenebilir ve süreci doğrulamak için gerekli tüm ekip üyeleri hazır olur. Bir geliştirici, başka bir izlemenin yazdığı kodu değiştirmekten vazgeçmemelidir, çünkü büyük olasılıkla herkes için mevcut koşuşturmayı bozacak. Özellikle birleştirme zamanı kodu söz konusu olduğunda.

Eğer tek koruyucu olan ve kendi boş vaktiniz olan bir proje ise, o andaki sprintinizde gereksiz gecikmelere neden olmamanız için gerekli önlemleri almanız farklı olabilir.

Şüphe duyduğunuzda yöneticinize danışın.

EDIT: Ayrıca sevmediğiniz bir kodun kendisiyle ilişkili belirli bir performans hedefine sahip olabileceğini de belirtmek isterim. Hoşunuza gitmeyebilir, ancak kullanmak istediğinize uyan, inşa edebileceğiniz her şeyden daha hızlı olabilir. İşlevsel yeniden faktoringin her zaman yönetilen bir süreç olması için bir başka neden.

Scrum yeniden yapılanma ile ilgili hiçbir şey söylemez (bkz. Robert C. Martin, “Unutulan topraklar” konulu bir konuşma).

Scrum'da görevler, yeniden yapılandırmayla ödemesi gereken teknik borçları değil, müşteri tarafından belirtilen yazılımınızın özelliklerini hedefler. Bunlar tamamen farklı soyutlama seviyeleri. Müşteri çoğunlukla gerekliliği değerlendirebilir.

Scrum istatistiksel proje yönetimidir. Ne kadar sürdüğü konusunda anlamlı önlemler almak için performansı bilmek gerekir (sprint başına çıktı). Bir özelliğin tahminini ve gerçek süresini, istatistiklere girebilmek için en az 1 sprint'ten daha fazlasını karşılaştırırsınız. 5 sprint öneririm. Ama bu senin takımına bağlı.

Önemli olan, tahminleri mümkün kılmak için önlemleri anlamlı ve karşılaştırılabilir tutmaktır. Teknik borçlardan dolayı performans düşüyorsa, durum böyle olmayacaktır.

Şimdi hala görevleri yeniden düzenlemeyi düşünüyorsanız, iki sorununuz var: 1. Anlamayan bir müşteri, neden yeni bir özellik üretmeyecek bir görevi kabul etmek zorunda olduğunu anlıyorsa 2. İstatistiklerini ve dolayısıyla tahmin etme yeteneğini tamamen çarpıtıyorsun aniden önceki sprintlerde dikkate alınmayan farklı bir değişkeni değiştirdiğiniz için

Her iki durumda da, müşteriyle özellikler hakkında konuşmak istediğinizde scrum fikrinden ödün vermez ve "Ne kadar sürer?" İçin güvenilir tahminler yaparsınız. istatistiksel bir şekilde. Güvende olmak için, kod tabanınızı sabit (belki de yüksek) kalitede tutmak zorundasınız.

Yeniden düzenleme, çoğu zaman bir yeraltı görevidir. "Büyük" yeniden yapılanmalar, "küçük" yeniden yapılanmaların geçmişte işlenmediği anlamına gelir.

Son bir not: Yeniden ateşleme yaparsanız, test edilen bileşenin yeniden denetlediğinizden emin olun. Ohh, testlerin yok mu? Test yazmak için bir görev yapın. Müşteriniz şu anda kullanmakta olduğu yazılımın test kapsamının yeterli olmadığını bilmekten mutluluk duyacaktır ...

Teknik işleri müşteriden uzak tutun ve profesyonel bir geliştirici olarak işinizi yapın.

İşte bir yaklaşım: ikisini de yap!

Yeniden yapılanma, başlangıçta @misterbiscuit'in işaret ettiği şekilde hataya eğilimli ya da daha fazla zaman alıcıdır.

Bu yüzden bir taslak ya da diken yapma girişimini düşünün. Bu aşamada, onay veya reklam istemezsiniz.

Ardından, iki kanaldan birine dahil etmeye bakın:

• Bunu makul bir şekilde sarabileceğiniz aynı koda / işlevselliğe dokunan mevcut bir bilet.
• biletin tamamını bir sonraki bilet bakımında (veya şelalede haftalık toplantı, vb.) gözden geçirmek üzere. O zaman bunun için dava açabilirsiniz.

Gerçek bir giriş yaptıktan sonra, spike'ınızı uygulamak veya tekrarlamak ve gerçek kodun ana hat (master, vb.) Şubesine dahil edilmesini isteyebilirsiniz.

Bunun birkaç avantajı olacaktır:

• Tüm kod kodlarınız aynı süreçte, QA, sürüm satırında vb. Test edilir.
• Yeniden tatlandırmanın teknenin bir parçası olduğunu ve bir tatile “gizlice girilmesi” gereken bir şey olmadığını, ürün müdürü de dahil olmak üzere resmi olarak satın alıyorsunuz. Neden 'gizlice girmediğinizi' kendinize sorun, gerçek bir özellik perspektif için yardımcı olabilir.
• Eşleştirme, kod inceleme, qa, sapmalar ve faktoring kodu değişikliği için gerekli olabilecek diğer tüm destek talep edebilirsiniz. Politika ve Prosedüre ve yukarıdaki kurullara göre hepsi resmi olacaktır.
• Eğer SOX uyumluluğuna sahip, halka açık bir şirketseniz, bu tür bir resmi işlemi (olasılıkla belgeleyin ve ardından uygulayın) yapmanız gerekir / ihtiyaç duyarsınız.
• Hem ürün yöneticisi (hızlı bir şekilde değişiklik yapıldı) hem de geliştirme ekibi (kod temeli geliştirildi) ile daha iyi bir ün kazanırsınız.
• Kuruluş, üretkenlik, moral, çalışanların tutulması ve diğer birçok neden için iyi olan kod kalitesine önem vermeye çalışıyor.
• Tüm çalışmalar dahil edildiğinde proje hızına etkisi daha kolay takip edilebilir. Varlığın kendisi hızı etkilemek için kullanılabildiğinden herhangi bir puan vermemek uygun olabilir.
• Geliştiricilerin, Fisheye, Github, vs. gibi daha kolay kod incelemelerini teşvik eden araçları görmeleri muhtemeldir.
• Geliştiricilerin paylaşım kodunu ve dolayısıyla yeniden düzenlemeyi kolaylaştıran bazı temel standartları (bazen belgelenmiş, bazen değil) görmeleri daha olasıdır. Bazen yeniden yapılanmanın büyük bir kısmı bir stil seçmek ve daha sonra bunu geniş çapta uygulamaktır (yaklaşımların karışımını bir ile değiştirmek).

Son bir yorum: Ürün yöneticisinin 'rastgele' kelimesini duymasından kaçının. 'Hedeflenen, stratejik, performans arttırıcı' kod yükseltme ile daha olumlu yanıt verebilirler. Veya uygulama servis paketi. Veya hangi dilde olursa olsun size kapsam kazandırır.

Rastgele yeniden düzenleme bir anlam ifade etmiyor. Mantıklı olan, çoğu fayda sağlayacak bir kodun yeniden düzenlenmesidir. Bunun anlamı :

• tasarım veya mimari problemini çözme
• uygulamanın iyileştirilmesi

Scrum'da rasgele yeniden düzenlemeye başladığımda yazıp yazmamış olduğum ve her zaman beni rahatsız eden, ancak diğer günler atamalarından dolayı başka günler ayıramayacak zamanım olmadı mı?

Gönderen bu cevap :

Kodun korunabilir olması, yazma listenizdeki bir öğe olmalıdır (eğer bir Scrum kullanıyorsanız). Yeni gelişme kadar önemlidir. "Kullanıcı tarafından görülebilir" bir şey gibi görünmese de, bunu gözardı etmek teknik borcunuzu artırır. Teknik borç yeterince zorlandığında yolun aşağısında, kodunuzun bakımsızlığı gelişimi yavaşlatır, yeni özellik geliştirmedeki gecikmeler müşteriler tarafından görülebilir.

Önceki çalışmamda daha büyük sprintlerle (2-3 ay) bir çeşit scrum vardı. Sprintler arasında bazı gecikmeler olduğundan (1 ay), yazılımı analiz etmek ve kodu yeniden düzenlemek için bu zamanı kullandık.