Kodlama Pratikleri

static decimal status

{

get

{

if (HttpContext.Current.Session["status"] == null) HttpContext.Current.Session["status"] = 0;

return Convert.ToDecimal(HttpContext.Current.Session["status"]); }

set { HttpContext.Current.Session["status"] = value; }

}

00:01 - 12/12/2009 - yorum {yok} - yorum yaz

Referanslar

23:48 - 11/12/2009 - yorum {yok} - yorum yaz

Kodlama Esnasında Dizayn - Code Complete C5

PART || - Yüksek Kalitede Kod Yazma

CHAPTER 5

KODLAMA ESNASINDA DİZAYN

5.1 Çoğu insan dizaynı kodlama aktivitesi olarak görmemekte , küçük projelerde bir çok aktivite gibi dizayn da bir kodlama aktivitesi olarak görülmekte ancak büyük projelerde dizayn kodlamadan önce yapılabilmekte.Küçük çaplı projelerde programcı klavyenin başındayken sınıflar ve interface ler tasarlar , sınıf diagramlarını çizer başka bir arkadaşına problemle ilgili kullanılablecek tasarım desenini sorar vs. Proje küçük olsa da tasarıma önem verilmelidir.

İYİ TASARIM : Tasarım isterlerin toplanmasından kodlama ve hata ayıklamaya kadar süregelir. Üst seviye dizaynı iyi olursa bu alt seviyedeki dizayna da yardımcı olur.İyi bir tasarım yapılmazsa kodun başka bir yerinde de kötü bir tasarıma yol açabilirsiniz ayrıca tasarımınızın ne kadar iyi olduğunu algılamak zordur aynı problem için birden fazla kabul edilebilir iyi dizayn yapılabilir.

İdeal olarak bütün sistem stabil olarak çalışabilmelidir , sıfır kaynak tüketmeli , sıfır bandwith tüketmeli , hata içermemeli , geliştirme maliyeti olmamalı Ancak gerçek dünyada tasarımcının görevi bu sayılanlardan optimumu yakalamaktır.

Tasarım durağan değildir zaman içinde değişebilir.

5.2 Anahtar Noktalar

- Kompleksliği Yönetmek

Yazılım geliştirmede iki tip zorluk bulunmakta.Bunlar rastlansal ve temel zorlunluluklar. Örneğin bir arabanın araba olabilmesi için motoru , tekerlekleri ve kapıları olmalıdır , eğer bu şartlar sağlanmazsa araba olamaz. Bu temel zorlunluluklar sınıfına girmektedir.Rastlansal zorlunluluklara da örnek olarak zorunlu olmayan örneğin ABS , 4 silindirli olma gibi özellikleri sayabiliriz, yani opsiyoneldir.

Proje başarısızlıklarının nedenleri genelde ; iyi planlanmamış , iyi yönetilmemiş , isterleri iyi toplanmamış olmasıdır. Bu başarısızlık teknik bir sebepten olabileceği gibi projenin kompleksliğinden de kaynaklanabilir.Komplekslik kesinlikle yönetilmesi gereken bir aktivitedir.
Bir problemin kompleksliğini azaltmak için küçük alt sistemlere bölmek gerekir.  İnsan beyni karmaşık bir yapıyı , parçalara ayrılmış bir yapıya göre daha zor  kavrar.
Kod yazarken , bir problemi çözerken önce istenilen işi yapmak gerekir daha sonra daha iyi bir çözüm olabilir mi diye üzerine yoğunlaşılmalıdır.

İyi dizayn için aşağıdaki kriterler sağlanmalıdır.

Minimum Karmaşıklık : Başkalarının da anlayabileceği şekilde bir dizayn yapılmalıdır.
Kolay Bakım : Bakım yapan programcıya anlaşılır bir kod sağlanmalıdır.
Loose Coupling : Programın iki parçası birbirine mininum bağımlılık içermelidir.
Genişleyebilir : Bir parçasında değişiklik diğer parçaları etkilememelidir. Temel sağlam olmalı üzerine inşa rahatça devam edilebilmeli.
Tekrar Kullanılabilirlik : Geliştirilen bir kod parçası diğer bir sistemde de kullanılabilmelidir.
High fan-in : Sistemin alt seviyelerdeki sınıfları kullanması
Low-to-medium fan-out : Bir sınıf az sayıda sınıfı (7den az) kullanmalı yoksa kompleksliği artar.
Portability : Bir sistemi kolayca başka bir ortama taşınabilmesi
Leanness : Dizaynı bozmadan bir parça çıkarıldığında veya eklendiğinde geriye uyumlu olabilmesi gerekir.
Stratification : Bir sınıfı anlamak için başka sınıflara bakmaya gerek kalmadan anlaşılabilmesi gerekir. Örneğin bir sürü eski  kodun kullanıldığı bir sisteme bir arayüz üzerinden erişim sağlamak.

Yazılım geliştirirken yapılması gereken adımlar:

Seviye 1: Öncelikle sınıf ve metodları tanımlamaya başlamadan önce sistemi bütün olarak ele almakta fayda vardır.

Seviye 2: Sistemi alt sistemlere ayrıştırmak. Bu parçalar büyük olabilir örneğin  veritabanı , kullanıcı arayüzü , raporlama aracı ve iş kuralları. Bu seviyede sistemi hangi alt sistemlere bölüneceğine ve diğer alt sistemlerle nasıl bir etkileşim içinde olacakları belirlenir. Bu etkileşim çok karmaşık olmamalıdır. Örneğin kullanıcı arayüzünü değiştirecek bir programcı diğer alt sistemleri de anlamak zorunda kalmamalıdır.

