Ben acemi bir geliştirici değilken, sizin (geliştirici olarak) benim için yazdığınız eğitimi nasıl okuyorum

 (anniemueller.com)
5 puan yazan GN⁺ 2025-09-23 | 1 yorum | WhatsApp'ta paylaş
  • Acemi birinin geliştiricilerin yazdığı teknik eğitimleri okurken yaşadığı kafa karışıklığını ve engelleri mizahi bir dille anlatan bir yazı
  • Geliştiricilerin sık kullandığı uzmanlık terimleri ve kısaltmalar, acemilere bağlamı olmayan birer 'uzaylı dili' gibi geliyor
  • Eğitimlerdeki kurulum adımları, dosya yolları ve terminal komutları çoğu zaman fazla karmaşık ya da eksik bırakıldığı için anlaşılması zor oluyor
  • Yazar, geliştirici açısından çok doğal görünen açıklamaların acemiler için saatlerce arama ve deneme-yanılma gerektiren engellere dönüştüğünü söylüyor
  • Bu yazı, eğitim yazan geliştiricilere başlangıç seviyesindeki birinin bakış açısından daha nazik ve daha açık anlatmaları gerektiğini hatırlatıyor

Yazının arka planı ve mesele

  • Yazar, geliştirici olmayan bir acemi olarak geliştiricilerin yazdığı eğitimleri okurken yaşadıklarını anlatıyor
  • Eğitimlerde geçen teknik terimlerin ve araç adlarının ne anlama geldiğine dair hiçbir fikrinin olmamasını hicivli bir şekilde aktarıyor
  • Örneğin Hoobijag, Snarfus, Shamrock portal gibi uydurma teknik adlar kullanarak, bir aceminin gözünde her şeyin ne kadar karmaşık göründüğünü vurguluyor

Metnin çevirisi

“Merhaba! Ben bir geliştiriciyim. İlgili deneyimim şöyle: Hoobijag ile kod yazıyorum, bazen jabbernocks da kullanıyorum ve tabii ki ABCDE++++ de yapıyorum (ama asla ABCDE+/^+ değil, o tam bir saçmalık, değil mi? Hahaha!) Ayrıca Shoobababoo ile çalışmayı seviyorum, arada kleptomitrons da uğraşıyorum. Company[1]'de Shoobaboo ile ilgili bazı kodlar üzerinde çalıştım ve bu da beni Snarfus'a götürdü. Hadi başlayalım!

Bu eğitim hakkında

Snarfus ile ilk kez çok basit bir şey[2] yapmaya başladım ama kullandıkça ne kadar potansiyelli olduğunu gördüm! chromus biraz dağınık ama aslında inanılmaz derecede çok yönlü. Bu yüzden hoobastank yerine quagmire ile pintafore'u argyle etmeye başladım! Çılgınca, biliyorum. Ama bir bakıma çalıştı ve açıkçası oldukça eğlenceliydi… ta ki büyük bir engele çarpana kadar: fisterfunk, shamrock portal ile hiç konuşmuyor ve Snarfus'a beep-boops da göndermiyor! Tabii bunun ne anlama geldiğini biliyorsunuzdur[3]— artık tüm hoob-tüneli gramelions ile tıkanmış durumda. Kabul edilemez.

Neredeyse vazgeçiyordum ama sonra fark ettim ki backside Snarfus stagnator'u backside shamrock Klingon troglodyte emulater'a bağlayınca sorun çözülüyor! Her şey beep-boops ve ding-dongs yapmaya başladı ve sonunda eğitimin asıl konusuna gelebildim. Sonunda istediğiniz şekilde çok basit bir şey yapabiliyorsunuz! Oldukça havalı, değil mi[4].

