9 Mart 2019 - PHPkonf İzmir sunumu

1. Muhittin Özer
Co-founder at

2. Kötü Kod Yazmanın Sebepleri
• “Bu iş çok acil” / Deadline baskısı
• “Kervan yolda düzülür" / Hatalı proje yönetimi
• “Burayı sonra toparlarım” düşüncesi / Üşengeçlik - Disiplinsizlik
• Bilgi ve/veya tecrübe eksikliği.

3. Temiz Kod Nedir ?
• “Sıradan her programcı bilgisayarın anlayabileceği kodlar yazabilir, sadece iyi
programcılar insanların da anlayabileceği kodlar yazarlar" - Martin Fowler
• “Temiz kod için bildiğim birçok özelliği sıralayabilirim; ancak bir tanesi diğer
tüm özellikleri kapsıyor. Temiz kod her zaman ona değer veren biri tarafından
yazılmış gibi görünür.” - Michael Feathers
• “Yazılımın en önemli; değeri olabilecek değişikliklere uyum göstermesidir” -
Robert C. Martin

4. Temiz Kod Nedir ?

5. Temiz Kod Nasıl Olur ?
• Basit, açık ve net. Tabiri caizse şiir gibi değil düzyazı gibi olmalıdır.
“Şair burda bize ne anlatmak istiyor?” diye birbirimize sormamalıyız
o Başka bir geliştirici okuduğunda rahatlıkla anlayabilmelidir
o Kodu okuyan her geliştirici aynı şeyi anlamalıdır
• İsimlendirmeler mantıklı, tutarlı ve anlaşılır olmalıdır
• Aynı işi yapan birden fazla kod bloğu (fonksiyon, sınıf, kütüphane vb)
olmamalıdır
• Mümkün olduğunca küçük parçalara bölünmüş şekilde tasarlanmalıdır.

6. Temiz Kod Nasıl Olur ?
• Mümkün olduğunca küçük parçalara bölünmüş şekilde tasarlanmalıdır.
• Minimum düzeyde bağımlılığa sahip olmalıdır
• Maksimum düzeyde hata yakalama kontrolleri yapılmalıdır
• Değişken, Sabit, Fonksiyon, Sınıf, Paket, Kütüphane isimleri doğru
yapılmalıdır
• Eğer imkan varsa (ekip halinde çalışıyorsanız) kesinlikle Code Review
yapılmalıdır
• TDD, Design Patterns, Software Design gibi kavramlar hakkında bilgi
sahibi olunmalı, daha da önemlisi uygulanmalıdır.

7. SOLID Prensipleri
• Single Responsibility Principle (Tek Sorumluluk)
• Open/Closed Principle (Gelişime Açık/Değişime Kapalı)
• Liskov‘s Substitution Principle (Yerine Geçme)
• Interface Segregation Principle (Arayüz Ayrıştırma)
• Dependency Inversion Principle (Tersine Bağımlılık)

8. Bağımlılıklar
• Klasik bir muhabbet vardır: “Abi şu fonksiyonda bir bug vardı onu düzelttim ama başka bir
yeri patlatır mı bilmiyorum!” Eğer durum buysa bağımlılıkların iyi yönetilmediğini gösterir.
• Bir özellik, kavram yada işlemde (bir nesneye eklenecek bir field yada login prosesine
eklenecek bir kontrol vb.) değişiklik yapabilmek için çok fazla farklı dosyada değişiklik
yapmanız gerekiyorsa orada yanlış giden birşey var demektir.

9. DRY: Don’t Repeat Yourself
Aynı kod bloğunu değişen birkaç parametre için tekrar tekrar yazmak olası bir hatayı yada
geliştirmeyi hepsi için tekrar tekrar yapmak anlamına gelir.

10. DRY: Don’t Repeat Yourself
Aynı kod bloğunu değişen birkaç parametre için tekrar tekrar yazmak olası bir hatayı yada
geliştirmeyi hepsi için tekrar tekrar yapmak anlamına gelir.

11. DRY: Don’t Repeat Yourself
Aynı methodlara sahip benzer birkaç sınıfa ihtiyaç duyduğunuz durumlarda bu methodları Trait
haline getirip sınıflarınıza dahil edebilirsiniz.

12. DRY: Don’t Repeat Yourself
Aynı methodlara sahip benzer birkaç sınıfa ihtiyaç duyduğunuz durumlarda bu methodları Trait
haline getirip sınıflarınıza dahil edebilirsiniz.

