Yeni başlayanlar için kodlama proje fikirleri: 4 canlı proje

En iyi yeni başlayanlar için kodlama proje fikirleri küçüktür, bir haftada bitirilir ve sonunda canlı bir URL ile biter. Herkese açık bir API üzerinde hava durumu paneli, kendi küçük REST API'niz, sağlık kontrolü olan bir yer imi servisi ve bilerek bozup sonra düzelttiğiniz bir proje bu listenin çekirdeğini oluşturuyor. Eğitim kopyalarını atlayın, bir fikir seçin, gerçek bir barındırma sağlayıcısına yükleyin ve sonucu bir kişiye gösterin.

Salı öğleden sonra saat 14:40. Bir öğrenci Discord sunucusunda şunu yazıyor: "Todo uygulamam bilgisayarımda çalışıyor. Nasıl yayına alırım?" Bir saat boyunca kimse cevap vermiyor. "Yerelde çalışıyor" ile "başkası için çalışıyor" arasındaki bu boşluk, çoğu başlangıç projesinin öldüğü yerdir. Bu liste o boşluğu kapatmak için hazırlandı.

Başlangıç projesi neden canlı bir URL'ye ihtiyaç duyar?

Bilgisayarınızdaki bir depo, talimatları izleyebildiğinizi kanıtlar. Yayındaki bir servis ise aynı anda yapılandırmayı, gizli anahtarları, bir portu ve bir derleme adımını yönetebildiğinizi kanıtlar. Gerçek iş budur.

Sigma School'un başlangıç rehberi aynı argümanı öne sürüyor: ilk proje canlı bir URL ile bitmeli, gerçek bir kişiye gösterilen yayındaki bir URL, bitirilmemiş üç depodan daha değerlidir. Biz buna bir ekleme yapıyoruz. URL bitiş çizgisi değil, zemindir. Gerçek bitiş çizgisi, bir şey bozulduğunda açıklayabildiğiniz projedir.

Bu listedeki her fikir için kullandığımız filtre şöyle: 10 saatten kısa sürede yapılabilir mi? Bir API'yi çağırıyor ya da sunuyor mu? Ücretsiz olarak yayınlanabilir mi? Gözlemleyebileceğiniz en az bir hata biçimi var mı? Bunlardan birinin cevabı hayırsa, o bir eğitim alıştırmasıdır, proje değildir.

Hangi ilk proje saat başına en çok şey öğretir?

Birinci proje, herkese açık bir API'yi tüketen bir hava durumu ya da döviz panosudur. Çok kolay görünür. Değildir, çünkü her gerçek servisin yaptığı dört şeyden geçirir: istek göndermek, beklemek, yanıtı ayrıştırmak ve yanıtın hatalı olduğu durumu ele almak.

Strapi'nin API proje fikirleri derlemesi olağan adayları sıralıyor: hava durumu, film arama, döviz çevirisi, bir Pokédex, bir ülkeler gezgini. En kullanışlı ayrıntısı ise bir uyarı: NewsAPI'nin ücretsiz katmanı yalnızca geliştirme ortamlarıyla sınırlı. Bu yüzden bunun üzerine kurulmuş bir haber toplayıcı canlı demonuz olamaz. Arayüzü yazmadan önce API'nin koşullarını okuyun, sonra değil.

İlk yapım için bizim seçimimiz bir döviz çevirici ya da bir ülkeler gezgini. İkisinin de cömert ya da yayımlanmamış limitleri var, anahtar döndürme telaşı yok ve yanıt yapıları kararlı. Hava durumu da olur, ama tek bir ilginç satır yazmadan önce API anahtarları ve CORS ile bir öğleden sonra harcarsınız.

İlk geçişte yapılacaklar:

• Bir sayfa, bir giriş alanı, bir API çağrısı ve gösterilen tek bir sonuç

• Dış çağrıda 3 saniyelik zaman aşımı, yavaş bir üst akışın sayfanızı takılı bırakmaması için

