Yeniden düzenlemeyi ekibim için nasıl önceliklendirebilirim?

Günlük çalıştığım kod tabanında otomatikleştirilmiş testler, tutarsız adlandırma ve "Neden burası burada?", "Gerekli olup olmadığından emin değil" veya "Bu yöntem doğru şekilde adlandırılmamış" ve kodlar çok küçük. Kaynak kontrolünü kullanmamıza rağmen "Değişiklikler". Bizim kod tabanımızın yeniden düzenlemeyi kullanabileceğini söylemek yeterli.

Hataları düzeltmek veya yeni özellikler eklemek için her zaman görevimiz vardır, bu nedenle refactor kodunun daha iyi ve daha modüler olması için hiçbir zaman bir kenara bırakılmaz ve yüksek bir öncelik olarak görünmez.

Yeniden yapılanmanın değerini, görev listelerimize eklenecek şekilde nasıl gösterebilirim? Gittiğimde sadece refactor için izin almaktan ziyade affedilmeyi istemek buna değer mi?

"İzin vermek yerine affetmek istemek daha iyidir" doğrudur.

Neden endişeleniyorsun? Sadece en korkunç kısımları yeniden yansıtın.

En pahalı hataların ne olduğunu zaten biliyorsun , değil mi?

Bunu yapmazsanız, adım 1, en pahalı, karmaşık, hataya baskın, böcek istilasına uğramış problem kodunu pozitif ve net bir şekilde tanımlamaktır.

Sorunlu bilet sayısını, hata ayıklama saatlerini ve diğer çok özel, ölçülebilir maliyetleri tanımlayın .

Ardından, yüksek maliyetli sorunların bulunduğu listedeki bir şeyi düzeltin .

Affetmek istemeniz gerektiğinde, maliyet azaltmalarını işaret edebilirsiniz.

Farkında değilseniz, yeniden düzenleme, öncesi ve sonrası davranışların eşleştiğini kanıtlamak için birim testlerini gerektirir . İdeal olarak, bunun bir otomatik test, örneğin bir birim testi olması gerekir.

Bu bir şey seçmek anlamına gelir . Birim testi yazın. Bir şeyi düzelt. İki iyileştirme yaptınız. (1) bir test yazdı ve (2) kodu düzeltti.

Uygulayın.

İzci kuralına uyun: kamp alanını (kodunu) bulduğunuzdan biraz daha iyi bırakın. Bir zamanlar "oradayken" küçük kod geliştirmeleri yapmak için yazılan birini duymadım.

Belki de aşırı derecede alaycı bir bakış açısına sahip olacağım.

Yeniden düzenlemek, yutması zor bir haptır. Sorumluluk ve suçu alırsınız ve emeğinizin meyveleri genellikle temiz kod tabanınıza dayanan bir başkasına gider.

Bu tür mühendislik uygulamaları şirketinizdeki kültür haline geldiyse, daha yüksek düzeyde mücadele etmeniz gerekebileceğini söyleyebilirim. Gerçekten refactoring için savaşmıyorsunuz, mühendislik mükemmelliği için savaşıyorsunuz ve bu, sadece yüzlerini şapırttığında yönetimde göze çarpan bir değişiklik. Bu senaryoda, muhtemelen çar en iyi uygulamalar için dışarıya bakacaklar ve tüm harika fikirleriniz yine de ele alınacak.

Mühendislik uygulamalarını daha ciddiye aldıkları farklı bir şirkete katılmayı düşünün.

Buradaki posterlerin birçoğunun yönetim probleminin iktidarda olduğuna ikna olmuş gibi göründüğünü fark ettim - soru buna değmezken.

Bundan daha ileri giderdim: Bence kötü bir kod tabanı neredeyse hiçbir zaman doğrudan yönetimin hatası değildir. Yönetim bu kodu yazmadı, geliştiriciler yaptı (benim şirketimde mevcut yönetimimizin bazılarının ilk kod temelini yazdığı bazı istisnalar var). Bu nedenle kültür sorunu geliştiricilere aittir - eğer kültürün değişmesini istiyorlarsa, kendilerinin de değişmesi gerekecektir.