Seviye 3:Sınıfların ve birbirleri  ile olan etkileşimin belirlenmesi.

Seviye 4: Sınıfların metodlarının belirlenmesi.

Seviye 5: Metodların kodlarının yazılması.

5.3 Kod Bloglarının Dizayn Edilmesi.
Yazılımcı olarak bizler sorunun veya problemin bize net olarak gelmesini bekleriz , önce A yı sonra B yi yap gibi. Bu adımları teker teker geçtikten sonra sistem çalışmayınca sinirleniriz. Tasarım kod yazmadan farklı olarak sezgiseldir ve tek bir doğru cevabı yoktur.

- Örneğin Personal Time-Billing Sistemi geliştireceğiz. Sınıf diyagramı aşağıdaki gibi olsun.

Her bir nesnenin özellikleri vardır. Örneğin Employee nesnesinin özellikleri name,title,billingRate dir. Görsel kullanıcı arayüzünde butonlar, messageBoxlar, forlar,çizme araçları hepsi birer nesnedir.
- Herbir nesnede neler değişebileceğinin belirlenmesi

- Bir nesnenin diğer nesneler üzerinde yapacaklarının belirlenmesi.Hangi nesne hangi nesneleri içinde barındıracak,kim kimden kalıtım alacak,

- Bütün metod ve değişkenlerin public mi private mi olacağının belirlenmesi.
- Her nesneye bir arayüz uygulanması.

Nesneye dayalı bir tasarıma iki farklı yoldan gidilebilir. Birincisi üst seviyedeki sınıfların (interface,abstract) tasarımı ikincisi ise alt sınıfların tasarımı. İyi bir sınıf organizasyonu yapabilmek için öncelikle sistemin bütünü ele alınmalı ve genel üst seviye sınıfların yapısı çıkarılmalıdır. Daha sonra üst sınıflardan alt sınıfların detaylandırılması işlemi yapılmalıdır.

Abstraction : Soyutlama : Base sınıflar yapmak bir sınıfın detaylarına inmeden genel yapısı hakkında fikir edinmemizi sağlar. Soyutlamanın en büyük faydası gereksiz detaylardan bizi kurtarmasıdır.
İyi programcılar fonksiyon-interface seviyesinde,sınıf-interface seviyesinde ve package-interface seviyesinde soyutlama yapar.

Encapsulation : Kapsülleme : Soyutlamanın olmadığı bir yerde nesnenin herhangi bir özelliğini gizlemek için kullanılır.

Bir sınıf tasarlarken anahtar nokta sınıfın hangi özelliklerinin dışa açılacağının belirlenmesidir. Örnek olarak bir herhangi bir yere log tutan bir sınıfınız var ve kullanıcıya bu logları gösteriyorsunuz. Bu sınıfın dosyayı nereye yazdığı veya dosya uzantısının private olması gerekir çünkü veriyi geriye liste halinde alıyoruz. İyi bir sınıf tasarımı dışarıya mininmum karmaşıklık yansıtanıdır. Bunu bir buz dağının suyun altında kalan kısmına benzetebiliriz.

Örnek : Bir A sınıfının integer tipinde id isminde bir değişkeni var ve tekil olması gerekiyor. Bir de global düzeyde maksimum id yi tutan g_maxId değişkeni olsun. Her yeni nesne yaratılırken id = ++g_maxId; ile yeni bir id olması garanti ediliyor. Şimdi bir düşünelim burada ne tür sorular bizi bekleyebilir.

-          Belli bir Id aralığı olacak mı , Güvenlik için Id ‘yi birer birer değil de çoklu artırmak istersek ne olacak , Silinen id leri kullanmak istersek ne olacak.

Şimdi yukardaki gibi id’yi id = ++g_maxId; şeklinde verdiğimizde bir değişiklik yapmamız gerektiğinde yeni nesne oluşturduğumuz her yerde kodu değiştirmek zorunda kalırız. Bu bizim istediğimiz bir şey değil. Veya uygulamamız multi thread ise yukarda bahsedilen yapı çalışmaz. Id = NewId(); daha sağlıklı ve yönetimi kolay bir yapıyı bize sunar. NewID() rutini arka planda istenilen işleri yapar ve onları gizler.

*** A sınıfındaki bir metod B sınıfını çağırıyor ve B sınıfındaki bir metod A sınıfını çağırıyorsa bu hatalı bir yapıdır.
*** Bir Id yi integer tanımlamak yerine kendi oluşturacağınız bir IdType tipinden yaratın.

İyi bir tasarım yapmak için yazılım içerisinde sık değişebilecek yerleri tespit etmek gerekir. Değişmesi muhtemel parçaları birbirinden ayır ve diğerlerinden izole et. Çok değişen parçalar genelde iş kurallarıdır.
-Donanımdan Soyutlamak : Örneğin programınız yazıcı , ses aygıtları , iletişim araçları , sabit disk gibi donanımlar ile iletişim halinde ise donanım değişikliklerinde zarar görmemek için bu donanımları alt sisteminizden veya ilgili sınıfınızdan soyutlamanız gerekir. Taşınabilirlik açısından da önemli.

-Kullanıcı input ve outputundan sistemi soyutlamak : Örneğin bir dosya çıktısı veriyorsanız bunun uzantısını soyutlamalısınız. .xls , .xlsx , csv gibi
-Standart haline gelmemiş dil özelliklerini kullanmak sakıncalıdır.
-Bir durum değişkeni için boolean kullanmak sakıncalı onun yerine enumaration.

-Bir durum değişkenini direk kontrol etmek yerine bir alt rutinde kontrol etmekte fayda var.

