/ BAKANLIK MAKAMINA

Transkript

1 T.C. GÜMRÜK VE TİCARET BAKANLIĞI Sayı : Konu :Yazılım Geliştirme Standartları / BAKANLIK MAKAMINA Tüm profesyonel alanlarda olduğu gibi yazılım geliştirme süreçlerinde ortak bir dilin ve standartların kullanılması, ortaya çıkan ürünün yetkin her teknik personel tarafından yönetilebilir ve anında müdahale edilebilir olmasını sağlayan, ürünün ve uygulamaların kişiye bağımlılığını ve buna bağlı maliyetleri ortadan kaldıran, böylece geliştirme süreçlerinin ve genel anlamda tüm organizasyonun kurumsallaşmasında kilit rol oynayan faktörlerdendir. Bu çerçevede Bilgi İşlem Dairesi Başkanlığınca bilgi işlem hizmetlerinin kurumsallaştırılması hedefi doğrultusunda çeşitli standardizasyon çalışmaları yürütülmektedir. Yürütülen standardizasyon çalışmaları kapsamında; Bakanlığımız yazılım alım ve projelerinin daha etkin yürütülebilmesi, yazılım geliştirme süreçleri ve sonrasında kişilere bağımlılığın ortadan kaldırılması, geliştirme ve bakım süreçlerinde bir kalite standardının korunabilmesi amaçlarını gerçekleştirmek üzere Bakanlığımız bünyesinde veya Bakanlığımız hizmetleri için dış kaynak kullanımı yoluyla gerçekleştirilen geliştirme ve bakım süreçlerinde esas alınmak üzere Bilgi İşlem Dairesi Başkanlığınca Yazılım Geliştirme Standartları belirlenmiştir. Halen yürütülmekte olan geliştirme ve bakım süreçleri ile yeni başlatılacak tüm projelerde Yazılım Geliştirme Standartları belgesi içeriğinin esas alınarak hizmet yürütülmesi, Bakanlığımızca alıma konu edilecek tüm yazılım hizmetlerinde bahse konu standartların ön koşul olarak aranması ve teknolojik gereksinimler doğrultusunda belge üzerinde gerek görülen teknik değişikliklerin Bilgi İşlem Dairesi Başkanı tarafından güncellenmesinin uygun olacağı değerlendirilmektedir. Takdir ve tensiplerine arz ederim. Uygun Görüşle Arz ederim..../11/ 2013 İsmail YÜCEL Müsteşar Yardımcısı V. OLUR.../11/ 2013 Ziya ALTUNYALDIZ Bakan a. Müsteşar Volkan KAPLAN Bilgi İşlem Dairesi Başkanı

2 Yazılım Geliştirme Standartları 2 S a y f a

3 İçindekiler Giriş... 5 Amaç... 5 Kapsam... 5 Geliştirme Ortamı... 6 Programlama Dili... 6 Kütüphaneler... 6 Kaynak Kod Sunucusu... 6 Check-in/Check-out Politikası... 6 Sürüm Branşları... 6 Kaynak Kod Dizin Hiyerarşisi... 7 Sürekli Entegrasyon... 7 Testler... 8 Hata Takip ve Talep Yönetim Sistemi... 8 Proje Oluşturulması... 8 Proje Liderinin ve Üyelerinin Belirlenmesi... 8 Talep Oluşturulması... 8 Proje Versiyonlaması... 8 Bileşenlerin Oluşturulması... 8 Raporlama... 8 Veritabanı İsimlendirme Standartlar... 8 Tabloların İsimlendirilmesi... 8 Sütunların İsimlendirilmesi... 9 Yazım Formatı:... 9 İndekslerin İsimlendirilmesi... 9 Yazım Formatı:... 9 Tetikleyicilerin İsimlendirilmesi Yazım Formatı: Saklı Prosedürlerin İsimlendirilmesi (Stored Procedüres) Görüntülerin İsimlendirilmesi (Views) Dış Anahtarların İsimlendirilmesi(Foreign Keys) Değişkenler ve Parametrelerin İsimlendirilmesi (Variables, Parameters) Ortak Yazılım Standartlar Düzen Açıklamalar S a y f a

4 Tasarım Sınıf Tasarımı Arayüz Tasarımı Sınıf Üye Tasarımı Yazılım Versiyonlama Sürüm Numaraları Versiyon Günlüğü Bilgilendirme, Uyarı ve Hata Mesajları Mesaj Sözlüğü Hata Yönetimi Loglama Kritik Veri Yönetimi Programlama Diline Özgü Standartlar C# Standartları İsimlendirme Stil String Veri Türü && ve Operatörleri Yerel Değişken Tanımı Sabit ve Salt Okunur İfadeler Enum İfadeler Diziler New Operatörü Delegate ler Olaylar Statik Üyeler Hata Yönetimi Web Servisleri Dış Kurumlardan/Sistemlerden Alınan Servisler Dış Kurumlara/Sistemlere sunulan Servisler Alınan/Sunulan Servislerin Güvenlik Politikaları Analiz S a y f a

