Tag Archives: Pragmatic Programmer

Pragmatic Programmer kitabında verilen ipuçlar 2

There Are No Final Decisions

Business requirements (iş isterleri) geldiği zaman dökümanın son hali diye düşünülür. Daha sonra ise döküman v1 den v10 a kadar uzayabilir. Yazılım geliştirmede değişikliğin geleceğini işe başlamadan önce kafamıza oturtmalıyız. Örneğin MSSQL kullanılıyorsa MYSQL’e geçiş yapmak istenebilir. Yazdığımız kodun gelişime açık değişime kapalı olması gereklidir.

Database sınıfının soyutlaştırılması örneği:

https://softwareengineering.stackexchange.com/questions/301362/how-are-abstract-database-interfaces-written-to-support-multiple-database-types/301371

Use the Power of Command Shells

GUI kullanmak yerine Shell komutlarını kullanmak performansı arttırır.  Bence bazı şeyler GUI ile daha rahat oluyor. Örneğin database için GUI olmasını tercih ediyorken GIT için komut satırını kullanmayı tercih ediyorum. Komut satırı kullanımı birazda işletim sistemiyle alakalı. Gözlemlediğim Linux ve macOS kullanıcıları komut satırı kullanımına daha yatkın.

Use a Single Editor Well

Güçlü bir editor seçin ve seçtiğiniz editor üzerinde iyi olmaya yoğunlaşın. Bütün kısayolları bilin. Günümüzde birçok editor var. En popülerleri VIM, Notepad++, Sublime Text, ATOM, VSCode, Bracket …

Always Use Source Code Control

Takımdaki tek kişi olsan dahi, 1 haftalık bir prototype olsa dahi mutlaka Source Control aracı kullanın diye öğüt verilmiş. “throw-away” olsa dahi source control ile kodunuzu yönetin.

Fix the Problem, Not the Blame

Yazılım içerisinde çıkan bug’ın kimin hatası olduğunun önemi yok. Önemli olan bug’ın çözülmesi. Kişilere yönelmek insanların enerjisini düşürür ve asıl odaklanılması gereken problem unutulur.

Don’t Panic When Debugging

Debugging sırasında panik olunmamalı. Sinirli bir takım yöneticisi, hızlı çözüm isteyen bir müşteri panik olmanıza neden olabilir. Önemli olan sakin davranıp bug üzerine kafa yormaktır. Anlatılan konu bug’da olmayabilir. Semptomlar dinlenir ve ona göre karar verilir.

Bug çözümü yapmanın en iyi yolu bug’ı reproducible edebilmektir.

Don’t Assume It—Prove It – Don’t Program by Coincidence

Varsayımlar yapılmalıdır fakat yapılan varsayımların kanıtlanması önemlidir. Yıllardır çalışan kod üzerinde bir anda bug gelmiş olabilir. Bu tür bir bug ile karşı karşıya gelindiğinde o zaman düşünülen varsayımın yanlış olduğu anlaşılabilir veya o durum düşünülmemiş olabilir. Data kaynaklı bir bug varsa parameter check yapılabilir. Kodlama yapılırken ne yaptığının farkında olunmalı.

Minimize Coupling Between Modules

“By writing “shy” code as much as possible we can achieve our objective. “ Yazılım projelerinde oluşturulan modüller, objeler birbirlerini sıkı sıkıya bağlı olmamalıdır. (tight coupling, loose coupling) Örneğin bir iş sınıfındaki alanlar private olmalıdır. İş mantığı get-set üzerinden değilde sınıf içerisinde public edilen bir metod üzerinde yapılabilir.

Örnek birbirine bağlı Java class:

public class Service {
  private CustomerService customerService;
  private OrderService orderService;
  public Service() {
     customerService = new CustomerService();
     orderService = new OrderService();
  }
  private void doSomething() {
     orderService.processOrder();
  }
}

Service Class’ı CustomerService ve OrderService ‘e bağımlı durumda. Buradaki bağımlılık kodun test edilmesini engelleyecek ve bakımının okunabilirliği tasarım açısından azaltacak. Dependency Inversion prensibine uygun değil. Yüksek Seviyeli modülleri düşük seviyeli modüllere bağımlı olmamalı. Modüller soyutlara bağımlı olmalı. (Program to interface) Soyutlamalar detay sınıflara(concrete class) bağımlı olmamalıdır. Constructor injection ile bağımlılıklar tersine çevrilebilir.

Always Design for Concurrency

Concurency(eş zamanlılık) birden fazla işlemin aynı anda gerçekleşmesi olayına denir. Birden fazla iş aynı anda yapılabilir. Örneğin iki iş aynı anda çalışmaya başlarsa iş bitme zamanları birbirlerinden farklı olabilir. Kod execution lineer ilerlemez. Her iki işin ortak paylaştığı değişkenler, objeler thread-safe yapılmalı. 