Loose  Coupling : Sınıfların birbirleri arasındaki bağımlılıkları yok etmek.
Örneğin az parametreli fonksiyonlar çok parametrelilere göre daha az bağımlı olurlar ; Bir sınıfın çok fazla public metodu varsa bu da bağımlılığı artırır.
Modüllerin birbirleri arasındaki erişimi doğru yapılandırılmalıdır , örneğin bankacılık işlemlerinde bir modül yetkisi olmadığı başka bir modülü görememelidir. Esneklik ise bir değişikliğin yapılmasının ne kadar zor veya basit olduğu ile ilgilidir.

Bağımlılık çeşitleri :
Simple-data-parameter coupling : Datanın parametre olarak aktarıldığı kabul edilebilir bir bağımlılıktır.
Simple-object coupling :
Object-parameter coupling
Semantic coupling

Tasarım Desenleri : Sıkça karşılaşılan sorunlara genelleştirilmiş çözümlerdir.

5.4 Tasarım Pratikleri.

Bir program yazdığınızda aynı programı tekrar yazmak istediğiniz olmuştur. Bir kez yazdıktan sonra artık o programı daha iyi kavradığımızdan dolayı tasarımı konusunda daha iyi çözümler sunabilir. Tasarım iteratif bir olgudur. A noktasından B noktasına vardığınızda tekrardan A noktasına dönmek zorunda kalabilirsiniz.

Olaya üst seviyeden bakmak olayın alt seviye detaylarını persfektif olarak anlamamıza yardımcı olur. Bir dizayn iyi dörünüyorsa yeni teknikler uygulamamazlık yapmayın çünkü bir sonraki yapacağınız her zaman bir öncekinden iyi olacaktır.

Böl-Parçala-Yut : Hiçkimsenin beyni karmaşık bir programın tamamını içerecek kadar yeterli değildir.Karmaşıklık ile başa çıkabilmenin yolu onu daha küçük parçalara ayırmaktır.
Yukarı-Aşağı ve Aşağı-Yukarı Tasarım Yaklaşımları : İnsan beyni bir zamanda belli büyüklükteki bir detaya bir seferde konsantre olabilir. Eğer incelemeye sadece genel sınıflardan başlanırsa ilk başta çok fazla detaylarla uğraşmak zorunda kalınmaz. Genel sınıflar daha küçük sınıflara ayrıştırılır. Bu ayrıştırma işlemi sınıfları ve metodları en basit haline getirene kadar devam eder.
Bazen de tam tersi olarak sistemi bilmeden sadece alt seviyedeki bir modülü veya sınıfı geliştirmek gerekebilir. İki yöntemin de bir birine göre artı ve eksileri bulunmaktadır.

Deneysel Örnekleme: Bir tasarım yapıldığında bunun çalışıp çalışmadığını implementasyon yaparak daha iyi görebiliriz. Tasarımı çalıştırmak için mininmum kod yazılır.
İşbirlikçi Tasarım : Tasarımı bir başkası ile birlikte yorumlamak.
Kodlamaya Geçmeden Önce Ne Kadar Tasarım İle Uğraşmak Gerekir ? : Bu sorunun cevabı projenin kapsamı , takımın tecrübesi gibi kriterlere göre karar verilebilir

Use CRC (Class, Responsibility, Collaborator) cards
Create UML diagrams at appropriate levels of detail

13:38 - 1/12/2009 - yorum {yok} - yorum yaz

Yazılımda Mükemmel Olmak

Merhaba arkadaşlar bu yazımda bir çok yazılımcının kafasını kurcaladığına emin olduğum bir konu ; mükemmeliyetcilik konusunda bir kaç satır karalamak istiyorum.
Öncelikle mükemmel olmak ne demektir : Kusursuz olmak , her şeyin ile ideal kişi olmak , en çok para kazanan insan olmak , en iyi kariyere sahip insan olmak , herşeyi düzenli olan bir insan olmak , zamanı en etkili kullanabilen kişi olmak. .

Esasında mükemmel olmak göreceli bir kavramdır ve kişiden kişiye değişir. Ancak bana sorarsanız mükemmel olmak diye bir şey insan için bana pek de inandırıcı gelmiyor. Bir özelliği iyi olan birisinin diğer özelliği kötü olabiliyor.

Bu bir telefon , bilgisayar alırken de böyle değilmi dir. İstemiş olduğunuz özelliklerden mutlaka bir tanesi eksiktir. Ya şarjı az gider , ya kamerası kötüdür vs.vs.

Bu yazılımcı içinde böyle her konuda mükemmel olacak uzman olacak diye bir şeyden bahsetmemiz pek de olası değil. Mutlaka belli konularda eksiklerimiz olacaktır. C# biliyorsunuzdur çok iyi ancak Java bilmiyorsunuzdur. Oracle biliyorsunuzdur sql bilmiyorsunuzdur.ASP.NET biliyorsunuzdur Silverlight bilmiyorsunuzdur. Veya şöyle diyelim bir problem çıktığında yazılımcı kısa bir sürede problemi çözüyor ancak en iyi çözüm yolu ile çözemiyor.

Kendimden örnek verecek olursam google'a çok defalar yazılımda mükemmel olmaklı alakalı sorular sordum. Forumlarda aradım ama Cem Yılmazın da dediği gibi Hepsi İçimizde :) Akışına bırakıp , çok okuyarak , çok projede bulunarak gerekli tecrübeleri elde edebileceğimi biliyorum ancak hiç bir zaman tatmin olmayacağımdan da eminim

Bazılarına göre en iyi çözüm yolu en hızlı olan çözüm yoludur. Ancak bu çözüm ilerde geliştirilmeyecekse. Geliştirilip değiştirilecek bir kod parçası ise mutlaka değişimlere ve gelişimlere açık esnek yani en iyi çözümü uygulamak daha doğru olacaktır.