Bu farkındalığı ve tutum değişikliğini "geliştiricilerime" karşı karşıya getirmeye çalışıyorum. Ne zaman bana "ne zaman yeniden ateşlenecek zamanımız olacak?" Diye sordukları zaman şaşırdım ve cevap veriyorum "zaten her zaman yeniden düzenlemelisin!". Bir kod temelini sağlıklı tutabileceğime inanmanın tek yolu üç kat:

1. Sadece hiç sağlıklı kodlar ekleyin.
2. Her zaman çok sağlıklı olmayan kodu gördüğünüzde düzeltin.
3. Son başvuru nedenlerinden dolayı 1 veya 2 yapamazsanız, her zaman "son başvuru tarihinden hemen sonra düzelt" sorunlarının bir listesini yapın ve son başvuru tarihinden sonra bu listede çalışmamak için herhangi bir bahane kabul etmeyin.

Değişmez bir şekilde geliştiricilerin bir sonraki ifadesi “ama bunu yapmak için nasıl zaman ayırabiliriz - şimdi zamanımız yok mu?”. Tek doğru cevap (yine IMHO) “Bunu yapmak için vaktiniz yok”. Kod tabanını sağlıklı tutmazsanız, geri dönüş süresinin uzadıkça uzadığını, programların tahmin edilemeyeceğini, hataların azalmaya başladığını ve değerin azalmaya başladığını göreceksiniz.

Geliştirme ekibinde gerçekleştirmeniz gereken en büyük tutum değişikliği, “kalitenin”, belirli bir anda (“refactor için zamanımız olduğunda”) belirli bir anda yaptığınız bir şey olmamasıdır - TÜM zamanı yapmanız gereken bir şeydir.

Sonunda, bir uyarı hikayesi. Basılırsa, bu olanları inkar edeceğim. Çalıştığım bir şirkette, 10 yıl öncesine dayanan büyük, eski bir kod temeli olan uzun süredir devam eden bir uygulama vardı. Ben de dahil olmak üzere birçok geliştirici bu eski kod tabanının son teknoloji ürünü değil kötü ya da en azından eski olduğuna inanıyordu. Böylece başarılı bir şekilde büyük bir yeniden projelendirme projesi için lobi yaptık ve yeniden yazma projesini başlattık ve sonrasında her şeyin daha iyi olacağına inandık.
Yeni kütüphaneleri, yeni dil özelliklerini kullanarak hemen hemen her şeyi yeni ve modern bir şekilde uygulamak için uzun ve çok çalıştık. Sonuna kadar, yeni ve geliştirilmiş kod tabanı ile uzun süredir devam eden uygulamanın yeni bir sürümünün yayınlanmasına izin vermek için her şeyi bir araya getirmek için büyük çaba harcadık.
Beklendiği gibi, yeni sürümde henüz aşina olmadığımız yeni kütüphaneler ve kodumuzda öngörmediğimiz bazı etkileşimler nedeniyle bazı diş çıkarma sorunları vardı. Bununla birlikte, nihayet, daha önceki sürümlerimizle ve kapıdan çıkanlarla aynı standarda getirmeyi başardık. "Başarımız" da rahat bir nefes aldı. Sonra bir grup alt geliştirici yönetime geri döndü, yeni bir yeniden projelendirme projesi istedi; çünkü yeni kodumuz bekledikleri gibi gümüş bir mermi değildi ve bazı şeyleri tamamen yeniden yazmak için bazı fırsatlar gördüler ...

Hikayenin ahlaki: çoğu zaman işler göründüğü kadar kırılmaz ve 'baştan başlamak' genellikle en az kılsız bir mesele kümesiyle bilinen bir dizi meseleyle ticaret yapacağınız anlamına gelir. Refactor her seferinde bir kısım!

Birisi bir keresinde bana bir röportaja gittiğimde, şirketle röportaj yaptığımı da unutmamam gerektiğini söyledi. Çalışmak istediğim bir yer mi? Kod incelemeleri yapıyorlar mı? Otomatik entegrasyon testleri var mı? Birim testleri? Çift programlama hakkında ne düşünüyorlar? Şahsen başka bir iş bulurdum ve bu kez de bazı sorular sormayı unutmayın.