5 Giriş Amaç Bu dokümanın amacı bünyesinde geliştirilen/kullanılan yazılımların geliştirme ve kodlama süreçlerini bir standarda oturtarak tutarlı, sürdürülebilir bir yapıya sahip olmasını sağlamaktır. Yazılım kodlarının tutarlı bir kodlamaya sahip olması ile birlikte yazılım geliştiriciler görünüme değil içeriğe odaklanabilme şansına sahip olacaktır. Bu durum beraberinde yazılım geliştiricilerin ilk defa inceleyeceği kodlarda bile daha yüksek bir aitlik duygusuna sahip olarak koda daha hızlı müdahale edebilmesini sağlayacaktır. Aitlik duygusunun beraberinde getirdiği hızlı müdahale ve adaptasyon ise kaçınılmaz olarak bakım maliyetlerinde düşüş olarak kendini gösterecektir. Yazılım kodlamalarında belirli bir standardın takip edilmesiyle birlikte kodları inceleyen yazılım geliştiriciler önceden sahip oldukları deneyimlerden yola çıkarak inceledikleri kod parçacıkları hakkında öngörülerde bulunabilecek, kod parçacıklarını yabancılık çekmeden kendi uygulamalarında kullanabilecek, bakımları yapılabilecektir. Yazılım standartları, belirlenirken ilgili dile ait en iyi pratiklerin bir araya getirilmesi nedeniyle junior yazılım geliştiriciler için de önemli bir rehber olacaktır. Beraberinde, hataya daha kapalı bir yazılım geliştirme ortamı sunacaktır. Kapsam Bu doküman yazılım geliştirme sırasında kullanılmak üzere kaynak kod yönetimi, hata ve talep yönetimi, veritabanı, web hizmetleri, yazılım kodlama düzeni, açıklama, isimlendirme, programlama stili dokümantasyon konularını kapsamakta olup uygulamalar, bileşen kütüphaneleri, web hizmetleri, web uygulamaları ve zengin istemci uygulamalarına uygulanabilir. 5 S a y f a

6 Geliştirme Ortamı Bu başlık altında uygulama geliştirme ortamının ne şekilde olması gerektiği ve olmazsa olmaz bileşenleri hakkında bilgiler verilmektedir. Programlama Dili Managed dillerin tercih edildiği projelerde uygulama C# ile geliştirilmelidir. Versiyon ile ilgili bir kısıtın bulunmaması (istemci, işletim sistemi v.b.) durumunda güncel en son versiyon kullanılmalıdır. Bu, önceden tespit edilerek düzeltilmiş olan hataların/açıkların önüne geçilmesi ve gerektiğinde destek alabilmek adına önemlidir. Web uygulamaları geliştirilirken Asp.Net MVC kullanılmalıdır. Aynı C# versiyonunda olduğu gibi Asp.Net MVC nin de mümkün olan en son versiyonu kullanılmalıdır. Kütüphaneler Veri erişiminde Entity Framework kullanılmalıdır. Bu sayede gerektiği durumlarda hızlı destek alınabilmesi mümkün olacaktır. Performans, güvenlik, kullanım kolaylığı gibi nedenlerle her zaman için en son sürümün kullanılmasına özen gösterilmelidir. Projede içerisinde kullanılan birinci ve ikinci parti kütüphaneler kaynak kodlarıyla birlikte teslim edilmelidir. Performans, hızlı geliştirme, düşük bakım maliyeti, destek v.b. nedenlerle üçüncü parti ticari kütüphanelerin tercih edilmesi durumunda lisansları ve destek süreleri azami proje ömrünü kapsamalıdır. Kullanılan tüm harici kütüphanelerin lisanslarının projede kullanılmalarına engel teşkil etmediği teyit edilmelidir. Kaynak Kod Sunucusu Uygulama kaynak kodlarının geliştirme ve bakım süreçlerinde takip edilebilir ve yönetilebilir olabilmesi için bir kaynak kod sunucusunda tutulması gerekmektedir..net tabanlı yazılım dilleri ile geliştirilen projeler için kullanılacak olan ortam Team Foundation Server (TFS) 2013 veya üzeri olmalıdır. Check-in/Check-out Politikası Kaynak kod sunucuna gönderilen her bir kod ile ilgili olarak yapılan işleme dair kısa; fakat açıklayıcı bir mesaj girilmelidir. Bu sayede kod geçmişi incelendiğinde hangi adımda hangi işlemin yapıldığı bilgisine daha rahat ulaşılacaktır. Bu amaçla kaynak kod sunucusunda Changeset Comments Policy aktif olmalıdır. Karışıklığa izin verilmemesi adına, bir kaynak kodu üzerinde aynı anda sadece bir yazılım geliştiricinin çalışması gereklidir. Bu amaçla kaynak kod sunucusunda çoklu check-out a izin verilmemelidir. Sürüm Branşları Kaynak kod sunucusunda Main, Test ve Production ortamlarına ait kodlar tutulmalıdır. Bu ortamlardan; Main: Yazılım geliştiricilerin aktif olarak kod yazdıkları geliştirme ortamıdır. 6 S a y f a