13. DRY: Don’t Repeat Yourself
Kodu tekrar etmemek demek sadece kod bloklarını tekrar etmemek anlamına gelmez. Bazen
parametreleri de gereksiz yere sürekli tekrar ettiğimiz durumlar olabilir. Bu durumda birbiri ile
alakalı bu parametreleri bir nesne haline getirebilirsiniz.

14. DRY: Don’t Repeat Yourself
Kodu tekrar etmemek demek sadece kod bloklarını tekrar etmemek anlamına gelmez. Bazen
parametreleri de gereksiz yere sürekli tekrar ettiğimiz durumlar olabilir. Bu durumda birbiri ile
alakalı bu parametreleri bir nesne haline getirebilirsiniz.

15. Kodu Anlamlı Parçalara Bölün
• Bir method/fonksiyon 20 satırdan fazla olmamalıdır
• Bir method/fonksiyon minimum sayıda parametre almalıdır
• Bir method/fonksiyon tek bir işi en doğru şekilde yapmalıdır, yan etkileri
olmamalıdır
• Bir sınıf asla çok fazla methoda sahip olmamalıdır. Her sınıf yalnızca tek bir
amaca hizmet eden methodları barındırmalıdır

18. İsimlendirme
• Aldığı değerin ne olduğunu söylemelidir.

19. İsimlendirme
• Yaptığı işin ne olduğu anlaşılmalıdır.

21. İsimlendirme
• Benzer anlamlara sahip farklı elemanlar birbiri ile karıştırılabilir

22. İsimlendirme
• Eğer bir değer kod içerisinde birden fazla yerde kullanılacaksa mutlaka hangi
değeri ifade ediyorsa o isimle sabit yada değişken olarak tek bir yerde
tanımlanmalıdır

23. İsimlendirme
• Sınıf isimleri her zaman isim yada isim tamlaması şeklinde olmalıdır

24. İsimlendirme
• Method ve fonksiyon isimleri fiil yada doğrulama (kontrol) ifadesi şeklinde olmalıdır

25. İsimlendirme
• Aynı amaç için aynı isim tamlamasını kullanılmalıdır, benzer anlamda farklı
tamlamalar kullanmak gereksiz karışıklıklara neden olur

26. İsimlendirme
• Gereksiz ön eklerden kaçınılmalıdır

27. İsimlendirme
• Sürekli aynı isimlendirme standardı kullanılmalıdır

28. İsimlendirme
• Dil tutarlılığı korunmalıdır

29. İsimlendirme
• Keşke PHP’nin kendisinde bu tutarsızlıklar olmasaydı

31. Kodu Formatlama
Bu konuda bu görseli kullanmayanı dövüyorlarmış!

32. PSR Standartları Güncel Bilgiler için: https://www.php-fig.org/psr/

33. PSR-0: Otomatik Yükleme
• Her sınıfın bir namespace’i olmalıdır.
• Her namespace’in bir üst namespace’i olmalıdır.
Yani; Proje_adinamespaceclass
• Her namespace’in alt namespace’leri olabilir.
• Her namespace “_” işareti, / (DIRECTORY_SEPARATOR) olarak
algılanmalıdır.
• Proje adında, sınıf isimlerinde büyük küçük harf kombinasyonları olabilir.

34. PSR-1: Temel Kod Yazma Standartları
• PHP dosyaları <?php veya <?= başlamalı.
• Dosyalar UTF-8 ve BOM’suz olmalıdır.
• Sınıf isimleri StudlyCaps olmalıdır.
• Sınıf sabitleri tamamı büyük harften oluşmalıdır.
• Metot isimleri CamelCase olmalıdır.
• Değişken isimlerinde StudlyCaps, camelCase veya hepsi küçük şekilde alt çizgi dahil
kullanım olabilir. getOption, get_option
• Dosyalar ya sınıfları, fonksiyonları, sabitleri tanımlamalı yada yalnızca yan etki
üretmelidir (config çıktısı üreten .ini dosyaları). Ancak asla ikisini bir arada
yapmamalıdır.
• Otomatik yükleme standardı olan PSR-0 yada PSR-4 kullanılmalıdır.