En iyi çözüm , en iyi tasarım da projeye , ortam şartlarına göre değişir zaten bu da sezgisel olarak ortaya çıkar. İlerde minimum refactoring yapmak ideal olanıdır.

Burada çok da nasıl en iyiyi buluruz konusunda detaylara inmeyeceğim. Ancak bulduğum birkaç linki sizinle paylaşmak istiyorum.

http://www.kodaman.org/yazi/daha-iyi-yazilim-gelistiricisi-olmak
http://www.serdardemir.net/daha-iyi-yazilim-gelistiricisi-olmak-icin-ipuclari-nedir.html
http://turkce.focusoncode.com/programlama-hastaliklari-i-mukemmeliyetci-kod-yazimi/
http://www.fussilet.com/mukemmeliyetcilik-sagliga-zararli-t20681.0.html

1-Kitap Okuyun
2-Listelere Üye Olun
3-Açık Kaynak Araçları Kullanmayı Öğrenin
4-Sürüm ve Konfigürasyon Yönetimi Konusunda Bilgilenin
5-Bir Bilene Sorun
6-Seminerlere Katılın
7-Yeni İnsanlarla Tanışın
8-Blog Yazın/Okuyun
9-Refactoring Nedir Öğrenin
10-İnsan İlişkilerini Sıcak Tutun
11-Değişime ve Yenilenmeye Açık Olun
12-Firma Kültürünü Öğrenin
13-Kişisel Bilgisayarınıza Yazılım Araçlarını Kurun
14-Açık Kaynak Projelere Katılın
15-Hayal Kurun
16-Kod Teftişi

Yazılım  geliştirken sürekli daha iyiyi araştıran bulmaya çalışan birisi bu pratiği artık günlük hayatına da ister istemez adapte ediyor. Her konuda en iyi çözümü bulmaya çalışır halde buluveriyor kendisini. Her şeyde mükemmeli aramak gerçekten de insanın psikolojisini bozabilir burada ince bir çizgi var ve bu çizgiyi dengede tutmak gerekir. Sonuçta sağlık hepsinden önemli.

11:45 - 25/11/2009 - yorum {1} - yorum yaz

ORACLE SQL Tunning’e Bir Çırpıda Bakış

          Bu makalemizde Oracle ile ilgili bazı temel bilgilere ve özellikle de performans konusunu inceleyeceğiz. Oracle ile performans konusuna girmeden önce konuyla ilgili Oracle veri blokları ve bellek yapısını az da olsa anlamakta fayda var diye düşünüyorum. Temel kavramları anladıktan sonra üzerine inşa etmek daha kolay olacaktır.

Veri Blokları
Data Block : Mantıksal olarak veri tutan en küçük veri birimidir. Küçükten büyüğe doğru
Extent ,Segment ,Tablespace ,Database olarak devam eder.
Fiziksel olarak ise OS blokları ve data file lerdan oluşur.
Tablespace : Bir dosya sistemindeki klasör gibi nitelendirebiliriz. Mantıksal olarak datafile bazında verileri fiziksel olarak gruplar. Schema ise tablespace’den farklı olarak mantıksaldır ve kullanım hakları ile ilgili bir gruplama yapar. Yani bir schema bir kullanıcının kullanmaya yetkili olduğu objeleri tutar. Bir kullanıcı bir tablespace’deki bütün objeleri kullanamayabilir.

*** : Performans faktörlerinden bir tanesini sistemin nasıl bir sistem olduğu etkiler. İki türlü sistem vardır. Bunlar OLAP(Online Analytic Processing).  yani raporlama sistemi büyük select sorguları çalıştırılır , diğeri ise OLTP (Online Transaction Processing) bu sistemde de küçük sorgular ancak çok kullanıcılı ve yoğun bir sorgu trafiği vardır.
Sistem türüne göre block size’lar belirlenmeli ve gerekli optimizasyonlar yapılmalıdır.
Örneğin çok büyük miktarda veri raporlanıyorsa data bloklar büyük set edilmeli çünkü bir seferde (1 fiziksel okumada)getirilecek veri miktarı daha fazla olur.

Bellek Yönetimi
Oracle yapı itibari ile SGA(System Global Area) ve PGA(Program Global Area) olmak üzere 2 tür bellek yapısı vardır.Bu yapıda SGA bütün veritabanı kullanları için ortak iken PGA ise connection bazlı olarak açılır. bu memory alanları Oracle’da performansı direk olarak  etkiler.Belleklerin iyi paylaştırılması ciddi anlamda performans kazandırır.Zaten tunning yaparken en çok karşımıza sorun olarak IO çıkacak yani performamızı belirleyen en önemli kriterlerden bir tanesi fiziksel okuma. Ne kadar az diske gidersek o kadar hızlanacağımızı aklımızın bir köşesinde tutalım.

*** : Ne kadar az fiziksel diske gidersek o kadar yüksek performans sağlarız. Bellekten çalışmak diskten çalışmaya göre daha hızlıdır.