7 Test: Yazılımın bir sonraki sürümüdür. Bu branştaki kod üzerinde aktif kod geliştirme yapılmaz. Test ekibi çalışmalarını bu branş üzerinde gerçekleştirir. Test ekibinin tespitleri/geri bildirimleri ile ilgili çalışmalar ilk olarak bu branş üzerinde gerçekleştirilir. Bu değişiklikler daha sonra Main branşa da yansıtılmalıdır. Production: Yazılımın aktif kullanımda olan sürümüdür. Bu branş üzerinde aktif kod geliştirme yapılmaz. Uygulama ile ilgili sahadan gelen ve acil düzeltilmesi gereken talepler öncelikle bu branş üzerinde yapılır. Bu değişiklikler daha sonra sırasıyla Test ve Main branşlarına yansıtılır. Her test döngüsü başlangıcında kaynak kod Main branşından Test branşına merge edilir. Aynı şekilde her üretim döngüsü başlangıcında kaynak kod Test branşından Production branşına merge edilir. Kaynak Kod Dizin Hiyerarşisi Uygulama Kaynak kodlarının bir kaynak kod sunucusunda bulunması kadar bu sunucuda belirli bir düzende tutulması da önemlidir. Ürünlerin geliştirme, test ve üretim ortamlarındaki durumlarını birebir tutabilmek adına kaynak kod sunucusunda her bir faza ait bir branş bulunmalıdır. Bu branşları her biri içerisinde Reference ve Source adıyla iki klasör yer almalıdır. Bu klasörlerden Reference klasörü projeler tarafından kullanılan 3.parti kütüphaneleri barındırırken, Source klasörü proje kaynak kodlarının yer aldığı klasördür. Projenin tek bir ana çözüm ve alt projeleri yerine birden farklı ve bağımsız çözümden oluşması durumunda her bir branş altında ilgili çözüm adıyla bir klasör ve bu klasörlerin altında Reference ve Source klasörleri yer almalıdır. Sürekli Entegrasyon Özellikle Çevik (Agile) metodolojilerde duymaya alışkın olduğumuz Sürekli Entegrasyon (Continuous Integration) yazılımın sürekli test (Birim/Entegrasyon/Fonksiyonel) edilerek olası hataların daha geliştirme aşamasında tespit edilerek düzeltilmesini amaçlamaktadır. Bu sayede geliştirilen yazılım her an bir kalite kontrolünden geçirilmiş olacaktır. Aşağıda, yazılımlar için olması gerekli minimum Sürekli Entegrasyon döngülerini bulabilirsiniz; Gated Check-in: Yazılım geliştiricinin her bir check-in işlemi sonrasında kaynak kod için işletilen sürekli entegrasyon sürecidir. Bu süreçte temel amaç kaynak kodun her daim derlenebilir durumda olmasıdır. Dolayısıyla da büyük kod tabanına sahip sistemlerde test ve kalite kontrol süreçleri göz ardı edilebilir. TFS gibi kullanılan kaynak kontrol sunucunun yeteneklerinin izin vermesi durumunda gated check-in lerde başarısız derlemelerde yapılan check-in kabul edilmeyerek ana kod tabanına dahil edilmemelidir. Gecelik Derleme: Gün içerisindeki derlemelerden farklı olarak her gün sonunda, önceden belirlenmiş bir saatte kaynak kodun derlenerek test ve kalite kontrollerinden geçirilmesi sürecidir. Gated Check-in den farklı olarak Günlük derlemelerde test ve kalite kontrol süreçleri olmazsa olmaz adımlardır. Tercihen her bir günlük derleme sonunda oluşan çalıştırılabilir kod paket olarak arşivlenmelidir. Yazılım geliştirme ekibi günlük derlemeleri takip ederek olası hataları bir sonraki iş gidererek yazılım kalitesinin her daim üst seviyede olmasını takip etmelidir. Sürüm Derlemesi: Her yeni sürüm (test, üretim v.b.) öncesi kaynak kodun derlenerek test ve kalite kontrollerinden geçirilmesi sürecidir. Gecelik derlemelerden farklı olarak Sürüm derlemeleri sunucuya atılabilir hazır paket çıktılarına sahip olmalıdır. 7 S a y f a

