Geliştiricinin Huyu Suyu

Geçenlerde internette gezinirken Quora’da sorulmuş bir soruya denk geldim. Soru şuydu:

“Bir yazılımcı olarak iş ortamınızda sizi en rahatsız eden şeyler neler?”.

Cevapları incelediğimde genellikle ortak sorunların yaşandığını gördüm ve sorunların başlıca sebebinin yöneticiler ile olan iletişim eksikliği olduğunu fark ettim. Bu sorunları, yaşanma sıklığına göre şöyle sıralayabiliriz.


1. Spesifikasyon eksiklikleri

Projelere başlanmadan önce müşterilerle konuşulur ve proje detayları incelenip, maddelendirilerek spesifikasyon listesi oluşturulur. Ancak çoğunlukla gözden kaçan detaylar çıkar (ki bazen bu detaylar detay denemeyecek kadar büyük olabiliyor). Bu eksiklikler proje geliştirilmeye başlandıktan sonra geliştiricilerin takıldığı noktaların çoğunluğunu oluşturuyor.

Müşteri ne istediğine emin değilse veya müşteriden spesifikasyonlar net bir şekilde alınmadıysa, geliştirme duraksatılarak müşteriden geri dönüş beklenir. Ya da geliştirici insiyatif kullanarak eksik olan kısımlarda kendi çözümünü üretir. Bu çözüm genelde sonradan değiştirilmek üzere yapılır. Bile bile lades yani. Sorun şu ki, geliştiriciler zihin okuyamazlar.

TLDR; projenin her detayını açık ve net bir şekilde dökümante edin, geliştiricileri insiyatif kullanmak zorunda bırakacak veya bekletecek durumlara sokmayın.


2. Bölünmeler

Araştırmalara göre insanların veriminin en çok arttığı, odağının doruğa ulaştığı bir evre var, ‘The Zone’ olarak geçiyor. Çalışılmaya başlandıktan sonra yaklaşık bir 25–45 dakika sonra odağımız yüzde 300 kadar artıyor ve zone’a girmiş oluyoruz. Odaklanma süresi bu kadar uzunken kaybolması saniyeler içinde hatta belki bir el şıklanmasıyla olabiliyor.

Image Credit: The Social Network

Geliştiriciler bu evrenin verimine en çok inanan ve en iyi şekilde kullanan mesleklerden biri. Kulaklığını takıp müzik dinleyerek kod yazanlar gözünüze çarpmıştır. İşte bunun sebebi dışardan gelen uyarıları yok edip zone’a dalabilmektir.

Image Credit: Toggl Blog

Kulaklık kuralı diye bir kural var. Kural şu: Eğer kulaklık takıyorsam beni rahatsız etme. Bazen şunu da görüyorum şapka takılıyor. Şapka takıyorsa da siz dokunmayın en iyisi. Yanına gidip konuşmak yerine mesela Slack’ten yazın, tabii işiniz çok çok acil değilse . Veya en güzeli daha en başından her şeyi organize etmiş olun. Scrum buluşmalarının bir amacı da bu değil mi zaten?

TLDR; koda gömülmüş geliştiriciyi ufak tefek sorular ile rahatsız etmeyin, odağını bölmeyin. Slack kullanın, önceden organize edin.


3. Teknik Borç

Geliştiricilerin en çok şikayet ettiği bir başka konu da gitgide artan teknik borçlar. Önce teknik borcun ne olduğuna değineyim. Aslında epey detaylıca incelenebilecek ve çözümleri sıralanabilecek bir konu, ancak burada özet geçmek zorundayım.

Teknik borç, projenin ilerleyişi sırasında en uygun çözüm yerine, hızlı ve kolay yolları tercih edip projenin kirlenmesi sebep olmaktır. Ancak dt sürede hızlı olan yol bu gibi gözüksede T sürede kısa olan yol, kolay veya zor olan değil, doğru olan yoldur. Çünkü projelerin devamında bu kirlilik geliştiriciye yük olacak ve yapacağı her değişikliğin zaman maliyetini arttıracaktır. Projenin ölçeklenebilir olması, arkada teknik borç bırakmadan ipleri baştan ele alarak ilerlemekten geçer. Bazen hızlı ve kolay çözümleri tercih etmek kaçınılmaz ancak birikmesine izin vermeden arada bir geriye dönüp refactor etmek gereklidir.

Zaman konusunda geliştiriciyi boğup nefes almasına engel olan yöneticiler ve müşteriler genellikle projeyi teknik borca sokarlar. Zaman içinde bunun ceremesini yine kendileri çekerler. Borçlar batağa girdiğinde hop projeyi baştan yazmak zorunda kalabilirsiniz :)


4. Sürekli Tekrarlanmalar

Bölünmeler başlığıyla biraz ters düşen bir madde. Ancak tek bir projeye takılı kalıp sürekli aynı şeyler üzerine çalışmak da verimi düşüren bir etken. Bunun dengesinin iyi ayarlanması gerekiyor.

Aynı projede çalışmak o kadar can sıkıcı olmasa da, o projenin tek bir kısmına takılıp sürekli olarak aynı yerleri bir öyle bir böyle değiştirmek zorunda kalmak epey can sıkıcı olabiliyor.