Yukardaki şekilde de görülen yapıları bizim için önemli olanları kısaca tanımlayalım.
Library Cache : Her sql sorgusu çalıştırıldığında sorgu parse edilir ve bir tane execution plan denilen bir plan oluşturur. Bu plan hangi tabloda hangi indexler ile nereye bağlantı yapıldı , costu ne gibi bir takım özellikleri barındırır. İşte bir sorgu bir kez çalıştırıldığında oluşan execution plan bu bellek alanına yazılır. Eğer aynı sorgu bir kez daha çalıştırılırsa eğer Library Cache’te varsa tekrardan sorguyu parse etmez ve aynı planı kullanarak performans kazanır.
Data Dictionary Cache : Sql cümlesi bir tabloya erişmeye çalıştığında (SELECT * FROM tablo1) bu tabloya select atma hakkı var mı , bu tablonun istatistikleri neler gibi bir takım bilgilerin tutulduğu bellek alanıdır.
Buffer Cache : Bir tabloya bellek alanı boşken ilk sefer select sorgusu çalıştırılırsa direk olarak fiziksel diskten okur.Ancak bir kez çalıştıktan sonra bu bellek alanından okuyarak sonucu daha hızlı getirir.
Large Pool : Paralel ve Shared Server gibi işlerde kullanılabilir. Opsiyoneldir.
Log Buffer : Burada transaction bilgileri var. Veritabanı herhangi bir sebepten dolayı kapanırsa buradan son yapılan çalışmaları elde edebiliriz.

Redo Buffer,Java Pool ve Stream Pool

PGA ise kullanıcı bazlıdır. Oracle’a açılan her bir User process için server tarafında bir server process tahsis edilir. Yani her bir kullanıcı için serverda bellekten yer ayrılır.

*** : Gereksiz connectionların hafızadan temizlenmesi performansı artırır.

*** : Oracle 8i de bellek yönetimi tamamen admine bırakılmıştı.Her bir cache e teker teker boyutlarını vermek gerekiyordu.Library Cache’e ayrı Data Dictionary Cache’e ayrı. 10g ile birlikte sadece PGA ve SGA ya bellek alanları vermek durumundaydık , alt cache’lere teker teker verme zahmetinden kurtulmuş olduk. 11g ile birlikte bu yönetimi Oracle tamamen kendisi yapabilmektedir.

Performansınızı Uçurun

1- Tablo istatistiklerinin yanlış olması : Oracle execution plan oluştururken istatistiklere bakar. İstatistiklerde bir tabloda kaç kayıt var vs gibi bilgiler mevcuttur. Eğer sık insert alan bir tablo ise istatistikler sorgu çalışacağı anda yanlış olabilir.

Bunu bir örnekle modelleyelim. Stok adında bir tablomuz olsun başlangıçta 10 kaydımız var diyelim daha sonra toplu birşekilde tabloya import yaptık ve 9000000 kaydımız oldu diyelm. Oracle normal şartlarda sadece belli zamanlarda tabloların istatistiklerini tekrardan düzenler bu yüzden import işlemini yaptıktan sonra istatistiklerde kayıt sayısı hala 10 görülecektir.

SELECT * FROM Stok WHERE Kategori=’Bilgisayar’ sorgusunu çalıştırdık diyelim.

Stok tablomuzda Katagori kolonunda indeksimiz olmasına rağmen kayıt sayısı az olduğunu sanan Oracle bu indeksi kullanmayıp  Full Table arama yapabilir. Bu da sistemi bir hayli yorar. Halbuki istatistikler tam olsa index range scan yaparak çok daha az maliyet ile kayıtları getirebilir.

2- Sorgularda eşitliğin sol tarafında fonksiyon kullanmak index kullanımına engel olur. Örnek
     SELECT * FROM Stok WHERE UPPER(StokAdi)=’KLAVYE’
Bu sorguda StokAdi kolonunda indeks olsa dahi indeks kullanılmaz ve FULL TABLE çalışır.

3-Sub queryleri FROM’a yazmak en hızlısıdır.
Kötü Örnek:
   Select Count(*) FROM Stok S WHERE S.Fiyat < 2*(SELECT AVG(Fiyat) FROM StokHareket          SH WHERE S.StokKod=SH.StokKod)

Düzeltilmiş Örnek:
 Select Count(*) FROM Stok S ,(SELECT StokKod,AVG(Fiyat) Fiyat FROM STokHareket GROUP BY StokKod ) SH WHERE SH.StokKod=S.StokKod AND S.Fiyat<2.SH.Fiyat

4- Eğer kesişen kayıt almadığından eminseniz UNION kullanmak yerine UNION ALL kullanmak daha hızlı olacaktır. Çünkü UNION ALL kesişen kayıtlarla uğraşarak vakit kaybetmez.

5- WHERE TO_CHAR(Fiyat) = :fiy yerine WHERE Fiyat = TO_NUMBER(:fiy)

6- ORDER BY,NOT IN,IN,UNION,DISTINCT gibi ifadeler kullanılırken dikkatli olmak lazım çünkü maliyeti çok yüksek.

7- Doğru yerde doğru indeks kullanımı çok önemlidir. Nerede indeks kullanmalı konusu  biraz tecrübe ve biraz da sistemin genel yapısı ile alakalıdır.

8- Çok sık değişen ve küçük tablolarda indeks kullanmak çok da doğru değildir.

9- Genel olarak bütün mantığımız execution planı mümkün olduğu kadar az çalıştırtmak. Library Cache mizde yeteri kadar sorgu çalışmış olmalı. Eğer oracle veritabanı uzun süre çalıştıktan sonra kapanırsa açılınca performansı düşük olacaktır çünkü cache’deki bütün execution planlar silinmş olacaktır. O yüzden veritabanını kapatmamalıyız.


10-Materalized View kullanmak : Eğer sık değişen büyük veriniz varsa mutlaka kullanın.

11- Bir sorguda AND ile bağlanan iki filtre varsa WHERE ad=’KORAY’ AND Soyad=’adsds’ ikili index yapmak bu sorguyu daha çok performanslı çalıştırır.