• Çağrı başarısız olduğunda boş ekran yerine görünür bir hata durumu

• Sayfa yenilemenin ücretsiz katmanı zorlamaması için 60 saniye önbelleğe alınmış yanıt

Son madde bu dersin özüdür. Önbellekleme ve zaman aşımları, hiç kullanıcısı olmayan ve sonucu olmayan bir projede vereceğiniz ilk güvenilirlik kararlarıdır.

Bir pratik ipucu daha: API'den dönen her yanıtı bir kez ham haliyle kaydedin ve bu örnek yanıtı testlerinizde kullanın. Böylece sağlayıcı kapalıyken bile çalışan bir test setiniz olur. Bu, ilk günden test yazma alışkanlığının en küçük biçimidir ve hiçbir çerçeve gerektirmez.

API'nizin sahibi olmaya hazır olduğunuzda ne yapmalısınız?

İkinci proje yönü değiştirir. Başkasının API'sini tüketmek yerine kendi API'nizi sunarsınız. Bir yer imi servisi tam boyutta bir projedir: oluştur, listele, sil ve etiketle. Dört uç nokta, bir tablo ve bir öğleden sonra.

Sınırda, yani hataların en çok yaşandığı yerde tip güvenliği sağladıkları için TypeScript ya da Go ile yazın. Çoğu eğitimin atladığı bir uç nokta ekleyin: sağlık kontrolü.

// GET /healthz: yalnızca veritabanı yanıt verirse 200 döner
app.get("/healthz", async (_req, res) => {
  try {
    await db.query("select 1");
    res.status(200).json({ status: "ok" });
  } catch {
    res.status(503).json({ status: "degraded" });
  }
});

On satır, çalışan bir süreç ile çalışan bir servis arasındaki farkı öğretir. Her barındırma platformu bu rotayı yoklayabilir ve başarısız olduğunda sizi yeniden başlatabilir. Bunu ilk haftada kimse öğretmez. Öğretmeleri gerekir.

Bir ayrıntıya daha dikkat edin: sağlık kontrolü her yoklamada veritabanını sorguladığı için çok sık çağrılırsa veritabanına yük bindirebilir. Yoklama aralığını barındırma platformunun ayarlarında makul tutun. Çoğu zaman birkaç on saniyede bir yeterlidir. Bu, bir servisin kendi yükünü de hesaba katmak zorunda olduğunu gösteren ilk örnektir.

Sonra yayınlayın. Bir Git deposundan derleme yapan herhangi bir ücretsiz katmanlı sunucu yeter. Veritabanı adresini depoya değil, bir ortam değişkenine koyun. Sahte değerlerle bir .env.example dosyası commit edin. Herkese açık bir depoya gerçek bir gizli anahtarı bir kez gönderirseniz, bunu bir daha yapmazsınız. Bunu atılabilir bir veritabanıyla şimdi öğrenmek daha iyidir.

Mikroservis ayrımını, mesaj kuyruğunu ve Kubernetes manifestosunu atlayın. Tek bir servisiniz var. Onu tek bir servis gibi ele alın.

Yapılacaklar uygulaması hâlâ yapmaya değer mi?

Çoğunlukla hayır. Her yeni başlayanlar için kodlama proje fikirleri listesinde yer alır ve her işe alım yöneticisi bunlardan yüzlercesini görmüştür. Yapılacaklar uygulaması yanlış değildir, sadece ayırt edici değildir. CRUD kısmı, yer imi servisinin daha iyi öğrettiğinden fazla bir şey öğretmez.

Yine de yaparsanız kısıtı değiştirin. Gerçek kimlik doğrulamalı, çok kullanıcılı yapın. Çevrimdışı çalışsın ve sonra senkronize olsun. İki sekmenin aynı öğeyi düzenlediği durumda da ayakta kalsın. Öğrenme bu kısıtlarda gerçekleşir. Liste kendisi öğretmez.

