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
Yazar Hakkında
En Güncel Yazıları
Özcan Acar
Özcan Acar 1974 İzmir doğumludur. İlk ve orta öğrenimini İzmir’de tamamladı. Almanya'daki lise öğreniminden sonra doksanlı yılların sonunda Almanya’nın Darmstadt şehrinde bulunan FH Darmstadt üniversiteden bilgisayar mühendisi olarak mezun oldu.
KurumsalJava.com, SmartHomeProgrammer.com ve Mikrodevre.com adresleri altında blog yazıyor. Kurduğu BTSoru.com'da ona yazılımla ile ilgili sorularınızı yöneltebilirsiniz. Pratik Programcı Yayınları bünyesinde Pratik Spring, Pratik Agile ve Pratik Git ismini taşıyan kitapları bulunmaktadır. 21.12.2009 tarihinde Java Champion olarak seçildi.
Son Yazıları (hepsini göster)
Yazan Özcan Acar
28 Eylül 2015
4 Yorum
Performans
Yazılım ,
Yazıyı Oku
4 Yorum	
Levent Yıkılmaz 1 Ekim 2015 at 17:30
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.
Emre KAÇAN 2 Ekim 2015 at 13:43
Hocam yazı için teşekkürler
Derviş ERDİN 8 Ekim 2015 at 00:06
Elinize sağlık hocam ,
Abdullah 19 Kasım 2016 at 13:26
Teşekkür Ederim Öğrettiklerinizden Dolayı
Müşterilerimiz Ne Diyor?
Profesyonel Java
Mustafa Emek
Kursu tamamlamam 1 haftamı aldı. Gerçekten ciddi emek verilmiş harika bir çalışma. Elinize emeğinize sağlık..
E-Posta Bilgilendirme
Leave Blank: Do Not Change:
E-Posta Adresiniz:
Güncel Yazılar
14
May	JVM Nasıl Çalışır Yazı Serisi – Java Just In Time Compiler (JIT) Nasıl Çalışır? 0 Yorum.
03
May	JVM Nasıl Çalışır Yazı Serisi – Java Nesne Düzeni (Java Object Layout) 0 Yorum.
05
Mar	Blog Yazılarım Ekitabı Yeni Sürümü 0 Yorum.
26
Şub	Yazılımda Şemsiye Modeli 0 Yorum.
22
Oca	Kıymeti Bilinmeyen Eskimiş Bilginin Kıymeti 1 Yorum.
01
Oca	Daha İyi Bir Programcı Olmak İçin Sınırlar Nasıl Zorlanmalı? 3 Yorum.
04
Ara	Karadelikler, Soyutluk ve Yazılım 3 Yorum.
26
Kas	Gitolite İle Git Depo Erişimi 0 Yorum.
20
Eki	Paralel Evrenlerin Programcıları 4 Yorum.
15
Eki	Neden Frontend ve Backend Programcısı Tarihe Karışıyor 15 Yorum.
Ürün Etiketleri
Agile Design Patterns Git Java Spring Tasarım Şablonları XP
En Beğenilen Ürünler
Pratik Git	
5.00 5 üzerinden
Ücretsiz!
Pratik Agile	
5.00 5 üzerinden
Ücretsiz!
Pratik Spring Core	
4.93 5 üzerinden
Ücretsiz!
Design Patterns	Ücretsiz!
Özcan Acar Blog Yazıları	
5.00 5 üzerinden
Ücretsiz!
Blog Yazılarımız
Yazılımda ve Yazılımcıda Çok Boyutluluk
Matematiksel anlamda boyut belli bir yönde ölçülmüş bir büyüklüğü ifade etmek için kullanılan geometrik bir terimdir. Günlük kullanılan dilde boyut kelimesi bakış açısı, vizyon, perspektif, farkındalık gibi kelimelerle eş anlamlıdır.…
JVM Nasıl Çalışır Yazı Serisi – Java Just In Time Compiler (JIT) Nasıl Çalışır?
Java’yı çoğu programcı yorumlanan (interpreted) dil olarak bilir. Java’nın yavaş olduğu efsanesi de başlangıcını da burada bulur. Bytekod olarak derlenen Java sınıfları Java sanal makinesi (Java Virtual Machine – JVM)…
JVM Nasıl Çalışır Yazı Serisi – Java Nesne Düzeni (Java Object Layout)
Bu yazımda bir Java nesnesinin hafıza alanında (heap) nasıl yer aldığını yanı sahip olduğu hafiza düzenini (object layout) aktarmak istiyorum. Bu amaçla aşağıda yer alan sınıfı kullanacağım. Java nesnelerinin hafıza…
Blog Yazılarım Ekitabı Yeni Sürümü
Blog Yazılarım isimli ekitabımın 4. sürümünü hazırladım. Bu link üzerinden ücretsiz edinebilirsiniz. EOF (End Of Fun) Özcan Acar Yazar Hakkında En Güncel Yazıları Özcan AcarÖzcan Acar 1974 İzmir doğumludur. İlk…
Yazılımda Şemsiye Modeli
Yazılımda testlerin gerekliliğini ve hangi testlerin ne zaman uygulandığını açıklamak amacıyla şemsiye modeli ismini verdiğim bir model oluşturdum. Bu yazımda sizlerle bu modeli ve işlevini paylaşmak istiyorum. Şemsiyeler gerçek hayatta…
Kıymeti Bilinmeyen Eskimiş Bilginin Kıymeti
Bilginin yarı ömrünün aylar seviyesinde ölçüldüğü bir çağdayız. Her şeyi çok hızlı tüketiyoruz. Bu bilgi için de istisnasız geçerli. Bu durumun en büyük mağdurlarından birisi yazılımcılar. Sürekli yeni bir şeyler…
Daha İyi Bir Programcı Olmak İçin Sınırlar Nasıl Zorlanmalı?
Herhangi bir konuda daha iyi olabilmenin yolu, mevcut sınırları ve bariyerleri daha öteye taşımaktan geçer. Bu sınırlar fiziksel ya da manevi türde olabilir. Fiziksel sınırları ileriye taşımanın nasıl bir şey…
Karadelikler, Soyutluk ve Yazılım
Günümüzde yazılım elli sene öncesi gibi if/else/while ile yapılsa da, en büyük farklılığı gelinen soyutluk seviyesi teşkil ediyor. Elli sene önceki gibi yazılımcılar artık mikro işlemcinin üzerinde işlem yapmıyorlar. Artık…
Gitolite İle Git Depo Erişimi
Gitolite sunucu üzerinde bulunan Git depolarına (repository) erişimi kontrol etmek için kullanılan bir ara katman. Gitolite ile kullanıcılara SSH protokolü aracılığı ile depo bazında okuma ve yazma hakları tanımak mümkün.…