Dürüst olmak gerekirse başka bir şirket bulun. Gelişim sürecindeki bu gelişmeler, herkesin aynı sayfaya gelmesinden önce önemli bir zaman alacağı ve o zamana kadar umursamayacağınız büyük kültürel atılımlar gerektiriyor.

İçinde hala bir kavga olduğunu ve henüz iniş yapmadığını hissediyorsan, son bir adım at. Gibi düşünen ekip üyelerinden daha fazla destek almaya çalışın, yorgunluğunuzu iyiliğinize önem veren üstünlere ifşa edin, inancınıza karşı çıkabilecek herkesi doğrudan atlayın ve uzaklaştırın ve bazı zorunlu yeniden düzenleme saatlerini yeni planlamayı planlamaya itmeye çalışın projeler / özellikler.

Yaptığınız şey hakkında tutkuluysanız ve şirketinize önem veriyorsanız, bu sizin tarafınızdan övgüye değer bir çaba olacaktır. Eğer takdir edilmezse, o zaman kendinize saygı gösterin ve boş bir programcılığa dönüşmeden önce kurtarın.

Böyle bir bağlamda işleri daha iyi hale getirmek için bir pratik yapmam gerekirse, kod incelemeleri olur. Kod incelemeleri

• genellikle geliştiriciler tarafından daha iyi kod, daha az hata vb. için bir faktör olarak sezgisel olarak kabul edilir.
• işbirlikçi ve demokratik
• onları doğru şekilde zamanlarsanız çok zaman alıcı olmaz
• “normal” gelişim sırasında buna vaktiniz yoksa yeniden yapılanma yapmak için iyi bir yer
• yavaş yavaş kod tasarımı, birim testi açısından her türlü en iyi uygulamaları tanıtmak için oldukça etkili bir Truva atı ...

Kod incelemelerini sistematik olarak yapmanız gerekmez, yalnızca ilk başta büyük / karmaşık kod bölümleri işlerken.

Elbette, kod incelemeleri yapmadan önce resmi onay almanız gerektiğine inanıyorsanız, önce patronunuz olduğu gibi bırakılırsa ilk önce kod tabanının çökeceği konusunda ikna etmeniz gerekebilir.

İşte böyle durumlarda yaptığım şey (kariyerimin 15 yılında bir geliştirici olarak kariyerim boyunca neredeyse her gün böyle bir kodla karşılaştım)

1. Örnek olarak yönlendir - Dokunduğum kodu yeniden hesaba kattığımdan emin olun. Eski yorumlanmış kodu ve büyük yorum paragraflarını acımasızca silerim.
2. Kod değişikliğini her gözden geçirmem istendiğinde yeniden faktoring isteyin; kod incelemesini onaylamıyorum.
3. İnsanlar yavaşça, kodu daha zayıf, daha okunaklı ve dolayısıyla daha az parazitli hale getirdiğinde değişimi görüyorlar. Zaman alır ancak yavaş yavaş tüm takım uygulamayı takdir eder ve benimser.

Yönetim hiçbir zaman yeniden faktoring koduna zaman ayırmaz (asla yeterli kaynağa sahip olmazlar!), Bu nedenle yavaş ve düzenli bir şekilde yapmak doğru bir yaklaşımdır.

Yönetime "teknik borç" konusunda biraz araştırma yapın. Bunları ayrıca “Kırık Pencere Teorisi” ne bakın, bu etkilerin her ikisi de verimlilik, kalite ve moral üzerinde doğrudan etkiye sahiptir.

"Temiz bir şantiye güvenli ve üretken bir şantiyedir" ve karışıklığa yapılan her katkı karışıklığı doğrusal bir değil, üstel bir biçimde birleştirir.