8 Testler Geliştirilen projelerde her bir modüle ait testler olmalıdır. Projeler için birim testler oluşturulmalıdır. Birim testleri %50 nin üzerinde bir kod kapsama oranına sahip olmalıdır. Hata Takip ve Talep Yönetim Sistemi Bu başlık altında, Uygulamalarına yönelik hata bildirimlerinin, değişiklik ve iyileştirme taleplerinin değerlendirildiği Talep Yönetim Sistemi(TYS) anlatılmaktadır. Kurum içi ve/veya dışında başlatılan tüm projeler Talep Yönetim Sisteminden takip edilmelidir. Proje Oluşturulması bünyesinde geliştirilen/kullanılan her bir yazılımlara ait taleplerin takip edilebilmesi için Talep Yönetim Sistemi altında proje oluşturulmalıdır. Bu projeler proje sahipleri tarafından talep edilmelidir. Proje Liderinin ve Üyelerinin Belirlenmesi Talep Yönetim Sistemine yeni bir proje açılırken proje sahipleri tarafından projeye liderlik yapacak kişi, geliştiriciler ve ilgili iş birimi üyelerinin atanması sağlanmalıdır. Talep Oluşturulması Projenin geliştirilmesi, sahada kullanımı sırasında oluşan hatalar, yeni istekler ve iyileştirme talepleri Talep Yönetim Sistemi üzerinden girilmelidir. Projenin türüne göre bu iş kalemleri proje liderleri, yazılım geliştiriciler, iş analistleri, test ekibi ya da iş birimi üyelerince oluşturulmalıdır. Proje Versiyonlaması Proje versiyonlarına ait iş kalemlerinin takip edilebilmesi adına yeni talep oluşturulması esnasında projenin versiyon bilgisi girilmelidir. Bileşenlerin Oluşturulması Proje bileşenlerine ait iş kalemlerinin takip edilebilmesi adına yeni talep oluşturulması esnasında projenin bileşen bilgisi girilmelidir. Raporlama Talep Yönetim Sistemin de aktif kullanılan projelerin aylık, günlük, haftalık, bileşen ve versiyonlama bazında raporlarının istenildiğinde Word veya Excel formatta alınabilmelidir. Veritabanı İsimlendirme Standartlar Tabloların İsimlendirilmesi Tablolar, herhangi bir varlığın anlık bilgilerini sunmaktadır. Örneğin, tüm hasta bilgilerini bir tabloda saklanmaktadır. Burada hasta bir varlık niteliğindedir ve hasta tablosunun tüm satırları hasta varlığının anlık bilgilerini sunmaktadır. Bu durumda, tabloyu, bilgilerini sunduğu varlığın ismi uyarınca adlandırmak gereklidir. Yazım Formatı: MODULKODU(3 karakter)_amacayonelikisim Örnek: ORN_HASTA 8 S a y f a

9 Amaca yönelik kelimeler arasında _ karakteri kullanılmayacaktır. Amaç Hastalar hakkında veri saklayan bir veritabanında, Muayene Kabul departmanı ile ilgili tabloların isimlendirilmesi Radyoloji departmanı ile ilgili tablolar İsimlendirme HAS_KABUL HAS_SEVK HAS_MUAYENE RAD_SIRA RAD_BIRIM RAD_RANDEVU Sütunların İsimlendirilmesi Sütunlar, belirli bir varlığın özelliklerini tanımlarlar. Bu nedenle, sütun isimlerinin anlamlı ve doğal olması gereklidir. Sütun isimlerinin başına simgeledikleri varlık isimleri, sonlarına da bu varlık isimlerinin türlerini belirten kısaltmalar eklenmelidir. Yazım Formatı: SUTUNBELIRLEYICIISIM (her hangi bir ayraç olmamalı) Amaç Satış tablosunun sütunlarının adlandırılması İsimlendirme SATICI NAKIT Sütun isimlendirmelerinde ilgili kurallara dikkat edilmelidir: Sütun isimleri özel amaçlı sözcüklerden (reserved words) oluşmamalıdır. Sütun isimlerinde sadece sayılar (0-9), harfler (a-z,a-z) kullanılmalıdır. Özel karakterler kullanılmamalıdır (ör: _ ). Sütun isimlerinin başına modül kodu ya da tablo ismi eklenmemelidir. İndekslerin İsimlendirilmesi İndeks, veritabanından istenilen verilerin mümkün olan en az disk erişimiyle performanslı bir şekilde getirilmesi amacıyla kullanılan veritabanı yapılarıdır. Yazım Formatı: TABLOADI_IDX<nn> Örnek: ORN_IDX01_SATIS <nn> sıralı olarak artan bir sayı dizisidir. İndeks için sütun isimleri yerine sıralı olarak artan nn formatında sayilar kullanılacaktir. 9 S a y f a

