SWC, Babel gibi uyumlu JavaScript kodu üretmeye ve paketlemeye odaklanırken, bu ise TypeScript kodunu JavaScript'e dönüştürmeye veya hataları kontrol etmeye odaklanıyor.
Basit ama ezberlemesi zor kodları yazarken (dosya G/Ç işlemleri, container kullanımı vb.)
Derleme veya çalışma zamanı hatası oluştuğunda bunun ne tür bir hata olduğunu ve hangi kodun buna sebep olduğunu anlamaya çalışırken
Daha önce yazılmış bir işleve benzer ama biraz farklı işlev eklenmiş bir işlevi yeniden yazmak istediğimde
Bir kütüphaneye bağımlı kodu başka bir kütüphaneyle değiştirmek ya da kendi işlevimle ikame etmek istediğimde
Belirli bir özelliği uygularken ya da belirli bir ortamda çalışırken nasıl geliştirme yapılacağına dair rehbere ihtiyaç duyduğumda
Yukarıdaki gibi durumlarda epey zaman kazandırdı. Google + Stack Overflow kombinasyonuyla da iyi bulunmayan durumlar çok oluyor; özellikle Stack Overflow'da bir yanıt varsa yorumlarda sürekli itirazlar çıkması, eski sürüm uygulama yöntemleri olup artık kullanılmaması gerektiği gibi sorunlar yüzünden gerçekten çok sinir bozucu oluyordu...
1-2 haftaya bölündüğünde, doğal olarak tek bir özelliğe dair genel resmi yalnızca sınırlı sayıda kişinin bileceğini düşünüyorum. Tıpkı process ve thread arasındaki fark gibi. Yani ilgiyi sınırlayarak üretkenliği artırmak söz konusu.
Genel resim paylaşılsa bile, insanların bu resim hakkında soru işaretleri taşıyacağı varsayımı var; ama sanırım ben de doğal olarak, her sprint planlamasında biraz biraz değişen yön doğrultusunda o büyük resmin nasıl takip edildiğini yakalayamama varsayımını yapmışım.
Bu kadar küçük görevlere bölündüğünde, büyük resmi elinde tutan lider çok fazla yetki sahibi oluyor. Birlikte çalışan mühendisler ise tam tersine motivasyon kaybı yaşıyor ve "Biz tam olarak nereye gidiyoruz?" noktasına geliyor. Sprint tabanlı agile'ın en tipik dezavantajlarından biri bu.
Bence yazı fazla liderin bakış açısından yazılmış; başlıkta dendiği gibi.
Mühendislerin momentumu, liderin bayrağı hangi yöne tuttuğundan da büyük ölçüde etkilenir. Müşteriye verilmek istenen değerin ne olduğu, her sprintteki output ile teslim edilen outcomeun ne olduğunun nasıl ortaya konabileceği konusunda da biraz daha düşünmek gerekiyor gibi görünüyor. Elbette bunlar zor soft skill'ler; bu yüzden gerçekten iyi yapan lider görmek de zor, bu konuda yazı da pek yok.
Dotnet anlaşılır ama bence Rust, Go ile aynı konumda. Muhtemelen mevcut olarak yapılmış JS ile ilgili Go projeleri ve kütüphaneleri de bu kararı etkilemiş gibi görünüyor.
Ancak en yeni teknolojileri(?) devreye almak istediğinizde JUnit4 sık sık ayak bağı olabiliyor; bu yüzden kişisel olarak JUnit5'e geçilmiş olmasını dileyen küçük bir temennim var. https://docs.gradle.com/develocity/test-distribution/
junit-vintage-engine kullanılırsa büyük değişiklikler yapmadan junit4 testlerini junit5 üzerinde çalıştırmak mümkün, ancak ek yük oldukça fazla. (yaklaşık %20 kadar yavaşlıyor)
Bir şekilde Android uygulama build mühendisi olarak yerleşmiş biri olarak fikrimi bırakacak olursam..
Build: gradle
Çok büyük ya da karmaşık olsa bile gradle kullanmak gerekiyor... (uzaklara dalan bakış)
Çok büyük ya da karmaşık projelerde gradle’ın build performansını iyileştirmek için aşağıdaki projeler yürütülüyor; bu yüzden büyük projelerde gradle kullanıyorsanız, migration hazırlıklarını şimdiden yapmakta fayda var.
Kişisel olarak, mimari katmanları özellikle build sistemine görünür kılmak için bir neden olmadığını düşünüyorum.
Benim yönettiğim uygulamada modülleri feature-api / feature-impl olarak build sistemine görünür olacak şekilde düzenliyoruz.
feature-app:
Veri modeli veya başka modüllerle entegre olan interface
feature-impl:
feature’ın gerçek implementasyonu
Bu şekilde yapılandırınca, feature-impl içindeki kod değişiklikleri feature-api’yi referans alan diğer modülleri etkilemediği için (dependency isolation), incremental build ya da build cache hit rate artışı açısından çok faydalı oluyor.
Birim testi - junit 4
Burada Google’ın kararının büyük rol oynadığını düşünüyorum.
Makro engelleme aşma özelliği eklenirse.. pazarda kazananın o olacağını düşünüyorum.
Görünüşe göre tartışma epey hararetli; Anders Hejlsberg bizzat yorum bırakmış.
https://github.com/microsoft/typescript-go/…
Evet, aynen o!
TypeScript ile derleyip çıktının doğrudan ikili dosya olarak gelmesini isteyen biri
İyi kaynak tanıtımı için teşekkürler.
SWC, Babel gibi uyumlu JavaScript kodu üretmeye ve paketlemeye odaklanırken, bu ise TypeScript kodunu JavaScript'e dönüştürmeye veya hataları kontrol etmeye odaklanıyor.
Benim deneyimime de benzer geliyor.
Yukarıdaki gibi durumlarda epey zaman kazandırdı. Google + Stack Overflow kombinasyonuyla da iyi bulunmayan durumlar çok oluyor; özellikle Stack Overflow'da bir yanıt varsa yorumlarda sürekli itirazlar çıkması, eski sürüm uygulama yöntemleri olup artık kullanılmaması gerektiği gibi sorunlar yüzünden gerçekten çok sinir bozucu oluyordu...
1-2 haftaya bölündüğünde, doğal olarak tek bir özelliğe dair genel resmi yalnızca sınırlı sayıda kişinin bileceğini düşünüyorum. Tıpkı process ve thread arasındaki fark gibi. Yani ilgiyi sınırlayarak üretkenliği artırmak söz konusu.
Genel resim paylaşılsa bile, insanların bu resim hakkında soru işaretleri taşıyacağı varsayımı var; ama sanırım ben de doğal olarak, her sprint planlamasında biraz biraz değişen yön doğrultusunda o büyük resmin nasıl takip edildiğini yakalayamama varsayımını yapmışım.
Büyük resmi paylaşmak ve herkesin anladığından emin olduktan sonra işi küçük görevlere bölmek gerekmiyor mu??
Güzel yazı için teşekkürler
Bu kadar küçük görevlere bölündüğünde, büyük resmi elinde tutan lider çok fazla yetki sahibi oluyor. Birlikte çalışan mühendisler ise tam tersine motivasyon kaybı yaşıyor ve "Biz tam olarak nereye gidiyoruz?" noktasına geliyor. Sprint tabanlı agile'ın en tipik dezavantajlarından biri bu.
Bence yazı fazla liderin bakış açısından yazılmış; başlıkta dendiği gibi.
Mühendislerin momentumu, liderin bayrağı hangi yöne tuttuğundan da büyük ölçüde etkilenir. Müşteriye verilmek istenen değerin ne olduğu, her sprintteki
outputile teslim edilenoutcomeun ne olduğunun nasıl ortaya konabileceği konusunda da biraz daha düşünmek gerekiyor gibi görünüyor. Elbette bunlar zor soft skill'ler; bu yüzden gerçekten iyi yapan lider görmek de zor, bu konuda yazı da pek yok.Front-end konusunda yabancıyım da.. swc'den farklı mı?
Şu an sabah 8:40 ve dalgınlıkla bir baktım, tam olarak 7:40:28 PM EST görünüyor... Ne ilginç
McDonald's’a gitmek kolay görünüyor. Eğlenceli bir deneyim olacak gibi duruyor.
Dotnet anlaşılır ama bence Rust, Go ile aynı konumda. Muhtemelen mevcut olarak yapılmış JS ile ilgili Go projeleri ve kütüphaneleri de bu kararı etkilemiş gibi görünüyor.
Gerçekten çok özgün bir fikir ama diğer yorumlarda da olduğu gibi, yoğun trafik akışını nasıl çözeceklerini ben de merak ediyorum.
Sanırım Node gibi bir runtime'dan bahsediyorsunuz; ancak burada kastedilen, TS dilinin derleyicisinin kendisi.
> TypeScript kodu artık TypeScript ile yazılmıyorsa, ekibin doğrudan TypeScript kullanmaması uzun vadede geliştirme deneyimini etkileyebilir.
Buna "kendi yaptığını kullanmak" deniyor ya. Kendi yaptığın şeyi bizzat kullanmak. Ama konu bir dil olunca, insan biraz düşünüyor.
Ancak en yeni teknolojileri(?) devreye almak istediğinizde JUnit4 sık sık ayak bağı olabiliyor; bu yüzden kişisel olarak JUnit5'e geçilmiş olmasını dileyen küçük bir temennim var.
https://docs.gradle.com/develocity/test-distribution/
junit-vintage-enginekullanılırsa büyük değişiklikler yapmadan junit4 testlerini junit5 üzerinde çalıştırmak mümkün, ancak ek yük oldukça fazla. (yaklaşık %20 kadar yavaşlıyor)Bir şekilde Android uygulama build mühendisi olarak yerleşmiş biri olarak fikrimi bırakacak olursam..
Çok büyük ya da karmaşık olsa bile gradle kullanmak gerekiyor... (uzaklara dalan bakış)
Çok büyük ya da karmaşık projelerde gradle’ın build performansını iyileştirmek için aşağıdaki projeler yürütülüyor; bu yüzden büyük projelerde gradle kullanıyorsanız, migration hazırlıklarını şimdiden yapmakta fayda var.
Kişisel olarak, mimari katmanları özellikle build sistemine görünür kılmak için bir neden olmadığını düşünüyorum.
Benim yönettiğim uygulamada modülleri feature-api / feature-impl olarak build sistemine görünür olacak şekilde düzenliyoruz.
Bu şekilde yapılandırınca, feature-impl içindeki kod değişiklikleri feature-api’yi referans alan diğer modülleri etkilemediği için (dependency isolation), incremental build ya da build cache hit rate artışı açısından çok faydalı oluyor.
Burada Google’ın kararının büyük rol oynadığını düşünüyorum.
Ama yakın zamanda yayınlanan screenshot testing plugin ise JUnit5 tabanlı.