Durum ele alınmazsa, nihayetinde geri dönüşü olmayan bir noktayı geçersiniz, ekonomik olarak olanaksız hale gelir, daha önce giderek artan bir şekilde onunla başa çıkarak, faydalar toparlanır ve sorunla başa çıkmanız için size daha fazla yakıt verir.

Sorunların daha genel gibi geliyor.
Yeniden düzenleme sorunu hem bir belirti hem de sorunun bir kısmından kaynaklanan potansiyel bir rahatlamadır.

Yazılım Lideri ve Takım, Takımın Zamanını Tahsis Ediyor

Tecrübelerime göre, "herkes bir yazılım yöneticisidir" dediğim bir sorunla karşılaşabileceğinizi düşünüyorum. Ürün yöneticileri, proje yöneticileri ve bazen sistem mühendisleri ve testçileri, muhtemelen zaten deneyimli bir yazılım yöneticisine sahip olan geliştiricileri mikro-yönetmeye çalışmakla ünlü olabilir. Ekibinizde rollerinin yönetmek olduğuna inanan birkaç üyeniz bile olabilir.

Yazılım yöneticisiyseniz, istediğiniz yeniden düzenleme için atama yapın veya daha iyisi, ekibinizin onayınız için size yeniden düzenleme yapmasını önerin. Mikro yönetmeme konusunda, yeniden düzenlenecek yaş / yazar / boyut / kod bağlamı hakkında serbestçe yeniden denetlenebilecek ve onaylanması gereken kurallar olabilir. Ekibinizin bir üyesi, özelliğinin bir parçası olmayan, yazmadığı dört büyük karmaşık eski kod sınıfını toplu olarak yeniden incelemek istiyorsa, iki haftalık saptaması sizin sorununuzdur, bu nedenle hayır demek için bir şansa ihtiyacınız var.

Etrafınıza gizlice girebilirsiniz, ancak tahminlerinizi analiz, tasarım, kodlama, birden çok test formu (en azından birim ve entegrasyon), yeniden yapılanma ve tarihsel olarak değerlendirilmediği gibi risk için zamanla dikkatle oluşturmak daha iyi olur. görevle ilgili deneyim veya açıklık. Ekibinizin çalışmaları hakkında çok açıksanız (veya ekibinizde üyeleriniz varsa), iletişim kanallarını daraltmak akıllıca olabilir, böylece sizden geçerler ve kaynakları ve sonuçları tartışır, yöntemleri değil.

Erken Proje Seçimleri, Yenileme için Vicious Döngüsü Oluşturuyor

Yazılım bakımı zor. Kuruluştaki diğer kişilerin sizin lehinize seçim yapması iki kat daha zor. Bu yanlış, ama yeni değil. Teori W. olarak tanımladığı bir yönetim modelini öne süren büyük yazılım yazarlarımızdan Barry Boehm tarafından ele alınmıştır.

http://csse.usc.edu/csse/TECHRPTS/1989/usccse89-500/usccse89-500.pdf

Genellikle yazılım geliştiricileri, işçilerin temel olarak tembel olduklarını ve teslim edilmediği sürece performans göstermeyeceklerini söyleyen Theory-X yönetim yaklaşımı altında üretmek üzere dövülürler. Boehm önerilen modelini şöyle özetler ve karşılaştırır:

“Bir yöneticiyi bir otokrat (X teorisi), bir koç (Y teorisi) veya bir kolaylaştırıcı (Z teorisi) olarak nitelemek yerine, W Teorisi, çeşitli seçmenleri ve proje çözümleri paketleyicisi arasında bir müzakereci olarak yöneticinin birincil rolünü karakterize eder. Tüm taraflar için kazanma koşullarıyla, bunun ötesinde, yönetici aynı zamanda bir hedef belirleyici, hedeflere yönelik ilerlemenin bir izleyicisi ve günlük kazan-kazan-kaybetme veya kaybetme proje çatışmalarını bulma ve bunlarla yüzleşme arayışında olan bir aktivisttir. ve onları kazan-kazan durumlarına dönüştürmek. "

Hızlı ve Kirli genellikle Sadece Kirli

Boehm, bakım ekibindeki geliştiriciler için işlerin bu kadar mutsuz olmasının nedenini belirtmeye devam ediyor.