10 Amaç HAS_KAYIT tablosununa konulacak birinci indeksin isimlendirilmesi İsimlendirme HAS_IDX01_KAYIT Tetikleyicilerin İsimlendirilmesi Tetikleyiciler, ilişkisel veri tabanı yönetim sistemlerinde bir tabloda belirli olaylar meydana geldiği zaman yani ekleme, güncelleme, silme işlemlerinden biri gerçekleşmeden önce veya sonra çalışan ve belirli işlemleri kodlandığı şekilde yerine getiren prosedürel program parçacıklarıdır. Yazım Formatı: MODULKODU(3 karakter)_ TRG_AMACAYONELIKISIM_ISLEM(3 karakter) Örnek: ORN_TRG_UPD_SATIS Modul Kodundan hemen sonra trigger olduğunu belirten TRG kelimesi kullanılacaktır. Amaca yönelik kelimeler arasında _ karakteri kullanılmayacaktır. Tetikleyici yazım formatında ISLEM olarak belirtilen kelime yerine işlemin amacına göre: ekleme (insert) işlemleri için INS, silme (delete) işlemleri için DEL güncelleme (update) işlemleri için UPD kelimeleri kullanılacaktır. Amaç Hasta tablosundaki insert, update ve delete tetikleyicilerin adlandırılması Hem insert hem de update için tek bir Tetikleyici kullanılıyor olması durumunda İsimlendirme HAS_TRG_INS_HASTAKAYIT HAS_TRG_UPD_HASTAKAYIT HAS_ TRG_DEL_HASTAKAYIT HAS_TRG_INS_UPD_HASTAKAYIT Saklı Prosedürlerin İsimlendirilmesi (Stored Procedüres) Saklı prosedürler, iyi tanımlanmış ve spesifik görev üstlenirler ve eylem/hareket odaklıdırlar. Bu nedenle, isimlerinin üstlendikleri görevleri ifade ediyor olması gereklidir. Yazım Formatı: MODULKODU(3 karakter)_sp_islem(3 karakter)_amacayonelikisimler SP_AMACAYONELIKISIMLER (Prosedürlerde kullanılan alt prosedürlerin isimlendirilmesinde) 10 S a y f a

11 Örnek: ORN_SP_SEL_HASTA Modul Kodundan hemen sonra stored procedure olduğunu belirten SP kelimesi kullanılacaktır. Amaca yönelik kelimeler arasında _ karakteri kullanılmayacaktır. Prosedür yazım formatında ISLEM olarak belirtilen kelime yerine SP nin içerisinde yapılmak istenen temel amaca göre Ekleme (insert) işlemleri için INS, Silme (delete) işlemleri için DEL Güncelleme (update) işlemleri için UPD Sorgulama (select) işlemleri için SEL Zamanlanmış (scheduled) işlemler için BAT kelimeleri kullanılacaktır. Bazı durumlarda SP ler hem select hem insert hem de update işlemlerini içerebilirler. Bu durumda SP ile sonuçta yapılmak istenen ana işlem hangisi ise ona uygun işlem kelimesi kullanılması gerekmektedir. Amaç Hasta Tablosunda, belirli bir sicil numarası ile hasta bilgilerini sorgulayan saklı prosedürün isimlendirilmesi Hasta Tablosunda, Hasta bilgilerini güncelleyen prosedürün isimlendirilmesi Hasta Tablosuna, yeni Hasta bilgileri ekleyen prosedürün isimlendirilmesi Batch işlemler için uygulanacak isimlendirme İsimlendirme HAS_SP_SEL_HASTADETAYI HAS_SP_UPD_HASTABILGI HAS_SP_INS_HASTALBILGI HAS_SP_BAT_HASTABILGI Görüntülerin İsimlendirilmesi (Views) Herhangi bir andaki görünüm, o an programa erişen uygulama için oluşturulan bir tablodan ibarettir. Bu nedenle tablo isimlendirme kuralları görüntü tabloları için de geçerlidir. Yazım Formatı: MODULKODU(3 karakter)_v_amacayonelikisim Örnek: ORN_V_HASTA Yazımdaki formatındaki V harfi View i belirtmek için kullanılacaktır. Amaca yönelik kelimeler arasında _ karakteri kullanılmayacaktır. 11 S a y f a

12 Amaç Hasta Tablosunda Hasta ve Adres tablolarını birleştiren bir görünümün adlandırılması İsimlendirme HAS_V_HASTAADRES Genel amaçlı görünümler için GEN_V_HASTAADRES Dış Anahtarların İsimlendirilmesi(Foreign Keys) Dış Anahtar, veritabanındaki diğer veri tablolarıyla ilişki kurmaya yarayan bir anahtardır. Tabloları birleştirmek için de kullanılır. Bu anahtar, irtibat kurulan veri tablolarının bir tanesinin de ana anahtarıdır. Yazım Formatı: MODULKODU(3 karakter)_fk_ AMACAYONELIKISIM Örnek: ORN_FK_HASTAAKRABA Dış anahtar isimlendirme kuralı olarak, Modul Kodundan hemen sonra _FK eklenmelidir. Amaca yönelik kelimeler arasında _ karakteri kullanılmayacaktır. Değişkenler ve Parametrelerin İsimlendirilmesi (Variables, Parameters) Veritabanı nesnelerinin parametre isimleri p_ ile, nesne içinde sütun adını saklamayan değişkenler ise v_ öneki ile başlatılmalıdır. Yazım Formatı: p_parametreismi v_degiskenismi Örnek: p_hastakod V_HastaAd Veritabanı nesnelerine giren parametreler nesne içerisinde nesne_ismi.parametre_ismi şeklinde kullanılmamalıdır. Veritabanı nesnelerinde tanımlanan değişkenler nesne içerisinde nesne_ismi.degisken_ismi şeklinde kullanılmamalıdır. Veritabanı nesnelerinde tanımlanan parametre ve değişken isimleri, nesne içerisinde kullanılan tabloların alanlarıyla aynı ismi taşımamalıdır. 12 S a y f a

