Yazılım Geliştirme Standartları

T.C. GÜMRÜK VE TİCARET BAKANLIĞI Bilgi İşlem Dairesi Başkanlığı Sayı :63499644.609 Konu :Yazılım Geliştirme Standartları 09.12.2013 / 02401 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. Volkan KAPLAN Bilgi İşlem Dairesi Başkanı 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 T.C. Gümrük ve Ticaret Bakanlığı Bilgi İşlem Dairesi Başkanlığı Yazılım Geliştirme Standartları İç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 10 Yazım Formatı: 10 Saklı Prosedürlerin İsimlendirilmesi (Stored Procedüres) 10 Görüntülerin İsimlendirilmesi (Views) 11 Dış Anahtarların İsimlendirilmesi(Foreign Keys) 12 Değişkenler ve Parametrelerin İsimlendirilmesi (Variables, Parameters) 12 Ortak Yazılım Standartlar 13 Düzen. 14 Açıklamalar 14 Tasarım.. 15 Sınıf Tasarımı 15 Arayüz Tasarımı 15 Sınıf Üye Tasarımı 15 Yazılım Versiyonlama. 16 Sürüm Numaraları 16 Versiyon Günlüğü. 16 Bilgilendirme, Uyarı ve Hata Mesajları 16 Mesaj Sözlüğü. 17 Hata Yönetimi 17 Loglama. 17 Kritik Veri Yönetimi 17 Programlama Diline Özgü Standartlar 17 C# Standartları 18 İsimlendirme. 18 Stil 20 String Veri Türü. 21 && ve || Operatörleri 21 Yerel Değişken Tanımı 21 Sabit ve Salt Okunur İfadeler 22 Enum İfadeler 22 Diziler 22 New Operatörü. 22 Delegate'ler 23 Olaylar 23 Statik Üyeler 23 Hata Yönetimi 23 Web Servisleri 24 Dış Kurumlardan/Sistemlerden Alınan Servisler 24 Dış Kurumlara/Sistemlere sunulan Servisler 24 Alınan/Sunulan Servislerin Güvenlik Politikaları 24 Analiz. 24 Giriş Amaç Bu dokümanın amacı T.C. Gümrük ve Ticaret Bakanlığı 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. 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. · 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. 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, T.C. Gümrük ve Ticaret Bakanlığı 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ı T.C. Gümrük ve Ticaret Bakanlığı 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 Amaca yönelik kelimeler arasında "_" karakteri kullanılmayacaktır. Amaç İsimlendirme Hastalar hakkında veri saklayan bir veritabanında, Muayene Kabul departmanı ile ilgili tabloların isimlendirilmesi HAS_KABUL HAS_SEVK HAS_MUAYENE Radyoloji departmanı ile ilgili tablolar 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ç İsimlendirme Satış tablosunun sütunlarının adlandırılması 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. Amaç İsimlendirme HAS_KAYIT tablosununa konulacak birinci indeksin isimlendirilmesi 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ç İsimlendirme Hasta tablosundaki insert, update ve delete tetikleyicilerin adlandırılması HAS_TRG_INS_HASTAKAYIT HAS_TRG_UPD_HASTAKAYIT HAS_ TRG_DEL_HASTAKAYIT Hem insert hem de update için tek bir Tetikleyici kullanılıyor olması durumunda 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) Ö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ç İsimlendirme Hasta Tablosunda, belirli bir sicil numarası ile hasta bilgilerini sorgulayan saklı prosedürün isimlendirilmesi HAS_SP_SEL_HASTADETAYI Hasta Tablosunda, Hasta bilgilerini güncelleyen prosedürün isimlendirilmesi HAS_SP_UPD_HASTABILGI Hasta Tablosuna, yeni Hasta bilgileri ekleyen prosedürün isimlendirilmesi HAS_SP_INS_HASTALBILGI Batch işlemler için uygulanacak isimlendirme 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. Amaç İsimlendirme Hasta Tablosunda "Hasta" ve "Adres" tablolarını birleştiren bir görünümün adlandırılması 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. Ö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 T.C. Gümrük ve Ticaret Bakanlığı 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 T.C. Gümrük ve Ticaret Bakanlığı 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. 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. · 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 T.C. Gümrük ve Ticaret Bakanlığı 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ı 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üğü T.C. Gümrük ve Ticaret Bakanlığı 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. Loglaması yapılan verinin içeriği ve kritikliğine göre hata ayıklama, uyarı, hata, kritik v.b. farklı seviyelerde loglama yapılmalıdır. Loglama işlemi, verinin kritikliğine göre, fonksiyonlara geçilen parametreler seviyesinde de olabilir. Özellikle hata loglamalarında iş kritik değişkenlerin de loglandığından emin olunmalıdır. Ayrıca loglamalarda zaman damgası, loglamanın yapıldığı sınıf/fonksiyon, log girdisine özgü tekil bir id, loglama seviyesi gibi bilgiler yer almalıdır. Loglama uygulama içerisinde ya da yapılandırma dosyasında yer alan bir anahtar üzerinden yapılandırılabilir olmalı. Loglama performans kaybına yol açmamak adına gerektiğinde modül, sınıf ve/veya fonksiyon bazında kapatılabilmelidir. Veritabanı şifresi, kullanıcı şifresi v.b. kritik veri kesinlikle loglanmamalıdır. Kritik Veri Yönetimi Uygulama içerisinde yer alan ve kritik önem arz eden tüm veri şifrelenmiş olarak saklanmalıdır. Yine kullanıcı şifresi v.b. verilerin saklanmasında tek yönlü şifreleme algoritmaları kullanılmalıdır. Loglama başlığı altında da değinildiği üzere kritik veri loglanmamalıdır. Programlama Diline Özgü Standartlar Bu başlık altında, genel kabul görmüş modern programlama dillerine özgü olarak en iyi deneyimlerin bir araya getirilmesi ile ortaya çıkmış olan standartlar programlama dili bazında gruplanarak paylaşılmıştır. C# Standartları Bu başlık altında yer verilen C# standartları diğer programlama dillerinde de kullanılabilir olmalarına karşın yer verilen kod örnekleri ve veri yapıları C# diline özgüdür. Bu standartlar C# topluluklarınca genel kabul görmüş olup bir başka programlama dili ile geliştirilen uygulamalarda kullanımı beklenmemektedir. İsimlendirme İsimlendirme standardı uygulama kodlarının anlaşılmasındaki en önemli noktalardan birisidir ve katı kurallara tabidir. Aşağıda daha detaylı bilgi bulabileceğiniz isimlendirme standartları ile ilgili en önemli noktalardan birisi sadece İngilizce karakterlerin kullanılabileceğidir. Kullanıcı yerine Kullanici, Gümrük yerine Gumruk kullanılmalıdır. Bunun yanında, herhangi bir programlama dilinde anahtar kelime olabilecek kelimelerin seçilmesinden özellikle kaçınılmalıdır. İsimlendirme de üç genel kabul görmüş yöntem kullanılmaktadır; Pascal, Camel, Upper case. · Pascal case'de tanımlayıcının ilk harfi ile takip eden her bir kelimenin ilk harfi büyük harftir. Bu stil sınıf kütüphanesindeki tüm public tanımlayıcılar için geçerlidir. · Camel case'de tanımlayıcının ilk harfi küçük iken takip eden her bir kelimenin ilk harfi büyük harftir. Bu stil sınıf kütüphanesindeki tüm private ve protected tanımlayıcılar, fonksiyon parametreleri ve yerel değişkenler için geçerlidir. · Upper case ise 4 ya da daha az harften oluşan kısaltmalar için geçerlidir. Bu yöntemlerden hangisinin ne zaman kullanılacağına dair tabloyu aşağıda bulabilirsiniz; Tanımlayıcı Türü Kullanılacak Stil Örnek Kısaltmalar Upper ID, REF İsim Uzayları Pascal Gov.GTB.EIhale Sınıflar ve Struct'lar Pascal OrnekSinif Sabitler ve Enum'lar Pascal KullaniciRolleri Arayüzler Pascal IKullaniciDeposu Enum Değerleri Pascal KullaniciRoller.SistemYoneticisi Özellikler Pascal ArkaplanRengi Değişkenler ve Öznitelikler Pascal (public) Camel (private, protected, yerel) PencereBoyutu pencereGenisligi pencereYuksekligi Fonksiyonlar Pascal (public, private, protected) ToString() Filtrele(string filtreIfadesi) Yerel Değişkenler Camel kayitSayisi İsim Uzayları İsim uzayları yazılım katmanları ile bu katmanlar içerisindeki bileşenlerin ve alt sistemlerin mantıksal olarak gruplanmasında kullanılmaktadır. T.C. Gümrük ve Ticaret Bakanlığı bünyesinde geliştirilen/kullanılan yazılımların isim uzayları Gov.GTB ile başlamalıdır. Devamında ise ilgili proje adı kullanılmalıdır. İsim uzayı için kullanılması gereken şablon: Gov.GTB.ProjeAdi.PaketAdi.AltSistemAdi Bu şablonda Gov.GTB ön eki sabit değer iken, AltSistemAdi seçimlidir. Örneğin; Gov.GTB.EIhale.Domain Gov.GTB.EIhale.Domain.Varliklar Proje ve paket seviyesindeki isim uzayları her bir projenin mimari tasarım aşamasında belirlenmelidir. Alt sistem isimlendirmelerinde Pascal case kullanılmalıdır. Sınıflar ve Yapılar Sınıflar ve yapılar doğaları gereği sistemin yapılarını tanımlamaktadırlar. Dolayısıyla da bir ad/isim ile temsil edilmelidirler. İsimlendirmede Pascal case tercih edilmelidir. Öznitelik (Attribute), Kontroller (Controller) v.b. yapılar dışında bir son ek almamalıdırlar. İsimlendirmelerinde fiil ifadeler kullanılmamalıdır. Duyuru, Personel, Kullanici, Rol v.b. örneklerde olduğu gibi ad/isim kullanılmalıdır. Arayüzler Arayüzler, kalıtan sınıfların uymak zorunda oldukları kontratları temsil etmektedir. İsimlendirmelerinde tanımlandıkları işi temsil eden net isim, isim tümceleri ve/veya sıfatlar kullanılmalıdır. Arayüz isimlendirmeleri I harfi ile başlamalıdır. Örneğin; IBilesen IVergilendirilebilirUrun Olaylar Olaylar, doğaları gereği bir durum değişikliğini bildirmeleri nedeniyle isimlendirmelerinde fiil kullanılmalıdır. Enum'lar Enum değerler doğaları gereği bir değer kümesini temsil etmektedir. Öte yandan kod içerisindeki pek çok kullanımda değer kümesinin aynı anda sadece bir elemanı için işlem yapılmaktadır. Buna en güzel örnek if kontrolleridir. Bu kullanım göz önüne alınarak enum değer kümeleri isimlendirilirken tekil isimlendirme kullanılmalıdır. Örneğin; KullaniciTipleri TarayiciTipleri Yerine; KullaniciTipi TarayiciTipi Tercih edilmelidir. Stil Segme ve Girdiler Farklı editörlerde farklı şekilde yorumlanması nedeniyle segme (tab) karakteri kod içerisinde kullanılmamalıdır. Kod içerisindeki tüm girdiler 4 adet boşluk karakteri ile yapılmalıdır. Parantez Süslü parantezler her zaman için ilgili kod bloğunun sonunda ve blok ifadesinin bitimini takip eden bir boşluktan sonra başlamalıdır. Kapatan parantez her zaman için ayrı bir satırda ve açılan kod bloğu ile aynı hizada yer almalıdır. Kod bloğunun içeriği 4 adet boşluk ile içeri doğru girdi oluşturmalıdır. public class OrnekSinif { // İş Mantığı. } Kod bloğu tek bir satırdan bile oluşsa bloğu belirten süslü parantezler kullanılmalıdır. Bu hem kodun okunurluğunu arttıracak, hem de yeni satırların eklenmesi durumunda blok parantezlerinin unutulması riskini ortadan kaldıracaktır. Tek satırdan oluşan bloklarda bloğu belirten süslü parantezler aynı satırda olabilir. private int birOzellik; public int BirOzellik { get { return birOzellik; } set { birOzellik = value; } } if (deger==null) { return; } Boşluk Okunurluğu artması için kod içerisindeki boşluklar önemlidir. Aşağıda boşluklar hakkında dikkat edilmesi gereken noktaları bulabilirsiniz; · Kod bloklarının belirtilmesi için konulan girdiler 4 adet boşluktan oluşmalıdır. · Fonksiyonların her bir parametreleri arasına 1 adet boşluk bırakılmalıdır. KonsolaLogla(LoglamaSeviyesi.DEBUG, "Loglama Mesajı", hataNesnesi); · Fonksiyon çağrımında parantezler ile parametreler arasında boşluk bırakılmamalıdır. · Fonksiyon adı ile parantezler arasına boşluk bırakılmamalıdır. OrnekFonksiyon(); · if, while v.b. akış kontrol cümleciklerinde kontrol ifadelerinde 1 adet boşluk bırakılmalıdır. if (deger1 == deger2) { // İş Mantığı. } Yeni Satır Okunurluğun artması adına else, catch ve finnaly blokları yeni satırdan başlatılmalıdır. try { // İş Mantığı. } catch (Exception e) { // Hata Yönetimi. } finally { // İş Mantığı. } Linq sorgusundaki her bir ifade yeni satırda olmalıdır. var uyeListesi = from oda in odalar from uye in oda.Uyeler orderby uye.Adi descending select new { oda.OdaAdi, uye.Adi, uye.ID }; Sınıf içerisinde yer alan her bir fonksiyon arasında bir satır boşluk olmalıdır. String Veri Türü String veri türü ile ilgili sıklıkla yapılan işlerden birisi birden fazla string ifadenin bir araya getirilmesidir. Programlama dilleri incelendiğinde en fazla performans kaybının string işlemlerinde yaşandığı da göz önüne alındığında string birleştirme işlemlerinde StringBuilder kullanılması gerektiği aşikardır. Buradaki tek kısıt yapılacak birleştirme işleminin yoğunluğudur; · Az sayıdaki string ifadenin birleştirilmesi gerektiği durumlarda + operatörü kullanılmalıdır · Yoğun string birleştirmesi gerektiği (örneğin döngü içerisinde) durumlarda performans kazanabilmek adına StringBuilder kullanılmalıdır. && ve || Operatörleri Karşılaştırmalarda hatalı kullanımları azaltmak ve performans kazanabilmek adına & operatörü yerine &&, | operatörü yerine || operatörü kullanılmalıdır. Yerel Değişken Tanımı Yerel değişkenlerin kullanımlarına özen gösterilmelidir. Kod içerisinde kullanılmayan bir değişken yer almamalıdır. Yerel değişkenlere sadece bir anlam yüklenmelidir, birden farklı amaç için kullanılmamalıdır. Yerel değişken tanımlamaları sırasında değişken türünün eşitliğin sağ tarafında yer alan ifadeden rahatlıkla anlaşıldığı ya da türün kesinliğinin gerekmediği durumlarda üstü kapalı ilklendirme formatı kullanılmalıdır. var ornek1 = "Örnek bir string ifade"; var ornek2 = 33; var ornek3 = Convert.ToInt32(Console.ReadLine()); dynamic yerine var kullanılmamalıdır. for ve foreach gibi döngülerin değişken tanımlamalarında üstü kapalı ilklendirme formatı kullanılmalıdır. for (var i = 0; i < 100; i++) { // İş mantığı. } int[] degerKumesi = { 1, 2, 3, 5 }; foreach (var deger in degerKumesi) { // İş Mantığı. } Sabit ve Salt Okunur İfadeler Sınıf içerisinde ilklendirmesi ardından değeri hiçbir zaman değişmeyecek olan ifadeler sabit olarak atanmalıdır. Bu ifadelerin değerlerinin constructer'larda (örneğin; dışarıdan kabul edilen değerler ile) ilklendirilmeleri söz konusu ise salt okunur (readonly) olarak işaretlendirilmelidirler. Enum İfadeler Kod içerisinde kullanılan enum ifadeler kod okunurluğunu arttırdığı gibi aynı zamanda yazılım geliştiricilerin hatalı yazımları (typo) kaynaklı uygulama hatalarının ortaya çıkmasını engellemekte ve kodun yeniden düzenlenmesi (refactor) sürecini hızlandırmakta/kolaylaştırmaktadır. Bu nedenlerle kod içerisinde yer alan sabit değerler için tam sayı ve string veri türleri yerine enum türü tercih edilmelidir. Diziler Dizi ilklendirilmeleri tanımlama ile aynı satırda yapıldığı durumlarda kısa format kullanılmalıdır. Kısa formatta tercih edilen yöntem tür bilgisinin tanımlama kısmında verilirken atama kısmında yer almamasıdır; int[] degerKumesi = { 1, 2, 3, 5 }; Öte yandan, atama kısmında tür bilgisinin verildiği durumlarda (açık atama) tanımlama kısmında var ifadesi kullanılabilir; var degerKumesi = new int[]{ 1, 2, 3, 5 }; Yukarıdaki örnekte olduğu gibi dizi içerisindeki tüm veri türlerinin aynı ve rahatlıkla anlaşıldığı durumlarda atama kısmında tür bilgisi verilmeyebilir; var degerKumesi = new[] { 1, 2, 3, 5 }; New Operatörü Yeni nesne tanımlamalarında mümkün olduğunca kısa formatta ve örtülü tür tanımı kullanılmalıdır; var veriKaynagi = new Veritabani(); Nesne ilklendirilmesi sırasında mümkün olduğunca kısa nesne ilklendirme formatı kullanılmalıdır; var veriKaynagi = new Veritabani { VeritabaniAdi = "OrnekVeritabani", KullaniciAdi = "veritabaniKullanicisi", Sifre = "veritabaniSifresi" }; Delegate'ler Delegate türleri için örnek oluşturulurken kısa format kullanılmalıdır. Tanımlamada tercih edilen yöntem yoğun söz dizimin kullanılmasıdır; public delegate void Logla(string logMesaji); public static void KonsolaLogla(string logMesaji) { Console.WriteLine("Log : {0}", logMesaji); } Logla delegateOrnegi = KonsolaLogla; Olaylar Olaylar için her zaman iki parametre alan bir delegate tanımı yapılmalıdır. Bu parametrelerden ilki tetikleyici nesneyi temsil eden ve object türünden olan tetikleyici, diğeri ise olay ve duruma dair bilgilerin yer aldığı e olmalıdır. Bu sayede olay ve duruma dair bilgilerde bir değişiklik olması durumunda olayı dinleyen yerler daha kolay güncellenebilecektir. Olaylar sınıf içerisinde doğrudan tetiklenmek yerine ara bir fonksiyon üzerinden tetiklenmelidir. Ata sınıf ve kalıtanlar tarafından kullanabilmesi amacıyla bu fonksiyon protected olarak işaretlenmelidir. Tetikleyici parametresi belli olduğu için fonksiyon sadece olay ve duruma dair bilgilerin yer aldığı e parametresini kabul etmelidir. Statik Üyeler Sınıf statik üyelerinin kod üzerinden çağrımı sınıf üzerinde olmalıdır; SinifAdi.StatikUye. Statik üyeler her zaman için ata sınıf üzerinden çağırılmalıdır. Hiçbir koşul altında kalıtan sınıf üzerinden çağırım yapılmamalıdır. Hata Yönetimi Hata yönetimi her zaman için maliyeti yüksek bir süreçtir. Bu sebeple uygulama içerisinde mümkün olduğunca hata fırlatmaktan kaçınılmalıdır. Hatalar iş akışının bir parçası olarak değil gerçekten gerekli olduğu için fırlatılmalıdır. Hatalar ile ilgili aşağıdaki noktalara dikkat edilmelidir; · Hata oluşturulurken her zaman için tanımlayıcı bir ifade verilmelidir. · Bir fonksiyonun hata fırlatabileceği özel durumlar önceden biliniyorsa bunlar dokümantasyonda belirtilmelidir. · Mümkün olduğunca aşağıdaki hata türlerinin kullanılmasına özen gösterilmelidir; o ArgumentException, ArgumentNull, ArgumentOutOfRange, IndexOutOfRange: fonksiyon parametrelerinin doğruluğunda kullanılmalıdır. o InvalidOperationException: Mevcut nesnenin durumu nedeni ile bu fonksiyonun çağrılmaması gerekiyorsa kullanılmalıdır. o NotSupportedException: İlgili fonksiyonun çağırımı geçersiz ise kullanılmalıdır. o NotImplementedException: Mevcut fonksiyon içeriği henüz kullanıma hazır değilse kullanılmalıdır. · Hataların yeniden fırlatılması gerekiyorsa bu doğru şekilde yapılmalıdır. try { // İş Mantığı. } catch (Exception ex) { HatayiLogla(ex); throw ex; } Yukarıdaki kullanım pek çok senaryo için hatalıdır. Bu kullanımda hata yakalandıktan sonra hata yönetimi yapılmakta ve throw ex satırı ile yeni bir hata fırlatılmaktadır. Bu satır ile orijinal hata değiştirilmiş olur. Bu kullanımda hata uygulamada daha yukarılarda yakalandığında değiştirilmiş bir stack-trace alınmış olacak, bu sebeple hata kaynağına doğrudan erişim zorlaşacaktır. Aşağıda kullanım daha doğru bir hata yönetimini beraberinde getirecektir; try { // İş Mantığı. } catch (Exception ex) { HatayiLogla(ex); throw; } Web Servisleri Dış Kurumlardan/Sistemlerden Alınan Servisler Dış kurumlardan/sistemlerden alınacak olan servisler hali hazırda bakanlık tarafından kullanılan Web servis alt yapısı üzerinden kullanılacaktır. Buna yönelik olarak geliştirme işlemleri, BİD tarafından belirlenen teknik personel tarafından yönetilecektir. Web Servis istemci uygulamaları kurumsal bir ESB (Kurumsal Veri Yolu Sunucusu) üzerinde geliştirilecektir. Dış Kurumlara/Sistemlere sunulan Servisler Dış kurumlara/sistemlere sunulacak olan servisler hali hazırda bakanlık tarafından kullanılan Web Servis alt yapısı (ESB (Kurumsal Veri Yolu Sunucusu)) üzerinden sunulacaktır. Buna yönelik olarak geliştirme işlemleri, BİD tarafından belirlenen teknik personel tarafından yönetilecektir. Web Servisler kurumsal bir ESB (Kurumsal Veri Yolu Sunucusu) üzerinde geliştirilecektir. Alınan/Sunulan Servislerin Güvenlik Politikaları Dış kurumlara/sistemlere sunulan veya dışarıdan alınan servislerin güvenliği hali hazırda bakanlık tarafından kullanılan Web Servis güvenlik alt yapısı (XML Firewall) üzerinde kullanılacaktır. Buna yönelik olarak geliştirme işlemleri, BİD tarafından belirlenen teknik personel tarafından yönetilecektir. Web Servisler kurumsal bir ESB (Kurumsal Veri Yolu Sunucusu) üzerinde geliştirilecektir. Analiz İş akışları BPML (Business Process Modeling Language) standardına göre dijital ortamda modellenmeli. Kuruma sunulan dokümanlarla birlikte dijital kopyaları da sunulmalıdır.