Harika Geliştiriciler, Rails Kodunu Ne Zaman ve Nasıl Yeniden Düzenleyeceklerini Bilir

Büyük ölçekte yeniden düzenleme: Neden böyle bir şey yapasın ki?

Bozuk değilse tamir etme.

Bu iyi bilinen bir tabir, ancak bildiğimiz gibi, insanlığın teknolojik ilerlemesinin çoğu, bozuk olmayanı onarmaya karar veren insanlar tarafından yapıldı. Özellikle yazılım endüstrisinde, yaptığımızın çoğunun bozuk olmayanı onarmak olduğu iddia edilebilir.

İşlevselliği düzeltme, kullanıcı arayüzünü iyileştirme, hız ve bellek verimliliğini artırma, özellikler ekleme: bunların tümü, yapmaya değer olup olmadıklarını görmenin kolay olduğu etkinliklerdir ve sonra biz, deneyimli Rails geliştiricileri olarak bunlara zaman ayırmayı ya da buna karşı çıkmayı tartışırız. Bununla birlikte, çoğunlukla gri bir alana düşen bir etkinlik vardır - standart yeniden düzenleme ve özellikle büyük ölçekli kod yeniden düzenleme.

Büyük ölçekli yeniden düzenleme terimi açıklamayı hak ediyor. Tam olarak "büyük ölçek" olarak kabul edilebilecek olan, terim biraz belirsiz olduğu için durumdan duruma değişecektir, ancak yalnızca birkaç sınıftan veya birden fazla alt sistemden daha fazlasını önemli ölçüde etkileyen her şeyi ve arayüzünün "büyük" olduğunu düşünüyorum. ” Öte yandan, tek bir sınıfın arayüzünün arkasında gizli kalan herhangi bir Rails yeniden düzenlemesi kesinlikle "küçük" olacaktır. Tabii arada çok fazla gri alan var. Son olarak, içgüdülerinize güvenin, eğer yapmaktan korkuyorsanız, o zaman muhtemelen “büyük”tür.

Yeniden düzenleme, tanımı gereği, herhangi bir görünür işlevsellik, müşteriye gösterebileceğiniz hiçbir şey, çıktılar üretmez. En iyi ihtimalle, küçük hız ve bellek kullanımı iyileştirmeleri üretebilirler, ancak bu birincil hedef değildir. Birincil hedefin memnun olduğunuz kod olduğu söylenebilir. Ancak, kodu, kod temeli boyunca geniş kapsamlı sonuçlara sahip olacak şekilde yeniden düzenlediğiniz için, kıyametin kopması ve sorunların ortaya çıkması ihtimali vardır. Bahsettiğimiz korku elbette buradan geliyor. Hiç kod tabanınıza yeni birini tanıttınız mı ve özel olarak organize edilmiş bir kod parçası hakkında soru sorduktan sonra, şu satırlar boyunca yanıt verdiniz:

Yeeeaahh, bu o zamanlar mantıklı gelen eski kod ama teknik özellikler değişti ve şimdi onu düzeltmek çok mu pahalı?

Belki de onlara çok ciddi bir bakış attın ve onlara öylece bırakmalarını ve ona dokunmamalarını söyledin.

“Neden bunu yapmak isteyelim ki?” Sorusu. doğal bir süreçtir ve yeniden düzenleme süreci kadar önemli olabilir, çünkü çoğu zaman yeniden düzenleme için pahalı zamanınızı harcamanıza izin vermek için ikna etmeniz gereken başka insanlar vardır. Öyleyse, ne zaman yapmak isteyeceğinizi ve elde edilecek faydaları düşünelim:

Performans geliştirmeleri

Sürdürülebilirlik noktasından kodunuzun mevcut organizasyonundan memnunsunuz ancak yine de performansla ilgili sorunlara neden oluyor. Şu anda kurulum şeklini optimize etmek çok zor ve değişiklikler çok kırılgan olacaktır.

Burada yapılacak tek bir şey var, o da kapsamlı bir şekilde profil çıkarmak. Karşılaştırmalar yapın ve ne kadar kazanacağınıza dair tahminler yapın ve ardından bunun nasıl somut kazanımlara dönüşeceğini tahmin etmeye çalışın. Bazen önerilen kod yeniden düzenlemesinin buna değmediğini bile fark edebilirsiniz. Diğer zamanlarda, davanızı desteklemek için soğuk sabit verileriniz olacaktır.

Mimari iyileştirmeler

