1. Tüm yeni kodu Typescript'e yazın - bazen
Daha sonra taşınması için daha fazla kod iterek ekibiniz için fazladan iş yaratmayın - Typescript yığınınıza dahil edilir edilmez, ileriye dönük her çekme isteği TS'de yazılmalıdır. Ama bu ne kadar katı olmalı? TS'de yeni dosyalar ve bileşenler yazmak yeterince kolaydır, peki ya mevcut dosyalardaki değişiklikler? Bir çekme isteği bir dosyada yalnızca bir satırı değiştirirse, tüm dosya dönüştürülmeli mi?
Geliştiricilerin her değişen dosyayı taşımasını zorunlu kılmak moral ve üretkenlik katili olabilir. En küçük hata düzeltmeleri bile ev işleri haline gelir ve yeni özellikler için PR'lerin gözden geçirilmesi imkansızdır çünkü diff, taşınan dosyaları yeni olarak değerlendirir. Öte yandan, geçiş gerekli değilse, iş asla bitmeyebilir. Bu, özellikle sık düzenlenmeyen eski dosyalar için geçerlidir. Ekibiniz için anlamlı olan ve geçişin ilerlemesini sağlayan dengeyi bulun.
2. Önce ortak dosyaları ve genel bileşenleri dönüştürün
Herhangi bir yeni özellik çalışmasında içe aktarılma olasılığı en yüksek olan dosyaları hedefleyerek Typescript'in özelliklerinden en hızlı şekilde yararlanacaksınız. Bu paylaşılan bileşenler dönüştürülmezse, tüm yeni TS dosyalarınızda teknoloji borcu oluşturuyorsunuz. Bunun önüne geçin ve tüm yeni dosyalarınızda otomatik tamamlamanın ve anlık hataların keyfini çıkarın.
Bu temel bileşenlerde API'nin tüm özellikleri için mevcut olan en doğru türü kullanın. İşlevler, geri aramalar ve olaylar için kesin türü bulmak zor olabilir (özellikle React olayları, DOM özellikleri veya üçüncü taraf bağımlılıkları için), ancak tüketicilerinizdeki aşağı akış sorunlarından kurtarır. Temel bileşenleri doğru bir şekilde almak için yavaş ilerlemek, genel olarak size zaman kazandıracaktır.
3. Yaklaşan geçişler hakkında ekibinizle iletişim kurun
Birden fazla geliştirici aynı dosyada çalışıyorsa, geçişler bazen kabus gibi birleştirme çatışmalarına yol açan büyük farklar yaratabilir. Kendinizi sinir bozucu ve buggy çatışma çözümlerinin anlamsız saatlerine hazırlamayın. Bir geçişe başlamadan önce ekibinizle görüşün. Kodun o alanında önemli bir faaliyet varsa, işi ertelemeyi veya şubenizi onlarınkinden ayırmayı düşünün.
4. Yeniden düzenleme dürtüsüne direnin
Herhangi bir büyük kod tabanını taşırken, kaçınılmaz olarak kendinizi korkunç bir borçla eski dosyaları açarken bulacaksınız. Brüt, tüm bu kullanımdan kaldırılmış kalıplara ve verimsizliklere bir bakın. Oh, bunu satırların üçte birine kesinlikle yazabilirsin. Artık kimse bu işlevi kullanmıyor, değil mi? Snip-snip.
Bu kibir. Yapma. Regresyonlar yaratacaksınız. Kendinize ve ekibinize iyi davranın. QA'yı vurgulamayın.
5. Aynı bileşenin paralel sürümlerini korumaktan kaçının
Bazen, karmaşık veya çok kullanılan bir bileşeni taşımak, yerinde bir dönüşümü riske atmak için çok zahmetlidir - bu tür durumlarda, tek seçenek, kod tabanınız boyunca eskiyi çoğaltmak, dönüştürmek ve yavaş yavaş yenisiyle değiştirmek olabilir. Ancak her iki sürüm de mevcut olduğu sürece, hangisinin kullanılacağı konusunda kafa karışıklığı olacaktır; eskisi alışkanlık veya kopyala-yapıştır yoluyla ithal edilecek; hata düzeltmelerinin ve geliştirmelerin her ikisine de uygulanması gerekecektir; davranış zamanla bile değişebilir.
Bu durumda harcanan zamanı en aza indirin - yinelenen bir TS bileşeni eklerken, bu geçiş alanına öncelik verin. İçe aktarırken karışıklığı önlemek için dosyalarınızı ve bileşenlerinizi net bir şekilde adlandırın.
6. Tahminler ve planlamadaki geçişleri hesaba katın
Gelecekteki çalışmalar için zaman veya nokta tahminleri sağlarken, önce kodu taşımayı planlıyorsanız,% 20 daha ekleyin. Geçişlerinizi planlayın; Bir alanda önemli çalışmaların yapılacağını biliyorsanız, geçişi erken yaptırın. Görünmez veya beklenmedik bir maliyet olarak bırakmayın.
7. veya kullandığınızda bir yorum bırakınts-ignoreany
Üçüncü taraf bağımlılıklarınızdan bazıları, günlerce kafanızı kaşıymanıza neden olacak yanlış tür tanımları verecektir. Genel kayıtlara sahip belirsiz bir köşe kasası, sizi 5 saat boyunca bir Yığın Taşması solucan deliği gönderecektir. En büyük fayda, ilerlemeye devam etmek ve bir saldırıya zorlandığınızda iyi yorumlar bırakmaktır.
8. Kalmasına izin vermeyin
Typescript için olası geçiş yollarından biri, katılığını aşamalı olarak artırmaktır; Bu kuralları kapatmak başlangıçta yardımcı olabilir, ancak bunu uzun süre ertelemek ekibinizin dilin tüm avantajlarından uzak durmasını sağlayacaktır. Başlangıçta gerekli bağımlılıkları taşıdığınız için yüksek bir maliyet olabilir, böylece tek bir bileşen bile tam olarak yazılabilir, ancak etkinleştirdiğinizde ufukta büyük bir farkla karşılaşmaktan daha iyidir.
Değişim hızında patlama ve çöküş dönemleri olacak, ancak orta göç teknoloji borcu başa çıkmak için yorucu. Hangi bileşenin dönüştürüldüğünü asla hatırlayamazsınız. Kodunuzdaki en büyük hatalardan bazılarını yakalamak için hala IDE'ye güvenemezsiniz. Neden en başta bu aptal geçişi başlattık?
Ancak, güçlü bir şekilde yazılmış bir dilin erdemleri, kod tabanının çoğu dönüştürüldükçe katlanarak büyür. Bir çekirdek bileşeni ilk kez yeniden düzenlediğinizde ve derleyici derhal düzeltmelerin gerekli olduğu satır ve sütuna kadar size söyler, hepsi buna değer. Elbette, diğer dillerin çoğu on yıllardır bu deneyimi yaşadı, ancak Javascript değil.
İyi şanslar! Bu çok iş ama sonunda karşılığını alacaksınız.
