- Bu yazı bir tavsiye listesi değil; yazarın şu anda uyguladığı geliştirme alışkanlıklarını anlatıyor
- Kötü alışkanlıklardan kaçınıp iyi alışkanlıklar oluşturmak için gösterilen çabanın deneyimlerini derleyen bu yazı, üretkenliği artırmaya ve kaliteyi korumaya yardımcı olan 10 alışkanlığı ele alıyor
1. Commit'leri küçük tutmak
- Commit'ler mümkün olduğunca küçük tutulmalı. Küçük commit'ler, bir hata oluştuğunda yalnızca ilgili commit'i geri almayı mümkün kılar ve karmaşık merge çatışmalarını önleyebilir
- "Yazılım derleniyorsa commit edilebilir olmalı" kuralı benimseniyor
2. Sürekli refactoring
- Kent Beck'in tavsiyesi: "Bir değişiklik istiyorsanız, önce değişikliği kolaylaştırın; sonra o kolay değişikliği yapın."
- Commit'lerin en az yarısında refactoring yer alması hedefleniyor. Küçük refactoring'ler, büyük gereksinimler geldiğinde çok yardımcı oluyor
- Büyük çaplı refactoring'den kaçınılmalı. Bunun yerine 10 dakikayı aşmayan küçük iyileştirmeler sürekli yapılmalı
3. Kod dağıtımının önemi
- Kodun kendisi potansiyel bir borçtur ve dağıtılmamış kod en büyük borçtur
- Testler güven verir, ancak gerçek dağıtım gerçek onay anlamına gelir
- Dağıtım sıklığı arttıkça hosting maliyetleri yükselebilir, ancak en güncel çalışmanın gerçekten çalıştığını doğrulamak önemli bir avantajdır
4. Framework'ün işlevlerini test etmemek
- Framework'ün kendi işlevleri test edilmez; framework zaten yeterince doğrulanmıştır
- Bileşenler küçük tutulursa framework işin çoğunu üstlenir ve test ihtiyacı azalır
- Büyük bileşenler karmaşıklık ekler ve buna bağlı olarak çok sayıda test gerektirir
5. Yeni modül oluşturmak
- Belirli bir işlev mevcut modüle uymuyorsa yeni bir modül oluşturmak daha iyidir
- İşlevi mevcut modüle zorla eklemek yerine onu bağımsız bir modül olarak bırakmak daha iyidir
6. Test güdümlü geliştirmenin (TDD) esnek uygulanması
- API tasarımı net değilse, önce test yazılarak "müşteri" bakış açısından düşünülür
- TDD dini bir ilke gibi uygulanmaz. Gerekirse daha büyük birimlerde çalışıp sonra test yazılabilir
- Küçük kod parçalarının mutlaka başarısız durumda bırakılması gerekmez; üretkenliği düşüren katı dogmalara bağlı kalınmaz
7. Kopyala-yapıştır yalnızca bir kez serbest
- Bir kez kopyalamak sorun değildir, ancak ikinci kopyadan itibaren tekrar oluşur
- Bu noktada uygun bir soyutlama ile tekrar giderilmelidir. Parametreleştirme biraz tuhaf görünse bile, birden fazla implementasyonu birleştirmekten daha iyidir
8. Tasarımdaki değişimi kabul etmek
- Tasarım zamanla eskir. Refactoring bu yaşlanmayı yavaşlatabilir ama sonunda değişmesi kaçınılmazdır
- Önceki tasarıma aşırı bağlanmamak, değişimi kabul etmek gerekir
- Mükemmel tasarım yoktur; değişime iyi uyum sağlama becerisi yazılım geliştirmenin özüdür
9. Teknik borcun üç türü
- Teknik borç üç türe ayrılabilir:
- Mevcut işi engelleyenler
- Gelecekteki işleri engelleme ihtimali olanlar
- Belki engel çıkarabilecek olanlar
- Birinci tür borç en aza indirilmeli, ikinci türe odaklanılmalı, üçüncü tür ise göz ardı edilmelidir
10. Test edilebilirlik ile iyi tasarım arasındaki ilişki
- Test etmek zorsa, tasarımda bir sorun olma ihtimali yüksektir
- Test tasarımı da iyileştirme konusu olabilir. Örneğin
em.getRepository(User).findOneOrFail({id}) için mock yazmak zorsa, bunu ayrı bir fonksiyona ayırmak veya test utility'leri kullanmak iyi olur
- Testlerin yazılmamasının nedeni test etmenin zor olmasıdır; bu da tasarım sorunu olabilir
9 yorum
Görünüşe göre DRY’den çok SRP’nin sağlanması gerekiyor; o zaman yapay zekaya bıraksanız bile saçma sapan şeyler üretmiyor.
Bence en önemli şey, değişime ne kadar hızlı uyum sağlayabilen bir kod ve ortam oluşturduğunuz.
Ayrıca uygun soyutlama sayesinde kodun yeniden kullanılabilirliğini ve genişletilebilirliğini artırabilir, AI araçlarını kullanarak geliştirme hızını en üst düzeye çıkarabilirsiniz.
Gerçekten çok iyi bir yazı. Onu her yerde tavsiye etmek istiyorum
Değişimi benimseyin, kopyala-yapıştırı yalnızca bir kez yapın, testleri daha iyi hale getirin, commit’leri daha küçük tutun...!
Güzel bir yazı.
Bence bu yazının mutlaka orijinaline de bakmalısınız.
İlgimi çeken haberlerde genelde orijinal kaynağa bakarım ama bunda özellikle öyle yapmanız iyi olur. 1. maddeye bakarsanız, asıl metinde
Keep commits small enough that you wonder if you're taking this "keep commits small" thing a little too far. yazıyor; burada ise "commit'leri mümkün olduğunca küçük tutmak gerekir" diye kısaltılmış..
Gerçekten çok iyi bir yazı.
Hacker News görüşü
Birden fazla implementasyondan kaçınmak için parametre kullanmak iyi olur. Parametreleri iyileştirmek, birden fazla implementasyonu birleştirmekten daha kolaydır.
Kodu bir kez kopyalamak sorun değildir, ancak ikinci seferden itibaren tekrardan kaçınılmalıdır. Yeterli veri noktası oluştuğunda iyi bir soyutlama yapılmalıdır.
DRY (kendini tekrar etme) ya da WET (her şeyi iki kez yaz) mutlak kurallar değildir. Zor olan, kod tekrarını ve ne zaman birleştirme yapılacağını anlamaktır.
Küçük commit'lere alternatif olarak, büyük bir commit'i geri almak yerine hatayı düzelten yeni bir commit eklenebilir.
Test edilebilirlik iyi tasarımla ilişkilidir. Kolay test edilemeyen bir şey, tasarım değişikliği gerektiğinin işareti olabilir.
Framework özelliklerini test ederken dikkatli olunmalıdır. Framework zaman içinde değişebilir.
Commit boyutu konusunda, belirli bir değişikliğin geri alınması gerektiğinde kolayca geri alınabilecek commit'ler hedeflenmelidir.
Şirketler kararlı bir kod tabanı ister, ancak sürekli refactoring gerekir. Bu da kararlılıkla çelişebilir.