13 Önceden tanımlanmış ancak mevcut durumda kullanılmayan değişkenler veritabanı nesneleri içerisinden silinmelidir. Ortak Yazılım Standartlar Bu başlık altında bünyesinde geliştirilen/kullanılan yazılımlarda kullanılacak ve herhangi bir programlama dilinden bağımsız olan standartlara yer verilmektedir. Dokümanın devamı incelenirken her daim akılda tutulması gereken altın kuralları aşağıda bulabilirsiniz; Kod mümkün olduğunca basit ve okunaklı olmalıdır. Karmaşık sınıf yapılarından ziyade basit, anlaşılır sınıf yapıları tercih edilmelidir. Basit; ama işi çözen mimarilerin her zaman için daha düşük bakım maliyetlerine sahip olduğu unutulmamalıdır. Her bir sınıf, struct, arayüz, enum kendine ait ayrı bir dosya içerisinde yer almalıdır. Bu duruma tek istisna iç içe sınıflardır. Uygulama içerisinde kullanılan sihirli değerler asla kod arasında tutulmamalıdır. Bunun yerine sabit, salt-okunur ya da enum şeklinde ve yapılandırma ya da kaynak dosyaları içerisinde tutulmalıdır. Uygulama geliştirme sırasında kullanılan ve son kullanıcı tarafında asla görülmemesi gereken değerler/ifadeler için asla arayüz bileşenleri (örneğin mesaj kutucuları) kullanılmamalıdır. Bunun yerine debug verisini takip edebilmek için izleme ve loglama yapıları kullanılmalıdır. Geliştirilen uygulamalarda mutlaka ticari ya da topluluklarca kabul edilmiş izleme ve/veya loglama kütüphaneleri kullanılmalıdır. Bu kütüphanelere Log4j, Log4Net ya da Common.Logging örnek olarak verilebilir. Fonksiyonlar sadece bir işi yerine getirmek için yazılmalıdır. Bir fonksiyon içerisinde aynı anda birden çok işin gerçekleştirilmesinden kaçınılmalıdır. Alt iş kalemleri her zaman için ayrı fonksiyonlara taşınmalıdır. Fonksiyonlar içerisinde basit atama işleri bir kenara bırakıldığında çok uzun kodlar yer almamalıdır. Bir önceki madde ile birleştirildiğinde bu durum kodun karmaşıklığına işaret etmektedir. Harici kaynaklarda (dosya, web servis, kullanıcı girdileri v.b.) sisteme kabul edilen her türlü bilgi öncelikle uygulama iş mantıklarında doğrulanmalıdır. Düzen Kodlamadaki düzen geliştirilen uygulama kodlarının daha rahat okunabilmesi adına önemlidir. Bu nedenle bünyesinde geliştirilen/kullanılan yazılımlarda aşağıdaki düzen standartlarına uyulması beklenmektedir; Her bir satıra sadece bir ifade yazılmalıdır. Her bir satıra sadece bir tanımlama yazılmalıdır. Fonksiyon tanımları ile özellik tanımları arasında en az bir satır boşluk bırakılmalıdır. if, while, try-catch v.b. dil yapılarında kullanılan programlama dili izin verse bile kod bloğu belirteçleri olmadan kod yazılmamalıdır. Tek satır bile olsa bu ifadelerde ilgili programlama dilinde tanımlı kodlama bloğu kullanılmalıdır. 13 S a y f a

