1. Her Bug İçin Bir Test Yazılması
Bir hatayı gidermiş olmak, o hatanın tekrar etmeyeceği anlamına gelmez. Tekrarı durumunda kullanıcıların değil, programcı olarak bizim kısa bir sürede tekrar eden hatayı keşfetmemiz gerekir. Bunun da en kolay yolu, keşfettiğimiz her hata için bir birim testi yazmaktır. Birim testleri hatanın tekrarı durumunda bize en kısa sürede geri bildirim sağlarlar.
Ne yapılmalı?
Keşfedilen her hata için bir test yazılmalıdır.
2. Commit Öncesi Testleri Çalıştırılması
Eğer sürekli entegrasyon yapmıyorsanız ve kod kırılmaları kimsenin umurunda değilse, bu bölümü geçebilirsiniz 😉 Lakin projenizde çok temel şeylerin yanlış gittiğini bilmelisiniz.
Sürekli entegrasyon mekanizmalarının kullanıldığı ortamlarda çalışmayan kodun commit edilesi tüm şimşekleri üzerinize çekebilir. Kodun çalıştığını kendimize ispat etmek için commit öncesinde mevcut testlerin yerel bilgisayarda çalıştırılması, mevcut hataların keşfedilmesi adına faydalı bir işlem olacaktır.
Ne yapılmalı?
Kodların versiyon kontrol sistemine eklenme işleminden önce, kırılmalar olup, olmadığını anlamak için tüm testler koşturulmalıdır.
3. Değişikliklerin Bir Seferde Versiyon Kontrol Sistemine Eklenmesi
Yerel testlerin çalışıyor olması, değişiklikler bir seferde commit edilmediği sürece bir şey ifade etmez, çünkü eksiklerden ötürü sürekli entegrasyon sunucusu uygulamayı yapılandıramayacağı için hata verecektir. Bu durumda şimşekleri yine üzerinize çekersiniz.
Ne yapılmalı?
Değişikliğe uğrayan tüm kaynak kod ve dosyaların bir seferde versiyon kontrol sistemine eklenmelidir.
4. Sürekli Entegrasyon Sunucusunun Kontrol Edilmesi
Yerel testlerin çalışıyor ve tüm değişikliklerin bir seferde versiyon kontrol sistemine eklenmiş olmaları, yaptığımız değişikliklerin uygulamanın diğer parçaları ile başarılı bir şekilde entegre edileceği garantisini vermez. Commit etmeyi unuttuğumuz mutlaka bir şeyler vardır ve bu bir sonraki entegrasyonun başarısız olmasına sebep vererek, tüm şimşekleri yine üzerimize çekmemizi sağlayacaktır. Şimşekleri seviyorsanız, bir sorun yok!
Ne yapılmalı?
Her commit işleminden sonra sürekli entegrasyon sunucusu kontrol edilerek, uygulamanın başarılı bir şekilde entegre edilip, edilmediği kontrol edilmelidir.
5. Sonar Verilerinin İncelenmesi
Yazdığımız kodun hangi durumda olduğunu anlamak için statik kod analizi yapan araçlardan faydalanabiliriz. Bu araçların başında checkstyle, findbugs, jdepend ve pmd gelir. Bu araçlardan edindiğimiz verileri Sonar sunucusu aracılığı ile inceleyebiliriz. Jenkins sürekli entegrasyon sunucusunun Sonar plugini bulunmaktadır. Bu plugin aracılığı ile her entegrasyon sonunda kodun statik analizi otomatik olarak yapılır. Verilerin incelenmesi de bize kalır.
Ne yapılmalı?
Her commit işleminden sonra Sonar aracılığı ile kodun yapısal durumu incelenmeli ve iyileştirmeye gidilmelidir.
6. Commit & Run Yapılmaması
Önümüzdeki cuma günü mesai bitimiyle iki haftalık tatile çıkacağınızı farzedelim. Yapmamanız gereken bir şey varsa, o da cuma günü mesai bitimine beş dakika kala üzerinde çalıştığınız dosyaları versiyon kontrol sistemine eklemektir. Murphy’nin kanunlarına göre ters gidebilecek her şey ters gider ve yaptığınız eklemelerle derleyemeyen bir uygulamayı arkanızda bırakırsınız. Artık arkanızdan neler konuşulduğunu siz düşünün. En kötü ihtimalle tatilde sizi patronunuz arayarak, bunun hesabını soracaktır.
Ne yapılmalı?
Tatile çıkılacaksa, yapılan işlerin devredilebileceği bir takım arkadaşı aranmalı ve yarım kalan işler birkaç gün öncesinden devredilmelidir.
7. Ne Yapılacağının Bilinmemesi
Yeni bir görev üstlendiğimizde, ilk etapta kafamızda neler yapacağımızı canlandırmaya çalışırız. Kafamızda bir zaman sonra bir takım sınıf isimleri uçuşmaya başlar. Bir yerlerden başlayıp, bu sınıfları implemente etmeye çalışırız. Müşteri isteklerini tatmin edecek uygulama parçasını geliştirmenin en verimsiz yöntemlerinden bir tanesi budur. Sistematik bir şekilde ilerlemediğimiz ve kafamızdaki bir takım hayallere bel bağladığımız için ne olduğu belli olmayan bir şeyler ortaya çıkar.
Bunun yerine bir birim testi yazarak uygulamayı geliştirmeye başlamalıyız. Bu test güdümlü yazılımda kullanılan bir yöntemdir. Testler uygulamadan olan beklentileri ifade etmek için kullanılabilecek en uygun araçlardır. Testler programcıya ne yapması gerektiği hakkında fikir verirler. Çoğu zaman testler uygulamayı kullanıcı gözünden görürler. Bu programcının yapılması gerekenleri daha çabuk kavramasını sağlar.
Ne yapılmalı?
Yeni bir göreve test yazarak başlanmalıdır. Test güdümlü yazılım yapılmasa da, testler bünyesinde ifade edilen beklentiler, programcının hangi program arayüzlerine (API – Application Programming Interface) ihtiyaç duyulduğunu anlamasını kolaylaştırır.
8. Uygulamanın Neden Çalışmadığının Anlamaya Çalışılması
Java gibi dillerde program modüllerini paralel koşturmak için threadler kullanılır. Reaksiyon göstermeyen uygulamalarda genelde thread bazında bir sorun vardır. Threadsel sorunları anlamak için thread dump yapılmalıdır. Bir Java uygulamasından “kill -QUIT pid” komutu ile thread dump alınabilir.
Ne yapılmalı?
Uygulamalar çok değişik sebeplerden ötürü çalışmaz hale gelebilir. Uygulama neden çalışmıyor acaba sorusunu sormak yerine, bir thread dump alarak, uygulamanın neden çalışmadığı analiz edilmelidir.
9. İzci Kuralına Uyulması
Kötü olduğunu düşündüğümüz bir kod parçası hakkında şikayet etmek yerine, o kodu daha iyi hale getirmeye çalışmalıyız. Bir izci kuralına göre izciler kamp yaptıkları yeri, buldukları halinden daha iyi bir şekilde geride bırakırlar.
Ne yapılmalı?
İzci kuralı uygulanmalı ve denk gelinen ve kötü olduğu düşünülen kod parçaları iyileştirilmelidirler.
10. Eve İş Taşınmaması
Programcı olarak yazdığımız tüm testlerin çalışır durumda olduğuna gayret göstermeliyiz. Çalışan ve yeşil olan testler bize her zaman manevi rahatlık verir. Özellikle mesai bitmeden önce çalıştırılan ve yeşil oldukları görülen testler, öz güveni ve huzuru artırır.
Ne yapılmalı?
Mesai bitmeden önce tüm testler çalıştırılmalı ve yeşil oldukları görülmelidir. Yeşil olan tüm testler programcının yaptığı işleri arkasında bırakarak, huzur içinde evine gitmesini sağlar. Eve iş taşımamanın en güzel yolu, her zaman yeşil olması sağlanan testlerdir.
11. NullObject Tasarım Şablonunun Kullanılması
Programcı olarak başımızı ağrıtan hataların başında NullPointerException gibi hatalar gelir. Yazdığımız kodların büyük bir bölümü null check yapar, çünkü başka bir programcı tarafından yazılan metotların hangi değerleri geri verdiklerinden emin değilizdir. Object veri tipinde bir nesneyi geri veren bir metodun null değerini geri verme ihtimali çok yüksektir.
Ne yapılmalı?
Oluşturulan metotlarda null değeri yerine boş bir nesne geri verilmelidir. Örneğin bir metot List
12. Tek Sorumluluk Prensibine Sadık Kalınması
Nesneye yönelik programlamada sınıf ve metotların çok uzun olmalarının başlıca sebebi, kodun tek sorumluluk prensibine sadık kalınarak, geliştirilmemiş olmasıdır.
Ne yapılmalı?
Oluşturulan her sınıf ve metot tek bir sorumluluğu yansıtacak yapıda olmalıdır. Tek bir sorumluluğu olan bir sınıf ya da metot tek bir sebepten dolayı değişikliğe uğrayabilir. Birçok sorumluluğu olan bir sınıf ya da metot birçok sebepten dolayı değişikliğe uğrayacaktır. Birçok uygulamanın en ufak bir değişiklikte çalışmaz hale gelmelerinin başlıca sebebi, uygulamaların temelini oluşturan yapıların bünyelerinde birçok sorumluluğu barındırıyor olmalarında yatmaktadır. Genel olarak programcı kod yazarken SOLID prensiplerine sadık kalmaya çalışmalıdır.
13. En Basit Çözümü Oluşturmaya Gayret Edilmesi
Zaman içinde uygulamalar zaten karmaşık bir yapıya bürünürler. Bu karmaşanın önüne geçmenin en kolay yolu KISS prensibini uygulamaktır.
Ne yapılmalı?
Mümkün olan en basit çözüm tercih edilmelidir. En karmaşık çözümü ortaya koyan değil, aynı sorunu en basit şekilde çözen 1-0 öndedir.
14. Kod İnceleme Seanslarının Yapılması
Yazdığımız kodun hangi durumda olduğunu anlamak için başka bir çift gözün kodu incelemesini sağlamalıyız. Biz programcı olarak yazdığımız kodun iyi olduğunu düşünürüz. Bu subjektif bir algıdır. Bakalım takım içindeki arkadaşlarımız da aynı fikirde mi?
Ne yapılmalı?
Bir görevi tamamladıktan sonra takım içinden bir programcı seçilerek, birlikte kod inceleme seansı yapılmalıdır. Kod inceleme seansından alınan geri bildirim ile daha iyi bir programcı olma yolunda ilerlenir.
15. Test Yazarken Ekran Çıktılarının Göz Ardı Edilmesi
Test yazarken ekran çıktılarına güvenmek ve test metotlarını cılız bırakmak, testlerin zayıf ve uygulamanın kırılgan olmasını sebep verir.
Ne yapılmalı?
Test metotları test edilen senaryoyu en kapsamlı şekilde test etme eğilimi göstermelidir. Test edilmedikleri sürece ekran çıktıkları uygulamanın doğru çalışıyor olduğunun garantisi olamaz.
16. Temiz Kod Yazılması
Kodun bakımı ve genişletilebilirliği, okunabilirliği ile doğrudan orantılıdır. Programcı olarak yazdığımız metotların kısa olmasına dikkat etmemiz gerekir. Uzun olan metotları otomatik refactoring araçları ile küçültebilir ve okunabilir hale getirebiliriz. İdeal bir metot dört ya da en fazla beş satırdan oluşmalıdır.
Ne yapılmalı?
Kullanılan IDE’nin sunduğu otomatik refactoring yöntemleri ile metotlar daha okunabilir hale getirilmelidir.
17. Soyut Sınıfların Kullanılması
Tasarım aracı olarak soyut sınıflar kullanılmalıdır. Somut sınıflara nazaran soyut sınıflar daha az değişikliğe uğrama eğilimi gösterirler.
Ne yapılmalı?
Daha iyi bir tasarım için DIP uygulanmalıdır.
18. Pratik Yapılması
Biz programcıların hiç ya da çok az pratik yaptığı bir gerçek. Oysaki pratik yapmak daha iyi programcı olabilmek için bir gerekliliktir.
Ne yapılmalı?
Kod kata yaparak, programcılık becerileri geliştirilmelidir
EOF (End Of Fun)
Özcan Acar
Yorumlar
“Programcının Hayatını Kolaylaştıran 18 Alışkanlık” için 2 yanıt
Hocam elinize sağlık çok faydalı bir yazı olmuş. Yazılimcı gücünü alışkanlıklarından alır.
Tesekkur ederim. Elinize saglik.