12- Index kullanırken de ne tip index tipini doğru seçmek gerekir. İki tip indeksimiz var. B-tree ve Bitmap Index. Hangisini kullanacağımıza doğru karar vermek çok önemli. Veri tekrarı az ise B-Tree : Örnek kolon stok kodu , Tekrar eden kayıt çok ise Bitmap : Örnek Cinsiyet. Primary Key ve Unique Key kolonlar B-TREE indekse örnektir.

13- Partition Yapalım. Range,Hash,List ...vs Partitions.

14- Birden fazla CPU varsa paralel indexlerden faydalanalım.

15- Cluster kullanımı: Örneğin bir adı,soyadı,tel gibi bilgi çok fazla yerde kullanılıyorsa buları cluster haline getirebiliriz. CREATE CLUSTER ....

16- INDEX ORGANIZE TABLE : Bir tablo çok fazla değişmiyorsa tabloyu yaratırken indeksli yaratırız ve sıralı bir şekilde kaydeder.Çok hızlı select yavaş insert. Primary Key şart
CREATE TABLE ...... ORGANIZATOIN INDEX

17-  Data dağılımları düzgün tablolar için bind variable kullanmak hız kazandırır.Çünkü ilk seferde sorgunun execution planı oluşturulur ve bir sonraki değeri farklı dahi olsa bir önceki plandan işlem görür. Örnek bölge kolonu için her bölgede aşağı yukarı 99 ile 101 kayıt varsa kullanmak mantıklı.

HINTS : Execution Planlara Hint ile baskıda bulunup değiştirtebiliriz ancak 11g ile artık buna çok fazla da ihtiyacımız kalmadı. Zaten en iyi maliyetli planı Oracle buluyor. Ancak spesific durumlarda ve test amaçlı kullanılabilir.

SELECT /*+ INDEX(t name_idx)*/ FROM tablo t where name=’koray’

Oracle Enterprise Manager
Oracle’ın yönetimsel aktivitelerini takip etmek için kullanışlı bir uygulamadır. Bu bir Oracle servisidir ve uzun süre alan sql’leri akalamktan tutunda sqller ile ilgili tavsiye vermeye kadar bir çok işlevi vardır. Ayrıca incelenmesi gereken bir konudur.Biz sadece bazı küçük modüllerini inceleyeceğiz.

1- SQL Tunning Advisor : Oracle Enterprise menüsü üzerinden bu araca gelerek mevcut bir sorgunuza olumlu bir tavsiye alabilirsiniz. Örneğin şu tabloda şu kolonda index yap gibi. Mutlaka kullanılması tavsiye edilir.

2- SQL Access Advisor : Index ve Partition tavsiyesinde bulunur. Daha detaylı tavsiyeler içerir.

Sonuç olarak yazımızda Oracle yapısına kısa bir göz attıktan sonra veritabanımızı nasıl dah etkili hale getip performansını iyileştirebileceğimizi gördük. Umarım yararlı olmuştur.

Herkese İyi çalışmalar.

13:12 - 21/11/2009 - yorum {yok} - yorum yaz

Diğer Sitelerdeki Makalelerim

http://www.csharpnedir.com/articles/read/?id=1008&filter=unedited&title=Yazılım%20Geliştiriyorum%20Öyleyse%20Varım!!!

http://www.csharpnedir.com/articles/read/?filter=&author=160&cat=&id=1007&title=Oracle%20ile%20mail%20gönderme%20UTL_MAIL.SEND%20fonksiyonu

http://www.csharpnedir.com/articles/read/?filter=&author=160&cat=&id=1010&title=Kaliteli%20Yazılım%20Geliştirmek%20İçin%20neler%20yapabiliriz

http://www.yazilimgunlugu.com/bilgisayar-muhendisligi-hakkinda-merak-edilenler-makalesi/798.aspx

http://www.yazilimgunlugu.com/isletmeler-neden-yazilima-ihtiyac-duyar-makalesi/801.aspx

17:18 - 16/11/2009 - yorum {0} - yorum yaz

Kodlamaya Başlamadan Önce Hazırlık - Code Complete C3-C4

CHAPTER 3

Kodlamaya Başlamadan Once Hazırlık – İki kere hesap et bir kere yaz

Kodlama öncesi hazırlık ne kadar iyi olursa alınabilecek hasarlar minimum iner.Kodlamaya başlamadan önce iyice ölçüp biçim olası istisnaları belirlememiz proje akşında meydana gelebilecek problemleri önceden tahmin edebilmemiz lazım.Bunun için iyi bir analiz ve dökümantasyon şart.

Yazılım kaliteli olması demek sadece testleri yazmakla sağlanmaz. Yazılım Geliştirmeyi üçe ayırırsak . Analiz – Kodlama ve Test bu üç biriminde kaliteli olması pronin kalitesini belirler hiçbiri tek başına kaliteyi garanti etmez.

Günümüzde çok teknik olmayan bir çok yönetici ve patronlar kodlama öncesi hazırlığa gerektiği önemi vermiyor. Yazılımcının diğer bir görevi de bu konuda teknik olmayan insanları yazılım geliştirme processleri konusunda eğitmektir.

Büyük projeler daha çok planlama gerektirir. İyi planlamadan kodlamaya geçilen bir yazılımın çok sorun vermesi kaçınılmazdır. Araştırmalara göre iyi planlanmış bir yazılımın maliyeti 10 ila 100 kat arasında azaltmaktadır.

Patronunuzun kodlama öncesi planlamaya verdiği önemi test etmek için aşağıdakileri söyleyin

-          Daha iyi kodlama yapmalıyız çünkü hata ayıklamakla daha sonra çok uğraşıyoruz.

-          İyi planlama yaparsak  teste ayıracağımız vakit azalır.