"Hızlı ve özensiz bir ürün oluşturmak, yazılım geliştirici ve müşteri için düşük maliyetli, kısa vadeli bir" kazanma "olabilir, ancak kullanıcı ve koruyucu için" kaybedilir "olacaktır." Boehm’in modelinde, müşterinin son kullanıcı yerine daha çok bir sözleşme yöneticisi olduğunu lütfen unutmayın. Çoğu şirkette, ürün yöneticisini müşteri vekili olarak veya belki de ürününün özellik listesi için satın alan kişiyi düşünün.

Benim çözümüm, kod en azından kodlama standartlarını karşılayacak şekilde yeniden yapılandırılıncaya kadar orijinal geliştirme ekibini (veya en azından orijinal liderliği) serbest bırakmamak olacaktır.

Müşteri için, ürün yöneticisini bir müşteri vekili olarak saymanın makul olduğunu düşünüyorum ve hızlı ve kirli bir şey sunmak için ödüllendirilen bir grup insan kesinlikle genişletilebilir, bu yüzden işleri yanlış yapmak için büyük bir seçim bölgesi var.

Yeniden yapılanma pazarlık değildir

Lütfen bir yazılım yöneticisi olarak rolünüzden vazgeçmeyin. Takımınızın zamanını süreç ve ürün geliştirmelerinde kullanmak için yetki ve takdir hakkına sahip olmalısınız. Bu rolde, ekibinizi daha profesyonel hale getirmek için seçimlerinizi müzakere etmeniz gerekebilir. Ancak, süreçle ilgili olarak pazarlama ile pazarlık etmeyin, çünkü deneyimlerime göre bu kaybedilen bir oyundur. Mühendislik yönetimi ile görüşün. Vizyon olduğunu gösterir. Profesyonel bir yazılım ekibi oluşturmak, rollerinin bir uzantısıdır ve kazan-kazan olarak görülmesi daha olasıdır.

Her zaman sadece bekleyebilirsin. Sonunda, takım yeterli süreleri kaçıracak ve yeterince yazılım üretecek, bu yönetim ellerini fırlatacak ve Tanrı tarafından bir şeylerin daha iyi bir şekilde değiştiğini söyleyecek !

Tamam, bu riskli bir teklif. Fakat aslında birkaç yıl önce mağazamızda olan şey (zorluğun bir kısmı son tarihler hakkında yönetim ile iletişim kurmaktı , ama bu başka bir hikaye) ve şu anda on binlerce otomatik test, paylaşılan kod sahipliği yapmamızın büyük bir nedeni, refactor özgürlüğü, ölü kodu silme isteği ve şimdiye kadar sahip olduğumuz en yüksek kalitede sürümler.

Belki de en şaşırtıcı şekilde, bu süreçte hiç kimse işini kaybetmedi - patronumun bize karşı gelmesi için kredi verdiğim bir şey ve bizim adımıza yeniden yapılanma ve sürekli entegrasyon için davayı tartışan bir danışman. Dışarıdan birinin söylediğini söylemesi her zaman daha inandırıcı geliyor.

Bence zamanı nasıl bulacağınız cevabı, neden yeniden kodlama kodu yapmak istediğinize bağlı.

Çalışırsa, özel refactor'a gerek yoktur ve kodun o bölümüne dokunduğunuzda yapabilirsiniz. Bu nedenle bunun için özel bir zamana ihtiyacınız yok.

Eğer takım gelişiminizi yavaşlatırsa, bunun için takım liderinizle konuşmanız ve refactoring için özel bir görev yaratmanız ve zamanınızın olması gerekir.

Çalışma hızı ve diğer durumlar için aynıdır, eğer refactor bir şeyi iyileştirebilirse ve sadece "iyi kodlara bakma" ya da senin kodun nasıl görünmesi gerektiği ve gerçek bir fayda sağlama, görev oluşturma ya da bundan sorumlu olan biriyle konuşma gibi düşünceleri değil.