Örnek thread-safe singleton class

https://www.geeksforgeeks.org/java-singleton-design-pattern-practices-examples/

Estimate the Order of Your Algorithms (Big O notation and Time Complexity)

Bir fonksiyonun çalışma süresini tam olarak ms, s türünden hesaplayıp kesin bir şey söylemek zordur. Çalışma süresini belirleyen faktörler değişkenlik gösterebilir. Örneğin çalışan bilgisayarın ne kadar hızlı olduğu, hangi programlama dilinin kullanıldığı, fonksiyon içerisinde başka çağrımlar yapılıp yapılmadığı, giriş parametrelerinin değişkenlik göstermesi gibi bir sürü parametre vardır. Direk olarak fonksiyonun çalışma süresi ne kadar diye sormak yerine “How does the runtime of this function grow? Fonksiyonun çalışma süresi nasıl büyür?” diye sorulmalıdır. Bu sorunun cevabı ise BigO ile verilir. Zaman karmaşıklığı kabaca linear time, constant time, quadratic time olarak sınıflandırılabilir.

Örneğin sıralı bir dizide bir değer bulunmak istendiğinde lineer bir yaklaşımla problem çözülebilir. Bulmak istediğimiz değer dizinin en sonunda olursa(worst case) O(n) olur. Bütün diziyi gezmiş(traverse-iterate) etmiş oluruz. Dizi sıralı olduğu için binary search ile algoritma geliştirilirse bütün diziyi iterate etmek durumunda olmayacağımızdan O(log(n)) olur. Algoritmamız büyük değerler ve küçük giriş değerleri için daha hızlı çalışır.

Yazdığımız kodlarda quadratic fonksiyonlara(iç içe döngüler) dikkat etmeliyiz. Fonksiyonun çalışması için gerekli bir setup’da olabilir. Giriş parametrelerine göre execute edilmesine gerek olmayan kod parçacıkları handle edilebilir. Dynamic programming ile set, hash collection larından faydalanılabilinir. Fonksiyonlar, metodlar büyük giriş parametleri ve küçük giriş parametrelerine göre çalışma zamanları farklılık gösterebilir.

Big O Notation

https://www.geeksforgeeks.org/analysis-algorithms-big-o-analysis/

You Can’t Write Perfect Software.

Yazılm mükemmel olamaz. Yapılabilinecek en iyi şey kodun secure, korunur ve gelebilecek hatalara karşı önlemlerin alınmış olmasıdır.

Test Your Software, or Your Users Will. . . . . . . . .

Bug çıkabileceğini bile bile kullanılan branchlere kod geçilmemeli. Diğer türlü bug’ı son kullanıcı veya test mühendisi bulacaktır. O tarafa gelmeden bug yerinde çözülmelidir.

Find Bugs Once

Test mühendisinin bug bulabilmesine izin verilmemelidir. Code coverage ve integration testler ile akla gelen tüm testler dev tarafından yapılmalıdır. Developer olarak zamanımızı yeni kod yazımı(feature) ve yeni bug çözümlerine harcamalıyız.

Don’t Be a Slave to Formal Methods

Varolan büyük projelerde çalışırken yapmak istediğiniz şey daha önce bir başkası tarafından bir benzeri veya aynısı yapılmış olabilir. İş mantığını, mimariyi bozmadan direk copy/paste yerine daha iyi nasıl yapılır diye düşünüp ufak araştırmalar yapmak kodun kalitesini arttırır.

Gently Exceed Your Users’ Expectations . . . .

Kullanıcı beklentileri tam olarak karşılanma hatta kullanıcının daha mutlu olabilmesi için biraz daha fazlası yapılmalıdır.

Work with a User to Think Like a User . . . . . . .

Yazılımın anlaşılır olması ve sistemin anlaşılabilmesi için kullanıcı ile birlikte çalışmak iyi bir yoldur. Agile çalışılan scrum projelerinde kullanıcılarda işin içerisine dahil edilir.

Refactor Early, Refactor Often

Yeniden yaz, yeniden üzerinde düşün, yeniden planla. Refactor işlemi sık sık yapılmalı.

Test Et -> Fail aldığını gör -> Refactor et -> Yeniden test et.

Pragmatic Programmer kitabında verilen ipuçlar

https://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X
Her yazılımcının okuması gereken kitaplar arasında gösteriliyor

Care About Your Craft

İşini severek yaparak zevk almak her insanın hayatında istediği bir durum. Yazılım Geliştirmeyi severek yapıyorsanız o zaman iyi sonuçlar verebilirsiniz. Diğer türlü sabah işe git akşam gel şeklinde geçen bir iş hayatı işveren içinde kendiniz içinde iyi olmayacaktır. İşinizi sevdiğinizde motive olmanız kolaylaşır ve işinizi daha iyi yapmak istersiniz.

Think! About Your Work