-          İsterleri ve tasarıma yeteri kadar önem verirsek kodlamaya geçtiğimizde ve hata ayıklarken önemli bir sorun yaşayacağımızı zannetmiyorum.

CHAPTER 4

PROGRAMLAMA DİLİ SEÇİMİ

Her programlama dilinin birbirine göre üstün olduğu ve zayıf olduğu yerler vardır. Projenin kapsamına ve içinde bulunulan duruma göre iyi bir seçim yapılmalıdır. Aksi halde kodları bir dilden diğerine geçirmek çok zahmetli olabilir.

Önemli Kodlama Pratikleri

-          Kod yazarken ne kadar ön taraf dizayn edildi . ne kadar klavyeden yazıldı

-          Koddaki yorum satırları ve isimler düzenlendi mi

-          Bir kod tekniği kullanıldı mı . Örneğin hatalar nasıl yakalanacak , güvenlik nasıl sağlanacak ,tekrar kullanılabilen kodlar , performans vs..

-          Mevcut kullandığınız teknoloji sizin için yeterli mi

-          Takım çalışmasında programcılar adım adım ne yapacaklarını biliyorlar mı,

-          Programcılar tek mi yoksa pair olarak mı çalışıyor

-          Programcılar kod yazmadan önce test case lerini yazıyorlar mı

-          Programcılar başta veya sonda  her ne olursa olsun birim testlerini yazıyorlar mı

-          Programcılar hata ayıklaması yapıyorlar mı

-          Programcılar entegrasyon testi yapıyorlar mı

-          Programcılar birbirlerinin kodlarını inceliyorlar mı

-          Versiyon kontrol aracı kullanılıyor mu

-          Bir dil veya compiler seçimi yapıldı mı

-          J2EE veya .NET gibi bir framework seçimi yapıldı mı

-          Bir dilin standart olmayan özellikleri kullanılıyor mu

-          Editör , test aracı , debugger ,refactoring aracı gibi araçlar kullanılıyor mu

11:08 - 9/11/2009 - yorum {1} - yorum yaz

Yazılım Metoforları - Code Complete C2

CHAPTER 2

Yazılım Metoforları - Yazılım Geliştirmeyi Daha İyi Anlamak

Yazılım geliştirirken 2 yöntem kullanırırız. Birincisi sezgisel o an ihtiyacımız ne ise onu yaparız ve sezgilerimiz bizi götürür. Diğeri ise algoritma yöntemi ; bu yöntem ile daha once yapılmış bir çözüm var ise onu uygulayarak programlamayı daha kolay ve tahmin edilebilir yapabiliriz. Fakat programlama da hiçbir zaman tek çözüm yoktur bir problem farklı yollarla çözmek mümkündür.Bugüne kadar yazılımla alakalı metoforlar geliştiriciler tarafından ortaya atıldı. Bunlara kısaca değinelim.Metoforların türkçe anlamlı birer isim bulmakta oldukça zorlandım bulamadım da zaten.

Yazılım Hattatlığı – Kod Yazma : Çok genel olan bu yaklaşımda yazılım geliştirmede olağan harfler yazmayı öneriyor.Kalemi elinize alırsınız ve kağıda baştan sona yaarsınız. Planlamaya ihtiyaç yoktur ve ne isterseniz onu yazarsınız.

Yazılım Tarımı : Sistemi Büyütmek : Bazı geliştiriciler yazılımı bir bitkyi büyütmeye benzetir.Kodun bir parçası dizayn edilir , kodlanır ve test edilir ve siteme ilave edilir.Küçük parçalara bölündüğü için olası sorular büyümeden önlenir.

Bu metoforun kötü tarafı yazılımın nasıl geliştirileceği ile ilgili direk bir kontrolün bulunmamasıdır.

Yazılım İstiridye Tarımı – Sisteme İlave Etme:

Bir önceki metofora benzer bir yapıya sahip ancak daha anlaşılır bir görüntüye sahip.Burada büyüme harici bir ekleme veya içerme yapılarak gerçekleşir. İlk önce sistemin çalışabilmesi için en basit versiyon yazılır ve iterative olarak  geliştirilir. İlk önce gerçek data ile ilgilenilmez sadece aptal sınıflar yazılır ve iskelet oluşturulur.

Yazılım İnşası:

Daha önceki metoforlardan daha yararlıdır.Planlama , hazırlık ve çalıştırma ayrı prosesler olarak görür. Yazılım geliştirmenin bir bina inşa etmeden farkı yoktur. Eğer baştan binada kapı koymayı unutursanız proje başarısız olacaktır.

Yazılım Teknikleri Uygulama – Zeki Araç Kutusu:

Programlamada iyi olabilmek için yazılımcının bir araç kutusu olmalıdır ve bu araçları yeri ve zamanı geldiğinde etkili kullanmasını bilmelidir.

Metoforların Birleşimi:

Metoforlar algoritmik olmaktan çok sezgiseldir ve birbirlerinden ayırmak zordur.Bir yazılım geliştirirken bumetoforların birleşimi projenize uygulayabilirsiniz.

ANAHTAR NOKTALAR:

Metaforlar algoritmik değil sezgiseldir

Metoforlar yazılım geliştirme prosesini diğer bağlantılı bileşenlerle birlikte daha iyi anlamanıza yardımcıolur.

En iyi metaphor projeye uygun olan metoforların birleşimidir.

11:48 - 23/10/2009 - yorum {0} - yorum yaz

Yazılım İnşaası (Kodlama) - Code Complete C1

Arkadaşlar bu aralar Steve McConnell 'ın Code Complete Second Edition ı okuyorum ve okuduklarımdan alığım notları ara ara sizlerle paylaşacağım.

