Yazılım süreçleri nasıl olmalı (Bölüm – 1)

yazilim_surecleri

Merhaba, daha önce yazılımın nasıl kodlamasıyla ilgili birtakım prensiplerden bahsetmiştim, şimdi ise karşılaştığım tecrübelerden derlediğim kodun nasıl yazılacağı kadar önemli olan yazılım süreçlerinden bahsetmek istiyorum.

Yazılım 2018 yılının 2. çeyreğini bitirirken artık hayatın tam ortasında kalmaktadır. Fabrikalar, evler, okullar devlet kurumları, otobüs durakları ve aklınıza gelebilecek her noktada ve mobilde bin bir türlü yazılım karşımıza çıkıyor. Yazılım sektörü gün geçtikçe değerli bir sektör olmaktan geri kalmıyor ve sürekli iş sirkülasyonu, personel ihtiyacı doğuruyor.

Tüm bunlar olmaya devam ederken geride tabi ki sanayi devriminden sonra yaşanan eski kurmalı el ile kullanılan cihazların yerine zamanla otomatik el değmeden çalışan cihazların gelmesi gibi yazılım sektörü arkasında tonla çöp kod ve süreçleri tamamlanamamış bir düzine yazılım bırakıyor.

Peki bu yazılım süreçleri nasıl olmalıdır?

Yazılım fikirle başlar tasarımla devam eder, planlama ve kodlama arkasından gelir. Mutlaka test ve revizeler son süreçlerde olmalıdır ki mutfaktan çıkmadan hazır hale gelebilsin. Yazılım sektöründe çok kullanılan bir tabir vardır, “Kevran yolda dizilir” her ne kadar yazılımcıların çoğu bu mantalite de hareket etse de (bazen bende yaparım) bu iyi bir yazılım süreci oluşturmak için doğru bir düşünce değildir.

1- Fikir

Genelde bu aşama yazılımcı dan değil, işveren, girişimci veya proje sahibi nasıl adlandırırsanız onun tarafından oluşur. Olgunlaşması sürecin son adımına kadar devam eder. Tüm süreçleri başlatan kısım burasıdır. Fikir tek başına bir işe yaramasa da sürecin yapı taşıdır. Fikir mutlaka bir ihtiyacı veya bir eksiği tamamlaması gerekir. Toplumun veya piyasanın kabulleneceği bir alanda olmalıdır. Bir yazılım kalbi onun kullanıcısı olduğu düşünürsek kullanılmayacak bir fikirden çıkan yazılım fikri süreci başından baltalamak anlamına gelir.

2- Tasarım

Tasarım deyince akla hemen “web tasarım” getirmediniz inş. üzlürüm yoksa. Tasarımdan kastım grafikte değil. Bu tasarım hazırlanacak olan yazılımın kağıt üzerinde tüm şemasının ve gerekirse iş kurallarının oluşturulma aşamasıdır. Genelde bu süreç adımı hep atlanır. Sonra sil baştan başa dönülür, tekrar tekrar düzeltmeler veya başta bahsettiğimiz kervan yolda dizilsin kavramına bırakılır.

Tasarım adımında yazılımın depolanacak verilerinin hangi şemalarda tutlacağı, yazılımın ilk ekranından son ekranına kadar olan süreçlerde neler olması gerektiği, ekranlardaki elementlerin yerleşimine kadar belirlenmesi gerekir. Ekranların olması gerektiği dizilimler mockup şeklinde veya basit karakalem çizimleriyle oluşturulmalıdır.

En önemliside dış bağlantılar, assets dediğimiz bu bağlantıları planlamak asıl kodu yazmak kadar önemlidir. Gene aklınıza web tasarımda içinde css, images, js bulunan klasör geldi sanırım. O değil, onu unut, örneğin bir e-ticaret sistemi yazıyorsak bunun diğer yazılımlarla entegrasyonu, atıyorum bir araç takip sistemi yazıyorsak bunun plaka tanıma sistemiyle entegrasyonu gibi ana yazılıma bağlanabilecek diğer yazılımlar ve bu yazılımlarla haberleşme kanallarını hesap edip yapıyı buna göre tasarlamamız gerekir.