Bazı şeyleri anlattığınız şekilde biraz güldüm, bu çalıştığım kod tabanına oldukça benziyor, bu yüzden durumlarımızın oldukça benzer olduğunu düşünüyorum. Neyse ki, benim durumumda, kod tabanını daha iyi hale getirmenin en iyi yoluna karar veren ileri görüşlü bir yöneticim var, kod kodunun tamamını yeniden düzenlemek yerine, modern bir web geliştirme çerçevesi kullanarak modülerleştirme yapmaktan geçiyor. Bu şekilde, ana uygulamanın zahmetli noktaları ayrı modüller olarak yeniden yazılabilir ve daha sonra ana uygulamaya entegre edilebilir (ancak temel olarak bağımsız olabilir). Bu, birlikte çalıştığınız tüm (presumabley large?) Kod tabanını yeniden düzenlemeyi gerektirmediğinden ortaya çıkarmak istediğiniz bir yaklaşım olabilir.

Tabii ki, belki de sizin kod üssünüz çalıştığım kadar kötü olmadığı için söylediklerinizden biraz uzak olabilirim, bu durumda neden ilerlerken küçük optimizasyonlar yapmıyorsunuz diyebilirim? Ekibimin devi aptalca ya da modası geçmiş yorumları ve o doğaya ait şeyleri kaldırma konusunda hiçbir sıkıntı yaşamıyor ve ben genellikle geliştiricilere ihtiyaç duyulan şeyleri optimize etmek için bir miktar yetki verildiği için yönetimden girdi gerektiren bir şey olduğunu sanmıyorum.

Eğer kod tabanı gerçekten kırılgansa, dikkatli olmalısınız ve bu nedenle aylarca süren bir projeye dönüşecek ve muhtemelen bir projenin dallanmasını ve dev'in projeye koyulmasını gerektireceği için büyük yeniden düzenlemeye devam etmek istememelerinin nedeni olabilir. Müşterilerin kaybedilmesine neden olabilecek acil hata düzeltmeleri gibi proje geliştirme ve diğer geliştirme görevlerinden uzaklaştırma, vb.

Her şey düşünüldüğü kadarıyla, diğer insanlar istifa etmeniz gerektiğini söylerken, sanırım, yönetimin bir şeyleri nasıl gördüğüne bağlı olduğunu, durumu anlarlar ve bazı şeylerin neden en iyi şekilde gerekenden daha uzun sürdüğünü anlarlarsa, o zaman işler iyi olabilir. iş ortamı kadar, ancak sürekli olarak size bir iş birikimi hakkında yaklaşıyorlarsa, zamanla zararlı olabilir. Uygulamanın temelde farkına varacak bir yönetime sahip olduğum için şanslıyım bir bok parçası, ancak çok fazla müşterisi var ve para getiriyor, bu yüzden kısa vadede olsa bile hala değerli ve hata düzeltmeleri yapmaya değer .

Asıl probleminiz kodların yeterince görünmemesi.

Jenkins gibi sürekli bir entegrasyon aracı ve döngüsel karmaşıklığı, adlandırma standartlarını, kod uzunluğunu vb. Ölçen bir statik kod analiz aracı kullanmasını öneriyorum.

Bir programcı değişiklik yapmaya karar verdiğinde, Jenkins ünite testlerini yapar, üzerinde statik kod analiz aracını çalıştırır ve trafik ışığı benzeri renk durumuyla herkesin görebileceği bir web raporu oluşturur.

Kod kalitesi herkes tarafından görülebiliyorsa (özellikle takım lideri ve patronu) ve sürüm kontrolü ve birim testleri arkanızda olacak ... insanlar kendilerini refactor için cesaretlendirmiş hissedecekler.

Bu kod birçok küçük değişiklikten yavaşça geçti. Bu şekilde de düzeltilmesi gerekecek.

Devam ederken bunu yapabilirsiniz, öncelikle - kod geliştirme ve uzun süreli bakıma izin vermek için tüm tahminleri% 10 artırın. Birisi şikayet ederse, her hafta bir araba motorundaki yağı kontrol etmenin veya motor tamamen kilitlenene kadar beklemenin daha iyi olup olmadığını sorun.

