BTSoru.com da yazılımcıların performansı nasıl ölçülür şeklinde bir soru sorulmuş. Bu konudaki naçizane fikirlerimi bu blog yazımda sizlerle paylaşmak istedim. Bu yazımda performans ile verimliliği eş tutuyorum. İyi bir performans verimli bir çalışma anlamına gelmektedir.
Yazılımcının iş gücü olarak ortaya koyduklarının tümünü performansı olarak tanımlayabiliriz. Performans ölçümünde sorulması gereken bazı sorular şu şekilde olabilir:
- İşini severek yaptığı söylenebilir mi?
- Müşteri gerensinimlerini hangi hızda kavrıyor?
- Programcı hangi zaman diliminde ne kadar iş ortaya koyuyor?
- Yaptığı işin kalitesi nedir?
- Etrafı ile iletişimde ne kadar başarılı?
- Yapılan tahminler (estimates) çerçevesinde işi tamamlayabiliyor mu?
- Yazdığı kodun hata oranı nedir?
- Yazdıgı kodun doğruluk oranı nedir?
- Yazdığı kodun dokümansyon oranı nedir?
Bu soruların cevaplarını aramadan önce, şu sorunun cevabını aramamızın daha doğru olacağını düşünüyorum: “iki programcı kendilerine verilen bir iş için aynı cözümü mü üretirler?” Bu sorunun cevabının hayır olduğunu biliyoruz. Her yiğidin yoğurt yiyiş tarzı değişik olduğu gibi, her programcının da kod yazış ve çözüm üretiş şekli farklı olacaktır. Peki bu durumda programcının performansını ölçmek için kaç satır kod yazdığı ya da işi hangi zaman diliminde bitirdiği önemini yitirmiyor mu? Her progragramcının seçtiği yöntem farklı olacağı için perfomans ölçümünü aynı terazi ile tartmamız imkansız hale geliyor. Bu yüzden yukarıda verdiğim soruların cevapları performans ölçümleri için ya yetersizdir ya da subjektif cevapların oluşmasını teşvik ederler. Örneğin müdürün sepmatik bulmasından dolayı iyi bir programcı olduğunu düşündüğü programcı benim için iyi olmayabilir. Yazılımda peformans ölçümlerinin sübjektif bir doğası olduğunu kabul etmemiz gerekiyor. Peki ama programcıların performansını nasıl ölçebiliriz? Zor iş doğrusu!
Bir ekibin içinde yer alan bir programcıya “bu ekibin en iyi programcısı kimdir” diye sorun, size hemen kim olduğunu ya da olmadığını söyleyecektir. İyi ama objektif yöntemlerle performansını ölçemediğimiz bir programcı hakkında nasıl olur da böyle bir kanaat ortaya atılabilir? Diyorum ya, burada yine subjektif algılar ortaya çıkıyor. Eğer objektif performans ölçümü mümkün degil ise, o taktirde subjektif performans ölçümlerini kullanmak zorundayız. Subjektif performans ölçümü nasıl yapılabilir, şimdi bu sorunun cevabını aramaya çalışalım.
Bir ekip içinde kimin iyi yazılımcı olduğunu ekip içinde herkes bilir demiştim. Bu gerçekten de böyle. Bu kanı subjektif algılarla oluşuyor. Bir progamcı hakkında bu algıların oluşabilmesi için programcının iki yetenek gurubunda faal olması gerekiyor. Bunlar:
- Somut teknik yetenekler (hard skills)
- Sosyal yetenekler (soft skills)
İlki programcının nasıl kod yazdığı, yazılım süreçlerine ne derecede hakim olduğu, müşteri gereksinmlerini kavrama ve koda dönüştürme kabiliyetinin gelişmişliği ile, ikincisi duygusal zekası, ekip çalışmasına yatkınlığı, bilgisine bilgi katma azmı, çalışma arkadasları ile iletişimi, hayata bakış açısı, hobileri ve programcı kimliği ile ilgilidir. Şimdi bu yeteneklerin programcıyı nasıl öne çıkardığını ve subjektif performans ölçümünde kullanılabilir veriler sağladığını yakından inceleyelim.
(İyi programcı == iyi kod yazan ve en basit çözümü oluşturan programcı) denklemi her zaman geçerlidir. Buradaki yazımda basit çözüm oluşturma yetisinin nasıl geliştirilebileceği konusuna değinmiştim. Geriye iyi kod yazma teknikleri kalıyor. Bu konu başlı başına bir bilim dalı. Bu yüzden uzun süre ihtisas gerektirir. Bu konuda sayılabilecek yüzlerce konu başlığı mevcut. Aklıma gelen bazı konu başlıklarını sizlerle paylaşmak isterim. Şöyle ki: temiz kod (clean kod) akımı, tasarım prensipleri, tasarım şablonları, çevik yazılım süreçleri, test güdümlü yazılım (TDD/ATDD = Test Driven Development, Acceptance Driven Development), kod kataları, versiyon ve sürüm yönetimi, versiyon kontrol yönetimi, modüler yapılar, yapılandırma araçları (build tools), performans ölçümleri, dijital elektronik, mikro denetleyiciler, IoT (Internet of Things) işletim sistemleri, donanım, alana has diller (DSL = Domain Specific Languages), UML, XML/XSL, sürekli entegrasyon (continuous integration), derleyici (compiler) mimarileri, webservice/microservice/SOA/rest/bulut mimarileri, büyük veri (big data), index ve arama teknolojileri, mobil programlama, katmanlı mimariler, yeniden yapılandırma (refactoring) teknikleri, nesneye yönelik programlama (OOP = Object Oriented Programming), fonksiyonel programlama, aspekt tabanlı programlama (AOP = Aspect Oriented Programming), alan bazlı programlama (DDD = Domain Driven Development), davranış güdümlü programlama (BDD = Behavior Driven Development), yazılım ustalığı (software craftsmanship)… Daha sayabileceğim birçok konu mevcut, lakin yazılıma yeni başlayanların gözünü korkutmak istemiyorum 🙂
Bu vermiş olduğum her bir konu başlığı için aylarca ya da yıllarca ihtisas yapmak gerekebilir. Yazılım bir ömür aralıksız sürebilecek bir ihtisas alanı gibi görünüyor. Nitekim iyi programcı olarak gördüğümüz meslektaşlarımız bu konuların hepsine hakim olmasalar bile, her konuda bilgi sahibidirler ya da çok kısa bir zaman diliminde otodidakt (kendi kendine bir konuyu öğrenebilme yetisi) olmalarından dolayı istedikleri konuyu öğrenebililer. Bu bilgilere sahip olunması, bilgi dahilinde kodun şekillendirilmesi ve uygulanan metot ve yöntemlerin tümü sonuç itibari ile somut teknik yetenekler olarak tanımladığım programcı yetenekleri gurubunu oluşturmaktadır. Bu yetenekleri gelişmiş bir programcının yazdığı koda bakarak dahi hangi seviyede olduğunu görmek mümkündür. Tabi kod yazmak madalyonun bir yüzü. Gelelim diğer yüzüne.
Yazılım bir giriş/çıkış (IO = Input/Output) transformasyonunda başka bir şey değildir. Kullanıcı veri girer, uygulama bu verileri başka verilere dönüştürür. Aynı şekilde programcı için de IO kuramı geçerlidir. Programcı yapacağı iş konusunda veri alır ve bunu koda dönüştürür. Bu dönüşüm sürecinin en mühim safhası, programcının kendisi yönünde gerçekleşen veri akışını nasıl algıladığıdır. Burada soft skills olarak tanımladığımız sosyal yetiler devreye giriyor. Sosyal yetiler olmadan bir programcının ne kadar mükemmel kod yazdığı hiçbir önem taşımamaktadır, çünkü madalyonun diğer kısmı kendisinde eksiktir.
Sosyal yetilerin subjektif performans ölçümlerini nasıl etkilediğini birkaç örnek üzerinde aktarmak istiyorum. Zaman zaman ekip toplantıları olur. Bu toplantılarda fikir alışverişine dahil olunuş seviyesi iletişim ve söz sahibi olma yetisinin ne kadar gelişmiş olduğuna işaret eder. Fikir sahibi olanlar ve toplantı içeriğine yön verebilenler öne çıkar ve göze batmaya başlarlar. Bir başka örnek vereyim. Modüler yazılım sistemleri arayüzlerden (interface, facade, rest api) oluşur/oluşmalıdır. Bu programcıları birlikte çalışmaya zorlayan bir durumdur. Ekip işi denilen durum buradan doğar. Ekip işine yatkınlık bir sosyal yetidir. Bu konudaki beceriklik subjektif performans ölçümünü sağlayıcı niteliktedir.
Genel olarak sosyal yetilerin programcı için bir süzgec vazifesi gördüğünü söyleyebiliriz. Programcı bu süzgeç sayesinde ekiple birlikte neyi nasıl yapması gerektiğine karar verir ve bu kararı somut teknik yetenekleri ile hayata geçirir. Madalyonun ön yüzünü sosyal yetiler, arka yüzünü somut teknik yetiler oluşturur. Programcıyı programcı yapan bu ikisinin birleşimidir. Birisinin eksikliği karşımızdaki şahsın programcı olmak için yeterli donanıma sahip olmadığı anlamına gelir. Ama bu eksiklik onun hiçbir zaman programcı olamayacagı anlamına gelmez. Şöyle ki…
Bahsetmiş olduğum somut ve sosyal yetenekler pratik yapılarak geliştirilebilecek cinstendir. Hiçbir şahıs programcı olarak doğmadığı gibi, bu yeteneklere de emek sarfetmeden sahip olamıyor. Bu yazımda pratik yapmanın önemine değindim. İnsanlar arası ilişkiler için gerekli sosyal yeteneklerin geliştirilmesi için de değişik türde pratikler yapılabilir. Burada önemli olan niyet ve sorumluluk bilincidir. İyi bir programcı olmak çok çaba sarfetmeyi gerektirir ve bireyin bu sorumluluğu alıp, alamadığı doğrudan subjektif performans ölçümlerine yansır.
Programcılık sadece kod yazmaktan ibaret değil. Aslına bakarsanız kod yazma programcılığın çok küçük bir bölümünü oluşturuyor. Oraya gelene kadar programcının diğer yeteneklerini kullanması gerekiyor. Bu yetenekler olmadan doğrudan kod yazma safhasına gelinemeyeceği aşikar. Bu durumda geriye programcının kendisini işine olan saygısı ve sorumluluk bilincine istinaden bahsetmiş olduğum yetenekleri geliştirmeye adaması kalıyor. Bu sadece yapılan işe duyulan tutku ile sağlanabilecek bir durum.
EOF (End Of Fun)
Özcan Acar
Yorumlar
“Yazılımcıların Performansı Nasıl Ölçülür?” için 4 yanıt
Güzel yazı elinize sağlık hocam, ayrıca çokda kasmaya gerek görmüyorum, kişisel düşüncem bir şirket müdürü olsaydım, şirketimdeki yazılımcıların performansını ölçmek isteseydim eğer bunu onların işlerini yaparken ne kadar hızlı, pratik ve rahat, relax modda iş yaptıklarını önemserdim, bir yazılımcı bence rahat olmalıdır, kendini kasmamalıdır, her gün bir önceki güne göre kendini geliştirmelidir. 🙂 Ama en önemlisi rahat davranmalı, sade olmalı ve yeniliğe açık bir beyne sahip olmalıdır.
Hocam yazı için teşekkürler 🙂
Elinize sağlık hocam ,
Teşekkür Ederim Öğrettiklerinizden Dolayı