14 if (deger1 <= 0) { Console.WriteLine("Sıfırdan büyük değer girilmelidir"); İfadelerin daha net olmasını sağlamak adına parantezler kullanılmalıdır. if ((deger1 < 5) && (deger2 >= 7)) { // İş mantığı kodları. Açıklamalar Yazılım kodlamalarının sade olması birincil hedefler arasın yer alması gerekse de bazı durumlarda yazılan kodun anlaşılabilmesi için ek açıklamalara ihtiyaç duyulacaktır. Bu nedenle T.C. Gümrük ve Ticaret Bakanlığı bünyesinde geliştirilen/kullanılan yazılımlarda aşağıdaki açıklama standartlarına uyulması beklenmektedir; Tüm açıklama blokları Türkçe ve kolay anlaşılabilir olmalıdır Yazılan açıklamalar ilgili kod bloğu satır sonuna yazılmamalıdır. Açıklamalar ayrı bir satırda olmalıdır Açıklama cümleleri her zaman için büyük harf ile başlamalıdır Açıklama cümleleri her zaman nokta ile sonlanmalıdır Kodu inceleyenin dikkatini dağıtmamak adına, açıklamaların etrafı * v.b. karakterler ile süslenmemelidir İlgili dilin açıklama blok karakterlerinden sonra bir boşluk bırakılmalıdır // Kullanıcı tarafından girilen değerin sıfırdan büyük // olması durumunda kullanıcıyı uyar. Kod içerisinde yer alan her bir sınıf ve fonksiyon için ilgili açıklama blokları içerisinde kullanım ve amaç belirtilmelidir Fonksiyonların hemen üzerinde yer alan açıklama bloğunda özet açıklama, her bir parametreye ait açıklama, varsa geri dönüş değeri açıklaması yer almalıdır. Bunlara ek olarak; alınması olası hatalar ve fonksiyonun kullanımı ile ilgili dikkat edilmesi gereken noktalar belirtilmelidir. Açıklama bloğunda kullanım örnekleri de verilebilir. Tasarım Bu başlık altında sınıf, arayüz v.b. temel programlama yapı taşlarının tasarımları sırasında dikkat edilmesi gerekli noktalar verilmektedir. Sınıf Tasarımı Her bir sınıfın sadece bir amacı olmalıdır. Bir sınıf ya personel, araç v.b. tek bir domain nesnesini temsil etmelidir ya da tek bir atomik iş mantığını. Bir sınıfa birden fazla anlam yüklenmemelidir. Bir sınıfın kullanıma hazır olabilmesi için constructer yeterli olmalıdır. Sınıfı işlevini yerine getirmesi için ihtiyacı olan parametrelerin constructer dan geçilmesi yeterli olacaktır. Bir sınıfın constructer ı 3 ya da 4 parametreden fazlasını istiyorsa sınıfa birden fazla sorumluluk verilmiş olabilir. Böylesi bir durumda sınıf tasarımı gözden geçirilmelidir. Kalıtılan sınıfın üye fonksiyonlarını new anahtar kelimesi ile saklanmamalıdır. Bu durumun nesne-tabanlı programlamanın önemli bir prensibi olan polymorphism i ihlal ettiği asla unutulmamalıdır. 14 S a y f a

15 Tüm sınıflar aksi gerekmediği sürece internal olarak tanımlanmalıdır. Arayüz Tasarımı Her bir arayüzün sadece bir amacı olmalıdır. Bir arayüz ya bir domain yapısını temsil etmelidir ya da tek bir atomik iş mantığını. Arayüzler olabildiğince küçük ve amaca uygun tasarlanmalıdır. Her zaman için temel sınıfların kullanımı yerine arayüz kullanımı tercih edilmelidir. Pek çok modern dilin çoklu kalıtıma izin vermediğini unutulmamalıdır. Yazılım geliştiriciyi kısıtlamak için özel bir amaç yok ise işlevselliğin tanımlanması için mümkün olduğunca arayüzler tercih edilmelidir. Tüm arayüzler aksi gerekmediği sürece internal olarak tanımlanmalıdır. Sınıf Üye Tasarımı Üye nin her çağrımında yeni bir değer alındığı durumlarda özellik yerine fonksiyon kullanılmalıdır. Bu duruma en güzel örnek Guid sınıfı NewGuid fonksiyonudur. Bu fonksiyon her çağırıldığında farklı bir değer dönmektedir. Dolayısıyla özellikle olarak tanımlanmamalıdır. Bir fonksiyon sadece tek bir sorumluluğa sahip olmalıdır. Birden fazla iş aynı anda bir fonksiyon içerisinde yapılmamalıdır. Bir fonksiyondan küme dönmek için array, list v.b. yapılar doğrudan tercih edilmemelidir. Bu veri türlerinin fonksiyonun çağırıldığı noktalarda değiştirilebileceği göz önüne alınmalıdır. Örneğin C# ile geliştirilen uygulamalarda küme değerler için IEnumerable<T>, ICollection<T>, IReadOnlyCollection<T>, IReadOnlyList<T> ya da IReadOnlyDictionary<TKey, TValue> tercih edilmelidir. String ya da bir küme dönen fonksiyonlar hiçbir zaman null (boş) değer dönmemelidir. Pek çok senaryoda boş değerin fonksiyonun kullanan yazılım geliştirici tarafından beklenmediği ve hatalara sebep olabileceği göz önüne alınmalıdır. Tüm sınıf üyeleri aksi gerekmediği sürece private olarak tanımlanmalıdırlar. Yazılım Versiyonlama bünyesinde geliştirilen/kullanılan yazılımlarda değişikliğin takip edilebilmesi ve yönetilebilmesi adına yazılımların versiyonlanması önemlidir. Bu başlık altında yazılım versiyonlamada dikkat edilmesi gerekli noktalar bulunmaktadır. Sürüm Numaraları Geliştirilen yazılımların her bir sürümü tekil sürüm numaralarına sahip olmalıdır. Bir uygulamanın yeni sürümü her zaman için bir önceki sürümden daha üst sürüm numarasına sahip olmalıdır. Sürüm numaraları x.y.z.w formatında verilmelidir. Buradaki ifadelerden; X: Major sürümü belirtmektedir. Major sürüm numarası ancak projedeki önemli değişiklikler sonrasında artmalıdır. Projelerde yaşanabilecek önemli değişikliklere mimari değişiklikler, programlama dili değişikliği, veritabanı değişikliği ve teknolojik değişiklikler örnek verilebilir. Y: Minor sürümü belirtmektedir. Minor sürüm numarası yazılımın modüllerindeki değişlikler, iş biriminden gelen taleplerin gruplanması ve benzeri sebeplerle değişebileceği gibi çevik metodolojilerde kullanılan sprint leri de belirtebilir. Z: Derleme numarasını belirtmektedir. Projenin derleme sunucusu üzerinden gerçekleştirilen günlük derleme sırasını belirtmektedir. Aynı kaynak kodunun farklı yapılandırma ile aynı 15 S a y f a

16 anda birden fazla derlemeye sahip olabileceği düşünüldüğünde derleme numarası bilgisi hangi yapılandırma ile derleme yapıldığını da belirtecektir. W: Değişiklik seti id sini belirtmektedir. Sürümün derlendiği kaynak kodun en güncel değişiklik seti (changeset) id sidir. Bu bilgi sayesinde çalışabilir kod ile kaynak kod eşleştirmesi yapılmış olacaktır. Yukarıda sıralı bilgilerden yola çıkılarak aktif kullanılan uygulamanın hangi majör ve minör versiyona ait olduğu bilgisi yanında hangi derleme sonunda üretildiği, kaynak kodun hangi haliyle üretildiği gibi önemli bilgilere ulaşılabilir. Versiyon Günlüğü Geliştirilen yazılımların takip edilebilirliği açısından versiyonlama önemlidir. Yazılımın her bir versiyonunun yayınlanması sırasında bu yeni versiyon ile birlikte gelen yenilik, iyileştirme ve diğer değişikliklerin iletilmesi gerekmektedir. Bu amaçla, her bir yazılım sürümünde bu değişikliklere ait hata takip ve/veya talep yönetim tekil id bilgisini de içeren bir versiyon günlüğü yayınlanmalıdır. Bilgilendirme, Uyarı ve Hata Mesajları Geliştirilen yazılımların maliyetleri incelendiğinde bakım sürecindeki yazılımlardaki en önemli maliyet kalemlerinden birisinin de kullanıcılardan gelen bilgilendirme ve hata taleplerinin yönetilmesi olduğu görülecektir. Bu maliyetin düşürülmesinin en temel yollarından birisi de taleplerin yazılım geliştirme ekibinin önüne gelmeden yönetilerek çözülebilmesidir. Bu amaçla; T.C. Gümrük ve Ticaret Bakanlığı bünyesinde geliştirilen/kullanılan yazılımlarda son kullanıcıya gösterilen bilgilendirme, uyarı, hata v.b. mesajlar Türkçe, kolay anlaşılır ve çözüme yönlenlendirici olmalı, mesajlar sınıflandırılarak her birine tekil bir kod atanmalıdır. İlgili mesaj ile birlikte mesaja ait bu tekil kodda son kullanıcıya gösterilmelidir. Bu kodlar ilgili mesajlarla birlikte dokümante edilmelidir. Bu tekil kod yardımıyla uygulama ile ilgili bir bildirimde bulunan son kullanıcının derdiği daha hızlı ve kolay biçimde anlatması sağlanacaktır. Mesaj Sözlüğü bünyesinde geliştirilen/kullanılan yazılımlarla birlikte bir mesaj sözlüğü sunulmalıdır. Bu sözlük içerisinde yukarıda bahsedilen ve uygulama içerisinde yer alan tüm bilgilendirme, uyarı, hata v.b. mesajlar ile bu mesajlara ait tekil kodlar yer almalıdır. Buna ek olarak; bu mesaja ilişkin son kullanıcının yönlendirilmesi / sorunun çözülmesi adına takip edilmesi gerekli adımlar detaylı olarak yer almalıdır. Hata Yönetimi Uygulamaların sağlıklı çalışmasının olmazsa olmaz bir parçası olan hata yönetimine önem verilmelidir. Hata yönetiminin maliyetinin yüksek olduğu göz önüne alınarak kesinlikle iş mantığının bir parçası olarak kullanılmamalıdır. İş mantığına / sürece ilişkin tüm bilgilendirmeler fonksiyon geri dönüşü olarak yapılmalıdır. Uygulamanın kullanımı sırasında oluşan hataların yönetilmesi amacıyla takip, müdahale ve düzeltme sistemleri kullanılarak mümkün olduğunca insan müdahalesine ihtiyaç duymayan otonom hata yönetim sistemleri kurulmalıdır. Loglama Geliştirilen uygulamalarda ticari ya da topluluklarca kabul edilmiş izleme ve/veya loglama kütüphaneleri kullanılmalıdır. Bu kütüphanelere Log4j, Log4Net ya da Common.Logging örnek olarak verilebilir. 16 S a y f a