React, API, veritabanı
Teknik tercihinizi gösterir. Ziyaretçinin hangi ihtiyacını ele aldığınızı tek başına açıklamaz.
YAZILIM GELİŞTİRİCİ GÖRÜNÜRLÜĞÜ
Sizi araştıran kişi kullandığınız teknolojileri gördüğünde, kendi problemini nasıl çözebileceğinizi de anlayabilmeli. Projeyi, kişisel katkınızı ve teslim sınırınızı aynı hikâyede görünür kılın.
Yazılım Geliştirici Arda Demir
01 / PROBLEM, ROL, ÇIKTI
Teknik tercihinizi gösterir. Ziyaretçinin hangi ihtiyacını ele aldığınızı tek başına açıklamaz.
Kullanıcının yaşadığı sorunu, geliştirdiğiniz akışı ve bu işteki kişisel rolünüzü aynı yerde anlatır.
İşveren, teknik ekip ve proje sahibi portföyünüzü farklı gözlerle okur. Biri kullandığınız altyapıyı, diğeri belirsiz bir süreci nasıl çalışır hale getirdiğinizi arar. Giriş cümlenizde problemi adlandırın; ardından kim için, hangi kapsamda ne geliştirdiğinizi açıklayın. Teknolojiler bu anlatımı destekleyen bilgi olarak yer alsın.
“Her türlü yazılım geliştirilir” gibi geniş bir vaat, hangi talebin size uygun olduğunu gizler. Web arayüzü, entegrasyon, otomasyon veya bakım işlerinden gerçekten üstlendiğiniz alanları ayırın. Bir projede kullandığınız araç, o aracın bütün kullanım alanlarında deneyim sahibi olduğunuz anlamına gelmesin.
02 / İHTİYAÇTAN KABULE
Ekran görüntüsünün yanında davranış ve kabul sınırı da görünür olsun.
Arayüz katkısı ile sunucu ve altyapı katkısı ayrılır.
Gerçekte bağlanan sistem ve veri sınırı açıklanır.
Mobil uygulama veya bütün süreç otomasyonu yapılmış gibi gösterilmez.
İhtiyacı, başlangıç koşullarını ve ortaya çıkan davranışı sıralayın. “Panel geliştirdim” yerine panelin hangi kararı kolaylaştırdığını açıklayın. Ardından kabulün nasıl değerlendirildiğini belirtin: örneğin bir rolün hangi bilgiyi görmesi gerektiği veya hatalı girişte nasıl bir geri bildirim beklendiği.
Gerçek projede ölçülmüş sonuç varsa tarih, karşılaştırma koşulu ve kendi katkınızı ekleyin. Ölçüm yoksa yüzde kazanç üretmeyin. Prototip, çalışan demo ve üretimde kullanılan uygulama farklı aşamalardır; ziyaretçi hangisine baktığını başlıkta veya künyede anlayabilmeli.
03 / PROJE BÜTÜNÜ VE KİŞİSEL İŞ
Ürün ekipçe ortaya çıkmış olabilir; sizin üstlendiğiniz iş ayrıca açıklanır.
Temsili ekip projesi
Ekran akışı ve erişim durumlarının arayüzde gösterilmesi; sunucu altyapısının tamamı kişiye atfedilmez.
Temsili mevcut uygulama işi
Yeni ürün geliştirme olarak sunulmadan değişen davranış, kontrol edilen senaryo ve teslim notu açıklanır.
Projenin amacını anlatmakla bütün uygulamayı kendiniz yapmış olduğunuzu söylemek arasında fark vardır. Tasarım, arayüz, servis, test ve altyapı rollerini gerektiği kadar ayırın. Size ait olmayan tasarım veya kod katkısını künyede doğru ilişkilendirin; başkasının emeğini görünmez hale getirmeyin.
Katkıyı açıklamak için müşterinin adı zorunlu değildir. Yayın hakkınız varsa işin bağlamını ve kendi kararınızı anlatabilirsiniz. İşe katkı vermiş olmak, depoyu veya müşteri ekranlarını herkese açma hakkını otomatik sağlamaz.
04 / DEPOYU ANLAŞILIR KILMAK
Yazılım Geliştirici Arda Demir · Proje açıklaması
GitHub profilinizde kendinizi ve çalışma alanınızı açıklayabilir, öne çıkardığınız depoları bilinçli seçebilirsiniz. Sırf çok görünmek için yarım kalmış örnekleri aynı ağırlıkta sıralamak yerine birkaç işi açıklamasıyla sunun. README, teknik okuyucunun projeyi anlamaya başladığı yerdir.
Kurulum adımları gerçekten uygulanabilir olsun. Örnek yapılandırmada gizli anahtar yerine güvenli yer tutucular kullanın; canlı müşteri verisini örnek veri sanarak eklemeyin. Katkı grafiği veya yıldız sayısı tek başına iş kalitesi kanıtı değildir. Kapalı kaynak işleriniz varsa paylaşılabilir vaka anlatımı, rol ve teslim bilgisi de değerlidir.
05 / ÖZETTEN TEKNİK AYRINTIYA
Teknik olmayan okuyucu işin amacını ve kapsamını görür.
Teknik okuyucu yaklaşım, depo veya paylaşılabilir kanıta ulaşır.
Ziyaretçi hangi tür projeyle size ulaşabileceğini öğrenir.
Proje kartı kısa bir problem ve katkı özeti versin. Ayrıntı sayfasında teknik kararlar, sınırlamalar ve paylaşılabilir çıktı bulunsun. Demo, kaynak kod ve vaka yazısı ayrı bağlantılarsa bunu etiketleyin. Kapanmış bir demo bağlantısını çalışan ürün gibi bırakmayın; arşiv durumu veya mevcut erişim açıklaması ekleyin.
Portföyünüz sizin geliştirme kaliteniz için de bir deneyimdir. Telefonda okunabilen metin, klavyeyle kullanılabilen menü ve anlaşılır bağlantı adları sağlayın. W3C'nin ilk erişilebilirlik kontrolleri başlangıç olabilir; kısa kontrol tam uygunluk değerlendirmesi değildir. Teknik SEO tarafında sayfaların erişimi ve bulunabilirliği de incelenebilir.
06 / ÇALIŞAN ÜRÜNÜN SONRASI
Tablonun devamını görmek için yatay kaydırabilirsiniz.
| Konu | Açıklanacak çıktı | Ayrıca netleşecek sınır |
|---|---|---|
| Teslim | Kod, kurulum veya kullanım dokümanı | Hangi ortam ve kabul koşulunda teslim edildiği. |
| Bağımlılıklar | Kullanılan servis ve paketler | Ücret, lisans, erişim ve dış hizmet sorumluluğu. |
| Bakım | Üstlenilen güncelleme ve hata incelemesi | Süre, kapsam ve ayrıca değerlendirilecek geliştirmeler. |
| Destek | Talep ve geri dönüş düzeni | Sınırsız veya kesintisiz hizmet izlenimi verilmemesi. |
Bir işin görünürlüğü yalnız ilk ekranla sınırlı kalmasın. Kurulum kimin kontrolünde, hesap erişimi kime ait, hangi doküman teslim ediliyor? Bu soruları genel çalışma yaklaşımınızda açıklayın; her projeye aynı bakım süresini uydurmayın. Yeni özellik geliştirme ile kabul kapsamındaki hatanın ele alınmasını da ayırın.
“Hiç hata yapmaz”, “tam güvenli” veya “ömür boyu destek” gibi doğrulanamayacak ifadeler yerine gerçek süreç ve sınırları yazın. Güvenlik ve performans iddiası varsa hangi kapsamda değerlendirildiğini gösterin. Portföy metni, proje için yapılacak teknik keşif ve sözleşmenin yerini tutmaz.
07 / KANIT VE GİZLİLİK
Ekranın küçük bir köşesi bile müşteriyi veya sistemi tanımlayabilir.
PAYLAŞIM HAKKI
GİZLİ BİLGİ
KATKI VE SONUÇ
Anonimleştirilmiş örnek de bağlamından tanınabilir. Gerektiğinde tamamen temsili bir şema kullanın.
Kapalı kaynak projeyi görünür kılmak için kaynak kodu açmanız gerekmez. Paylaşılması uygun problem, yaklaşım ve kişisel katkı üzerinden bir vaka yazabilirsiniz. Yayın sınırı belirsizse müşteri adı ve ekranı yerine temsili akış tercih edin; bu akışın gerçek ürün görüntüsü olmadığını yazın.
Telif çerçevesini, kullanılan kod ve görsellerin lisansını da dikkate alın. Herkese açık depo, her parçanın sınırsız kullanım hakkı olduğu anlamına gelmez. Gizli verileri bulanıklaştırdıktan sonra dosyanın diğer alanlarında veya metadata içinde kalmadığını ayrıca kontrol edin.
08 / KEŞFE UYGUN BAŞLANGIÇ
Problemi anlamak ile sisteme erişmek farklı aşamalardır.
Talebin size uygunluğunu değerlendiren başlangıç.
Gerektiğinde kontrollü paylaşım ve kapsam görüşmesi.
“Bir uygulama istiyorum” mesajını iş ihtiyacına çevirecek kısa sorular kullanın. Kimin hangi işi yapacağı, bugün neyin aksadığı ve hangi çıktının beklendiği ilk değerlendirmeyi kolaylaştırır. Henüz keşif yapılmadan kesin fiyat veya teslim günü verilmiş izlenimi oluşturmayın.
Genel iletişim alanında parola, erişim anahtarı veya gerçek müşteri dosyası istemeyin. Teknik doküman gerekiyorsa paylaşım amacını ve yolunu ayrıca belirleyin. Başvuru alınması projeyi kabul ettiğiniz veya bakım sorumluluğunu üstlendiğiniz anlamına gelmesin.
09 / KONU, KAPSAM, TALEP
Kullanıcı ihtiyacını teknik kararla eşleştiren temsili yazı konusu.
Hangi problemi, hangi koşulda ele aldığınız anlaşılsın.
Sayfa verileri
Hangi problem anlatımının ilgi gördüğünü öğrenirsiniz.
Ziyaret, proje teslim kalitesini kanıtlamaz.
İlk talepler
Açıkladığınız kapsamla eşleşen ihtiyaçları görürsünüz.
Mesaj imzalanmış proje değildir.
Görüşmeler
Teslim veya bakım açıklamasında eksik kalan yeri bulursunuz.
Yıldız ve beğeni tek başına iş göstergesi değildir.
Her framework için aynı metni çoğaltmak yerine gerçek kararlarınızdan içerik üretin. Bir entegrasyonun sınırı veya bir arayüz davranışının gerekçesi, çalışma yaklaşımınızı daha iyi gösterir. Google'ın kullanıcı odaklı içerik yaklaşımı açısından da okuyucunun ihtiyacını tamamlayan özgün açıklama önemlidir.
İçerik stratejisini blog trafiğinden uygun proje talebine uzanan sorularla kurun. SEO hangi ihtiyaçlarla keşfedildiğinizi inceleyebilir. Grafik tasarımcı görünürlüğünde olduğu gibi kişisel katkı ve teslim hakları burada da portföyün temel parçalarıdır.
10 / KENDİ PORTFÖYÜNÜZ İÇİN
GitHub teknik kanıtları sunabilir. Portföy sitesi ise problem, kişisel rol ve teslim sınırını teknik olmayan okuyucu için bir araya getirir. İhtiyacınıza göre iki alanı birbirine bağlayabilirsiniz.
Paylaşım hakkınızın izin verdiği kapsamda problem, yaklaşım ve kişisel katkıyı anlatın. Kod veya müşteri ekranını açmak zorunda değilsiniz; temsili şemayı açıkça etiketleyin.
Yalnız teknoloji adı değişen kopyalar yerine farklı bir kullanıcı ihtiyacını tamamlayan içerik hazırlayın. Ayrı sayfa ancak gerçek kapsam, örnek ve karar farkı varsa anlamlıdır.
Yayın hakkı ve gizlilik koşulları değerlendirilmelidir. Uygun olduğunda proje bütününü ve sizin katkınızı ayrı açıklayın; ekipteki diğer işleri kendinize atfetmeyin.
Gerçek ölçümün tarihi, ortamı, karşılaştırma koşulu ve katkınız görünür olsun. Ölçüm yoksa yüzde veya hız iddiası üretmek yerine kontrol edilen davranışı anlatın.
Yalnız çevrimiçi çalışmak profil uygunluğunu otomatik sağlamaz. Gerçek çalışma düzeninizi Google koşullarıyla değerlendirin; sanal ofis veya uydurma konumla kayıt oluşturmayın.
KAYNAKLAR
Son kaynak kontrolü:
Görünürlük ve portföy rehberidir. Örnekler gerçek proje, güvenlik denetimi veya teslim taahhüdü değildir; yayın ve lisans koşulları kendi işiniz için değerlendirilir.
BLOG / BİLGİDEN UYGULAMAYA
Aynı yazıyı iki sitede paylaşmanın Google görünürlüğüne etkisini, canonical ve noindex farkını ve yeniden yayınlama sonrası kontrolleri öğrenin.
Şirketinizin ChatGPT’de keşfedilmesi için arama botu erişimini ve hizmet sayfalarını kontrol edin. Marka anılması, kaynak gösterimi ve ziyaretleri ayrı ölçün.
Siteniz Google’da görünmüyorsa indeksleme ve sıralama sorunlarını ayırın. Search Console, robots.txt, noindex ve canonical kontrollerini sırayla uygulayın.