3- Veritabanı Hazırlama

Tasarımda ortaya çıkan veri depolama şemalarının fiziksel olarak oluşturulması aşamasıdır. Hemen en iyi bildiğimiz veritabanına hızlıca ittirveririz ki kodlamaya başlıyalım. Yok yok öyle değil tabiki, bunu yapmayın. Veritabanı yazılımın yaşam döngüsünde önemli bir yer kaplar. Dağıtık sistemlerin yaygınlaştığı yazılımın yüküne ve ihtiyaç duyulan gereksinimlere göre bir veritabanı seçilmelidir. Stresi çok fazla olan yani kullanıcı işlem sayısı çok fazla olan yazılımlarda Mutlaka ikincil bir depolama alanı veya nosql dediğimiz birbirine bağlantılı olmasada tek başına yüklü miktarda verilerde hızlı geri dönüş sağlayan depolama türleri düşünülmelidir. Kodlamada olacağı gibi veritabanında da versiyonlama kullanılmalıdır. Bu sayede farklı sürümlerdeki farklı veritabanı yapıları daha rahat takip edilebilir.

Veritabanı hazırlarken mutlaka standartlara uymalıdır. Veritabanı ismi, tablo ismi, tablodaki alanların isimleri, tablo alanlarına verilen tiplerin tamamı belirlenecek olan standartla oluşturulmalıdır. Tabi bunu belirlerken kişisel yazım stillerinden daha çok kabul görmüş standartlara uymakta fayda var. (Özellikle rica ediyorum Id alanlarının bağlantılarını yazarken iki harfide büyük yazmayın. Örneğin; CustomerID değilde customerId şeklinde oluşturun ayıpır yahu :) yada customer_id şeklinde hepsi ayırmada kabul edilebilir.)

Not: Bazı frameworkler de veritabanı direkt migration sınıfırlarında kod şeklinde hazırlanır, o şekilde veritabanına dönüşür, elbette bu bizim süreçlerimize uygundur.

4- Planlama ve Süre Belirleme

Neden bunu veritabanından sonra yazdım, aslında öncesinde olması lazımdı değil mi? Tabiki de hayır ! Veritabanı olmadan bir yazılımı planlamak ve süre belirlemek intihar olacaktır. Çünkü fikirde ve yazılımı tasarlarken ortaya çıkmayan, teknik olarak ihtiyaç bulunan tüm veri altyapısı veritabanı hazırlarken ortaya çıkacaktır. Yazılım veritabanının üzerine inşa edilecekse süresini ve planını veritabanı olmadan yapmamak gerekir.

Plan yapılırken çalışacak olan geliştirici sayısı, bilgi düzeyleri ve kimin hangi kısmı yapacağı ve ne kadar sürede yapılacağı belirlenmelidir. Bu planlama iş takibini ve yazılım sürecinin kalan adımlarını sağlıklı hale getirir.

Süre belirlerken mutlaka dahili testleri ve dahili revizyonları hesaba katmak gerekir. Yani yazılımcıdan teste çıkmadan önce yapılan kullanım sonrası çıkabilecek revizelerin yapılma sürelerinden bahsediyorum. Sonrasında asıl testler ve bu testlerden çıkabilecek revizelerin olabilme ihtimali göz önünde bulundurularak süreye eklenmelidir.

Tasarlanan her ekranın gerekirse her adımı ayrı ayrı plana yazılmalı ve iş listesi buna paralel oluşturulmalıdır. Arada kopukluk olmaması adına birbiriyle ilişikili olan adımları mutlaka belirtmeli ve birbiri ardına iş listesine girilmelidir.

Entegrasyon süreçleri için gerekli zaman göz önünde bulundurulmalı, entegrasyonla ilgili materyaller, dökümanlar, videolar veya örnek kodlar bu adımda düşünülüp yazılımcıya iletilmelidir. Bu sayede kodlama aşamasında kopmadan seri bir şekilde ilerleme kaydedilecektir.