Yani kurulum şöyle:

  1. Terminale ajkl;gawgor;iqeg;iJLkqen. wl;R aw;oeiga 4648664 arjarwgj;llj;ja fadgfgajkljl; wlj;sdjk;lfas yazın
  2. Şimdi folder/hidden/deep/in/the/file/system/surprise!.file konumuna gidin ve dosyanın içeriğini kopyalayın. Eğer orada yoksa, library/library/library/llibrary/liiiiiibrarrrary/llllliiiiibrary/hidden/hidden/hiding/you can’t find me/hidden/nope/never/hahahahereiam.file içinde olabilir
  3. Tekrar terminale dönün, dosya içeriğini yapıştırın ve 64A786AGR45JAR; rdja;jg [[]][[]][[]][[]]][[]()()()()()()()()(){{}{}{}|{}{|}{}{|}{ ////////////////!! !!!! !! //// !!! agjlkargji;lwej;OI [ASRGASG[]ASGDASG[]EAEadgasg[]EAGE[edaga][]ahgr-0-0=-0-=0-=0=0-0=-0-=0=-0-=0=-0=-0!!! yazın
  4. Boop![5]
  5. Snarfus'u açın ve az önce oluşturduğunuz dosyayı yükleyin
  6. Sırf eğlencesine, chronostatiomatrix'in sham'ini kaldırmak isterseniz —()()(]]asdg a=-do —cd go cd stay —sususudododo baby shark—][] komutunu da çalıştırabilirsiniz. Bu isteğe bağlıdır
  7. Tamamdır!

Nasıl gittiğini bana söyleyin. Bir de birilerinin bu yöntemi GewGawGamma ya da ometer2.7 ile kullanıp kullanmadığını merak ediyorum.”

Dipnot açıklamaları

  1. Muhtemelen ünlü bir şirket ama ben bilmiyorum
  2. Hiç de basit değil
  3. Ne anlama geldiğini bilmiyorum
  4. Havalı görünüyor ama ben yine de anlamadım. Yine de sizin yapabiliyor olmanıza sevindim
  5. İlk 3 adım muhtemelen yaklaşık 7 saat ve 193 arama gerektirecek. Ama Boop!'a ulaştığınızda gerçekten çok heyecan verici oluyor

Kapanış

  • “Bu sadece eğlence için yazılmış bir yazı. Bilgilerini paylaşan ve eğitim yazan herkese içtenlikle teşekkür ederim.”

İlgili okumalar

1 yorum

 
GN⁺ 2025-09-23
Hacker News yorumları

  • Birine yalnızca asgari düzeyde bilgi verip dokümantasyonu takip etmesini sağlama ve yanında sessizce izleme yaklaşımını şiddetle öneririm. Bu sırada hiç yardım etmeyip sadece gözlemlemek gerekir. Bu süreçte kullanıcının nerede takıldığını, yazarın fazla aşina olduğu için fark etmediği noktaları ya da eksik kalan ayarları ve benzeri birçok sorunu keşfedebilirsiniz. Kullanıcı fazla stres yaşamadan hedefine ulaşırsa dokümantasyon testi geçmiş demektir. Aksi halde başarısız olunan her noktayı eksiksiz kaydetmek, her birini iyileştirdikten sonra yeni biriyle tekrar test etmek gerekir. FAANG gibi büyük şirketlerin dokümantasyonunda bile bu standardı geçemeyen şeyler kullandım. Kuruluşumuzun yüksek standartlar koymuş olmasına gerçekten minnettarım. Bu şekilde dokümantasyon hazırlarsanız tekrarlayan toplantılar, destek talepleri ve görüntülü aramalar azalır; kullanıcılar da sorunlarını kendi başlarına çözebilir

    • Apple dokümanlarını kullanırken bu sorunu sık yaşıyorum. Dokümandaki tanımlar çoğu zaman sadece aynı adı tekrar ediyor, açıklama vermeden geçiyor; daha somut yazmaları gerekiyor
    • "Konuşma, sadece gözlemle" kuralı kolay görünür ama pratikte insanlar dayanamayarak açıklama yapıyor ya da ipucu veriyor. Hatta doğrudan fareyi alanlar bile oldu. Böyle insani tepkileri önlemek için tarafsız bir yürütücü (moderatör) ayrı olabilir, yazar/geliştirici ise sadece gözlemci kalabilir. Ama "sadece izleme" becerisini öğrenmek önemlidir; daha da ilerlemek istiyorsanız "think-aloud protocol"e bakmanızı öneririm
    • Çoğu şirket ekibinin onboarding dokümanı berbat durumda; bu da gerçek iş yükünü önceden gösteren bir pencere gibi. Son katıldığım üç ekipte ya neredeyse hiç doküman yoktu ya da çok eskimişti; gerekli erişim izinlerini veya deployment pipeline bilgilerini almak için ilgili kişileri tek tek bulmam gerekti. Bu sırada yeni dokümanlar yazılıyor ama sisteme ya da yetkilere yeni bir şey eklenince hemen eskiyor; kısır döngü böyle sürüyor. Yalnızca bir ekip iki gün içinde gereken tüm ortamı kurmamı sağlamıştı ve o deneyim mükemmeldi. Şimdi yeni devex ekibinde dokümantasyon ortamının kendisini iyileştirmeye çalışıyorum
    • Berbat kurulum dokümanları okuyarak onboarding yapmak gerçekten stresi 10 kat artırıyor gibi. Yeni başlayanların yaşadığı sorunları ilk katkıları olarak hemen düzeltmelerini hep teşvik ettim. Yeni başlayanların hiçbir bağlamı olmadığı için en iyi gözden geçirenler onlar olabiliyor
    • Bizim kuruluşumuz da aynı iş akışını kullanıyor. Daha az deneyimli birinin dokümantasyonu takip etmesini sağlıyor, sonrasında herkesin sürekli dokümantasyonu iyileştirmesini teşvik ediyoruz. Çünkü uzun deneyimden doğan "kör noktaları" yeni gelenler iyi yakalayabiliyor. Kendi deneyimime göre, kullanıcının özgüvenini yönetmek de çok önemli. Bu yüzden "bu shell komutunu çalıştırın" gibi adımları anlatırken varsayılan olarak bazı bölümleri katlanır şekilde sunuyoruz (ör. başarılı çalıştırma çıktısı örneği, göz ardı edilebilir uyarılar, oluşabilecek hata listesi ve çözüm yolları, karmaşık komutların açıklaması gibi). Bazı adımların altında bir sayfalık açıklama bile oluyor ama onboarding sırasında bu ayrıntı gerçekten çok yardımcı oluyor

  • Blog yazısının başlığı "Ben bir geliştirici değilim, senin yazdığın tutorial'ı okuyorum" idi, ama HN başlığı "Ben acemi bir geliştiriciyim..." olarak değiştirildi. Geliştirici olmayan biri ile acemi geliştirici tamamen farklı şeylerdir. Örneğin İK ekibi ya da tamamen alakasız bir alandan gelen biri için şirket içi terimler ve kavramlar baştan sona yabancı olabilir. Bu durumda geliştirici tamamen kopuk bir açıklama yazdıysa eleştirilmeyi hak eder. Buna karşılık acemi geliştirici zor da olsa yeni terimleri ve kavramları kendisi araştırabilir ve zamanla yeni gelen başka acemiler için dokümantasyonu güncelleyebilir

    • Bilgi olsun diye: Yazıyı "geliştirici olmayan" başlığıyla göndermiştim ama ortada "acemi geliştirici"ye çevrildi. Yazarı teknik uzman olmayan bir blogger ve web sitesi ya da CSS ile uğraşmak için çeşitli teknik dokümanlara bakmak zorunda kalmış olmalı. Site yayımlama ve uzman olmayanlara yönelik doküman eksikliği üzerine konuşmak daha uygun olabilirdi diye düşünüyorum ama HN topluluğunun tartışmayı başka yöne çekmesi de sorun değil
    • Bu ayrım çok önemli. Yazar Annie, kendisinin "içerik/dokümantasyon işi" yaptığını ve CSS hobisi olduğunu söylüyor; yani "uzman olmayan hobi geliştiricisi" katmanında. Bunun giderek büyüyecek bir alan olduğunu düşünüyorum. Acemileri/geliştirici olmayanları kapsayan tutorial yazarken "cd ~/.snarfus(klasör yoksa oluştur)" gibi bir ifadeye çok kısa bir ek açıklama koymak bile yeterli olabilir. Ben de geçmişte Debian kurarken böyle küçük bir açıklamadan çok fayda görmüştüm
    • Programlamaya başlarken beni etkileyen site "FromZero" olmuştu. Geliştirici olmayanları hedefleyerek IDE kurulumundan konsolu açmaya kadar her şeyi adım adım anlatıyordu; yabancı terimlerde de "bunu daha sonra ele alacağız, şimdilik dert etmeyin" diyerek insanı rahatlatıyordu. Harikaydı. Elbette dokümantasyon yazmak çok zaman ve emek istiyor, bu yüzden bazen kısmi açıklama bile hiç olmamasından iyidir diye düşünüyorum. Acemi geliştiricilere yönelik dokümanlar, geliştirici olmayanlara gösterilen özenle yazılmalı
    • Bazıları her şey kendilerine çok basit anlatılmazsa bunun gatekeeping olduğunu iddia ediyor; ama kendileri zorlandığında, ön bilgi olmadan hiçbir şeyi anında kavramanın mümkün olmadığını gözden kaçırıyorlar gibi geliyor
    • Eğer bu acemi geliştiriciler için bir tutorial ise ve profesyonel geliştiricilere yazılmış bir metin değilse, her bir "Hoobijag" ya da "shamrock portal" kavramının tek tek açıklanmasını beklemek tuhaf olur. Sonuçta hepimiz başta bilmediğimiz terimleri Google'layarak öğrendik

  • Çoğu tutorial geliştirici olmayanlar için değil, daha çok geliştiricilerin kendi aralarında bilgi paylaşması için yazılıyor; belirli bir bilgi topluluğuna yönelik akademik makalelere benzer bir konumda. Bunun kendisi de kötü değil. Hatta benim geçmişte bıraktığım notları yeniden bulmam açısından da işe yarıyor. Bu yüzden başlangıç seviyesine yönelik ayrı kurslar ve ders materyalleri var. Eğer tutorial'lar her seferinde 30 bin karakterlik tüm arka plan açıklamasıyla başlamak zorunda olsaydı, kimse sonuna kadar okumazdı. Tersine, ne kadar fazla arka plan eklerseniz ekleyin birileri için yine de yetersiz kalabilir

    • Oğlumun (17) programlamaya büyük ilgisi var; yakın zamanda public/private/internal/static kavramlarını ve recursion'ı anlattım. İçimden bir sonraki tepkisini merakla bekliyorum
    • "Tutorial'ların çoğu geliştirici olmayanlar için değildir" iddiasına katılmıyorum. Bu tutorial'ın başlığı zaten geliştirici olmayanları hedeflediğini açıkça ortaya koyuyor, bunu vurgulamak istiyorum. Bir açık kaynak projeyi kurmaya çalışırken zorlanıp, en temel kurulum kılavuzlarının bile acemilerin takip edebileceği kadar anlaşılır yazılması gerektiğini savunan seslere kesinlikle ihtiyaç var. Küçük bir adımın atlanması, alışık olmadığınız bir alanda saatler kaybettirebilir
    • Tam tersine, dokümantasyonu herkes için daha anlaşılır yazmanın kötü bir şey olduğunu düşünmüyorum. İyi dokümantasyon yalnızca acemilere değil geliştiricilere de yarar sağlar. Erişilebilir dokümanların eksik olmasının nedeni bence sadece biraz daha fazla emek vermek istememeleri. Ayrıca geliştirici dokümanları, akademik makalelerden farklı olarak fazla kısa yazılıyor ya da yazan kişi okuyucuyu pek umursamıyor; sorun da buradan çıkıyor. Sonuçta uzmanlar dışında kimseye yaramayan bir doküman ortaya çıkıyor. Bu başarısızlıktır
    • Acemiler için bağlamı adım adım inşa eden dokümantasyona ihtiyaç olduğu konusunda katılıyorum. Ancak bugünlerde DX (geliştirici deneyimi), yalnızca "kolay olanlar" etrafında iyileştirilirken eskiden yararlı olan log'lar ya da hata mesajlarında arama gibi özellikler feda ediliyor; böylece sadece acemilere odaklanan ve mevcut kullanıcıları zorlayan bir eğilim doğuyor
    • Günümüzde tutorial'lar çoğu zaman gerçekte "X projesine katkı yaptım" şeklinde özgeçmiş parlatmak için yazılmış gibi görünüyor. Yazarın üç ay sonra dönüp kendi tutorial'ını yeniden izlemesi bile, eksik kısımları bariz hale getirip büyük iyileştirme sağlayacaktır

  • Pek çok teknik yazar "bilginin laneti"ni yeterince fark etmiyor. Eskiden bir WoW (World of Warcraft) guild'i yönetmiştim. 40 kişi aynı anda toplanıp bir dungeon'a giriyor, birlikte birçok boss ile savaşıyordu; küçücük bir hata bile tüm grubun ölmesine yol açabiliyordu. Bu yüzden herkes Teamspeak'te toplanır, stratejileri önceden uzun uzun anlatırdık. Buradaki en büyük dersler şunlardı: "Karşındakinin ne dediğini bilmediğini varsay" ve "Bir kez söylediklerini tekrar et". İnsanlar çoğu zaman bir şey bilmediklerinde araya girip sormuyor; bu yüzden sürekli "şu an hangi terimi kullanıyorum?", "bu kavramı bilmiyor olabilirler" diye kendime sorup ek açıklama yapma alışkanlığı olağanüstü etkili olmuştu. Bu tür iletişim deneyimleri teknik iletişime de birebir aktarılabiliyor; "bilginin laneti"ni aşma çabası refleks haline gelirse başkalarının anlama düzeyi ciddi biçimde artıyor

    • Eski raid guild'imizde 18 yaşındaki guild liderinin yetişkinleri farklı saat dilimlerinden toplayıp loot dağıtımını, stratejiyi ve takvimi sorunsuz yönetmesini görünce "bu çocuk doğrudan yönetici olarak işe alınmalı" diye düşünmüştüm
    • 40 kişilik raid yönetmiş herkes, proje yöneticisi olarak en üst düzey yetkinlik kazanmıştır. Bu iş tam anlamıyla "dağılıp giden kediler sürüsünü" tertemiz yönetmektir

  • Birçok proje ana sayfası ya da GitHub README'si sanki "bunu okuyan zaten her şeyi biliyor" tavrıyla yazılıyor. Ben dokümanlara bakarken "bu araç neden gerekli", "hangi sorunu çözüyor", "benzer başka araçlardan farkı ne", "hâlâ aktif kullanılıyor mu", "artı ve eksileri karşılaştırabilmem için bana yeterince malzeme veriyor mu" gibi bir özen görmeyi isterdim. Sadece 5 dakikanızı ayırıp "tam bir acemi olsaydı neyi merak ederdi?" diye düşünerek bunları yazsanız erişilebilirlik ciddi biçimde artar. Bir projeye yıllarınızı vermiş olsanız bile, kullanıcıların aradığını bulduğunu bile fark etmeden sırf uğraştırdığı için vazgeçtiği durumların tekrarlanması gerçekten üzücü. Ayrıca farklı doküman türlerinin rollerini iyi anlamak da önemli. https://diataxis.fr/ bunun için iyi bir başlangıç noktası

    • ROS (robot yazılımı) alanında README'ler gerçekten çok yetersiz; bu yüzden sürekli stres oluyordum. Proje adı dışında ipucu olmayınca, ne işe yaradığını anlamak bile zorlaşıyor. Bu sadece açık kaynakta değil, iş yerinde de aynıydı; README'lere açıklama ekleyen tek kişi benmişim gibi hissediyorum. Eski monorepo günleri daha mutluydu
    • Geliştiricilerin sevgi ve emekle araçlar yaptığını anlıyorum ama yalnızca dokümantasyona biraz özen gösterseler giriş bariyeri çok daha düşük olurdu. Üstelik yığındaki diğer bileşenlerin dokümanları da zorsa öğrenme eğrisi katlanarak dikleşiyor
    • Geçmişte HN'de, içinde ne olduğunun bile yazılmadığı bir proje bile paylaşılmıştı

  • Dokümantasyon yazarken en önemli şey, hedef okuyucunun bilgi seviyesini net biçimde belirlemektir. Taban çizgisini yüksek ya da düşük tutmanız fark etmez; ama bu taban seviyeden fazla saparsanız bazı okurlar mutlaka memnuniyetsiz olacaktır. Böyle durumlarda ya bahane üretirsiniz ya da çözüm ararsınız. Gerçi bugünlerde AI, Google, kitaplar vb. ile her şeyi anında bulmak mümkün. "Shoobababoo nedir" ya da "neden quagmire kullanılıyor" diye merak eden biri aratabilir. Elbette ideal olan, dokümanın mümkün olduğunca dış kaynağa ihtiyaç duymadan kendi kendine yeterli olmasıdır; ama dünya her zaman bu kadar cömert değil

    • Bu yüzden birçok kurulum rehberinin "şimdi exe dosyasına çift tıklayın, ardından next" diye başlaması gibi eğilimler daha da sorunlu. Rehberin taban seviyesini doğru belirlemek gerçekten çok önemli
    • Ben çoğunlukla iç hassas sistemler için doküman yazıyorum ve bazen en başa açıkça "bu rehber x, y, z kullanımını zaten bildiğinizi varsayar; bilmiyorsanız bu işi yapmamalısınız" diye not düşüyorum. Erişim yetkileri zaten kısıtlı ama olur da DR senaryosu gibi bir durumda alışık olmayan biri kullanırsa diye, "bunu bile anlamıyorsan sakın yapma" sınırını özellikle bırakıyorum

  • Uzun yıllar mentorluk yaparken vurguladığım ilke şuydu: "Bildiğini paylaşmak en iyisidir." Bir şeyi biliyorsanız mutlaka açıklayın; eğer zaten bilen birine söylemişseniz en fazla onun güvenini tazelemiş olursunuz, bilmiyorsa da büyük fayda sağlarsınız. Bazen fazla uzun anlattığıma dair şikâyet geliyor ama "bunu belki bir yeni çalışan, müşteri ya da yönetici de görebilir; onlar için yazmıştım" deyince çoğu kişi anlıyor. Bu ilke geliştirme, raporlama, insan yönetimi dahil her alanda geçerli

    • Elbette zaten bildiği şeylerin açıklanmasından aşırı rahatsız olan insanlar da var. Sinyal/gürültü oranı çok kötü olursa iletişimin kendisi bile zarar görebilir
    • Oğluma bilardo öğretirken de benzer bir şey yaşıyorum. Savunmacılığı bırakıp ekip içinde ipuçlarını saklamayan bir kültür büyümeye çok yardımcı oluyor. Mentorlukta doğrudan cevabı vermek yerine sorularla kişiyi kendisinin bulmasına yönlendirirseniz, asıl gelişim o kişinin kendi fark edişiyle geliyor
    • Herkese tek tek her şeyi anlatmak bazen "mansplaining" olarak yanlış anlaşılabilir ya da "her şeyi biliyormuş gibi davranıyor" şeklinde politik risk yaratabilir. Şirket içinde bazen en güvenlisi, insanlar soru sorduğunda yanıt vermekle sınırlı kalmaktır

  • Yakın zamanda Gitlab ile DigitalOcean Kubernetes üzerine uygulama deploy etmeyi denedim; ne işe yaradıkları açıklanmadan 3-4 tane üçüncü taraf aracı uygulamak gerekti ve komut satırına yazılacak isimleri ya da yolları da kendim bulup doldurmam beklendi. Neyin referans olduğu ve neyin neye uyması gerektiği de anlatılmıyordu. Docker konusunda epey yetkin olmama rağmen bu araçların dokümanları o kadar kullanışsızdı ki, neredeyse hiç olmasalar daha iyiydi

  • Kitap yazmayı bırakıp tutorial web sitesi yapmamın ana nedeni, tutorial'ları daha erişilebilir kılmak için çeşitli interaktif araçlardan (<abbr> öğesi gibi) yararlanabilmekti. Buna rağmen bugün web içeriğinin hâlâ kâğıt kitabın imkânlarında takılı kalması sinir bozucu. Tıklama, hover, bölüm katlama, video, kullanıcı etkileşimi gibi sayısız olanak var ama hâlâ duvar gibi uzun metinler görüyoruz. Hatta OP bile dipnota tıklayınca sayfanın en altına kaydıran bir yöntem kullanıyor; bu da web'in potansiyelini tam kullanmıyormuş gibi hissettiriyor

    • Az önce blogumu yükseltmeye çalışıyordum; bu tarzı iyi yapan sitelerden öneri verebilirseniz sevinirim

  • Aslında tutorial'ların çoğu ne geliştirici olmayanlara ne de geliştiricilere hitap ediyor; gereksiz uzun metinlerin arasına sıkışmış ve sonunda önemli bir iki adımı atlayan şeylere dönüşüyorlar. Bunun en büyük nedeni, insanın yazarken karşısında birine anlatıyormuş gibi ifade kurmasının zor olması. Zihninizde bildiğiniz bir şeyi yazıya dökmezseniz, okuyucu onu asla bilemez. "Tutorial" yerine daha çok "cookbook" tarzında yazmak, hem pratik kullanım için daha elverişli olur hem de sürüm yükseltmelerinden sonra tümüyle işe yaramaz hale gelmesini önler

    • İşin ironik yanı, bugünlerde çevrimiçi tarifler de geliştirici olmayanların bloglarından bile daha fazla gereksiz gevezelik içerebiliyor