Belki mimari iyi ama biraz modası geçmiş, ya da kod tabanının o kısmına her dokunduğunuzda sinmeniz o kadar kötü ki. İyi ve hızlı çalışıyor ancak yeni özellikler eklemek acı verici. Bu acıda yeniden düzenlemenin ticari değeri yatmaktadır. "Acı" aynı zamanda yeniden düzenleme sürecinin yeni özellikler eklemek için daha uzun, belki de daha uzun süreceği anlamına gelir.

Ve kazanılacak bir fayda var. Önerilen büyük yeniden düzenlemeniz olsun veya olmasın birkaç örnek özellik için maliyet/fayda tahminleri yapın. Benzer farklılıkların, sistem geliştirilirken, sistemin o kısmına şimdi ve sonsuza kadar dokunan gelecek özelliklerin çoğuna uygulanacağını açıklayın. Tahminleriniz genellikle yazılım geliştirmede olduğu için yanlış olabilir, ancak oranları muhtemelen basketbol sahasında olacaktır.

Güncel hale getirmek

Bazen kod başlangıçta iyi yazılmıştır. Bundan son derece mutlusunuz. Hızlıdır, bellek açısından verimlidir, bakımı yapılabilir ve spesifikasyonlarla uyumludur. İlk olarak. Ancak daha sonra özellikler değişir, iş hedefleri değişir veya son kullanıcılarınız hakkında ilk varsayımlarınızı geçersiz kılan yeni bir şey öğrenirsiniz. Kod hala iyi çalışıyor ve bu konuda hala oldukça mutlusunuz, ancak son ürün bağlamında baktığınızda bir gariplik var. İşler biraz yanlış alt sisteme yerleştirilmiş veya özellikler yanlış sınıfta oturuyor ya da belki bazı isimler artık bir anlam ifade etmiyor. Artık tamamen farklı bir şekilde adlandırılmış ticari anlamda bir rolü yerine getiriyorlar. Bununla birlikte, herhangi bir tür büyük ölçekli Rails yeniden düzenlemesini haklı çıkarmak hala çok zordur, çünkü ilgili çalışma diğer örneklerin herhangi biri ile ölçekli olacaktır, ancak faydalar çok daha az somuttur. Bunu düşündüğünüzde, onu korumak o kadar da zor değil. Sadece bazı şeylerin aslında başka bir şey olduğunu hatırlamanız gerekiyor. Sadece A'nın aslında B anlamına geldiğini ve A üzerindeki Y özelliğinin aslında C ile ilgili olduğunu hatırlamanız gerekir.

Ve burada gerçek fayda yatıyor. Nöropsikoloji alanında, kısa süreli veya işleyen hafızamızın sadece 7+/-2 elementi tutabildiğini öne süren birçok deney vardır, bunlardan biri Sternberg deneyidir. Bir konuyu incelediğimizde temel unsurlarla başlarız ve ilk olarak üst düzey kavramları düşündüğümüzde onların tanımları hakkında düşünmemiz gerekir. Örneğin, basit bir "tuzlu SHA256 şifresi" terimini düşünün. Başlangıçta, "tuzlu" ve "SHA256" için çalışma belleği tanımlarımızı ve hatta belki bir "karma işlevi" tanımını tutmamız gerekir. Ancak terimi tam olarak anladığımızda, sezgisel olarak anladığımız için yalnızca bir bellek yuvası kaplar. Üst düzey kavramlar hakkında akıl yürütebilmek için alt düzey kavramları tam olarak anlamamız gerekmemizin nedenlerinden biri de budur. Aynı durum projemize özel terimler ve tanımlar için de geçerlidir. Ancak kodumuzu her tartıştığımızda çevirinin gerçek anlamını hatırlamak zorunda kalırsak, bu çeviri o değerli çalışan bellek yuvalarından birini işgal ediyor demektir. Bilişsel yük üretir ve kodumuzdaki mantık yoluyla akıl yürütmeyi zorlaştırır. Buna karşılık, akıl yürütmek daha zorsa, önemli bir noktayı gözden kaçırma ve bir hata ortaya çıkarma şansımız daha yüksek demektir.

Ve daha belirgin yan etkileri de unutmayalım. Müşterimizle veya sadece doğru iş şartlarını bilen herhangi biriyle değişiklikleri tartışırken kafa karışıklığı için iyi bir şans var. Ekibe katılan yeni kişilerin hem iş terminolojisine hem de koddaki karşılıklarına aşina olmaları gerekir.

