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.

Leave a Reply

Your email address will not be published. Required fields are marked *