Planlama yapılırken mutlaka bir sonraki aşamadaki grafik görsel hazırlama ile kodlamanın birbirine entegreli şekilde ilerleyebilmesi göz önünde bulundurulmalıdır.

6 – Grafik ve Görsel Ekran Hazırlama

Grafikçiler kıza heralde, burası en kebap kısım :) sistemin görsel ön yüzlerinin yüksek grafik beceresi ve gerçekten ayrı bir yetenek isteyen grafiker arkadaşlarımız tarafından çizilmesidir. Bu grafikler elbette kullanıcıya hitap edecek şekilde hazırlanmalıdır. Albenisi yüksek olmasının yanında kullanım kolaylığı ve alışkanlıkları bozmadan ilerlemeyi sağlayacak ekranlar çizilmelidir.

Genelde çizim yaparken yazılım tarafı çok düşünülmez, bir şekilde ooo süpermiş denilen grafikler hazırlanır ve döküm yapacak (html, css) veya ekranı tasarlayacak olan geliştiriciye verilir. Bu aşamada mutlaka ve mutlaka kullanılacak yazılım dilinin ve yazılımın yapısal durumu düşünülmeli ve hesap edilmelidir. Geriye tasarım aşamasında oluşturulan ekranların graiksel olarak renklendirilip kullanıcıya hitap edecek hale gelmesini sağlamak kalıyor.

5- Kodlama

Kodlama ön yüz kodlama (frontend) ve arka yüz kodlama (backend) olmak üzere ana iki kolu vardır. Masaüstü yazılımlarda genelde tek koldan ilerlenir. Tabi ek olarak backoffice dediğimiz yardımcı yazılımlar veya sunucu taraflı yazılımların kodlanmasıda vardır. Bunlara ayrıca değineceğim.

Frontend tarafı grafiklerin gelmesiyle başlar, grafiklere uygun olan fontlar ve javascript kütüphaneleri belirlenir ve bir paket yöneticisi yardımıyla tasarıma eklenir. Ön yüz kodlaması yapılırken mutlaka html standartlarına css uyumluluğu javascript uyumluluğu ve tüm bunların tarayıcılar tarafından uyumluluğuna dikkat edilmelidir.

Css ve javascript için bir üst katman mutlaka kullanılmalıdır. Yani css için less, sass, javascript için type script gibi yazımı kolay derlendiğinde projeyi yormadan çalışacak teknolojiler kullanılmalıdır. Tabi tüm bunları yönetecek GULP veya GRUNT tarzı yazılımlar kullanarak yazdığınız kodları dönüştürmek sıkıştırmak veya fotografları işlemek için toplu iş yazılımları faydalı olacaktır.

Backend tarafında mutlaka bir framework yapısı kullanılmalıdır. Neden frameworkler kullanılmalıdır konusundan daha önce bahsetmiştim. Frameworkler sürekli güncellenirler, yenilenirler, test edilirler, çünkü bir topluluk tarafından desteklenirler. Her frameworkte iş görmez, güncel olması gerekir ve benim tercihim mutlaka MVC (Model View Controller) yapısında olmalıdır. Zaten genelde frameworklerde Solid prensipleri hakimdir. Solid prensiplerinden de daha önceki yazılarım da bahsetmiştim.

Bu gibi etkenler kod yazımını kolaylaştırır, yazılımcıya bir çatı sunar, bu çatı minimum gereksinimleri içerdiği için ve yerli yerinde olduğu için, geliştirici değiştiğinde veya eklendiğinde kolay adaptasyon sağlar. En önemlisi de genişletilebilir ölçeklenebilir scaleble), revize edilebilir ve yenilenebilir  olmasıdır. Frameworkler dış paketlerle güçlendirilebilir, kabul görmüş paket yöneticileriyle (örn: composer) ihtiyaç duyulan kütüphaneler framework’e entegre edilerek hızlı ilerleme sağlanabilir.

