Yaptığımız işleri ne kadar teknik bilgi içerse de hatta ne kadar yüksek teknik bilgi içerse de mümkün olduğunca basitleştirerek, net örnekle anlatmak gerektiğine inananlardanım. Bu nedenle kendimce anlatmaya çalıştığım her konuyu gündelik hayatımızdaki bir örnekle eşleştirmeye çalışırım. Bu yazıda da öyle bir eşleştirme olacak. O nedenle hatam olursa affola…
“Bir şeyi basit bir şekilde anlatamıyorsan, yeterince anlamamışsın demektir.”
Albert Einstein
Yazılımları yaşan bir organizma gibi düşünmemiz gerektiğini bu nedenle de sürekli bir evrim geçirdiklerine dair birçok ifade anlatım duymuşuzdur, okumuşuzdur. Günümüzdeki yazılımlar birçok bileşenden meydana geldiğinden yaşayan bir birey yerine bir topluluk olarak değerlendirmek daha doğru bir yaklaşım olacaktır. Bu durumda yazılımlar, yazılımların modülleri ve bu yazılımları geliştiren yazılımcılar aynı topluluğa üye birer birey olarak değerlendirilebilir/değerlendirilmelidir.
Toplumlar birbirleri ile paylaşımda bulundukları oranda güçlüdürler. Bu paylaşım bilgi alış-verişi şeklinde de olabilir eleştiri şeklinde de olabilir. (demokrasi) Önemli olan toplumdaki her bir bireyin topluma maksimum katkı sunmaya özen göstermesidir.
Demokrasilerde muhalefet nasıl vazgeçilmez ise yazılımlarda gerçekçi Code Review, Code Metrics, Test ve Üçüncü Göz o kadar önemlidir. Demokrasilerde yöneticiler kendi yaptıkları her şeyin iyi olduğunda canı gönülden inandıklarından kendi yaptıklarının körüdürler. Onları bu hatadan döndürmek için muhalefet vardır.
Yazılımcılarda bu durum çok da derindir. Çünkü işine, yazdığı koda o kadar odaklanmıştır ki çoğu zaman o kodun içerisinde kaybolur. Bu nedenle code-review ve/veya üçüncü göz mekanizmaları her projenin en başında kurgulanmalı ve net kurallarla belirlenmelidir. Bu mekanizmalar gerek insan gözü gerekse otomatize edilmiş süreçlerden oluşmalıdır.
Demokrasilerde sıkça duyduğumuz kuvvetler ayrılığı kuralları yazılım projeleri için de tamamen geçerlidir. Yazılım projeleri gerek bir başka yazılım ile otomatize edilen metrik ölçümleri, gerek insan kontrolleri, gerek test süreçleri ile sürekli denetlenmelidir. Yazılım = toplum diye bir benzetmemiz var ise bu topluluğun sağlıklı kalabilmesi için bu toplumdaki kuvvetler bağımsız şekilde ayrıştırılmalı ve birbirlerini denetleyecek şekilde konumlandırılmalıdırlar.
Kuvvetlerin ayrılmadığı her yerde herkes, her şeyi yapar, her şeyin en iyisini bilir.
Yazılımcı arkadaşlar kızmaz ise yazılımcı ilginç bir türdür. Özellikle yaptığı iş soyut olduğundan denetlemesi zordur. Birbirine bağlı doğru kurgulanmış mekanizmalar ile denetlenmediğini, denetelenemediğini hissederse işiniz zor. Bu durumda yazılımcı şöyle düşünür. “Bugün de kodu koyduk. Bundan sonrasını onlar düşünsün.” der geçer. Bu türü tespit etmek çok kolaydır. Yuvarlak cevaplar verirler ve hep bir bahaneleri bulunur. Aman dikkat.
İşini doğru yapan, yapmaya çalışan, yapmak için tüm şartları zorlayan yazılımcı çok ender bulunan oldukça nazik bir türdür. Bu türdeki arkadaşlar code review, code metric ve üçüncü göze önem verirler. Bir yerde takıldıklarında etraflarına soru sormaktan, soru sorulduğunda ise net cevap vermekten çekinmezler. Baş üstünde gezdirilecek arkadaşlardır, iyi davranın.
Bir de çekimser, utangaç yazılımcı vardır. Hatta bunların içinde ne cevherler vadır, çıkarmasını bilene. Bu arkadaşlar yanlış yaparsam, eksik yaparsam bana kızarlar mı? Benimle dalga geçerler mi? diye genelde var ile yok arasındadırlar. Kendilerini pek göstermenden aramızda yaşarlar.
Buraya kadar olayı biraz kişisel getirdik. Yani yazılımcı üzerinden geldik. Ancak yazılımcı buradaki en masum taraftır.
Yazılım projelerinin sahipleri yani yazılım firmaları, yazılımcılara doğru geliştirme ortamı ve kaliteli denetim mekanizmaları sağlasalar sepetteki çürük elmalar kendiliğinden dökülür. Ortaya kaliteli yazılımlar hatta global ölçekte kaliteli yazılımlar çıkar.
AWS, Netflix, Google bilmem ne, aklınıza gelen tüm diğer global firmaların ortak özelliği yazılımlarını bir pipeline içerisinde bir süreçten geçirerek, belirli kalite standarlarını uygulayarak yayınlamalarıdır. Böylece kaliteyi daima yukarıda, daima belirli bir standart içerisinde tutmaktadırlar.
Aslında yapılacakar oldukça basit. Aşağıdaki gibi bir pipeline’nın tavizsiz işletilmesi tüm firmalara tüm yazılımlara bir standart bir kalite getirecektir.
- Sizlerle birikite çalışan yazılımcıların yazdıkları kodun kalitesinin ölçülmesinin onların yeteneği ile ilgili değil kurum kültürü ve yazılım kalitesi ile ilgili olduğunu anlatın, hissettirin.
- Hatalı, eksik kodların size ulaşması durumunda süreci iyi yönetemezseniz önce yazılımcı size sonra siz bu sisteme küsersiniz. Sonrasında saldım çayıra mevlam kayıra projeler çıkmaya başlar.
- Code Convention kurallarının belirlenmesi
- Code Quality standartlarının belirlenmesi,
- Code Security kurallarının belirlenmesi
- Code Review checklistlerinin yukarıdaki maddeler baz alınarak oluşturulması,
- Static Code Analysis Metric araçlarının yukarıdaki kullara göre yapılandırılması ve işletilmesi,
- Sonarqube gibi birçok ücretsiz toolun işletilmemesini-kullanılmamasını hala anlamış değilim.
- Code Review yapılması,
- Sonarqube veya benzeri bir statik kod analizi çalıştırılmadan code review yapılmasını çok doğru bulmuyorum.
- Statik bir analiz aracı incelene kod üzerindeki spot noktaları bize verecektir.
- Bunun üzerine checklist üzerinden yapılacak bir code review tadından yenmez.
- Cyclomatic Complexity,
- Kod metriğinin içerisinde olsa da burada özellikle belirtmek istedim. Kodunuzun geleceği hakkında bir öngörü vereceğinden bir gözünüz daima bu ölçümde olsun.
- Testler, acımasız testerlarınız olsun.
- Lütfen analiz ve test konusunu hafife almayın. İyi analiz edilmemiş, iyi test edilmemiş bir projede yazılımcı mucize yaratamaz.
- Unit Test: Bu biraz karmaşık bir konu projenizin büyüklüğüne, genişleme/büyüme olasılığına, fonksiyonel karmaşıklığına göre değerlendirilmeli.
- CI/CD Integration,
- Tüm deployment stratejilerinizi bu testlerden geçen uygulamaları prod/canlıya almak üzerine kurgulayın.
- Bu testlerde fail olanları canlıya almadığınızda canlıda minimum hata çıkacaktır.
- Kurum Kültürü,
- Bunları göstermelik, şekil olsun diye değil. Bir kurum kültürü olarak, tüm kurumun benimsemesini sağlayın.
Bu maddeleri uyguladığınız ilk 3 ay size işkence gibi gelecektir. Sonrasında getirdikleri avantajları görünce daha önce neden yapmadık diyeceksiniz, emin olun.
Not: Sanıyorum bir sonraki yazım Türkiye’nin Open Source Serüveni ile ilgili olacak. Ancak onu kendi bloğumda yayınlayacağım.