35. PSR-2: Kodlama Stili Standartları
• Her satırda önerilen 80 karakter, max 120 karakter olmalıdır.
• Satırlarda tab yerine 4 boşluk kullanılmalıdır. (whitespace).
• Namespace, class ismi, method isminden sonra 1 boşluk bırakılmalı.
• namespace tanımlamasından sonra bir boş satır bırakılmalıdır. use tanımlamalarından
sonra da bir satır boşluk olmalıdır.
• Method, sınıf oluşturulduğunda açılan süslü parantezler “{” ismin bitişinde değil bir alt
satırda açılmalı.
• Tüm metodlarda görünürlük ( public, protected, private ) tanımlaması bulunmak
zorundadır abstract ve final tanımlamaları görünürlük tanımlamasından önce, static ise
görünürlük tanımlamasından sonra olmalıdır.
• Operatörler ile değişkenler arasında bir karakter boşluk bırakılmalı.
• true, false, null küçük kullanılmalı.

36. PSR-3: Logger Arayüzü Satndartları
• 8 level log tipi olmasını öneriyor; debug, info, notice, warning, error,
critical, alert, emergency
• Her method string veya obje kabul edebilir.
• Mesaj içerisindeki placeholder’lar, verilen array içerisindekiler ile
değiştirilir.
• Mesaj içerisindeki placeholder’lar {} arasında yazılır.
• Placeholder’lar A-Z, a-z, 0–9, _ karakterlerinden oluşabilir.

37. PSR-4: Gelişmiş Otomatik Yükleme
• Tam nitelikli sınıf adı “Sağlayıcı Namespace’si” olarak da bilinen bir üst
düzey namespace’e sahip olmalı.
• Tam nitelikli sınıf adının bir veya daha fazla namespace’i olabilir.
• Alt çizginin sınıf adında herhangi bir bölümünü için özel bir anlamı yok
• Sınıf adları büyük veya küçük harflerin herhangi bir kombinasyonundan
oluşabilir.

38. Yorum Yazma!
• Eğer bir kodun ne iş yaptığını açıklamak için yorum yazmanız gerekiyorsa o
kod muhtemelen kötü yazılmıştır. Yorum yazmaya gerek kalmayacak
şekilde yeniden yazmayı deneyin!
• Genellikle kodu güncellediğiniz zaman yorumları güncellemeyi
unutursunuz. Bir kod parçası ne kadar eski ise koddaki yorum o kadar
hatalı olur.
• Kodun gerçekten ne yaptığını sadece ve sadece kodu okuyarak
anlayabilirsiniz. Yorum ise adı üzerinde yorumdur. Sizi yanlış
yönlendirebilir.

39. Yorum Yazma!

40. Bazı durumlarda ise yorum yazmak gerekir.
• PHP DocBlock ( http://docs.phpdoc.org/guides/index.html )

41. Bazı durumlarda ise yorum yazmak gerekir.
• Önemli ve geçici olarak devre dışı bırakılan yada bir işlemin nasıl yapılması gerektiğine
örnek teşkil eden kodlar

42. Bazı durumlarda ise yorum yazmak gerekir.
• Regex desenleri gibi koda bakınca okuması zor olan kısımları açıklamak için

43. Temiz Kod Yazmak İçin Öneriler
• Bol bol açık kaynak olarak geliştirilmiş kütüphaneleri ve framework’lerin
kaynak kodlarını okuyun.
• Açık kaynak projeler geliştirin yada mevcut açık kaynak projelere katkıda
bulunun.
• Code Review yapın/yaptırın.
• Standartları, ve toplulukları takip ederek kendinizi güncel tutun.
• CodeReview yapan ve kod kalitesini kontrol eden araçlar kullanın.
(Scrutinizer vb.)

44. ÖZET
Basit ve okunabilir kodlar yazın.
Unutmayın;
muhtemelen bu kodu ileride okuyacak kişi muhtemelen yine siz olacaksınız!

45. ÖZET
Tekrar eden kodlardan uzak durun.
Unutmayın;
daha sonra bir değişiklik yapmanız gerektiğinde onu tek bir yerde yapmak size zaman kazandıracak!

46. ÖZET
Kodu anlamlı ve tek bir iş yapan parçalara bölün.
Unutmayın;
düzenli kod yazmaya harcayacağınız efor,
daha sonra çıkabilecek hataları düzeltmek için harcayacağınız efordan çok çok daha az.

47. ÖZET
İsimlendirme konusunda titizolun.
Unutmayın;
muhtemelen bu kodu ileride okuyacak kişi muhtemelen yine siz olacaksınız!

48. ÖZET
Daha sonra düzeltmek üzere günü kurtaracak kod yazmayın.
Unutmayın;
sonra, “asla” demektir.

49. ÖZET
Standartlara ve prensiplere uygun kod yazın.
Unutmayın;
siz de mutlaka bir gün başka bir yazılımcının sonraki yazılımcısı olacaksınız!

50. TEŞEKKÜRLER!
Muhittin ÖZER
www.90pixel.com
twitter.com/muhittin
muhittin@90pixel.com