Bu gerçekten ikircikli bir durum. Bir yandan çok iyi. Sonuna asla ulaşılamayacağını bile bile tepeden başlayıp kazır gibi ilerleyen backlog temizlik toplantısı yaşamamış biri var mıdır bilmiyorum; o his kesinlikle berbat
Öte yandan sorunlar ortadan kalkmış değil, sadece etiketleri değişmiş oluyor; mesele tamamen etiketler ve düzenlemeyse, kusursuzca boş bir issue listesi gibi sözde bir ütopyayı kontrol etmeye çalışmak yerine akışına bırakmak gerekmez mi diye düşünüyorum. Böyle notları görünür bir yerde tutmanın da mutlaka faydaları vardır. Büyük temizlik sırasında atmaya karar verdiğin ama bilinçaltının “ileride lazım olabilir” diye tutmanı söylediği şeye benziyor
Yine de genel olarak destekleyen taraftayım. En azından bir özgürleşme hissi ve yeni issue’lara yönelik yeniden enerji toplama etkisi olur gibi
Biraz daha bağlam eklersek, geliştirici tam bir yeniden yazım yapıyor
Yeniden yazılmış sürümü önce yayımlayıp ardından mevcut issue’ları deprecated olarak kapatmak daha temiz olurdu sanki. Yeniden yazım branch’indeki issue’lar sürüm etiketleriyle ayrılabilirdi. Yeni sürüm henüz bitmemişken kapatılırsa, katkıda bulunanlar artık desteklenmediğini bilmeden mevcut sürüme yeni issue açabilir
Yine de issue’ları görmezden gelip kod tabanındaki sorunları öylece bırakıyor değiller; projenin tamamı yeniden elden geçiriliyor https://twitter.com/jdalton/status/1571863497969119238
Kullanıcı açısından böyle bir “temizlik” issue’ları kapatmak anlamına geliyorsa sorunlu. Üründe hâlâ var olan bir issue ise hem dokümantasyon açısından hem de aynı sorunu yaşayan kullanıcıların kolayca bulup ekleme yapabilmesi için açık kalmalı
Bence projenin issue’nun varlığını kabul edip açık bırakması daha dürüstçe. Geliştirici açısından issue sayısı göze batıyorsa eski ve önemsiz issue’ları gizleyen bir filtre kullanmak daha iyi olur
Ben de ikircikliyim. Bir yandan JavaScript işlerine her döndüğümde lodash’a yöneliyorum. Öte yandan bu kütüphanenin yarısından biraz azı keşke standart kütüphanede yer alsaydı diye düşünüyorum
Bu tür işler büyük dil modellerinin iyi yapması gereken şeylerden değil mi? Ticket özetleme yani
Bu yüzden Basecamp backlog tutmuyor. Önemli olan şey zaten tekrar su yüzüne çıkar
jwz şöyle demişti
Açık kaynak yazılım projelerine bildirdiğim hataların kapatılmasının en yaygın biçiminin bu olduğunu düşünüyorum. Bir hata bildiriyorsun; 1 yıl, bazen 2 yıl okunmadan kalıyor, sonra bir gün o modül baştan yazılıyor. Ve yeni bakımcı, yeni sürümün önceki sürümde var olduğu bilinen sorunu gerçekten çözüp çözmediğini kontrol etmeye istekli olmuyor
Bakımcısı az olan ya da tek kişilik projelerde, tek bakımcının doğrulama için günler ya da haftalar harcaması yerine hata bildirenlerin her birinin 10-15 dakika ayırıp sorunun hâlâ var olup olmadığını kontrol etmesi daha mantıklı olmaz mı diye düşünüyorum
Özellikle yeniden üretmesi zor ya da karmaşık hatalarda, bakımcının kendi ortamında bunu yeniden üretebilip üretemeyeceği bile belirsizdir; bildiren kişinin o hatayı gözlemlemeye daha alışık olma ihtimali de yüksektir
Daha büyük bir ekip varsa ya da ticari bir servisin eşlik eden projesiyse bu denge biraz değişebilir
Pek çok özgür/açık kaynak projede görülen şey şu: kolları sıvamak isteyen çok az kişi var, ama aynı zamanda o projenin kendileri için ne kadar vazgeçilmez olduğunu anlatmaya, talep etmeye ve çok sayıda öneride bulunmaya epey zaman harcıyorlar
Çoğunluk, istek listesini duyurmak için yeni issue açıyor ya da çok belirsiz hata bildirimleri bırakıyor. Bazıları düzgün hata raporları da sunuyor ama katkı isteği genelde orada bitiyor
Şahsen sık görülen yorumların çoğunu diplomatik biçimde ele alma iradesine sahip olmadığım için proje bakımcılığına uygun bir karakterim yok
Yine de bildirdiğim issue’larda nedenini izlemeye ve mümkünse düzelten bir PR göndermeye çalışarak kendi payıma düşeni yapmaya hep gayret ediyorum
Bunun bir varyasyonu da var. Bir ana sürüm hakkında issue bildirilmişken yeni bir ana sürüm çıkınca, yeniden yazım bile değil yalnızca kademeli değişiklik olmasına rağmen sorun artık olmayabilir gerekçesiyle önceki sürüm issue’larının tamamını kapatmak
Geçmesi gereken ama şu anda atlanacak olarak işaretlenmiş testleri içeren bir PR oluşturmak yeterli. Böylece yeniden inşa ederken ilerleme durumunu kontrol etmek ve iyileşme olup olmadığını görmek için kolay bir yol oluşur
Gerçekten önemsediğin bir sorunsa test eklemelisin
Güvenlik bulguları da bazen böyle ele alınıyor
Kapalı kaynak yazılım projelerinde de benim deneyimim aynı
lodash’ın yazarı John-David Dalton [geçen yıl şöyle][1] yazmıştı
lodash yeniden yazımında teknik borç iflası ilan ediyorum. TypeScript ve Rollup ile sıfırdan başlıyorum. FP wrapper yok. O moda bitti. O baş ağrısını kod tabanına sokan kişinin çalışma arkadaşlarına başsağlığı. Ne ekipler için ne de insanlar için hiç dostça değil
%100 aynen böyle mi ilerliyor bilmiyorum ama oldukça yakın görünüyor
[1]: https://twitter.com/jdalton/status/1571863497969119238
“O moda bitti. O baş ağrısını kod tabanına sokan kişinin çalışma arkadaşlarına başsağlığı. Ne ekipler için ne de insanlar için hiç dostça değil” diyor; asıl yazarı kendisi değil mi?
Sanki eleştirdiği karmaşıklığı başka biri eklemiş gibi geliyor. Bunu kendisi getirdiyse, bir iç değerlendirme ya da öğrenilmiş ders gibi söylemekten ziyade, projeyi bir modaya göre geliştirip şimdi o moda bittiğine göre sıradakine geçme zamanı gelmiş gibi konuşuyor
FP wrapper neydi ve hangi modaydı?
JavaScript tarafındaki meseleleri pek bilmiyorum; bu bağlamda fonksiyonel programlamanın sorunu ne?
İyi yapmışlar
Listenin başındaki birkaç PR’a bakınca bile şunlar var:
Yorumlara tek bir kelime eklemek, geliştirme hizmetini tanıtmak için yapılandırma dosyası eklemek, varı lete çevirmek, temel bir fonksiyonun iyi yerleşmiş davranışını değiştirmek, noktalı virgülleri kaldırmak vb.
Çoğu muhtemelen kütüphaneyi iyileştirme niyetiyle açılmıştır, ama bir noktadan sonra bakımcı için sadece spame dönüşür ya da daha kötüsü, ilgilenemedikçe suçluluk duygusunu büyüten bir yük olur.
Ünlülerin sürekli ilgiden kaçınmak ve akıl sağlıklarını korumak için koruma tutup birinci sınıfta ya da özel jetle uçması gibi, ünlü açık kaynak projeleri için ne tür önlemler mümkün merak ediyorum
Kişisel olarak bir açık kaynak bakımcısı olarak yazım hatası, metin düzeltmesi ve otomatik refactoring PR’larını en çok seviyorum. İncelemek neredeyse hiç emek istemediği için neredeyse her zaman çok hızlı merge ediyorum.
En uzun sürenler, devasa bir özelliği uygulayan PR’lar oluyor. Çok inceleme ve tartışma gerektirdiğinden ayrıntılı bakmayı erteliyorum
Bir dönem popüler projelere önemsiz PR açma modası vardı. Bence özgeçmişi doldurma girişimiydi
Sadece varı lete çevirmekten ibaret PR’ları birçok JavaScript projesine tekrar tekrar gönderen belirli bir GitHub kullanıcısı vardı
GitHub profilini doldurmak gibi hissettiriyor
Vay
Paketimi Bun’a taşımaya ilgi duymaya başlamıştım ama uyumluluk ve Bun’ın gerçekten yaşamaya devam edip etmeyeceği konusunda kaygılanıp tereddüt ediyordum. “Modern Yarn”dan da biraz ağzım yanmıştı. Ama lodash’ın geçtiğini görünce artık daha ciddi değerlendirmek istiyorum
Bu gerçekten büyük haber. Özellikle son v1.0 sürümüne rağmen Windows’ta performans sorunları olduğu düşünülürse
Açık kaynak geliştiricilerine projelerini nasıl yürüteceklerini söylemekten kaçınmaya çalışıyorum. Ben de açık kaynak geliştiricisiyim ve başkaları bana bunu yaptığında sinir oluyorum
Ama bir issue yazıp sorunu çözmeye yardım etmek için epey zaman harcamış bir kullanıcı olsaydım ya da bir düzeltme veya yeni özellik üzerinde çalışıp PR göndermiş biri olsaydım, şu anda motivasyonum epey kırılmış olurdu
Ama çoğu kullanıcı issue yazmaya yalnızca az bir zaman harcar. Hata raporlarının çoğu berbat
Issue’lar kapatıldı, yok olmadı. Hâlâ geçerliyse ileride tekrar talep edilebilir gibi görünüyor
Issue iflası gerçek bir şey. Kişisel deneyimime göre, bir noktadan sonra açık kaynak bakımı gerçek dünyada yaşamakla bağdaşması zor hâle geliyor
İş ücretsiz ve çoğu zaman takdir edilmiyor. Elbette her zaman değil. Sorunlar karmaşık ve iş, aile, dinlenme gibi gerçek hayattaki sorumluluklarla yarışıyor. İnsanlar kolayca sinirleniyor, düzenli olarak tartışmaya çalışıyor ya da dokümanları onlar yerine okumanızı istiyor. Açık kaynak popülerse muazzam bir sorumluluk da beraberinde geliyor
Projeleri yöneten insanların “yeter” deyip daha önemli işlere gitmesiyle açık kaynak ekosisteminde büyük bir çöküş yaşanacağını tahmin ediyorum
Bunu anlıyorum. Bugünlerde önemsiz olmayan kişisel bir projenin gerçek bir projeden çok bağımlılık ya da kendine zarar vermeye daha yakın olduğunu bile düşünmeye başladım
Yine de açık kaynak ekosistemi çılgınca verimsiz. lodash, underscore ve sayısız başka kütüphane var; hepsinin var olması gerekmiyor. Tek bir şey yapan çok sayıda kütüphane de var ve bunlar genellikle bu tür kütüphanelerin bir alt kümesi
Bunların çoğu minifier’lar ve tree shaking ile birlikte kullanılıyor; kullanılmayan özellikler kaldırılıyor. Ağır kütüphaneler de kolayca optimize ediliyor ve çoğu ayrık parçalardan oluşuyor; bu yüzden özellikle hafif kütüphanelere gerek yok ve geliştirme emeği genelde doğrusal artıyor
Programcıların zarafet ve sadeliği her şeyden çok sevmesi ve biraz daha iyi yapmak için sürekli yeniden yazmak istemesi olmasaydı, herkes şu anda harcadığı zamanın yalnızca dörtte birini harcasa bile açık kaynak için yeterince insan gücü olacağını düşünüyorum
Lodash harika bir kütüphane. Üzerinde çalıştığım neredeyse her projede az da olsa kullanıyorum
Ama JavaScript giderek iyileştikçe Lodash kullanma miktarım da giderek azalıyor. Her kullandığımda, yapmaya çalıştığım iş için yerleşik bir özellik olup olmadığını kontrol ediyorum. PR’lara “bunun için Lodash gerekmez” diye link bırakıp yorum yapmam da oldukça sık oluyor
Yine de bunun projeden el çekildiğinin bir işareti olmamasını umuyorum
Kesinlikle kullanışlı ama sonuçta gerekirse yardımcı işlevler için kendi yazdığım sürümü daha çok tercih ederim gibi geliyor
8 yıldır lodash ya da underscore.js kullanmadım. map, filter, find vb. ile kolayca yapılamayan ne var, pek bilmiyorum
Issue tracker’ın üst üste binen iki kullanım amacı var. Biri, bakımcıların yapması gereken işleri takip etme biçimi; diğeri ise daha geniş topluluğun ve kullanıcıların yazılımdaki kusurları takip etme biçimi
“Issue iflası” ilan etmek ilk kullanım için mantıklı, ama ikinci kullanımda mevcut sürümde bulunan sorunlara dair değerli bilgileri silip atmak anlamına geliyor
1 yorum
Hacker News yorumları
Bu gerçekten ikircikli bir durum. Bir yandan çok iyi. Sonuna asla ulaşılamayacağını bile bile tepeden başlayıp kazır gibi ilerleyen backlog temizlik toplantısı yaşamamış biri var mıdır bilmiyorum; o his kesinlikle berbat
Öte yandan sorunlar ortadan kalkmış değil, sadece etiketleri değişmiş oluyor; mesele tamamen etiketler ve düzenlemeyse, kusursuzca boş bir issue listesi gibi sözde bir ütopyayı kontrol etmeye çalışmak yerine akışına bırakmak gerekmez mi diye düşünüyorum. Böyle notları görünür bir yerde tutmanın da mutlaka faydaları vardır. Büyük temizlik sırasında atmaya karar verdiğin ama bilinçaltının “ileride lazım olabilir” diye tutmanı söylediği şeye benziyor
Yine de genel olarak destekleyen taraftayım. En azından bir özgürleşme hissi ve yeni issue’lara yönelik yeniden enerji toplama etkisi olur gibi
Yeniden yazılmış sürümü önce yayımlayıp ardından mevcut issue’ları deprecated olarak kapatmak daha temiz olurdu sanki. Yeniden yazım branch’indeki issue’lar sürüm etiketleriyle ayrılabilirdi. Yeni sürüm henüz bitmemişken kapatılırsa, katkıda bulunanlar artık desteklenmediğini bilmeden mevcut sürüme yeni issue açabilir
Yine de issue’ları görmezden gelip kod tabanındaki sorunları öylece bırakıyor değiller; projenin tamamı yeniden elden geçiriliyor
https://twitter.com/jdalton/status/1571863497969119238
Bence projenin issue’nun varlığını kabul edip açık bırakması daha dürüstçe. Geliştirici açısından issue sayısı göze batıyorsa eski ve önemsiz issue’ları gizleyen bir filtre kullanmak daha iyi olur
jwz şöyle demişti
Özellikle yeniden üretmesi zor ya da karmaşık hatalarda, bakımcının kendi ortamında bunu yeniden üretebilip üretemeyeceği bile belirsizdir; bildiren kişinin o hatayı gözlemlemeye daha alışık olma ihtimali de yüksektir
Daha büyük bir ekip varsa ya da ticari bir servisin eşlik eden projesiyse bu denge biraz değişebilir
Pek çok özgür/açık kaynak projede görülen şey şu: kolları sıvamak isteyen çok az kişi var, ama aynı zamanda o projenin kendileri için ne kadar vazgeçilmez olduğunu anlatmaya, talep etmeye ve çok sayıda öneride bulunmaya epey zaman harcıyorlar
Çoğunluk, istek listesini duyurmak için yeni issue açıyor ya da çok belirsiz hata bildirimleri bırakıyor. Bazıları düzgün hata raporları da sunuyor ama katkı isteği genelde orada bitiyor
Şahsen sık görülen yorumların çoğunu diplomatik biçimde ele alma iradesine sahip olmadığım için proje bakımcılığına uygun bir karakterim yok
Yine de bildirdiğim issue’larda nedenini izlemeye ve mümkünse düzelten bir PR göndermeye çalışarak kendi payıma düşeni yapmaya hep gayret ediyorum
Gerçekten önemsediğin bir sorunsa test eklemelisin
lodash’ın yazarı John-David Dalton [geçen yıl şöyle][1] yazmıştı
Sanki eleştirdiği karmaşıklığı başka biri eklemiş gibi geliyor. Bunu kendisi getirdiyse, bir iç değerlendirme ya da öğrenilmiş ders gibi söylemekten ziyade, projeyi bir modaya göre geliştirip şimdi o moda bittiğine göre sıradakine geçme zamanı gelmiş gibi konuşuyor
İyi yapmışlar
Listenin başındaki birkaç PR’a bakınca bile şunlar var:
Yorumlara tek bir kelime eklemek, geliştirme hizmetini tanıtmak için yapılandırma dosyası eklemek,
varılete çevirmek, temel bir fonksiyonun iyi yerleşmiş davranışını değiştirmek, noktalı virgülleri kaldırmak vb.Çoğu muhtemelen kütüphaneyi iyileştirme niyetiyle açılmıştır, ama bir noktadan sonra bakımcı için sadece spame dönüşür ya da daha kötüsü, ilgilenemedikçe suçluluk duygusunu büyüten bir yük olur.
Ünlülerin sürekli ilgiden kaçınmak ve akıl sağlıklarını korumak için koruma tutup birinci sınıfta ya da özel jetle uçması gibi, ünlü açık kaynak projeleri için ne tür önlemler mümkün merak ediyorum
En uzun sürenler, devasa bir özelliği uygulayan PR’lar oluyor. Çok inceleme ve tartışma gerektirdiğinden ayrıntılı bakmayı erteliyorum
varılete çevirmekten ibaret PR’ları birçok JavaScript projesine tekrar tekrar gönderen belirli bir GitHub kullanıcısı vardıGitHub profilini doldurmak gibi hissettiriyor
Daha büyük haber, Lodash’ın Node.js’ten Bun’a geçmesi: https://github.com/lodash/lodash/commit/97d4a2fe193a66f5f96d...
Paketimi Bun’a taşımaya ilgi duymaya başlamıştım ama uyumluluk ve Bun’ın gerçekten yaşamaya devam edip etmeyeceği konusunda kaygılanıp tereddüt ediyordum. “Modern Yarn”dan da biraz ağzım yanmıştı. Ama lodash’ın geçtiğini görünce artık daha ciddi değerlendirmek istiyorum
Açık kaynak geliştiricilerine projelerini nasıl yürüteceklerini söylemekten kaçınmaya çalışıyorum. Ben de açık kaynak geliştiricisiyim ve başkaları bana bunu yaptığında sinir oluyorum
Ama bir issue yazıp sorunu çözmeye yardım etmek için epey zaman harcamış bir kullanıcı olsaydım ya da bir düzeltme veya yeni özellik üzerinde çalışıp PR göndermiş biri olsaydım, şu anda motivasyonum epey kırılmış olurdu
issue bankruptcyetiketiyle 363 issue kapatmışlar: https://github.com/lodash/lodash/issues?q=is%3Aissue+is%3Acl...PR’larda da 325 tanesi aynı şekilde: https://github.com/lodash/lodash/pulls?q=is%3Apr+is%3Aclosed...
Issue iflası gerçek bir şey. Kişisel deneyimime göre, bir noktadan sonra açık kaynak bakımı gerçek dünyada yaşamakla bağdaşması zor hâle geliyor
İş ücretsiz ve çoğu zaman takdir edilmiyor. Elbette her zaman değil. Sorunlar karmaşık ve iş, aile, dinlenme gibi gerçek hayattaki sorumluluklarla yarışıyor. İnsanlar kolayca sinirleniyor, düzenli olarak tartışmaya çalışıyor ya da dokümanları onlar yerine okumanızı istiyor. Açık kaynak popülerse muazzam bir sorumluluk da beraberinde geliyor
Projeleri yöneten insanların “yeter” deyip daha önemli işlere gitmesiyle açık kaynak ekosisteminde büyük bir çöküş yaşanacağını tahmin ediyorum
Yine de açık kaynak ekosistemi çılgınca verimsiz. lodash, underscore ve sayısız başka kütüphane var; hepsinin var olması gerekmiyor. Tek bir şey yapan çok sayıda kütüphane de var ve bunlar genellikle bu tür kütüphanelerin bir alt kümesi
Bunların çoğu minifier’lar ve tree shaking ile birlikte kullanılıyor; kullanılmayan özellikler kaldırılıyor. Ağır kütüphaneler de kolayca optimize ediliyor ve çoğu ayrık parçalardan oluşuyor; bu yüzden özellikle hafif kütüphanelere gerek yok ve geliştirme emeği genelde doğrusal artıyor
Programcıların zarafet ve sadeliği her şeyden çok sevmesi ve biraz daha iyi yapmak için sürekli yeniden yazmak istemesi olmasaydı, herkes şu anda harcadığı zamanın yalnızca dörtte birini harcasa bile açık kaynak için yeterince insan gücü olacağını düşünüyorum
Lodash harika bir kütüphane. Üzerinde çalıştığım neredeyse her projede az da olsa kullanıyorum
Ama JavaScript giderek iyileştikçe Lodash kullanma miktarım da giderek azalıyor. Her kullandığımda, yapmaya çalıştığım iş için yerleşik bir özellik olup olmadığını kontrol ediyorum. PR’lara “bunun için Lodash gerekmez” diye link bırakıp yorum yapmam da oldukça sık oluyor
Yine de bunun projeden el çekildiğinin bir işareti olmamasını umuyorum
..., tek başına bile muazzam etki yarattı. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Iterator helper’lar da yakında dağıtıma girecek; çok yardımcı olacak. Asenkron iterator helper’lar ise bir süre gecikecek gibi görünüyor. https://github.com/tc39/proposal-iterator-helpersEskiden üzerinde çalıştığım kod tabanında fonksiyonları yaratıcı biçimde çağırmak için haftada birkaç kez
.apply()kullanmam gerekiyormuş gibi hissederdim. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Artık bunların hepsi ortadan kalktı; ekip arkadaşlarının %50’si.callve.applynedir biliyor mu diye sorsanız, sanırım yazı tura gibi olurChrome 117’ye
Object.groupBy()geliyor ve bu, lodash kullanmaya iten son birçok noktayı ortadan kaldırmada çok yardımcı olacak. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...map,filter,findvb. ile kolayca yapılamayan ne var, pek bilmiyorumIssue tracker’ın üst üste binen iki kullanım amacı var. Biri, bakımcıların yapması gereken işleri takip etme biçimi; diğeri ise daha geniş topluluğun ve kullanıcıların yazılımdaki kusurları takip etme biçimi
“Issue iflası” ilan etmek ilk kullanım için mantıklı, ama ikinci kullanımda mevcut sürümde bulunan sorunlara dair değerli bilgileri silip atmak anlamına geliyor