Bazı şirketlerde bu şekilde bunalan çalışanların kafasını dağıtması için kendi işinden ayrı işler ayarlanıyor. Şirket için blog yazması, vlog çekmesi veya şirket içi anket yapması gibi. Kulağa belki saçma geliyor ama aslında çalışanların da hoşuna giden şeyler bunlar.

TLDR; yapılan bir yer üzerinde sürekli fikir değiştirmeyin, sürekli eski değişiklikleri çöpe atıp yenisinin yazılmasını istemeyin. Son bir karar verin ve onu uygulayın.


5. Kötü QA (Quality Assurance)

Kumdan bir kale inşa ettiğinizi düşünün. Saatlerce uğraşmışsınız, yapmışsınız, su kanalları bile açmışsınız efsane. Sonra çocuğun teki gelip tekmeleyip bozuyor bütün her şeyi. Kötü QA’in yarattığı tam olarak böyle bir his. Halbuki testi yapan kişiler kodu bölmek yerine yararlı raporlar çıkararak kodu iyileştirici etkiye sahip olmalıdır. Genelde kötü test denince şunlar akla geliyor:

  • Yaratılan bug raporunun, testi yapan kişinin kullandığı cihazdan kaynaklı bir problem olması
  • Yanlış sorunlara öncelik verilmesi veya her şeye yüksek öncelik verilmesi :)
  • Anahtar bilgileri rapora dahil etmemesi
  • Hatta hiç rapor hazırlamayıp, her sorun çıktığında yanınıza gelip ‘bu bozuk çalışmıyor’ diyip gitmesi. Dökümante edilmesi lazım.

Aslında bana sorarsanız testi yapan kişinin ucundan köşesinden kod yazmayı da biliyor olması lazım. Yazmayı bilmese dahi, teknik açıdan belirli bir yetkinlikte olması lazım.

Testi yapan kişiler iyiyse durum tam tersi. İyi bir testçi bir geliştiriciyi rahatsız ediyorsa, muhtemelen iyi bir amaçla rahatsız ediyordur. Onu daha iyi bir geliştirici olmaya teşvik ediyordur. Hatta gün gelir o geliştiricinin bütün kariyerini mahvetmesine sebep olacak bir hatayı önceden fark ettirebilir ve onu kurtarabilir. Saygımız sonsuz…

TLDR; testlerde bulunan bulguların tutarlılığından emin olun, önceliklendirmeyi doğru yapın. Bulgularınızı raporlayın


6. Süre Tahminleri

Süre tahmini çok zor bir iştir. Yapılan tahminlere göre bütün projeyi etkileyecek kararlar alınır ve ona göre plan yapılır. Ancak bunlar sadece tahmindir, onurumuzun üstüne ettiğimiz bir yemin değil. Bu sürelerin sadece tahmin olduğunu bilmeyen yöneticiler, bunlara deadline gibi davranarak sizi darlayabilir, hızlı yazmanıza sebep olarak sizi teknik borca sokabilir. Daha kötüsü sizi yetiştirememekle suçlayabilir ve çıkan problemleri görmezden gelebilir. Dolayısıyla her zaman süreyi fazla fazla vermekte fayda var :)

Eğer Agile geliştirme prensibiyle çalışıyorsanız ve Scrum kullanıyorsanız, Story Points kullanmanızı öneririm. Özetle şu: Yapacağınız işin boyutuna, karmaşıklığına, oluşabilecek risklere vs. puan veriyorsunuz. Bu puanlara göre harcama potansiyelindeki eforunuz için daha sağlıklı tahminler yapabilirsiniz.


7. Başkasının Kodundan Devam Etmek

İşe giriş çıkışın çok olduğu şirketlerde çok fazla yaşanır bu problem. Yeni bir işe girdiğinizde yeni bir projeye başlıyorsanız çok şanslısınızdır, çünkü genelde yıllar öncesinden gelen projelerin hatalarını çözmektir ilk göreviniz. Eğer önceki yazılanlardan bilgiler aktarılamamışsa içinde kaybolup gitmeniz ve anlamamanız çok normal. Bir şeyi anlamadan düzeltmeye çalışmak, iyi bir yaklaşım değil, anlamanız için de bütün kodu okumanız gerekmemeli. Eğer başka yolunuz yoksa demek ki şunları yaşıyorsunuz

  • Dokümantasyon yoksunluğu
  • Kötü dokümantasyon (Dokümantasyon yoksunluğundan daha çok nefret edilen bir şey varsa o da kötü yazılmış bir dokümantasyondur)
  • Yorum satırlarının olmayışı
  • Geleneklere(convention) uyulmamış olması
  • Hiçbir test yazılmamış olması

Her zaman o kadar da kötü değildir başkasının kodundan devam etmek. Özellikle de kod yazmaya yeni başladıysanız başkasının kodunu okumak çok eğitici olabilir. Çoğu geliştirici bir başkasının kodlarını okuyarak öğrenmiştir yazmayı. Ancak kodunu okuduğunuz kişi tecrübesiz ve kötü yazan birisiyse, o zaman işkenceye dönüşür.


Kodunuzu yazarken bir sonraki okuyacak kişinin nerede yaşadığınızı bilen vahşi bir psikopat olduğunu düşünerek yazın.
- John F. Woods, Eylül, 1991