Yaptığınız işin eleştirisini başkası yapmadan önce kendiniz yapın. Akışına bırakmak yerine ne yaptığınızın farkında olun ve işin modüler olarak değerlendirmesini/takibini yapın. Daha iyi çözümler olabileceğini aklınızdan çıkarmayın bu sebeple araştırmacı olun.

Provide Options, Don’t Make Lame Excuses..

Gerçek hayattan bir örnek vermek gerekirse hayatta yaşamını mutlu bir şekilde uzun süre sürdürebilmenin yolu değişikliğe açık olmanız ve bulunduğunuz ortama ayak uydurmanızdır derler. Yazılım projeleride değişir öncesinde/sonrasında hata çıkma olasılığı yüksektir. Örneğin test süreçlerinde bir hata yapıldıysa dürüst olmak gerekir ve hatayı kabullenmeliyiz. Hatayı düzeltmek için seçenekler sunulmalı ve çözümü yapılmalıdır. Faydasız bahanelerin kimseye faydası olmaz. Projedeki tüm stake holder ların bu düşünce yapısında olması gerekir. Kesin çözüm için problemin doğru kişiye adreslenmesi ve yardımcı olunması gerekir.

Bahane üretmek yerine takım arkadaşlarından destek almak veya internetten destek almak iyi bir çözüm.

 Don’t Live with Broken Windows

Kod yazımı sırasında sizinle ilgili veya ilgili olmayan bir hata(tasarım hatası, yanlış iş mantığı, zayıf kod) gördüğünüzde hemen düzeltin. Eğer düzeltmek için yeterli zamanınız yoksa durumu not edip takım liderine bildirin. Burası zaten yanlış ve kimse düzeltmemiş deyip hiç bir şey yapmamak yanlış bir durum.

Be a Catalyst for Change

Takım içerisinde uyumlu olmak ve pozitif olmak motivasyonu ve iş başarısını etkileyen bir durum. Takıma vereceğiniz iyi bir sinerji ile ilerisinin daha pozitif olmasını sağlayabilirsiniz.  Catalyst değişime sebep veren kişi olarak kullanılmış.

Remember the Big Picture

Detaylarda boğulmak yerine sonuca odaklanın. Daily sabah toplantılarının oldukça kısa olması bu sebeple önemli bir durum.

Make Quality a Requirements Issue

Şuan elde çalışan ürün yıllar sonra gelecek harika ürüne göre tercih edilir.  Ürün sahibi ile sürekli iletişimde olup erken ve sık sık ürünün genel değerlendirmesi yapılması kalitenin artmasına sebep olur. Erken yapılan geri dönüşler kaliteyi belirleyen unsurlardandır

Invest Regularly in Your Knowledge Portfolio

Öğrenme alışkanlığı edin.

  • Her yıl yeni bir programlama dili öğrenin
  • 6 ayda bir Teknik bir kitap okuyun
  • Kişisel gelişim için Teknik olmayan kitaplarda tercih edin
  • Dersler alın(Eski bilgileri tazelemek veya yeni şeyler öğrenmek için kaynak oluşturun Üniversitelerin ders sayfaları ve videoları takip edilebilir)
  • Meetuplara katılın: Isole olmak insanı bitiren davranışlardan biridir. Meetuplara katılıp yine fikirler edinin, insanlar ile konuşun
  • Farklı ortamları deneyin: Linux, Windows, MacOS ve benzeri ortamları deneyip karşılaştırma yapabilecek durumda olun
  • Şimdide kalın: Teknoloji/yazılım çok gelişen bir olgu olduğu için okuyarak dinleyerek kendinizi geliştirin

Kendinize yatırım yaparak bilginin en değerli hazine olduğunu özümseyin

Critically Analyze What You Read and Hear (Critical Thinking)

Dinlerken veya okurken direk kabul etmek yerine kendi anlayacağınız şekilde mantık kurun daha sonra anladığınızı karşı tarafa aktarın.

It’s Both What You Say and the Way You Say It (Communicate!)

Dinleyici olun. İletişiminiz iyi olsun. Fikirlerinizi insanlar ile paylaşmadığınız sürece veya efektif bir şekilde anlatmadığınız sürece herhangi fikrin bir kullanışlılığı yok.

  • Ne söyleyeceğinizi bilin
  • Konuşacağınız kişiyi tanıyın
  • Doğru zamanı bulun. Yazılımcılar meşgul olabilir
  • Konuşma stiliniz iyimser olsun
  • Konuşmaya dahil olun
  • Geri dönüş yapın

DRY—Don’t Repeat Yourself

Yazılımın kolay geliştirilmesi, tutarlı olması ve bakımının kolay yapılabilmesi için yazdığınız kodun duplike olmadığına dikkat edin.

  • Bazen aynı projede başkasının yazdığı kodu kopyalamak kolay gelir. Kopyalamak yerine refactor etmeyi deneyin.