CHAPTER 1

Yazılım İnşaası Nedir ? (Construction) Kodlama

Yazılım geliştirmek karmaşık bir takım işlemlerden oluşmaktadır. Araştırmalara göre bunları şu şekilde sıralayalım :

-          Problemin Belirlenmesi

-          İsterlerin Belirlenmesi

-          İnşa Planı (Kodlama)

-          Yazılımın mimarisi veya üst seviye dizayn

-          Detaylı Dizayn

-          Kodlama ve hata ayıklama

-          Birim testler

-          Entegrasyon Testleri

-          Entegrasyon

-          Sistem Testleri

-          Bakım ve Düzeltmeler

Yukardaki listenin detaylarına inecek olursak : Aşağıdaki liste yazılım inşaasının kapsadıklarıdır. Yönetim , ister analizi ,yazılım mimarisi ,UI design , sistem testi  ve Bakım bu katogori altında toplanamaz.

-          Zemini ne kadar doğru hazırlarsak kodumuz o kadar iyi olur.

-          Kodun nasıl test edileceğini belirlemek

-          Sınıfları ve içindeki metodları tasarlamak ve yazmak

-          Değişkenleri ve sabitleri tanımlamak

-          Kodun birim ve entegrasyon testlerini yazmak

-          Diğer takım arkadaşları ile birlikte alt seviye dizaynı kontrol etmek

-          Kodu parlatmak J ve yorum satırlarını düzenlemek

-          Harici kullanılan bileşenleri entegre etmek

-          Daha az kaynak tüketerek kodu daha hızlı çalıştırmak

Kodlamaya başlanmadan once isterler net olarak belirlenmeli ve yazılımın tasarımı doğru bir şekilde yapılmalıdır ancak günümüz projelerinin çoğunda direk kolamaya geçildiği için zamanında bitmeyen bir çok yazılım projesiyle karşılaşılmaktadır. Çoğu zaman test işlemi de hatalı kodlamalar çok olduğundan atlanabilmektedir. Kodlama genel sürecin projenin büyüklüğüne göre %30 ile 80 arasında bir zaman alabilmektedir.

15:52 - 22/10/2009 - yorum {0} - yorum yaz

Bilgisayar Mühendisliği Sıkıcı Bir İş mi?

           Arkadaşlar bu yazımızda bilgisayar mühendisliğinin nasıl bir meslek olduğu ve nasıl olması gerektiğini kendi cümlelerimle anlatma daha doğrusu içimi dökmeye çalışacağım.
Aslına bakarsınız mesleğe yeni başladığınızda o kadar eğlenceli bir iş ki sürekli yeni şeyler öğreniyorsunuz ve sürekli bir heyecan yaşıyorsunuz. Beyinler tabiki ilk etapta taze olduğundan her gelen bilgi fotoğraf çeker gibi hafıya alınıyor. Sürekli kod yazmak birşeyler okumak yeni şeyler öğrenmek için can atıyorsunuz. Dışarıdan size ne manyak adam kafayı yiyecek diyorlar ancak tabi bu sizin umrunuzda değil çünkü yaptığınız işi çok seviyor ve mesleğinizde ilerlemek için ne gerekirse yapmaya hazırsınız ve yapıyorsunuz.
       Ancak Türkiye şartlarında kendinizi geliştirme imkanınız bir süre sonra yavaşlayabiliyor. Tabi ki bu çalışmakta olduğunuz firma kültürüyle de alakalı. Eğer firmanız çalışanını kendisini geliştirmek için fırsatları önünüze açmıyorsa , zaman zaman eğitim ve bilgilendirme toplantıları yapmıyorsa ve eğer siz de kendinizi akışa bırakırsanız kendinizi bir rutin içerisinde buluveriyorsunuz. İşte bilgisayar mühendisinin bana göre başına gelebilecek en kötü şey.
     Bizler şartlar ne olursa olsun kendimizi sürekli güncel tutmalıyız aksi halde bir rutin içerisine girer ve yaptığımız işten haz almamaya başlayabiliriz. Durum böyle olunca da bu sosyal hayatımıza da yansır çünkü günümüzün büyük bölümü zaten işte geçiyor. İşinde huzurlu olmayan birisinin sosyal hayatında huzurlu olması beklenemez.
    İşin bir de diğer boyutu öğrenilecek teknolojilerin fazlalığı da bir buhrana yol açabilir. Kendinizi yetersiz hissedip hepsini öğrenmem lazım dediğinizde bir anda kaos ortamı oluşturmanız kaçınılmaz. Bunun için bizler plan yapmayı , organize etmeyi , zamanı efektif kullanmayı herkesten daha iyi öğrenmeliyiz. Kendimden bir örnek vereyim eğer planımı yapıp bir yapılacaklar listesi oluşturup sırayla her bir işi bitirip listeden çıkardığımda kendimi daha iyi ve verimli hissediyorum. 
   Tabiki her zaman plan yapmakta mümkün olmayabiliyor ancak mümkün oluğu kadar hem iş hem de sosyal hayatımızı planlamak gerçekten önemlidir. 
   Günümüz şartlarında en önemli şey zaman. Zamanı yetirebilmek ve keyifli geçirebilmek çok önemli çünkü zaman çok hızlı akıyor ve bizim bir şekilde onu yakalamamız ve yeri geldiğinde kontrol altına alabilmemiz lazım.
   
     

12:25 - 9/10/2009 - yorum {yok} - yorum yaz

• Yazılım
• C#
• ASP.NET
• Javascript
• Oracle/PL/SQL
• Güncel - Genel
• Birazda Benden