Unit tests are an important scaffold for large-scale software development; they enable us to design, write, and deploy production code with confidence by validating that software will behave as expected. Even though they may not execute in live systems, their development and maintenance requires the same care as general production code. Sometimes developers do not realize this which leads to testing code with more code smells than production code. Engineers may not give enough attention to test code changes in the code review process.
In this post, I’ll try to explain some high-level concepts of Domain-Driven Design and then I’ll mention my experience with the application of these concepts.
What, Why, When? Domain-Driven Design is a set of practices to model complex business domain into software better. These practices try to tackle different aspects of complex business domains, like communication, high-level design, team relationships/communications, low-level class designs, etc.
Domain-Driven Design is not bound to Object-Oriented Design.
Last week I attended the QCon London 2020 Conference first time. I think it’s one of the best-rated software engineering conferences in Europe. I had two main expectations from the conference; the first one is inspiring ideas, the other one is experience sharings about some architectural design.
A view scene from the Queen Elizabeth II Centre
The conference was organized very well, it reflected the experience of the team behind it.
In this post, I explain why we use JVM thread pools, what are the parameters that we should take into account when we decide a thread pool and it’s size. And how these parameters are affected when we run our application with Docker and Kubernetes.
Why do we use thread pools? We use thread pools to align our system workload with system resources efficiently. This system workload should be tasks that can run independently, for example, every Http request to a web application can be in this category, we can process every request without thinking another Http request.
Contributing to open source projects can have many different benefits and motivations for different individuals or companies. In this blog post, I’m going to write about my motivation and process for contributing to open source projects.
My Journey I have been aware of that contributing to open source projects is one of the best alternatives to improve professional skills for a long time. But I had also postponed it for a long time, even for the times that I couldn’t find enough opportunities to learn and grow at my employer.
In this post, I try to introduce you some basic concepts of an instrumentation of a Spring Boot 2 application with tools such as Micrometer, Prometheus, Grafana. There are 3 main phases while you’re instrumenting an application, first, one is producing metrics in the application(Micrometer), the second one is gathering these metrics to persist(Prometheus) and the third one is monitor these metrics(Grafana).
What’s Software Instrumentation? According to Wikipedia, instrumentation, in terms of computer programming, is;
Kasım 2017’den beri çalıstığım bölümdeki junior developer’lar için bilgi/deneyim paylaşım aktiviteleri düzenliyorum. Bu paylaşım aktivitelerinde bazı şeyler çok teorik seviyede kalabiliyor, bunu hem ben hissediyorum hem de bazen katılımcılardan geri bildirim olarak geliyor, özellikle projelerinde çok fazla bir şeyler deneyimleme imkanı olmayan arkadaşlarda problem biraz daha büyüyor. Bunu aşabilmek için bazı session’ları tamamen pratiğe yönelik yaptım, bazı sessionlarda da anlattığım çoğu şeyi pratik olarak temel seviyede göstermeye çalıştım ancak bu yetmedi.
After 2011 in my career, I decided to become a good technical manager and I had been reading lots of things about agile software development, scrum, people-oriented processes, organizations, etc. I started to share my knowledge in-house. This has lasted for about 5 years. I did lots of thing in terms of software development management with my teams and the other teams. I sold agile software development at some level in my department.
Bu yazımda Udemy’de yayınlanan “Java, JUnit ve Mockito ile Unit Test Yazma Eğitimi” ni hazırlayış sürecimden bahsedeceğim.
Yapabilir miyim? İnsanların öğrenmek için okumak ve dinlemek yerine izlemeyi daha çok tercih etmeye başlaması ile birlikte online eğitimler de, özellikle yazılım geliştirme sektöründe, çoğumuzun hayatına girdi. Eğitim deyince benim aklıma hep bu işi profesyonel olarak yapan insanların verdikleri eğitimler geliyordu, belki sınıf içi eğitim veren insanlardan kaynaklı oluşan bir algı. Youtube vb. ortamlarda eğitim tarzında içerik hazırlayan ve bu işi profesyonel olarak değil daha çok bir konferans’da veya meetup’da bir şeyler anlatıyormuş gibi yapan insanlar vardı ama onlarınki eğitimden ziyade bir paylaşım gibi geliyordu bana.
Udemy’de Java’da JUnit5, AssertJ ve Mockito gibi araclar ile nasıl unit test yazılacağını anlatan bir eğitim yayınladım.
Bu eğitimi bir programlama dilini bilen birisinin, buna paralel olarak o programlama dilinde yazdığı kodları otomatik olarak nasıl test edebileceğini yani nasıl unit test yazabileceğini de öğrenmesi gerektiğine inandığım için hazırlamak istedim.
Eğitimi hazırlarken en temel motivasyonlarından birisi de yıllardır bir çok projede unit testler olmadığı için hep benzer sorunlar ile yüzleşmem. Unit testlerin olmaması ve bunun sonucunda çıkan bir çok hata, çok fazla maliyeti olan ve çok uzun süren manuel testler, fazla mesai’ler, 1 saat’de yazılan kodun sisteme olan genel etkisi için 3 gün test yapılması gerekmesi vs.
In the first part of this blog post I wrote our problem about the mentoring to junior developers, results of this problem and a solution we wanted to apply. In this part, I write about the details of our solution, some practices and challenges of the process.
Project Management Methodology One of the advantages of the project is that this project is a replacement project for an already existing system, and I know the business domain well for this legacy system because a few years ago I had worked in a project that’s one of the clients of this legacy system.
In this 2-post series, I would like to write about our 5-month-old project team’s growth process or journey. When we talk about people related problems it’s very hard to propose standard solutions. Solutions can change for different countries, cultures, people, organizations, projects etc. So I can just talk only my own experiences about my team. And these are just my own ideas and observations, not the company I worked with.
Previously I’ve used Blogspot for my blogs. I’m not a very active blogger, I have just a few entry in Turkish at Blogspot. Recently I decided to share more things regularly with my blog posts both in Turkish and English and also improve my sharing environment. I’ve wanted to keep my entries with my full control, not in an external environment such as Blogspot, Wordpress, Medium etc. Also, I’ve wanted to use my own domain name and I thought mucahit.
Nedir teknik liderlik, neler yapar, nelerden sorumludur, nelere dikkat etmesi gerekir, zorlukları nelerdir, kişiye ve takıma avantajları dezavantajları nelerdir gibi konulardan bahsetmek istiyorum.
Öncelikle kabaca nasıl bir teknik liderden bahsedeceğimizi tanımlamak faydalı olacaktır çünkü benzer rolde ancak çok farklı pratiklerle/sorumluluklarla çalışanlar mevcut. Benim bahsedeceğim daha doğrusu olmasını istediğim teknik lider: Bir geliştirme takımından sorumlu lider ve zamanının en az üçte birini takım ile beraber kod yazarak geçiren kişidir.
Teknik liderliğe geçiş geliştirme takımının içindeki birisinin bu pozisyona geçmesine duyulan ihtiyaç ile olur.
Kendi halinde, daha çok bilgisayar ile konuşan ve genellikle bilgisayar üzerinden çözülebilecek sorunları olan bir developer iken bir gün gelir şirket büyür, ekip büyür ve sana sen artık bu ekibin takım liderisin veya teknik liderisin derler. Geçiş genelde hızlı olur, ne bir eğitim ne bir hazırlık, kendi yolunu kendin bulacaksındır. Yöneticinin, ekip arkadaşlarının ve zamanla muhattap olmaya başladığın müşteri, iş birimi gibi diğer paydaşların senden beklentileri hakkında da kafanda bir şeyler yok ise işin daha da zordur.
Yazılım geliştiren insanlar özelinde sektörde geleceğe yönelik net bir planı olmayan çok fazla insan var, bu kategoriden kendimi de çok dışlamıyorum. İşi sadece yaşamını belirli seviyede devam ettirebilmek için belirli seviyede yapan insanlar, sadece iş. Her gün ayağını sürüye sürüye işe gitmek. Her sabah ofise girdiğinde biran önce akşam olsada eve gitsem düşüncesi. Her gün niye bu saçmalıklarla uğraşıyorum düşüncesi.
Normal mi, değil, özellikle doğrudan insana, insanın psikolojisine, yeteneklerine, işini sevmesine bağımlı olan yazılım geliştirme gibi bir sektörde.
Bir yazılım geliştirme ekibi nasıl olmalıdır sorusuna yazılım projesinin bağlamına, müşterisine, karakterine vs. göre farklı farklı cevaplar verilebilir ancak çoğu zaman gözlemlediğim ve beni rahatsız eden bir yapılanma şekli çok yaygın; rollere göre kurulan ayrı ayrı ekipler. Mimari ekip, altyapı ekibi, tasarım ekibi, geliştirme ekibi, test ekibi, analiz ekibi, kalite ekibi vs. Bu ekiplerin hepsinin başında bir lider ve bu liderler de hiyerarşide bir üstte birine(proje yöneticisi, proğram yöneticisi, çözüm yöneticisi, direktör vs.
Organizasyonel anlamda merkezileşme’den kastım daha çok karar mekanizmaları bağlamında; onlarca, yüzlerce insanın her gün yaptığı işi etkileyen kararların 2-3 kişi tarafından alınması. Konu(Organizasyon, yönetim vs.) hakkında derinlemesine bilgi sahibi birisi değilim, bahsedeceğim bazı yönetimsel kavramları tam anlamıyla açıklayamayabilirim, ancak yazılım üreten şirketlerdeki bu çeşit politikalar, yazılım üreten insanlara ve yazılım projelerine bakış açıma çok uymuyor, dolayısı ile ben konuya merkeze insanı koyarak neden merkezileşmemeliyiz bakış açısıyla bakmaya çalışacağım, biraz beyin fırtınası tarzında olacak.
Agile yazılım geliştirme yaklaşımının öne çıkan özelliklerinden ikisi, değişime cevap verebilme ve değişen şartlara adaptasyondur. Bunu sağlayabilmek için yapılması gerekenlerden birisi de sürekli olarak nerede olunduğunun, nereye gidilmeye çalışıldığının değerlendirilmesi ve alınması gereken aksiyonların alınmasıdır.
Agile manifesto’da bununla ilgili olan prensip; “Takım, düzenli aralıklarla nasıl daha etkili ve verimli olabileceğinin üzerinde düşünür ve davranışlarını buna göre ayarlar ve düzenler.”
“Her zaman iyileştirilebilecek bir şeyler vardır.”, “Hiç bir şey mükemmel değildir ama her şey mükemmelleştirilebilir.
Behaviour Driven Development kavramı son zamanlarda dikkatimi çeken bir konu. İlk önce Dan North tarafından ortaya atılmış. Dan North, TDD(Test Driven Development) ile ilgili bazı tecrübelerinden yola çıkarak gördüğü aşağıdaki gibi bazı eksikliklerden dolayı bu kavramı ortaya atmış;
Testler nerede başlar nerede biter belli olmuyor, Testlere verilen isimleri sadece developer’lar anlıyor, Ortak bir dil(ubiquitous language) kullanılamıyor, Test, Analist, Development arasında ortak bir anlayış sürece dahil edilemiyor. BDD ile aynı amacı güden pratikler farklı isimlerle anılabiliyor, bunlardan bazıları; Specification by Example, Acceptance Test Driven Development, Extenden Test Driven Development.
Yapılacak olan işlerin önceden maliyetlendirilmesi yazılım geliştirme sektöründeki kritik işlerden birisidir ve bu konuda function point, uzman görüşü(expert judgement), story point kullanımı vb. çeşitli yöntemler günümüzde kullanılmaktadır. Her yöntemin olumlu olumsuz yönleri olduğu için tek bir standart model yok(yazılım dünyasının en büyük derdi standartlar yoktur çok fazla).
Agile dünyada maliyet hesabı için kullanılan yöntemlerden birisi de story point kavramı ile maliyetlendirmedir. Burada kritik kavramlar ekip, büyüklük, hız, süre ve takvimdir. Kısaca story pointler kullanılarak maliyetlendirmenin nasıl yapılacağından bahsetmeye çalışacağım.
Türkçe karşılığını bulamadığım holding space kavramı basitce insanın kendisi veya bir başkasının bir şeyleri yapması için ona müdahalelerden, ön yargılardan uzak bir ortamı sağlaması, onun ilerlemesi bir şeyler ortaya çıkarabilmesi için desteklenmesi yani ona kendini bir şekilde ifade edebilmesi için alan açılması anlamına geliyor.
Bu kavram farklı alanlarda uygulanmakla birlikte daha çok yoga vs. gibi meditasyon teknikleri alanında karşınıza çıkıyor. Ben bu kavram ile ilk defa Lyssa Adkins’in Coaching Agile Teams kitabında karşılaştım.