Geçenlerde yine tartışması yapılıyor: private olan metotları nasıl test ederiz? Benim cevabım: “edemeyiz!” Karşıdan gelen cevap: “dediğim gibi, her şeyi test etmek mümkün değil demek ki!“. Benim cevabım: “her şeyi test etmek mümkün, private’i protected yaparsın, olur, biter.” Karşı tarafın cevabı: “kardeşim ortada OOP diye bir şey var, kafana göre nasıl öyle private bir metodu proteted yaparsın?“. Yaparım canım kardeşim. OOP’yi filan takmam! Protected‘de yaparım, public‘de. Bir sınıfı test edebilmek için her türlü yöntemi kullanırım, gözünün yaşına bakmam. Bu uğurda her şey mübahtır.
Yazar arşivleri: Özcan Acar
Deneme Yanılmanın Bedeli
Yazılım yaparken en büyük zaman kaybının nedeni, kodu değiştirip, derleyip, çalışır hale getirdikten sonra değişikliğin sonucunu test etmektir. Kodu değiştir/derle/çalıştır/dene süreci otuz saniyeden beş dakikaya kadar sürebilir. Günde bunu on sefer yaptığınızda bir saatlik bir zamanı boşa harcamış olursunuz. Bu sebepten dolayıdır ki EJB2 ve benzeri teknolojilerin yerine Spring gibi daha hafif yazılım yapmayı sağlayan çatılar (framework) oluşmuştur.
Uzaktan Eşli Programlama
Eşli programlama yapmak için illa iki programcının aynı mekanda olması gerekmiyor. Eclipse kullanıyorsanız Saros pluginini kurarak, uzak bir bilgisayardaki bir şahıs ile eşli programlama yapabilirsiniz.
Veresiye Satan Yazılımcı
Editörü açtınız, public class yazarak yeni bir sınıf oluşturdunuz. Bu sınıfa yeni bir metot eklediniz. Başka bir şey yapan yeni bir metot daha eklediniz. Sınıf yavaş yavaş şismeye başladı. Birkaç refactoring yaptınız. Buradan yeni bir sınıf dünyaya gözlerini açtı. Bir sınıf, bir sınıf daha derken sınıf sayısı onlara ulaştı. Her sınıfın metot küfesi iyice ağırlaşmaya başladı. Göz açıp, kapayana kadar birkaç bin satır kod oluştu. Program istediğiniz şekilde çalışıyor sanırım. Yaptığınız işten memnunsunuz, ama içinizden bir ses bir şeylerin doğru gitmediğini söylüyor. Eksik olan ne? Testler!
Uzman ve Usta Yazılımcı Arasındaki Fark
Fanatik futbol severleri bilirsiniz. Takımları için yapmayacakları yoktur. Bu fanatiklik başka insanlara zarar vermeye kadar varabilir. Yazılımda da durum farklı değildir. Tek fark bu fanatikliğin insana zarar verecek seviyede olmamasıdır.
İzci kuralı
Her izcinin uyduğu bir kural vardır:
“Kamp yaptığın yeri bulduğundan daha iyi bir şekilde bırak!”
Yazılımcı olarak bu kuralı uygulamak istediğimiz taktirde, mevcut yazılım standartlarına uymayan kod birimlerini tereddüt etmeden yeniden yapılandırarak, uygulamanın bakılabilirliğini ve geliştirilebilirliğini artırmamız gerekir.
Sorumluluk Sahibi Olmak
Yazılım yapmayı zorlaştıran her zaman kod birimleri arasındaki bağimlılıklar ve bu bağımlılıkların yönetimi olmuştur. Bu bağımlılıkları tamamen yok etmek yazılım sistemini anlamsız kılarken, kontrolden çıkmalarına göz yummak yazılım sisteminin ölüm fermanı olabilir. Yazılım mühendisi bunu bilir ve gerekli gördüğü yerlerde DIP, ISP ve SRP gibi tasarım prensiplerini kullanarak kodu dokur.
Böyle Girişimcilik Olmaz!
Bu yazıyı okuyunca daha önce yazdığım Melek Programcılar ve Şeytan Yatırımcılar başlıklı yazımı anımsadım. Orada genç girişimcilerin nasıl şeytan yatırımcılar tarafından üç kağıda getirilip, sömürüldüklerinden bahsetmiştim. Durumun başka bir boyutunu da paylaştığım yazı gösteriyor.
Göz Boyamaca
Size herhangi bir şey satmak için kapınıza gelen bir satış temsilcisine ne gözle bakarsınız? Ben bu durumla karşılaşınca, beynimde otomatik olarak şahsı başımdan savma rutinleri devreye giriyor. Birilerinin benim üstüme bu şekilde gelerek bana bir şey satması imkansız. Bu inisiyatifin benden kaynaklanması lazım.
Acı Çekmeden Üstad Olunmaz
Her sektörün kendi guru, üstad, pir olarak görülen zatları var. Yazılım sektöründe de durum farklı değil. Şöyle başımızı kaldırıp devleşmiş bir üstada baktığımızda, bu adam nasıl bu kadar yetenek, kabiliyet, bilgi ve beceri sahibi olabildi diye bir soru aklımıza gelir. Aynı zamanda kendimizin bu devin yanında ne kadar küçük kaldığımızı görür, saklanacak bir yer aramamıza bile gerek kalmadan onun yanında kaybolup gideriz. Örnek mi ver diyorsunuz: Robert C. Martin, Kent Beck, Peter Norvig. Ne milletten oldukları önemli değil. Bu listede birgün mutlaka Türk yazılımcılarının da ismi yer alacak. Önemli olan nasıl üstadlaşabildikleri.
Detayları Görebilmek Ya Da Görememek
Robert Martin Transformation Priority Premise – Transformasyon Öncelik Teorisi başlıklı yazısında yeniden yapılandırmaya (refactoring) karşı yöntem olan kod transformasyonuna değiniyor. Refactoring uygulamanın dışa gösterdiği davranış biçimini değiştirmeden kodun yeniden yapılandırılması anlamına gelirken, kod transformasyonu uygulamanın davranış biçimini yeniden şekillendirmek için kullanılan bir yöntemdir.
Yazılımda Çeviklik İflas mı Etti?
Çevikliğin Böylesi başlıklı yazımı okudunuz mu? O yazımda çevik kelimesinin yerli yersiz her şey için kullanıldığını ve bu yüzden anlam erozyonuna ugradığından bahsetmiştim. Bu yazımda çevikliğin tanımını yapmaya çalışacağım.
Gezen Defterin Hikayesini Biliyor musunuz?
2009 yılında Enrique Comba‘nın aklına bir not defteri alıp, yazılım zanaatı akımında (Software Craftsmanship Movement) yer alan programcılara posta yoluyla gönderme fikri gelir. Her programcı deftere bu konudaki kendi düşünce ve tecrübelerini ekledikten sonra, defteri listede yer alan bir sonraki programcıya posta yoluyla gönderir. Bugün SocRaTes 2012 konferansında tanıştığım bir programcı 2010 senesinde bu defterin kendisine ulaştığını, defteri belli bir zaman sonra listede yer alan bir sonraki programcıya gönderdiğini, ama defterin 2011 senesinden beri kayıp olduğunu söyledi. Herhalde birisi defteri kitaplığına koyup, unuttu :)
Kataların Eşli Programlanması
Yaptığım kataları KodKata.com‘da sizinle paylaştım. Her gün düzenli olarak kod katalarımı yapıyorum. Her gün değişik bir kata yapmaya gayret ediyorum. Kataları tekrarladıkça katanın öngürdüğü birçok işlem benim için rutinleşiyor. Zaman zaman katanın öngördüğü yoldan saparak, başka şeyler deniyorum. Bu yeni bir tasarım kararı olabiliyor ya da yeni bir refactoring metotunun kullanımı. Okumaya devam et
Yazılımcı Anketi 2012
Bu anket 31.13.2012 tarihinde sona erdi. Bu anketteki verileri ihtiva eden rapora bu link üzerinden erisebilirsiniz.
Kişisel Gelişim
Bir programcının tipik bir haftasının kırk saati patronu için çalışmakla geçer. Daha önceki bir yazımda bir programcının mesai saatlerinde kendisini geliştirmesinin mümkün olmadığını, ama mesai haricinde pratik yaparak programcılık yeteneğini geliştirmesi gerektiğinden bahsetmiştim. Gel gelelim günde sekiz saat çalıştıktan sonra eve gelip, pratik yapmak ya da kitap okumak kolay bir şey olmayabilir. Yemek yedikten ve biraz televizyon seyrettikten sonra kişisel gelişim için gerekli motivasyon tabana vurabilir. Bu çok doğal bir şey. Bu sebepten dolayı kimse kendisine kızmamalıdır. Daha ziyade insan kendisine bu kısır döngüyü nasıl kırabilirim sorusunu sormalıdır.
Bilgisayar Mühendisi mi, Yazılım Mühendisi mi?
İsmini açıklamadan bir üniversite ögrencisinin bana göndermiş olduğu e-posta iletisini sizinle paylaşmak istiyorum.
Bana gelen e-postanın içeriği şöyle:
Özcan Bey Merhabalar
Ben XXX Üni. Teknoloji Fak. Yazılım Müh. okuyorum.Yatay geçişle YYY Üni.Müh Fak. Bilg. Müh. geçmek istiyorum ama kararsızım. Sizce hangisini seçmeliyim? Gelecekte hangisinde işsiz kalma ihtimalim daha az? YYY Üni. eğitimi daha iyi olur diye düşünüyorum ama bilg. müh. geleceğin meslekleri arasında yer alamıyor artık. Yazılım müh. adı geçiyor. Sizce ne yapmalıyım? Hangisini tercih ederek kariyerime devam etmeliyim? Şimdiden sağolun …
Not: Acil cevaplayabilirseniz sevinirim.
Kod A.Ş. – Kod Anonim Şirketi
Programcılar tarafından yazılan metotların ve kullanılan değişken isimlerinin çoğu anonim, yani adı sanı belirsiz. Kullanılan isimler ilk bakışta kod bünyesinde olup bitenleri ifade gücünden aciz. Bu kodun okunabilirliğini düşüren bir faktör. Zamanımızın büyük bir kısmını kod okuyarak geçirdiğimizi düşündüğümüzde, seçilen isimlerin ne kadar önemli olduğunu ortaya çıkmakta.
KodKata.com
Yeni projem KodKata.com yayında. Kod Kata ve Pratik Yapmanın Önemi başlıklı yazımdan sonra günlük pratik yapmak için kullandığım kataları sizinle paylaşmak istedim.