türk yazılım geliştirme standartları

• aslinda iki grupda degerlendirmek gerekirse,
  
  calisma hayati ile ilgili standartlar
  
  1) yazilim bir surec degil programciya sokuldugu anda hemen bitmesi gereken bir istir bu sebepden ilk etapda calisma saati kavrami yoktur, yazilimlar proje usuludur ve yazilimci uc kurus para icin 7/24 calismalidir. ve bu ac kalmamak icin hayat standardi olur.
  2) gelistirilecek yazilimin hizli, esnek ve kullanici dostu olmasi degil bir an once bitmesi ve calismasi gereklidir.
  3) musteriye calismiyorsada bir ekran gosterilmeli, musteri is yapildigini anlamalidir, cikan hatalar yazilim calismaya basladigi andan sonra bir sekilde duzeltilir.
  4) programin gelecek surumlerinde ve olabilecek mevzuat degisikliklerinde ilgili modullerin yeniden yazilabilmesi icin programcinin anlayamacagi sekilde analizler hazirlanmalidir.
  5) altyapi dedigin artik gereksiz bir istir her zaman oldugu gibi, ilgili arac acilmali tablo hazirlanmali, form acilip uzerinde edit ler gridler tasinmalidir.(analitik dusunme is ilaninda seksi duruyorda)
  6) herseye ragmen programci gelistirdigi altyapiyi analist ve patrona gosterse bile ilk sorulan soru mahsup fisinin nerde oldugudur, hadi bir fatura keselim yevmiye maddelerini gorelim pesinden kacmaz bile.
  7) ticari program degil bir sistem yazilimi olsa bile programcinin yaptigi, onune butun engeller konulmalidirki boyle hayati deger sahip yazilimlara verilecek servis maliyeti programciya yuklensin.
  8) programci is saati icinde sadece ilgili kod yazsin, yeni teknolojiler uzerinde arastirma ve gelistirme yapmasin cunku bu bos bir istir ha yapacaksa gitsin evinde yapsin.
  10) bir yazilimci maliyet muhasebesi, butce ve uretim sureclerine hakim oldugu anda isinde uzmanlasmis demektir. networku inceleyen programciya o anda maliyetlerin hangi hesaba alacak islenmesi gerektigi sorulmalidir ve cevaplayamazsa yetersiz oldugu icin isine son verilmelidir.
  11) proje icin bilgisi ve tecrubesi olan, en zor projelerin altindan bile kalkan ve donanimi ve yazilimi cok iyi sindirmis, bir problem oldugunda assembly view da bile yazilimi debug edebilecek bir alayli alinmali, uc kurus paraya gece gunduz calistirilip vaat destegiyle proje yaptirilmali ve kicina tekme vurulup yerine sql server uzerinde transaction dan habersiz bir muhendis alinmaliki musteri sordugunda biz bu isi bilenlere yaptiriyoruz denilebilsin.
  12) isi bilen ve emegi gecen yazilimcilara psikolojik savas acilmaliki istifa etsinler yerlerine yeni mezun emmeye gommeye gelecek adamlar alinsin.
  
  teknik acidan
  1)90 larda dbase vardi 2000 lerde sql. bu yuzden isam programlar gibi sql server programlamali.
  2)set tabanli sql serverda mumkunse tablodaki butun kayitlar acilmali hatta her seferinde yerel pc ye indirilmelidir ki network bi ise yarasin.
  3) pencere acildiginda sql server uzerinde transaction baslamali ve kapandiginda bitmelidir ki bir kullanici calisirken digerleri beklemeli.
  4) tek programcinin calistigi projelerde gelistirme suresi uzamamasi icin structural programlama yapilmali, programci sayisi artinca object orient olayina girilmeli.
  5) firebird, max db, postgre sql yerine teknik riskleri minimize etmesi acisindan sql server(kasit mssql, yalarim ms senden ote pazarlamaci yok) kullanilmali olmadi masrafli geliyorsa access kullanilmali.
  6) component gelistirme isi amerikalilarindir bu yuzden yazilmasi neysede ogrenilmesi bile gereksizdir. essek gibi kurumsal firmalarda bile crack sitelerden cekilmis componentler kullanilmalidir.
  7) programin kullanici dostu olmasi kullanilan componentlerin cesidiyle saglanir. ayni form uzerinde birbirinden farkli ayni isi goren editbox lar kullanilmalidir ki daha sonra proje karissin. igrenc bir mavi renk uzerine kirmizili sekli yamuk componentler serpilmelidirki eye candy olayi saglanabilsin.
  8) yazilim parametrik olmasin bunun yerine her musteri icin ayri executable lar yapilsin(ayri olmasinin nedeni project klasorlerinin ayri olmasindan kaynaklanmali). programci yeni bir kodu ayni isi yapan otuz ayri kaynak dosyada yapmali.
  9)bilgi giris formlari uzerindeki editler datasource baglanip cachede kontrol edilmemeli bunun yerine manual olarak editlerden datasource a assign yapilmaliki security saglanabilsin.
  10)dot matrix yazicilara grafik raporlar veya ayni matbu formlar dokulmeliki cok uzun sursun olmadi bu isi yapan componentler aransin.
  11)merkez sube arasi konsolidasyon yapan bir yazilimda exception handling kullanilmamali ki hayati degeri olan bir dosya transfer edilirken hata cikarsa finally'de o dosyalar delete edilebilsin.
  12) ayni isi yapan kodlar procedure icine alinmasin bunun yerine yazilip kod sisirilsin.
  13) bilgisayar deterministik bir cihaz degildir, connection bir kere kurulur disconnet edilirse daha sonra baglantilar daha hizli olur ve kod buna gore yazilmalidir ki pos yazilimlari musteriyi on dakika kasada kilitlesin.
  14)xml icin parser ne olaki onun yerine kafadan yaz gitsin ki bir sonraki programci yeni bir node ve attribute ekleyecegi zaman anneni ansin.
  .
  .
  .
  daha uzar bu.