Bu nedenlerin çok ikna edici olduğunu ve birçok durumda yeniden düzenleme maliyetini haklı çıkardığını düşünüyorum. Yine de dikkatli olun, ne zaman ve nasıl yeniden düzenleme yapacağınızı belirlemek için en iyi kararınızı kullanmanız gereken çok sayıda uç durum olabilir.

Sonuç olarak, büyük ölçekli yeniden düzenleme, çoğumuzun yeni bir projeye başlamaktan zevk aldığı aynı nedenlerle iyidir. O boş kaynak dosyaya bakıyorsunuz ve zihninizde cesur yeni bir dünya dönmeye başlıyor. Bu sefer doğru yapacaksın, kod zarif olacak, hem güzel hazırlanmış hem de hızlı ve sağlam ve kolay genişletilebilir olacak ve en önemlisi her gün çalışmak bir zevk olacak. Küçük ve büyük ölçekli yeniden düzenleme, bu hissi yeniden yakalamanıza, eski bir kod tabanına yeni bir soluk getirmenize ve bu teknik borcu geri ödemenize olanak tanır.

Son olarak, yeniden düzenlemenin belirli bir yeni özelliğin uygulanmasını kolaylaştıracak planlar tarafından yönlendirilmesi en iyisidir. Bu durumda, yeniden düzenleme daha odaklı olacak ve yeniden düzenleme için harcanan zamanın çoğu, özelliğin kendisinin daha hızlı uygulanmasıyla hemen geri kazanılacaktır.

Hazırlık

Kod tabanının dokunma olasılığınız olan tüm alanlarında test kapsamınızın çok iyi olduğundan emin olun. İyi kapatılmayan bazı kısımlar görürseniz, önce test kapsamını açmak için biraz zaman ayırın. Hiç testiniz yoksa, önce bu testleri oluşturmak için zaman harcamalısınız. Uygun bir test takımı oluşturamıyorsanız, kabul testlerine odaklanın ve olabildiğince çok yazın ve yeniden düzenleme yaparken birim testleri yazdığınızdan emin olun. Teorik olarak kodu yeniden düzenlemeyi iyi bir test kapsamı olmadan yapabilirsiniz, ancak çok sayıda manuel test yapmanızı ve bunu sık sık yapmanızı gerektirir. Çok daha uzun sürecek ve daha fazla hataya açık olacaktır. Sonuç olarak, test kapsamınız yeterince iyi değilse, büyük ölçekli bir Rails yeniden düzenlemesi gerçekleştirmenin maliyeti o kadar yüksek olabilir ki, ne yazık ki bunu hiç yapmamayı düşünmelisiniz. Bence bu, yeterince sık vurgulanmayan otomatik testlerin bir faydası. Otomatik testler, sık sık yeniden düzenleme yapmanıza ve daha da önemlisi bu konuda daha cesur olmanıza olanak tanır.

Test kapsamınızın iyi olduğundan emin olduktan sonra, değişikliklerinizi planlamaya başlamanın zamanı geldi. İlk başta herhangi bir kodlama yapmamalısınız. İlgili tüm değişikliklerin kabaca haritasını çıkarmanız ve tüm sonuçları kod tabanı aracılığıyla izlemeniz ve tüm bunlarla ilgili bilgileri zihninize yüklemeniz gerekir. Amacınız, bir şeyi neden değiştirdiğinizi ve bunun kod tabanında oynadığı rolü tam olarak anlamaktır. Sırf değiştirilmesi gerekiyormuş gibi göründüğü için veya bir şey bozulduğu için bir şeyleri değiştirirken tökezlerseniz ve bu onu düzeltiyor gibi görünüyorsa, muhtemelen çıkmaz bir sokağa girersiniz. Yeni kod çalışıyor gibi görünüyor, ancak yanlış ve şimdi yaptığınız tüm değişiklikleri hatırlayamıyorsunuz bile. Bu noktada, büyük ölçekli kod yeniden düzenleme konusunda yaptığınız işi bırakmanız gerekebilir ve aslında zamanınızı boşa harcamış olursunuz. Bu nedenle, biraz zaman ayırın ve yapmak üzere olduğunuz her değişikliğin sonuçlarını anlamak için kodu inceleyin. Sonunda cömertçe ödeyecek.

