Veri yapıları sınavım var..sınav süresi 30dk ve test..Veri yapılarında bilgili biri ücret karşılığında yardımcı olabilirse çok mutlu olurum..
► Eray
29.8.2020 tarihli telefon numaram ile yaptığım yorum, ÖZEL DERS vermek, konu anlatımı yapmak veya freelancer olarak yazılım projelerinde yazılımcı olarak çalışmak içindir. Ödev yaptırmak, sınava girmek gibi isteklere geri dönüş yapmıyorum.
► Tatar Ramazan
CLASS (Inheritance, abstract, interface, static) Kurallar: 1- Abstract ve interface classlarda new ile obje oluşturulamaz. Bu kural static sınıflar için de geçerlidir. 2- Statik metotlardan yalnızca statik değişken ve metotlar çağırılır. 3- Sınıfın tüm objeleri statik alanın aynı değerini paylaşır. 4- Sınıftan her obje oluştuğunda statik değişken değeri sıfırlanmaz kaldığı yerden devam eder. 5- Statik alana sınıftan obje oluşturmadan direk ulaşılabilir. 6- Statik değişken her zaman bir değere sahiptir. Nümerik değerler için değer atanmadıysa değeri sıfırdır. 7- Virtual metod, abstract ya da static olamaz. 8- Bir metod ya da properties override edilirken tipi değiştirilmez. 9- Türetilen sınıfta metod override edilmemişse ana sınıftaki içerik geçerli olur. 10- Bir interface uygulayan metod public olmalıdır. 11- Static metod abstract, virtual, override olamaz. 12- Properties?ler abstract ya da virtual olabilir. 13- Türetilen sınıf ana sınıftaki tüm abstract metodları uygulamazsa o da abstract olmalıdır. 14- Abstract metod içeren sınıf da abstract olmalı. 15- Abstract metod otomatikman virtual olur. 16- Türetilen sınıf abstract classtaki tüm metodları uygulamalıdır. 17- Virtual metod birden fazla türetilen sınıfta yeniden tanımlanabilir. 18- Bir sınıf birden fazla interface?i aralarına virgül konularak kullanabilir. 19- Interface tek başına hiçbir uygulama sağlamaz. 20- Abstract metod gövde içermez ve ana sınıf tarafından uygulanamaz. 21- Abstract sınıf içinde statik ya da virtual metod tanımlanabilir. 22- Bir interface metod uygulanırken public değilse başına tanımlandığı interface koyulur. 23- Protected tanımlanan field?a sadece türev sınıf içinden erişilir. 24- Fields (alanlar) virtual ya da abstract olamaz. 25- Interface?ler fields içermez. Properties içerebilir. 26- Bir constructor base ile miras alıyorsa hem aldığı mirası hem kendi içindekini uygular. İçi boşsa yalnızca kalıtım aldığını uygular. Miras alırken de derived (türetilen) classtaki parametre değerini esas alır. 27- Interface metod implemente edilirken override yazılmaz. Override virtual ya da abstract metodlar uygulanırken kullanılır.
► World
Hello PIO
► PIO
hello world
► Tatar Ramazan
2009-10 yıllarında millet maaşını yazardı yüksek miktarlar alırlardı şimdi kimse yazmıyor zavallılar sürünüyorlar. Yanlışsam, durumunuz iyiyse çıkın yanlışlayın beni. Az bir kısmınız mutlu olacak diğerleri kıvransın dursun.
► Tatar Ramazan
çok para bayılacaklar osuracaklar, sıçacaklar size zort zort zort...muhahah, puahahah...
► tatminsiz
10.000 tl den aşağı çalışmam.
►
java ve c# ı yalayıp yuttum mssql oracle pl sql ibm db2 biliyorum. projeler yaptım kaç para alcam?
► memnun
Muhasebe bölümünden bilişime geçtim 2 ay geride kaldım şimdi geri muhasebeye nakîl verdim ama bu parayı duyunca çallşmaya başladım
► muhendis
Eskidendi o çok eskiden..mühendisler artık aç..4 yıllık mühendisim aldığım ücret 5000 tl...
► cengiz
Ben de bilmiyorum faidesini...
► orhon
ilk önce sql sonra t-sql
Bilgisayar Mühendisleri

Here is the website inspired me to use 
it as a guide when I tried to define 
myself as an engineer candidate a few 
years ago. It really helped me to work
 and study feeling in confidence with 