Bir toplantı yapın ve tutarlı kodlama standartlarını belirleyin.

İlerledikçe kullanmak için temel kuralları tanıtın:

Ne zaman bir sınıfa yeni bir kod getirilirse, sınıf çalışmalarını kanıtlamak için otomatik testler yazılmalıdır (sadece yeni kodu değil).

Bir hata düzeltildiğinde sınıfın işe yaradığını ispatlamak için otomatik testler yapılmalıdır (sadece sabit kod değil).

Bir programcı bir dosyayı ne zaman değiştirirse, o dosyadaki tüm derleyici uyarılarını düzeltmeli ve kodu yeni kodlama standartlarına uyacak şekilde güncellemelidir.

Bir süre sonra en çok kullanılan kod güncel olacak ve otomatik testlerle kapsanacaktır. Eski kod değiştiğinde güncellenecektir, eğer hiç değişmediyse asla endişelenmenize gerek yoktur.

Önemli olan bu alışkanlıkları standart kodlama görevlerine yerleştirmektir, böylece hiçbiri 'gerçek' işten çok büyük bir zaman harcamaz ancak hepsi gerçek fayda sağlar. Eski kodları yeniden düzenlemekten bir proje yapmaya çalışmayın; bu, korkunç olmayan, sıkıcı, kederli bir acıdır;

İhtiyacınız olan kaynakları (zamanı) elde etmenin yolu, yetenek ve arzuyu hizalamaya odaklanmaktır. Patronunuz hedefler tarafından yönlendiriliyor (tipik olarak yeni özellikler için kar veya teslimat süreleri) ve mühendislerin zaman harcıyor ve bu hedeflere yemek yerken yeniden toplandığını görüyor. Yeniden refactoring için zaman harcıyorsanız, hedeflerin karşılanacağı ve aşılacağı konusunda onu ikna etmenin bir yolunu bulmanız gerekir.

İlk adım, patronunuzun hangi acıyı hissettiğini bulmak. En büyük probleminin ne olduğunu belirleyin. Ardından, ne yapmak istediğinizi sorununuzu çözme ile nasıl uyum sağladığını öğrenin ve bunu yapmak için güçlü bir iş durumu sunun. Sorunların nerede bulunduğuna dair kanıt sağlamak için kusur izleme ve proje planlama sistemlerini (zaman aşımları) kullanın. Gerçeklere ihtiyacın var, hislere değil. Metrikler olmadan (hata sayımı / modülü, bunları düzeltmenin maliyeti), yeniden düzenleme yalnızca bir kişinin hesabına oynadığı bir programcıdır. Patronunuz yalnızca gerekli kaynakları size verecek güçlü bir iş davası gösterebilirseniz verecektir.

Çökme kodu düzeltmek için fazla pahalı değil. Otomatik regresyon testi olmadan, yeniden kodlanmış kodun test maliyeti oldukça yüksektir.

Çoğu zaman gerçek anlamda yeniden düzenlemeye ihtiyaç duyan kötü kodlar görmüştüm, gereksinimlerde baştan anlaşılamayan çok sayıda belgelenmemiş özellik ve karmaşıklık vardı. Bu küçük bir girişim değildir ve deneyimim, yeniden yapılanma işinin maliyetini tahmin etmek için yeni bir özellik eklemekten zordur.

İlerlemekten kaçınmak ve arkanızda yapmaktan kaçınırdım patronlar geri (Kırılmamış olsaydınız ve kırdıysanız, nasıl görünüyor?) - yine de değişmesi gereken kodu düzeltin, ama kırılmazsa, yapmayın. Düzeltme.

Garip bir şekilde kimse bundan bahsetmiyor:

Her şeyi öncelik haline getirmek için kolay hale getirin: İyi bir yeniden düzenleme aracı edinin.

Orada mükemmel refactoring araçları var (en azından .NET afaik için). Oh, ve önceden birim ünite testleri yazmayı unutmayın (diğerleri de belirtildiği gibi).

İyi şanslar!