Yeniden düzenleme işlemi için bir yardıma ihtiyacınız olacak. Başka bir şey tercih edebilirsin ama ben basit bir boş kağıt ve kalemi severim. Kağıdın sol üst köşesine yapmak istediğim ilk değişikliği yazarak başlıyorum. Sonra değişimden etkilenen tüm yerleri aramaya başlıyorum ve ilk değişikliğin altına yazıyorum. Burada kararınızı kullanmanız önemlidir. Sonuç olarak, kağıt üzerindeki notlar ve diyagramlar sizin için oradadır, bu nedenle hafızanıza en uygun stili seçin. Altlarında madde işareti işaretleri olan kısa kod parçacıkları ve buna doğrudan (tam ok) veya dolaylı olarak (kesikli oklar) bağlı olan şeyleri gösteren bu tür diğer notlara götüren birçok ok yazıyorum. Ayrıca, kod tabanında fark ettiğim belirli bir şeyi hatırlatmak için oklara stenografi işaretleriyle açıklama ekliyorum. Unutmayın, bu notlara yalnızca önümüzdeki birkaç gün içinde, bunlarda planlanan değişiklikleri gerçekleştirirken geri döneceksiniz ve çok kısa ve şifreli hatırlatıcılar kullanmakta sorun yok, böylece daha az yer kaplarlar ve kağıt üzerinde daha kolay düzenlenebilirler. . Rails'in yeniden düzenlemesinden aylar sonra birkaç kez masamı temizliyordum ve o kağıtlardan birini buldum. Tamamen anlamsızdı, o kağıttaki hiçbir şeyin ne anlama geldiğine dair hiçbir fikrim yoktu, bunun delirmiş biri tarafından yazılmış olması dışında. Ama problem üzerinde çalışırken o kağıt parçasının vazgeçilmez olduğunu biliyorum. Ayrıca, her değişikliği tek tek yazmanız gerektiğini düşünmeyin. Bunları gruplayabilir ve detayları farklı bir şekilde takip edebilirsiniz. Örneğin, ana makalenizde “Ab'nin tüm oluşumlarını Cd'ye yeniden adlandırmanız” gerektiğini not edebilir ve ardından özellikleri birkaç farklı şekilde takip edebilirsiniz. Hepsini ayrı bir kağıda yazabilir, tüm oluşumları için bir kez daha küresel bir arama yapmayı planlayabilir veya değişikliğin yapılması gereken tüm kaynak dosyaları seçtiğiniz düzenleyicide açık bırakabilirsiniz. ve değişikliklerin haritasını çıkarmayı bitirdikten sonra bunları gözden geçirmek için zihinsel bir not alın.

İlk değişikliğinizin sonuçlarının haritasını çıkardığınızda, doğası gereği büyük ölçekli olması nedeniyle, büyük olasılıkla, daha fazla sonucu olan ek değişiklikleri belirleyeceksiniz. Tüm bağımlı değişiklikleri not ederek analizi onlar için de tekrarlayın. Değişikliklerin boyutuna bağlı olarak, bunları aynı kağıda yazabilir veya yeni bir boş kağıt seçebilirsiniz. Değişikliklerin haritasını çıkarırken denenmesi ve yapılması gereken çok önemli bir şey, dallanma değişikliklerini gerçekten durdurabileceğiniz sınırları denemek ve belirlemektir. Yeniden düzenlemeyi en küçük mantıklı, yuvarlak, değişiklik kümesiyle sınırlamak istiyorsunuz. Sadece durabileceğiniz ve gerisini olduğu gibi bırakabileceğiniz bir nokta görürseniz, yeniden düzenlenmesi gerektiğini görseniz bile, kavram olarak diğer değişikliklerinizle ilgili olsa bile bunu yapın. Bu kod yeniden düzenleme turunu tamamlayın, kapsamlı bir şekilde test edin, dağıtın ve daha fazlası için geri gelin. Değişikliklerin boyutunu yönetilebilir tutmak için aktif olarak bu noktaları arıyor olmalısınız. Tabii ki, her zaman olduğu gibi, bir yargılama çağrısı yapın. Sıklıkla, biraz arayüz çevirisi yapmak için bazı proxy sınıfları ekleyerek yeniden düzenleme sürecini kesebileceğim bir noktaya geldim. Hatta yeniden düzenlemeyi “doğal bir durma” (yani neredeyse hiç proxy koduna gerek yok) noktası olacak noktaya kadar biraz daha ileri itmek kadar iş olacaklarını fark ettiğimde onları uygulamaya başladım. Daha sonra geri döndüm, son değişikliklerimi geri aldım ve yeniden düzenledim. Her şey biraz keşfedilmemiş bölgelerin haritasını çıkarmaya benziyorsa, bunun nedeni, bölge haritalarının yalnızca iki boyutlu olması dışında, öyle hissediyorum.