Özellikle ve özellikle kodlama sürecinde iş akış yönetimi sağlayacak bir iş takip sistemi kullanmakta fayda var. İş takip sistemi veya basit bir todolist bile süreci düzenler ve daha önce belirlenen sürelerde bitmesine yardımcı olur.

6 – Test

Ben dahil kimse sevmez, test yapılmayan bir yazılım günün birinde mutlaka bir yerden patlayacaktır. Patlama derken istihbarattaki arkadaşların ekranına düşmüştür, öyle bir patlama değil :) bizdeki patlama kodun düzgün çalıştığını düşündüğümüz ve hata göremediğimiz, ve hatta uzun sürelerde hizmet veren kod bölümlerinde oluşan zamansız hatalardır. Bu hatalar anlıkta görülebilir belirli senaryolar oluştuğunda da meydana gelebilir. Bu senaryoları test işinde uzman olan asıl geliştiricinin dışında olan kişilere vermekte fayda var. Malum bütçe ve personel sıkıntısından bu her zaman mümkün olmuyor. Peki bu durumda ne yapmalıyız ?

Test eden bir test uzmanı yoksa yazılım geliştiricinin kendi yazdığı kodu test edecek dış yazılımcıklar geliştirmesidir. Yani yazdığı bir kod sınıfını test edecek başka bir kod sınıfı yazarak, yazılımda sonradan oluşabilecek hataların tespiti için bir test mekanizması. Atıyorum email gönderen bir yazılımımız var, bu yazılım belirli durumlarda tetikleniyor. O durumların dışında bu yazılımı içte tetikleyerek fonksiyonlarının düzgün çalışıp çalışmadığını kontrol edilip raporlayan bir kod yazılmalıdır. Bu belirli aralıklarla veya istenildiğinde çalıştırılıp hata oluşmadan önce hatanın belirlenmesi ve çözülmesinde faydalı olur.

Browser test otomasyonları (örneğin: selenium) veya pilot kullanıcı testleri imkan varsa yapılmalıdır. Çok hayati bulgular elde edilebilir bu sayede ve yazılım gerçek ortamda çalışırken oluşabilecek rahatlıkla hataların önüne geçilebilir.

7 – Revizeler

“Hadi hadi yap geç müşteri bekliyor” derler “tabi ya yapalım. ” deriz. Deriz de revize yapacağız diye güzelim yazılımı çorbaya döndürmenin anlamı da yok bence. Her yapılacak olan revizenin öncelikle bir önceki revizeye sonrada tüm yazılımın yaşamına bir kanser gibi girmesine izin vermemek gerekir.

Yani revize yapılırken kodlama aşamasında uyulacak tüm kural ve prensiplere uyulmalı, ve tekrar test edilmelidir. Revizeler majör ve minör şeklinde ana değişiklikler veya ufak değişiklikler gibi kategorize edilip eğer yazılım altyapısı elvermiyorsa sonraki versiyona daha kontrollü şekilde eklenmelidir.

Anlık yapılan ve sadece çok ufak bir kullanıcı kitlesini kapsayan revizeler sistemin geneline zarar verebilir, verecektir de. Murphy amcanın dediklerini unutmamak lazım.

“Bir işin ters gitme olasılığı varsa o iş mutlaka ters gider.”

 


 

Süreçlerden bahsettik diğer bölümlerde; Yazılım süreçleri 2, Back office yazılımları, Neye göre veritabanı seçmeliyim ?, Minör majör revize sınıflandırması, Yazılımcı nerde tıkanır ? Yazılım güvenliğinde dikkat edilecek hususlar nelerdir ? gibi konulardan bahsedeceğim. Takipte kalın, değerli zamanlarınızı tecrübe yazılarıma ayırdığınız için teşekkürler.

 

Dipnot: Yanıldığımı düşündüğünüz veya bende bu şekilde yapıyorum dediğiniz kısımlarda lütfen yorumlardan paylaşın. 

 



Bu yazı 283 kez görüntülendi.


Bir Cevap Yazın