Aynı kural hesap makineleri, rastgele sayı üreteçleri ve dijital saatler için de geçerlidir. Yeni bir dil için ilk hafta sonu uygundurlar. Portföy malzemesi değildirler ve yayın yapmak hakkında hiçbir şey öğretmezler.

Yapay zeka özelliğini oyuncak olmadan nasıl eklersiniz?

Ekleyin, ama küçük tutun. 2025 Stack Overflow anketi, yanıt verenlerin %84'ünün geliştirme sürecinde yapay zeka araçlarını kullandığını ya da kullanmayı planladığını, profesyonel geliştiricilerin %51'inin ise bunları her gün kullandığını gösterdi. İşverenler artık en az bir kez bir LLM API'si çağırmış olmanızı bekliyor. Asıl soru, bunu sorumlu bir biçimde yapıp yapmadığınızdır.

Sorumlu bir başlangıç yapay zeka projesinin üç özelliği vardır. Model çağrısına sert bir zaman aşımı koyar. Model kapalı ya da yavaş olduğunda çalışan bir yedek yol içerir. Her çağrının gecikmesini kaydeder, böylece p95 değerini görebilirsiniz. Yer imi servisiniz için bir özetleyici iyi bir uyum sağlar: bir URL yapıştırırsınız, iki cümlelik bir özet alırsınız ve çağrı başarısız olursa sayfa başlığına dönersiniz.

Kodu yazmak için bir asistan kullanıyorsanız, çıktıyı bir yabancıdan gelen bir çekme isteği gibi değerlendirin. Okuyun, çalıştırın ve bozmaya çalışın. GitHub Copilot ve Replit'in ajanı iskelet oluşturmada faydalıdır, ama ancak yaptığınız inceleme kadar güvenilirdirler. Aynı ankette yapay zeka çıktısına duyulan güvenin düşük olduğu görüldü: yanıt verenlerin yalnızca %29'u doğruluğuna güvendiğini söyledi. Bu sayı, kendi inceleme alışkanlıklarınız için makul bir varsayılandır.

Projeyi bilerek bozarsanız ne olur?

Bunu hiçbir listeye koymazlar, ama her yeni başlayana öneririz. Yayındaki yer imi servisinizi alın ve üç arıza yaratın. Veritabanı bağlantısını kesin. Dış API çağrınızdan 500 döndürün. İstek gövdesini on kat büyük gönderin.

Her arıza bir soruyu öğretir: kullanıcı ne görüyor ve bunu nasıl öğreniyorsunuz? İkinci sorunun cevabı gözlemlenebilirliktir ve bunu neredeyse hiçbir şeyle başlatabilirsiniz. Her istek için durum kodu ve süreyi milisaniye cinsinden içeren tek bir JSON satırı kaydedin. Bu tek başına "son bir saatte kaç istek başarısız oldu" sorusunu tek satırlık bir filtreyle yanıtlamanızı sağlar.

Birkaç günlük kayıt biriktiğinde bunları grafiğe dökün. Grafana'nın hobi servisleri için yeterli, ücretsiz bir katmanı var ve tek bir panelde p95 gecikmesini ve hata oranını göstermek, SLO'lar hakkında bir ay okumaktan daha fazla şey öğretir. Bir hedef tanımlayın, örneğin isteklerin %99'unun 500 ms altında olması, ve geçen hafta bunu tutturup tutturmadığınızı kontrol edin. İşte bu bir SLO'dur. Karmaşık değildir; yalnızca hiç nöbete çağrılmamış insanlar tarafından nadiren uygulanır.

Kayıtları okumak da ayrı bir beceridir. Hata satırlarını yalnızca saymakla kalmayın, her hata türü için bir not yazın: ne oldu, kullanıcı ne gördü ve düzeltmek için neyi değiştirdiniz. Bu notlar gerçek bir olay sonrası incelemenin (post-mortem) ilk taslağı olur ve yeni başlayanların çoğunun atladığı belgeleme alışkanlığını kendiliğinden öğretir.