Uygulamak

Yeniden düzenleme hazırlığınızı yaptıktan sonra, planı uygulama zamanı. Konsantrasyonunuzun yüksek olduğundan emin olun ve dikkat dağıtıcı olmayan bir ortam sağlayın. Bazen bu noktada internet bağlantısını tamamen kapatacak kadar ileri gidiyorum. Mesele şu ki, eğer iyi hazırlandıysanız, yanınızdaki kağıda iyi bir not seti bulundurun ve konsantrasyonunuz arttı! Değişiklikler arasında genellikle bu şekilde çok hızlı hareket edebilirsiniz. Teorik olarak, işin çoğu önceden, hazırlık sırasında yapıldı.

Kodu gerçekten yeniden düzenlediğinizde, çok özel bir şey yapan ve hatalı kod gibi görünebilecek garip kod parçalarına dikkat edin. Belki kötü kodlardır, ancak çoğu zaman üretimdeki bir hatayı araştırırken keşfedilen garip bir köşe vakasını ele alıyorlar. Zamanla, çoğu Rails kodu, örneğin, burada IE6 için gerekli olan garip bir yanıt kodu veya orada garip bir zamanlama hatasını işleyen bir koşul gibi garip köşe vaka hatalarını işleyen "tüyler" veya "siğiller" büyür. Büyük resim için önemli değiller ama yine de önemli ayrıntılar. İdeal olarak, önce bunları kapsamaya çalışmazlarsa, açıkça birim testleri ile kapsanırlar. Bir zamanlar orta ölçekli bir uygulamayı Rails 2'den Rails 3'e taşımakla görevlendirildim. Kodu çok iyi biliyordum ama kod biraz karışıktı ve dikkate alınması gereken pek çok değişiklik vardı, bu yüzden yeniden uygulamayı seçtim. Aslında, bu gerçek bir yeniden uygulama değildi, çünkü bu neredeyse hiç akıllıca bir hareket değildi, ancak boş bir Rails 3 uygulamasıyla başladım ve kabaca açıklanan süreci kullanarak eski uygulamanın dikey dilimlerini yenisine dönüştürdüm. Dikey bir dilimi her bitirdiğimde, eski Rails kodunu inceledim, her satıra baktım ve yeni kodda karşılığı olup olmadığını iki kez kontrol ettim. Esasen, tüm eski kod “kıllarını” seçiyor ve onları yeni kod tabanında kopyalıyordum. Sonunda, yeni kod tabanında tüm köşe vakaları ele alındı.

Yeterince sık manuel test yaptığınızdan emin olun. Hem sizi yeniden düzenleme sürecinde sistemin bir bölümünü test etmenize izin verecek doğal “kırılmalar” aramaya zorlayacak hem de süreçte kırılmayı beklemediğiniz hiçbir şeyi kırmadığınız konusunda size güven verecektir. .

topla

Rails kodunuzu yeniden düzenlemeyi tamamladığınızda, tüm değişikliklerinizi son bir kez gözden geçirdiğinizden emin olun. Tüm farka bakın ve üzerinden geçin. Oldukça sık, yeniden düzenlemenin başında gözden kaçırdığınız ince şeyleri fark edeceksiniz çünkü şu anda sahip olduğunuz bilgiye sahip değilsiniz. Bu, büyük ölçekli yeniden düzenlemenin güzel bir avantajıdır: özellikle orijinal olarak yazmadıysanız, kod organizasyonunun daha net bir zihinsel görüntüsünü elde edersiniz.

Mümkünse, bir meslektaşınızdan da incelemesini isteyin. Kod tabanının tam olarak bu kısmına özellikle aşina olması bile gerekmez, ancak projeye ve koduna genel bir aşinalığı olmalıdır. Değişiklikler üzerinde yeni bir bakış açısına sahip olmak çok yardımcı olabilir. Onlara bakması için kesinlikle başka bir geliştirici bulamazsanız, kendiniz gibi davranmanız gerekir. İyi bir gece uykusu alın ve taze bir zihinle gözden geçirin.

Kalite güvenceniz yoksa, o şapkayı da takmanız gerekir. Yine, bir ara verin ve kendinizi koddan uzaklaştırın, ardından manuel test yapmak için geri dönün. Az önce, bir sürü aletle darmadağın bir elektrik tesisatı kabinine girmenin eşdeğerini yaşadınız ve hepsini sıraladı, muhtemelen bir şeyleri kesip yeniden kabloladı, bu yüzden normalden biraz daha fazla özen gösterilmesi gerekiyor.