being on the right way. I suggest this 
website to whom it may direct her/his 
to find the right career path. It 
includes many articles varies from 
real life experiences to detailed 
software engineering issues. But the 
most dignified parts for me are the 
articles in general and career titles.
Son okunan makaleler:
► Martin FOWLER'dan XP Yorumları (Extreme Programming)
► Installing ASP.NET
► Bilgisayar Mühendisi Ne İş yapar? Program Nedir? Çeşitli Sorular?
► ASP.NET Output Cache Modeli
► En iyi bilgisayar mühendisliği bölümüne sahip üniversiteler
► Gül'den gençlere öğütler: Boşa zaman geçirmeyin
► Bilgisayar mühendisliğinde okuyan öğrencilere tavsiyeler
► Bilgisayar Mühendisliği Hakkındaki 10 Büyük Yalan!
► Para ile ödev yapmak üzerine
► Yazılım Ekibi Büyüklüğü
► Kısa sorular Kısa Cevaplar - 2
► Para ile ödev yapmak üzerine
► Bilgisayar Mühendisliği ÖSS Taban Puanları 2009
► Neden Bilgisayar Mühendisliği?
► Java'nın kurucusu Google'a transfer oldu
► En iyi bilgisayar mühendisliği bölümüne sahip üniversiteler
► Bilgisayar Mühendisi Ne İş yapar? Program Nedir? Çeşitli Sorular?
► ASP.NET Output Cache Modeli
► Microsofta çalışan Türkler - Aslı Bilgin Röportajı
► Para ile ödev yapmak üzerine
Bilgisayar Mühendisleri Portalı
Martin FOWLER'dan XP Yorumları (Extreme Programming)
Martin FOWLER'dan XP Yorumları
Basitligin Degeri
XP’de en çok duyulan sloganlardan ikisi “Çalisabilecek en basit çözümü uygula” ve “Gelecekte ihtiyacin olmayacak” ( kisaltmasi YAGNI ) seklindedir. Bu iki sloganin temeli XP pratigi olan basit tasarima dayanir.
YAGNI prensibine göre gelecekte kullanilir düsüncesiyle önceden kod eklenmemelidir. Bu prensibe uymak kolay görünebilir fakat problem esnek çatilar(flexible frameworks), tekrar kullanilabilir bilesenler(reusable components) ve esnek tasarimlar gibi konular gündeme geldiginde ortaya çikar. Bu tür yapilari gelistirmek zordur ve gelecekte esnekligi saglayabilmek için baslangiçta büyük bir tasarim çalismasi gerektirir ve etkili yazilim tasariminin hedeflerinden biri esnekliktir.
Fakat XP’nin önerilerinden birisi esnek çatilar ve bilesenlerin hemen gelistirilmemesi yönündedir. Sadece o anki gereksinimleri karsilayacak sekilde bir yapinin gelistirilmesi önerilir. Bu yapi zamanla eklenen gereksinimlerle evrimlesir. Örnek vermek gerekirse bugün Para nesnesinde sadece Toplama islemine ihtiyacim varsa ve Çarpma islemi benim için bir ihtiyaç degilse sadece Toplama islemini koda eklemeliyim. Gelecek yinelemede (iteration) da Çarpma islemine ihtiyacim olacagini bilsem ve bunu eklemenin çok kolay olduguna inansam bile bunu sonraki yinelemeye kadar ertelemeliyim.
Bunun nedenlerinden biri ekonomik olmasidir. Eger gelecekte ihtiyacim olacak birsey icin bugun zaman harcarsam su anki yinelemede kullanabilecegim zamandan kaybetmis olurum. Yayim plani(release plan) icinde bulunulan yinelemede neler ustunde calisilmasi gerektigini belgeler ve yazilim gelistiricilerin bunlar disinda seyler ustunde calismasi bu plana aykiri duser. Mevcut yinelemede zaman olmasi olasiliginda bile hangi ozellikler ustunde calisilacagi musterinin insiyatifindedir ki bu yazilim gelistiricinin secimiyle ayni olmayabilir.
Ekonomik olmamasinin yaninda bir olasilikta Çarpma isleminin o an müsterinin istedigi sekilde yapilamamasi riskidir. Ne kadar emin olursak olalim detayli bilgimizin olmadigi bir konuda yanlis yapabiliriz. Yanlis bir çözüm üstünde çalismak daha büyük zaman kaybidir. XP uzmanlari bu tur durumlarda çogu zaman yanlis yapilacagina inanirlar ve bende bu fikirdeyim.
Ikinci neden ise kompleks tasarimin basit tasarima göre anlasilmasinin daha zor olmasidir. Eklenen her karmasiklikla beraber sistemde degisiklikler yapmak zorlasir. Degisiklikler gerçekten bu degisikliklere ihtiyaç duyulan zamandan önce yapilirsa bu durum diger yapilan çalismalari zorlastirabilir ve bu nedenle ek bir maliyet getirir.
Bu ögütler çogu insana saçmalik gibi gelebilir ve böyle düsünmelerinde hakli olabilirler çünkü alisilan biçimde yazilim gelistirmede XP nin buna olanak saglayan pratikleri mevcut degildir. YAGNI nin iyi bir pratik olmasi için XP pratiklerine ihtiyaç vardir.
Özetlemek gerekirse gelecekteki bir yineleme(iteration) için gerekli bir özelligi simdiden eklemeyin. Size hiç maliyeti yok gibi görünebilir fakat gene de sistemi daha kompleks haline getirecegi için sistemin kolayca degistirebilirligini etkiler. Basitlikten yana olursaniz ancak XP pratiklerini (tekrar tasarim, test, sürekli tümlesim) kullanarak basarili olabilirsiniz.
Basitlik de ne demek?
Evet yazdigimiz kod mümkün oldugu kadar basit olmali dedik. Bu tartisilacak bir konu degil gibi çünkü kimsenin karmasiklik pesinde oldugunu sanmiyorum. Fakat soru su olabilir “Basitlik tam olarak ne demek”?
XP de Kent basit bir sistem için 4 kriter veriyor. Önem sirasina göre (Ilki en önemli oldugu halde)
1. Bütün testleri basariyla çalistiran
2. Maksadini kolayca gösterebilen -anlasilabilir
3. Ayni kodun birkaç yerde karsimiza çikmadigi- kopya kodlarin olmadigi
4. En az nesne ve metodun oldugu
Bütün testleri basariyla çalistiriyor olmasi basit bir kriter. Kopya kodlarin olmamasi da ayni sekilde basit bir kriter fakat çogu yazilim gelistiriçin bunu gerçeklestirebilmesi için bir kilavuza ihtiyaci olabilir. “Maksadini kolayca gösterebilme-anlasibilir olma” kriterinin biraz açiklamaya ihtiyaci var. Bu tam olarak ne demek?
Anlasilabilir olma burada kodun kolayca anlasilabilmesi anlamindadir. XP kodun rahatça okunabilmesine çok önem verir.
John Kerievsky XP 2000 deki bir makalesinde bunun için güzel bir örnek veriyor. Bu örnekte Junit kodunu inceliyor. Junit dekorator(decorator) tasarim kalibini(design pattern) kullanarak mevcut testlere ayni anda kullanim durumunda senkronizasyon(concurrency synchronization) ve topluca testlerin kurulabilmesi için kullaniyor. Bu tasarim kalibinin uygulanmis olmasi kodu daha anlasilabilir ve okunmasi kolay hale getiriyor.
Fakat kodun basit olup olmadigini göreceli bir durum. Bana göre basit olan bir durum baskalari için daha karmasik bulunabilir veya tam tersi. Kodun anlasilabilirligi koda bakan insanin deneyimine göre degisebilen bir durum. Deneyimli tasarimcilar için kodun anlasilmasi daha kolaydir.
Kod kopyalamalarinin engellenmesi XP nin (Sadece ve sadece bir kere – only and only once) ve Pragmatic Programmer in DRY (Kendini Tekrar Etme- Don’t Repeat YourSelf) in verdigi en iyi ögütlerden biri. Sadece bu tavsiyeyi uygulamaniz size çok yarar getirecektir. Fakat sadece bu hersey demek degildir ve basitlige ulasmak çok zor olabilir.
Geçenlerde fazlaca tasarlanmis(over-design) bir projede yeraldim. Tekrar tasarim(refactoring) uygulandi ve esnekligin bir kismi sistemden kaldirildi ve sistem basitlestirildi. Yazilim gelistiricilerden birinin dedigi gibi “Fazlaca tasarlanmis bir kodu tekrar tasarlamak ve iyilestirmek hiç tasarimin uygulanmadigi bir kodu tekrar tasarlamaktan daha kolay”. Gerekenden biraz daha basit olmak iyi fakat kompleks bir tasarim facia demek degil”. Yani fazla tasarimdan korkmamak gerekiyor.
Robert Martin den duydugum en iyi ögüt basit tasarim konusunda çok tutucu olmamak seklindeydi. Sonuçta tekrar tasarimin önemi neyin daha basit olduguna karar vermekten çok daha fazla ve tekrar tasarim sayesinde sistemi gelecekte basitlestirmek mümkün olabilir.
Tekrar Tasarim(refactoring) YAGNI prensibine aykiri mi?
Bu konu geçenlerde bir XP haber listesinde tartisildi. Bence burada bu konuyu irdelemekte yarar var. Basitçe soru söyle basliyor. Tekrar tasarim (refactoring) zaman aliyor fakat sisteme yeni özellikler eklemiyor. Fakat YAGNI prensibi sadece o an için tasarim yap dedigi için bu bir çeliski dogurmuyor mü? YAGNI deki ana nokta sistemi gelecekte ihtiyaç duyulabilecek özellikler için daha karmasik hale getirmemek.
Bu basit tasarim pratiginin bir parçasi. Tekrar tasarim ise mevcut kodu mümkün oldugunca basit tutmaya olanak saglayan bir pratik. Yani ikiside basitlige hizmet ediyor. Ne zaman kodunuzda bir iyilestirme imkani görseniz, bunu tekrar tasarim pratigiyle gerçeklestirmeniz gerekir.
Basit tasarimin uygulanabilmesi için test,sürekli tümlesim ve tekrar tasarim gibi XP pratiklerinin uygulaniyor olmasi lazim. Basit Tasarim ayni zamanda baska pratiklerin çalisabilmesi için de gerekli bir pratik.Yani XP pratikleri bir bütün teskil ediyor. Tasarimi basit tutmak degisim egrisini sabit tutmak için de gerekli. Gerekli olmayan kompleks özelliklerin eklenmesi sadece beklediginiz degisikliklerin gerçeklesmesi durumunda yararli olur. Beklentilerin çogu zaman gerçeklesmedigini düsünürsek bu eklentiler sistemi karisik hale getirmekten birseye yaramayacaktir. Böyle bir durumda tekrar tasarim ile basitlestirilmelidir.
Hedef : Basitlik...
***********************************************************
Kaliplar ve XP
JUnit örnegi ister istemez kaliplari akla getiriyor. XP ve kaliplar arasindaki iliski merak edilen ve hakkinda çok soru sorulan konulardan biri ve bence aralarindaki iliski oldukça ilginç. Joshua Kerievsky XP de kaliplarin gerektigince vurgulanmadigini öne sürüyor. Çogu insanda ayni fikirde gibi. XP kaliplarin kullanilmasiyla zit düsen özelliklere sahip gibi bir önyargi var.
Bana göre kaliplar kas yapalim derken göz çikartilan baslica alanlardan biri. Günümüzde Design patterns - GOF kitabini okuduktan sonra 32 satir kodda 16 kalip kullanan birçok efsanevi programci mevcut. Gerçekten günümüzde kaliplarin gereksizce kullanildigi çok durum karsimiza çikiyor fakat bu kaliplarin kötü bir fikir oldugu anlamina gelmemeli. Asil sorulmasi gereken soru kaliplarin nasil kullanilacagina dair olmali.
Bir teoriye göre basit tasarim ilkesini takip ederek sonuç olarak kaliplara ulasmak mümkün deniyor. Çogu zaman tekrar tasarim(refactoring) kodu bir kaliba uygun hale getirmek amaciyla kaliplara dogru yapilabiliyor. Ayrica tasarim kaliplari hakkinda bilginiz olmasa bile basitten karmasiga dogru tekrar tasarim pratigini uygulayarak ilerlediginizde sonuçta bu kaliplara ulasmak mümkün olabiliyor. Fakat kaliplari bilmeden ilerlemek gerçekten iyi bir yol olabilir mi? Tasarim kaliplarini bilerek ve referans bir kitap elinizin altinda iken çalismak daha akillica olur diye düsünüyorum. Bu sekilde bir kalibin kullanilma ihtimali belirdigi zaman bunu farkedip GÖF ün kaliplar kitabina bakabilir ve bunu uygulayabilirsiniz. Etkili tasarim bence kaliplarin maliyetlerinin de farkinda olmali. Kaliplara kodun evrim süreci içinde ulasilmali. Bastan sadece kaliplara uygulama amaciyla gerekmedigi halde kaliplar kullanilip maliyet ve kodun karmasikligi arttirilmamali. Bu açidan bakildiginda XP kaliplara gereken önemi veriyor fakat çogu tasarim sürecinin tersine XP de evrim süreci içinde bu kaliplara amaçlaniyor.
Buna ragmen bazi haber gruplarinda insanlarin XP de kaliplarin önemli olmadigi fikrine sahip olduklarini görüyorum. Bu biraz komik çünkü XP yi destekleyenlerin çogu kaliplar konusunda da lider konumundalar. Bence kaliplarin hayati bir önemi var. XP yazilim gelistirme süreci olabilir fakat kaliplar tasarim bilgisinin belkemigini olusturuyor ki bu bilgi hangi süreç kullanilir olursa olsun esit öneme sahip. Degisik süreçler kaliplari degisik sekillerde uygulayabilir. Bu açidan XP kaliplarin sadece gerekli oldugu hallerde kullanilmasini ve kaliplara dogru kodun evrimlesmesini savunuyor. Kaliplar hakkindaki bilgi XP içinde anahtar öneme sahip.
XP kullananlara kaliplar konusunda tavsiyelerim su sekilde olacak
1. Kaliplar konusundaki bilginizi arttirin
2. Ne zaman kaliplari kullanacaginiz konusunda yogunlasin(gerekliligine emin olmadan çok erken kullanmayin)
3. Bir kalibi en basit sekliyle nasil uygulayabileceginizi ve daha sonra nasil komplekslik ekleyebileceginiz konusunda yogunlasin.
4. Bir kalibi uygular fakat daha sonra bunun gerçekten isleri kolaylastirmadigini görürseniz kalibi çikarmaktan korkmayin.
XP nin kalplar konusuna daha fazla vurgulamasi gerektigini düsünüyorum. Bunun XP pratikleri içine nasil formüle edilecegini bilmiyorum fakat eminim Kent bununda bir yolunu bulacaktir.
Mimarinin Evrimle Gelistirilmesi
Yazilim mimarisi ne anlama geliyor? Bana göre mimari sistemin degistirilmesi zor olan ve altyapiyi teskil eden temel bilesenlerini ve bu bilesenlerin birbirleri arasindaki iliskileri kapsiyor.
Evrimlesen tasarimda mimarinin oynadigi rol nedir? XP ye karsi olanlarin bu konudaki savi XP nin mimariyi unuttugu yönünde.Ayni görüse göre XP deki yöntem hizli sekilde kodlamak ve tekrar tasarim pratigi sayesinde problemlerin çözülecegine inanmak. Ilginç olan bu konuda haklilik paylarinin olmasi ve bu konunun XP nin zayif noktalardan biri olmasi. Ron Jeffries , Kent Beck ve Bob Martin gibi XP nin en önemli savunuculari baslangiçtaki mimari çalismalarini önlemek için çok çalisiyorlar. Örnegin baslangiçta ihtiyaciniz yoksa veritabanini kullanmayi erteleyin, normal dosyalarla çalisin ve kesin ihtiyaç belirince veritabani kullanimina geçis yapin ve bu geçis için tekrar tasarim pratigini kullanin diyorlar.
Ben her ne kadar öyle olmasamda çekingen bir XP çi olarak bilinirim. Bunun nedenlerinden biri baslangiç noktasinda mimari için kisada olsa bir çalisma yapilmasi gerektigini düsünmem. Bu kisa çalisma esnasinda uygulamanin hangi katmanlardan olusacagi, veritabani ve/veya web sunucusu ile nasil iletisim kurulacagi gibi noktalar açikliga kavusturulabilir.
Mimari ile ilgili konulardaki kararlarin yillar boyu deneyimlerimiz sonucunda artik mimari kaliplari haline geldigini düsünüyorum. Kaliplar hakkindaki bilginiz arttikça , bu kaliplari uygulamadan önce kisa bir deneme çalismasinin gerektigini bilirsiniz. Önemli olan baska bir konuda bu tür kalip uygulamalarinin geri dönüsü olmayan degismez kararlar olarak görülmemesi gerektigidir. Ekip bu kaliplari sistemden çikarmaktan korkmamalidir. Örnegin bana anlatilan bir hikayeye göre bir projede sonlara dogru ekip EJB ye ihtiyaç olmadigina karar verdi ve bunu kaldirdi. Bu oldukça büyük bir tekrar tasarim idi ve projenin son asamalarina dogru yapilmisti fakat XP deki pratikler sayesinde bunun altindan kalkmak mümkün oldu ve sonuç basariliydi.
Bunun tam tersi bir durumu düsünelim. Diyelim ki ilk baslarda EJB kullanmamaya karar verdiniz. Daha sonralari EJB yi kullanmaya geçmeniz ne kadar zor olabilir? Zor olmayacaksa EJB kullanmadan baslayip daha sonra gerçekten ihtiyacini gördükten sonra EJB ye geçmeniz daha iyi bir yol olabilir mi? Bu sorunun cevabini belirlerken birçok faktörü gözönünde bulundurmak lazim. Karisik bir bilesen olmadan çalismak basitligi ve islerin daha hizli yürümesini saglayacaktir fakat zaman zaman bu tür bilesenleri sonradan sistemden çikarmak , eklemeye çalismaktan daha kolay olabilir.
Özetle benim tavsiyem ilk basta mimarinin nasil olabilecegi konusunda bir çalisma yapilmasi seklinde. Eger çok fazla verinin ve kullanicinin oldugunu görürseniz veritabanini kullanmaya ilk günden baslayin. Eger karisik bir is modeli görürseniz, alan(domain) modeli olusturun. Fakat YAGNI prensibine uymak açisindan mimarinin bir kisminin gerekmedigini anladiginiz anda bunu mimariden çikarmaktan çekinmeyin.
UML ve XP
XP konusunda bana yöneltilen sorulardan birçogu UML çevresinde odaklaniyor. UML ve XP birbiri ile uyumsuz mu?
Uyumsuzlugun akla geldigi birkaç nokta var. XP diyagramlardan kaçinilmasini veya sadece çok gerekli oldugu durumlarda kullanilmasini istiyor. Gerçek XP çiler diyagram kullanmaz gibi söylemler mevcut. Kent Beck gibi insanlar diyagramlar çizmekten ve bunlari kullanmaktan kaçinmaya çalisiyor.
Bence XP nin bu bakis açisinin iki nedeni var. Birincisi bazi insanlar diyagramlari yararli bazilari ise yararsiz buluyor. Burada tehlike bu iki ayri düsüncenin kendisini diger tarafa dikte ettirmeye çalismasi. Bence bazi insanlarin diyagramlari kullanacagini, bazilarinin da kullanmayacagini kabul etmemiz gerekiyor.
Ikinci nedende diyagramlarin agir yazilim süreçleri ile birlikte anilir halde olmasindan kaynaklaniyor. Bu tür süreçler diyagramlari çizmek için çok fazla zaman harciyor ve bu çizimler hem zaman kaybina hem de çogu zaman yarar yerine zarar getiriyor. Bu nedenle bence insanlarin diyagramlar kullanirken bunlari nasil kullanisli hazirlanacagi ve tuzaklardan nasil kaçinilacagi konusunda egitilmesi gerekiyor
Benim diyagramlarin nasil kullanilacagi ile ilgili su tavsiyelerim olacak :
1)Öncelikle diyagramlari ne için hazirladiginizi sürekli aklinizda tutun. Diyagramin ilk amaci iletisimi kolaylastirmasi. Etkili iletisim için önemli ögeleri seçmeli , önemsizleri ise bosvermelisiniz. Bu seçim UML in etkili kullanimi için sart. Bütün nesneleri UML çiziminizde göstermeyin. Çizim sadece önemli nesneleri içersin. Nesnelerde sadece önemli alan ve yöntemleri çizime koyun. Her durum için Sequence diyagramlarini çizmeyin ve bunlar gibi. Benim UML diyagramlarinda dikkatimi çeken problem insanlarin diyagramlari ayrintili ve kendini açiklayabilecek sekilde hazirlamaya çalismalari. Kod ayrintinin ve asil bilginin bulundugu yer. Bu bilgiyi diyagramlarda sunmaya çalismak diyagramlari amaçindan saptiriyor.
Diyagramlarin baslica kullanim alanlarindan biri kodlamaya baslamadan önce tasarimin yeterliligini görmek. XP ye göre kodlama öncesi tasarimi bir çizimle ifade etmenin yanlis oldugu gibi önyargi var. Fakat tam tersine karmasik bir ozelligin kodlanmasindan önce kisa bir tasarim çalismasi yapmak çok yararli. Bu çalismanin özellikleri sunlar olmali.
Kisa tutulmali Bütün detaylari çözmeye çalismamali ( sadece önemli olanlar üstüne yogunlasmali) Sonuçtaki tasarim taslak vazifesi görmeli, son tasarim degil. Sondaki özelligi biraz daha acayim. Ilk basta biraz tasarim yaptiginiz zaman bu tasarimdaki hatalarin , yanlis varsayimlarin farkina daha sonralari özellikle kodlamaya basladiginiz zaman varabilirsiniz. Bu problem olmayabilir çünkü tasarimi degistirebilirsiniz. Fakat problem eger insanlarin tasarim asamasinin bittigine inandigi durumlarda ortaya çikiyor çünkü bu tur durumlarda kodlamadan gelen geri beslenim bitmis tasarima etki edemiyor.
Tasarimi degistirmek diyagramlarin degisecegi anlamina gelmeyebilir. Tasarim için taslak seklinde bir diyagram hazirlayip daha sonra bunu atabilirsiniz. Diyagram tasarimi anlamaniz için yararli olacaktir fakat bu asamadan sonra önemli belgeler haline gelmemelidirler. En iyi diyagramlar bu sekilde kullanilmayan artifact haline gelmeyen diyagramlardir.
Birçok XP çi CRC kartlari kulanir. Bu UML ile çeliskili bir durum degildir. Ben CRC ve UML kartlarini o anki durum için daha yararli olani seçerek kullanmisimdir.
UML diyagramlarinin kullanim amaçlarindan bir baskasi da dokümantasyondur. Genel kullanimi ile diyagramlar bir case aracinin içinde bulunur. Bu sekilde insanlarin çalismasinin kolaylasacagi düsünülür fakat pratik bu düsüncenin tamamen yanlis oldugunu göstermektedir.
Case araçlarindaki diyagramlarin güncel tutulmasi için zaman harcamak gereklidir. Kisa zamanda diyagramlar ve kod arasindaki senkronizasyon bozulur.
Case aracinda veya kalin bir klasörde bulunan çizimlere bakmaya çogu zaman ihtiyaç duyulmaz.
Bu konudaki tavsiyem:
Sadece çok fazla zahmet gerekmeksizin güncel tutulabilecek diyagramlar kullanin. Diyagramlari herkesin görebilecegi bir yerde bulundurun. Örnegin bir duvara poster seklinde asin. Basit degisiklikler için insanlarin bu posteri kalemle degistirmelerine izin verin. Insanlarin bu diyagramlari kullanmadigina kanaat getirirseniz diyagramlari atin. Son olarak UML diyagramlarinin iki ilgili grup arasinda el degistirdigi durumlardan bahsetmek istiyorum. XP de dokümantasyon olusturmak müsteriye deger kattigi zaman tipki diger hikayeler(story) gibi degerlendirilir. Bu durumda UML gene yararlidir ve iletisimi kolaylastirir. Bir diyagram binlerce kelimeye bedel olabilir fakat gene diyagramlar seçilerek önemli ögeleri içerecek sekilde hazirlanmalidir. Kod ayrintili bilginin oldugu yegane yerdir. Diyagramlar kodun içerdigi bilginin özeti ve önemli noktalarini açiga çikarmak açisindan kullanilmalidir.
Cenk Çivici
Yazilim Mühendisi
Bu makaleyi beğendin mi? Yorumunu Yaz!
Tweet
Sizden Gelen Yorumlar:
Yorum Yazın
netiq69(6.12.2010 16:13:55)
...Windows XP, ondan sonra çıkan gerek Vista, gerekse Windows 7'ye göre gerçekten oturaklı bir işletim sistemi... Quad Core 2GB bilgisayrda Windows XP ile gayet verimli çalışırken, dieğr işletim sistemleri ile verimli olmayıp, düşük performansla çalışmakta... Ben, ne olursa olsun bilgisayrım, hala Windows XP kullanıyorum...