Yazılımcıların Altın Kuralları #1
Okuduğum yazılardan makalelerden ve gözlemlediğim ,yazılımın belki değil ama yazılımcının kalbi olarak nitelendireceğim yeni serimden herkese selamlar !
Amacım aslen kendim için bir kaynak oluşturmak ve geriye dönüp baktığımda unuttuğum ama altın değerinde bu kuralları ve yaklaşımları kendine hatırlatmak diyebilirim. Bu seride kaç post olur yada olabilir bilmiyorum ancak aklıma geldikçe geri dönüp düzelteceğim bir blog olacağına eminim :)
Kullanıcı Gibi Düşünmek ?
Hepimiz diğer insanların bizim gibi düşündüğünü varsayımına eğilimindeyiz. Bu konu sadece yazılımla ilgili değil bir psikolojik durum. Düşündüğümüz bir fikre aykırı bir düşünce duyduğumuzda yada bize dayatıldığında aslen bu sebeple biraz sinirleniyoruz desek yalan söylemiş olmayız.
Kod yazarken bu durum biraz daha garip bir hal alması da gayet doğal gözükebilir. Ancak bu göremediğimiz tuhaf ve kötü programlar oluşturmamıza neden oluyor yada olabilir.
UI şakaya benzer , eğer açıklamak zorunda kalıyorsan hata yapmışsındır.
Hepimiz harika projemiz için harika fikirlerimizi üretirken kafamızda oluşturduğumuz bir şablon bir kalıp vardır. Hatta gözümüzün önündedir neredeyse elimizi kaldırsak ulaşabilecek gibi hissederiz. Butonları yerleştirir arka planını yazar ve deneriz.
Ancak şimdi gelelim gözden kaçırdığımız o kısma ,peki o buton neden orada ? Başka bi yerde olsa daha iyi olur muydu ? Yada bu uygulamayı siz yapmasaydınız o butonu görebilmek için o ekranı sağa çekmeniz gerektiğini nereden bilecektiniz?
Burada temel yol şu olabilir. Bizler taskları , hataları ve geliştirmeleri cümleye dökerken şu kalıptan uzak durmalıyız.
Sağ tarafa bir kolon daha ekle
bunun yerine
Kullanıcı kar ve zarar yüzdesini görebilmeli
şeklinde olursa bu sefer bunun görmenin en iyi yolunu düşünebiliriz.
Belki ikinci bir yol sizden yaşça büyük ve küçük kişilere yaptığınız test uygulamalarınızı kullandırmak ve geri dönüşleri toplamak olabilir.
Bakalım anneniz yada babanız o gizlediğiniz ve görülmesi için sağa kaydırılması gereken ayar butonunu kendi başlarına bulabilecekler mi ?
Code Standarlarımız standart mı?
Çoğu zaman yeni bir projeye başladığımızda ki o iştahımızı o güzel anı hatırlayın. Bu projede baştan savma kod olmayacak her şey dokümante edilecek ve bu kusursuz bir proje olacak. Eminim çoğunuz kafanızı sallamaya başladınız bile.
Ancak işin özünde pekte öyle olmadığını görmemiz pek zaman almaz. Peki bunun sebeplerinden biri nedir ?
Gelin cevabı bulalım.
Her birimizin takip ettiği yada alıştığı bazı kod yazma standarlatı vardır. Ancak projede bunu devam ettirmek bir yerden sonra tahmin ettiğimizden çok zaman alır. Yazarken bilirsiniz bu kod parçası güzel olmadı ama devam etmelisinizdir. Daha sonra muhakkak geri döner bakarım dersiniz…
Şimdi tanıdık gelmeye başladı değil mi ?
Kod standartlarımızı korumak ciddi bir problem olabilir. Ancak bunu elimizle ve gözümüzle yapmak herkesde doğal olarak bir bıkkınlık bırakacaktır.
Bunu bir şekilde otomatize etmek en faydalı yol olacaktır. Eslint sana tanıdık gelmediyse okumaya devam!
ESLint sorunları hızlı bir şekilde bulmak için kodunuzu statik olarak analiz etmek için kullanılan bir çeşitli bir araçtır. daha fazla bilgi için
Kod kalitesi raporları üretmek ve kodlama standardını belgelemek ve sürdürmek için kullanılabilecek çok sayıda araç bulabiliriz. Ve bunları kullanmak ve otomatik hale getirmek bizi birçok şeyden kurtaracak!
• Kod biçimlendirmesinin oluşturma işleminin bir parçası olduğundan emin olun, böylece herkes kodu derlediğinde bunu otomatik olarak çalıştırır.
• İstenmeyen anti-paternlere karşı kodu taramak için statik kod analiz araçlarını kullanın. Eğer varsa, commitlemeyin.
• Sadece test kapsamını ölçmekle kalmaz, sonuçları otomatik olarak da kontrol eder. Test covarage sayımız düşükse commit atmanıza engel olun.
Temel olarak amaç yapabiliyorsak bu işi elimize ve gözümüze bırakmamak!