Son olarak, şimdi çok daha temiz ve uygulanması daha kolay olacak tüm planlı değişiklikleri göz önünde bulundurarak emeğinizin meyvelerinin tadını çıkarın.

Ne zaman yapmazsın?

Proje kodunu taze ve yüksek kalitede tutmak için düzenli olarak büyük ölçekli yeniden düzenleme yapmanın birçok faydası olsa da, yine de çok maliyetli bir işlemdir. Tavsiye edilmeyeceği durumlar da vardır:

Test kapsamınız zayıf

Belirtildiği gibi: çok zayıf test kapsamı büyük bir sorun olabilir. Kendi kararınızı kullanın, ancak yeni özellikler üzerinde çalışırken ve mümkün olduğunca çok sayıda yerelleştirilmiş küçük ölçekli yeniden düzenleme gerçekleştirirken kapsamı genişletmeye odaklanmak kısa vadede daha iyi olabilir. Bu, dalmaya karar verdiğinizde ve kod tabanının daha büyük kısımlarını sıralamaya karar verdiğinizde size çok yardımcı olacaktır.

Yeniden düzenleme, yeni bir özellik tarafından yönlendirilmiyor ve kod temeli uzun süredir değişmedi

“Kod tabanı değişmeyecek” demek yerine bilerek geçmiş zaman kullandım. Deneyimden yola çıkarak (ve deneyimle birçok kez yanılmış olmayı kastediyorum), kod tabanının belirli bir bölümünün ne zaman değiştirilmesi gerektiğine dair tahminlerinize neredeyse asla güvenemezsiniz. Öyleyse, bir sonraki en iyi şeyi yapın: geçmişe bakın ve geçmişin kendini tekrar edeceğini varsayın. Bir şey uzun süredir değiştirilmediyse, muhtemelen şimdi değiştirmenize gerek yoktur. Bu değişikliğin gelmesini bekleyin ve başka bir şey üzerinde çalışın.

zaman için baskı altındasın

Bakım, proje yaşam döngüsündeki en pahalı kısımdır ve yeniden düzenleme, onu daha ucuz hale getirir. Herhangi bir işletmenin gelecekteki bakımı daha ucuz hale getirmek için teknik borcu azaltmak için yeniden düzenlemeyi kullanması kesinlikle gereklidir. Aksi takdirde, yeni özellikler eklemenin giderek daha pahalı hale geldiği bir kısır döngüye girme tehlikesiyle karşı karşıyadır. Umarım bunun neden kötü olduğu aşikardır.

Bununla birlikte, büyük ölçekli yeniden düzenleme, ne kadar süreceği konusunda çok, çok tahmin edilemez ve bunu yarı yolda yapmamalısınız. Herhangi bir iç veya dış nedenden dolayı size zaman baskısı yapılıyorsa ve bu süre içinde bitirebileceğinizden emin değilseniz, yeniden düzenlemeyi bırakmanız gerekebilir. Basınç ve stres, özellikle zamana bağlı tür, büyük ölçekli yeniden düzenleme için kesinlikle gerekli olan daha düşük konsantrasyon düzeyine yol açar. Bunun için zaman ayırmak için ekibinizden daha fazla “katılım” elde etmeye çalışın ve zamanınızın olacağı bir dönem için takviminize bakın. Sürekli bir zaman dilimi olması gerekli değildir. Elbette çözmeniz gereken başka sorunlarınız olacak, ancak bu molalar bir veya iki günü geçmemelidir. Eğer öyleyse, kendinize kendi planınızı hatırlatmanız gerekecek çünkü kod tabanı hakkında öğrendiklerinizi ve tam olarak nerede durduğunuzu unutmaya başlayacaksınız.

Çözüm

Umarım size bazı yararlı yönergeler vermişimdir ve sizi belirli durumlarda büyük ölçekli yeniden düzenleme yapmanın faydalarına ve gerekliliğini söylemeye cesaret edebilirim. Konu çok belirsiz ve elbette burada söylenen hiçbir şey kesin bir gerçek değil ve ayrıntılar projeden projeye değişecek. Bana göre genel olarak geçerli olan tavsiyelerde bulunmaya çalıştım, ancak her zaman olduğu gibi, kendi özel durumunuzu düşünün ve kendi deneyiminizi belirli zorluklara uyum sağlamak için kullanın. İyi şanslar yeniden düzenleme!