Yeni başlayanlar özellik bayraklarını kullanabilir mi?

Evet, ve bu edinebileceğiniz en ucuz profesyonel alışkanlıktır. Özellik bayrağı, değeri koddan değil yapılandırmadan gelen bir if ifadesidir. Yapay zeka özetinizin etrafına bir tane koyun. Kapalı olarak yayınlayın. Kendiniz için açın. Sonra herkes için açın ve model sağlayıcısında kesinti olduğunda yeniden kapatın.

Bunun için bir platforma ihtiyacınız yok. Bir ortam değişkeni de bir bayraktır. Bir JSON dosyası ise daha büyük bir patlama yarıçapına sahip bir bayraktır. Kendi yaptığınız çözümün sınırlarına ulaştığınızda, LaunchDarkly ve Statsig gibi yönetilen seçenekler devreye girer ve neden birine ihtiyaç duyduğunuzu o zaman anlarsınız.

Alışkanlık, araçtan daha önemlidir. "Yayınlandı" ile "serbest bırakıldı" arasındaki ayrımı yapmak, kötü bir değişikliğin gece yarısı geri alınması yerine bir yapılandırma çevirmesi anlamına gelir. Birçok üretim ekibi bunu hâlâ yanlış yapıyor. 200 satırlık bir projeyle doğrusunu yapabilirsiniz.

Gerçekten bitirebileceğiniz yedi günlük bir plan

Yeni bir öğrenciye vereceğimiz sıra budur. Her günün sonunda kesin bir durak var.

• Gün 1: Döviz veya ülkeler panosunu oluşturun. Yalnızca yerelde. Bir çağrı, bir çizim.

• Gün 2: Zaman aşımını, hata durumunu ve 60 saniyelik önbelleği ekleyin. Yayına alın.

• Gün 3: Yer imi API'sini başlatın. Dört uç nokta, bir tablo, mutlu yol için testler.

• Gün 4: Sağlık kontrolünü ekleyin, gizli anahtarları ortam değişkenlerine taşıyın, yayına alın.

• Gün 5: Yapay zeka özetini bir bayrağın arkasına, zaman aşımı ve yedek yolla ekleyin.

• Gün 6: Yapılandırılmış istek kayıtlarını ekleyin. Servisi üç yoldan bozun ve ne gördüğünüzü not edin.

• Gün 7: Her arıza için bir paragraflık ve neyi değiştirdiğinizi anlatan bir README yazın. URL'yi bir kişiye gönderin.

Eksik olan şeye dikkat edin: her gün yeni bir çatı. Bir yığın seçin ve ona bağlı kalın. Beş dilin bir örneklemesi yerine tek bir dilde derinlik öğrenirsiniz ve yukarıdaki alışkanlıklar her yığına taşınır.

Neyi atlayacağız?

Yayınlanamayan her şeyi atlayın. Dosyaları yeniden adlandıran, yalnızca yerel çalışan bir Python betiği iyi bir yardımcı araçtır ama zayıf bir portföy girdisidir. Demonun çalışması için ücretli API anahtarları gerektiren projeleri atlayın. "Tam yığın sosyal ağ" projesini atlayın, çünkü altı haftanızı giriş ekranlarında harcarsınız ve yazılım çalıştırmak hakkında hiçbir şey öğrenmezsiniz.

Eğitim cehennemindeki devam projelerini de atlayın. Aynı kursu iki kez izlediyseniz, üçüncü proje kimsenin cevabı size vermediği bir proje olmalı. Bu rahatsızlık işin tam da amacıdır.

Yapmaya değer olan şey, bir URL'si, bir uç noktası, bir arıza biçimi ve neyi yanlış yaptığını kabul eden bir README'si olan her projedir. Böyle bir proje, okuyucuya cilalı bir klonun asla anlatamayacağı kadar şey anlatır.

Öyleyse yanınıza alacağınız soru şu: İlk projeniz bir yabancının önünde başarısız olduğunda, siz bunu onlardan önce fark edecek misiniz?