fazlamesai.net´e soralım: Programcı Verimliliği, UML, DSM

FZ
9 Eylül 2004 , 4 dakika okuma süresi

Birden fazla programcının belli bir sektöre yönelik olarak geliştirdikleri ve pek çok farklı insan tarafından kullanılacak olan uygulama programlarını geliştirmek belli bir dilde ``kodlama´´ bilgisinden çok daha fazlasını getirir. Bu tür projelerin geliştirilmesi için yazılım mühendisliği disiplini bağlamında pek çok metodoloji, disiplin, vs. önerilmiş, denenmiştir. Bunlardan en önemlisi, en ciddi mantalite değişkliği belki de nesneye yönelik programlamadır.

Nesneye yönelik programlama kavramı tüm dünyayı etkilemiş ve başka kavramların, soyutlamaların, vs. ortaya atılmasına yol açmıştır. UML yani "Unified Modelling Language" son yıllarda epey popülerdir ve bunu geliştiren ekibin geliştirdiği RUP (Rational Unified Process) de yazılım mühendisliğini bir üst seviyeye taşıma iddiasındadır.

Son günlerde karşılaştığım bazı yazılar ve yaklaşımlar modelleme konusunda daha çok yol alınması gerektirdiğine dair düşüncelerimi pekiştirdi. Özellikle 20 yıldır Boeing´de çalışan bir yazılım uzmanının UML karşıtı bir yazısını okuduktan sonra biraz daha düşünmeye karar verdim.

Bir yandan bunları düşünürken bir yandan da Bildem´den sürekli "Bakın çok güzel UML eğitimleri veriyoruz" bağlamında mesajlar alıyordum. Buna ek olarak bugün Dr. Dobb´s Journal sitesinde gezinirken UML ile model geliştiren yazılım mimarlarının doğrudan kod geliştiren ekiple sorunsuz bir şekilde çalışabileceğini iddia eden Borland´ın Together isimli iddialı bir ürünü ile karşılaştım.

Yine de kafam karışık, biliyoruz ki nesneye yönelik programlama, UML, RUP filan sihirli değnek değil ve bazı durumlarda işler arapsaçına da dönebiliyor. İşte böyle düşünürken aklımın bir köşesindeki Domain Specific Modelling kavramını bir araştırayım dedim ve konu ile ilgili http://www.dsmforum.org sitesini ziyaret ettim. Bir hayli radikal ve çarpıcı bir alıntı dikkatimi çekti:

`` Software Productivity Research´´e göre Java kullanan bir programcının üretkenliği BASIC kullanan bir programcıya göre yaklaşık %20 daha fazladır. C++ dili de üretkenlik konusunda Java´dan daha iyi değildir. Aslında Smalltalk haricinde, günümüzde genel amaçlı olarak kullanılan hiçbir popüler programlama dili üretkenlik bakımından BASIC´in çok ötesine geçememektedir.

Dil savaşalarından, nesnelerden, bileşenlerden ve çatılardan sonra, 20 yıl öncesine kıyasla çok daha verimli ve etkin olduğumuz söylenemez. Ancak birkaç onyıl öncesine bakacak olursak o günlerde çok ciddi, radikal bir değişikliğe şahit olduğumuzu hatırlayabiliriz: Assembler´dan BASIC´e geçişte %400´lük bir verimlilik artışı sözkonusu idi. Peki neden böyle büyük bir sıçrama olmuştu ve benzer bir yükselişi bugün nasıl sağlayabiliriz?

%400´lük bir artış olmuştu, bunun sebebi çok ciddi bir soyutlama mekanizması idi. Bir sonraki soyutlama seviyesine geçiş yapmıştık. C++, BASIC ya da Java´daki her ifade Assembler ortamındaki pekçok ifadeye denk gelir. Daha da önemlisi bu diller otomatik olarak Assembler´a dönüştürülebilir. Verimlilik açısından bakılacak olursa, bu, bir satırlık kod maliyetine 5 satırlık kod elde etmiş olduğunuz anlamına gelir.

UML verimliliği artırdı mı?

UML gibi geleneksel modelleme dilleri verimliliği artırmamışlardır çünkü çekirdek modellerin soyutlama düzeyi destekledikleri programlama düzeyi ile aynıdır. Bir günlük bir UML modellemesinin sonunda bir günde üretilebilecek kod çıkar ancak sonuç itibari ile programcının gidip kodu elle düzenlemesi ve pek çok değişiklik yapması gerekir. Aynı bilgiyi iki farklı yerde senkronize olarak tutmanız gerekmektedir, hem model verisinin içinde hem de program geliştirme ortamında ve bu da belaya davet anlamındadır. Bir yandan Assembler düzenleyip bir yandan da C++ kodunu senkronize tutmaya çalışan birini gördünüz mü?

DSM kavramı ile ilgili araştırma yapmaya devam ederken karşılaştığım şu makale de ilgimi çekti: Is UML really the best tool for the job?. DSM deyip durduğumuz şey ise şöyle tanımlanıyor:

``Domain-Specific Modeling´´ soyutlama seviyesini programlamanın üzerine yükseltmekte ve çözümü doğrudan içinde çalışılan alanın terimleri ile tanımlamaya olanak sağlamaktadır. Sonuç ürün ise bu yüksek seviyeli spesifikasyondan üretilmektedir. Bu otomasyon mümkün olabilmektedir çünkü hem dil hem de üreticiler belli bir alanın gereksinimlerine uymaktadır. O alanın uzmanı bunları tanımlamakta ve geliştiriciler de yine bu tanımlananları kullanmaktadırlar.

Endüstriyel DSM deneyimleri mevcut uygulamalara kıyasla 5-10 kat daha verimli ve hızlı geliştirme durumlarına işaret etmektedir.

Bu konularda düşünen kafası karışık bir yazılımcı olarak fazlamesai.net´i takip eden diğer yazılım geliştiricilere sormak istedim. Belki ortaya çıkan tartışma sonucunda hepimiz bir şeyler kazanabiliriz.

fazlamesai.net

Görüşler

malkocoglu_2
19 yıl önce

UML ve RUP gibi metotlarin verimliligi arttirmadigi dogrudur. Bir seviyede belgeleme olarak proje basinda hafiften ise yariyorlar, ama eger projenin tam ortasina, merkezine konarak bir "yol" olarak konulmaya calisilinca, esas isi program yazmak olan programciya kostek olunumus oluyor.

RUP hakkinda cok guzel bir elestiri, Extreme Programcilik yazari Martin Fowler'dan gelir. Bir sure once sitemizde tercumesini vermistik.

http://www.bilgidata.com/yazi.jsp?dosya=a_yeni_metod.xml

Fowler'in RUP'a belki en aci elestirisi, RUP'in bir metadoloji bile olmamasi :) Bir metadoloji altyapisiymis! Yani, "size oyle seyler veriyoruz ki, bir metadoloji yaratabiliyorsunuz". Fowler'da der ki :"Ben, bana tavsiyeler, yon gosterecek seye metadoloji derim. RUP, lapa gibi girdigi her kaba uyum sagliyor".

Fowler'in kendi sitesi www.martinfowler.com. Diger tercume ettigimiz yazilari :

http://www.bilgidata.com/yazi.jsp?dosya=a_continous_integration.xml
http://www.bilgidata.com/yazi.jsp?dosya=a_enterprise_transforming.xml

Yanlis metadolojilerden agzim cok yandi. 96-99 arasinda ooonceeee deziggnn, sooonnraaaa kodlama desturuna muazzam sIkI yapismis olan bir sirkette calistim. Projeleri sagdan soldan surekli patliyordu. Cok yetenkli programcilar hatta teknik liderleri vardi, fakat metadoloji hizimizi azaltirdi ve acaip dusunce kaliplarini zorlayarak bazen yanlis teknik cozumlere sebebiyet verirdi. Bir gereklilik tanimi (requirement definition) toplantisinda musteri ile oturdugumuzu hatirliyorum, ve bizim teknik sef illlaaaa ki uzerinde konusulan seyi UML kutulari ile yazacakti, bunda karar kilmisti, ve toplanti sonunda birseyler yazildi, fakat, isin komigi konusan musteri, muazzam SQL bilgisine sahip ender teknik musterilerden birisiydi ve ne istedigini veri yapisi ve SQL olarak cok iyi biliyordu. "Gercekten" ne istediginin ortaya cikmasi icin projenin tamamen gocmesi ve bir tekrar tasarlama (re-design) fazina girilmesi gerekti. Gocme sebebi, aylarca calismadan sonra elde olanin sadece altyapi (infrastructure) turu kodlari olmasiydi, bir ara yeni bir uygulama servisi (app server) yaziyorduk. Ve hala elde gosterilecek "islevsel" kod (functionality) yoktu. Herneyse, o toplantidan 7-8 ay sonra (o noktada eski metadoloji tamamen atilmisti) ayni islevi artik kodlamak icin gorevli olan ben, ayni musteri ile tablolar, vs uzerinden konusmaya basladigimizda, birden sunu farketmistim. "Sen yani su-su-su sekilde GROUP BY lar yapilmasini istiyorsun!". Bu soruya evet cevabi aldigimda, takip edilmis olan metadolojiye olan dus kirikligimi tarif bile edemem.

Belki de 20 senelik, tecrubeli ellerde, metadoloji bu kadar patlayici olmayabilirdi, fakat, iste butun sorunda iste burada degil midir? Metadolojileri, eksiklerimizi azaltip, guclu taraflarimizi arttirsin ve bir disiplin saglasin diye takip ediyoruz. Sersemgecirmez (foolproof) bir metadoloji, projeye net bir yon saglar. Fakat kotu metadoloji, bir ibadet gibi zorunlulukla yapilan ama hicbirsey getirmeyen acaip bir rituele donusuyor.

Neyse; Ben bu sebeplerden Extreme Programming yontemini takip ediyorum. Bir diger bu isin kivamini bilen bir sirkette de, guzel bir gereklilik belgesi urettikten sonra, bir teknik dokuman hazirlardik, ve genelde altyapi mimarisinden, final donanim yapisindan, olcekleme gibi "somut" konulardan bahsederdik. Butun nesne modelini UML ile tamamlama gibi bir takintiya bu sirkette asla kapilmadik.

malkocoglu_2
19 yıl önce

||Fakat kotu metadoloji, bir ibadet gibi zorunlulukla
||yapilan ama hicbirsey getirmeyen acaip bir rituele ||donusuyor.

Bu cumle yanlis anlasilmasin; ibadetin hicbirsey getirmedigini soylemek istemedim. Virgul eksik kalmi$.

malkocoglu_2
19 yıl önce

"UML gibi geleneksel modelleme dilleri verimliliği artırmamışlardır çünkü çekirdek modellerin soyutlama düzeyi destekledikleri programlama düzeyi ile aynıdır. Bir günlük bir UML modellemesinin sonunda bir günde üretilebilecek kod çıkar ancak sonuç itibari ile programcının gidip kodu elle düzenlemesi ve pek çok değişiklik yapması gerekir. Aynı bilgiyi iki farklı yerde senkronize olarak tutmanız gerekmektedir, hem model verisinin içinde hem de program geliştirme ortamında ve bu da belaya davet anlamındadır. Bir yandan Assembler düzenleyip bir yandan da C++ kodunu senkronize tutmaya çalışan birini gördünüz mü?"

Yukaridaki sozler olayi tam bam telinden yakalamis. Altina imza atabilirim.

mentat
19 yıl önce

guzel konu.

yazida arada bazı abuk görüşler gördüm, mesela assemblerdan basic'e geçildiğinde 5 satır yerine 1 satır kod yazıldı, verimlilik arttı.. nea? erdener abi moduna giresim geldi, verimliliği satır sayısıyla ölçüp ondan sonra da UML falan mı tartışılır.

aynı bilgiyi iki yerde tutmak? UML ve kodun kendisinin senkronizasyonu????

bu eleştirileri yapanlar, tahminen benden de zavalli durumdalar, ben her projede 10-15k satıra gelince artık ipun ucunu kaçırmaya başlıyorum, ezber gücüm, kodun entropisine yeniliyor her seferinde. ama arap saçlı spagettiyi sadece yemek olarak severim, ve tek kişilik projelerde bile, belirli bir eşiği aştıktan sonra insan anlıyor UML ıvır zıvırlarının aslında boş işler olmadığını.

laf salatası yeter, sadede gelelim. UML ve benzeri "naneler" klavye maymunlarının satır sayısını arttırmak için düşünülmemişlerdir. aksine, verimliliğin büyük bir proje ömründe, tüm zamana yayılması amacı ve gereksinimiyle ortaya çıkmıştır. milyon satırlık projelerde, projenin başındayken sonu hakkında az çok fikir var işe, ve ekip farklı tecrübe ve bilgi seviyelerinde yazılımcılardan oluşuyorsa, bunların aralarında haberleşmelerini, anlaşabilmelerini sağlayacak bir yöntem şarttır.

UML herşeyden önce, iki programcı arasında iletişimi sağlar. yanımdaki iş arkadaşım javacı ben c++, tamamen apayrı projelerimiz var, ama yine de bir derdim olduğunda ufak bir iki şey çiziktirdiğimde, birkaç standart terim kullandığımda birbirimizi az çok anlıyoruz.

Kalabalık ve kozmopolit (ne?) bir ekipte, guru oturur, bir iki hafta mı artık neyse, tüm sistemi kağıt üzerinde çizer (UML?) sonra da cömeze al genç sen şu kısmı yapıyorsun, dış dünyaya şu fonksiyonları açıyorsun falan filan diye açıklamaya bile gerek kalmadan verir UML diagramını.

bu tur yapilar bize uymaz, zaten ne buyuk bir ekibiz, ne de milyon satirlik oracle yazicaz diyosaniz da size xp [www.extremeprogramming.org] oneririm..
( UML kullanmiyorum, ama biliyorum az cok, kullanmiyorum, cunku tek kisilik bir projede calisiyorum. )

polemige dalmadan once verdigin linkleri bi okumak lazim biliyorum ama turkum iste.

yazdiklarimi tekrar okuyunca biraz UML fanatigi gibi konustugumu farkettim, yok bir fanatikligim, milyon satirlik bir projedeyseniz, basiniz beladadir, illa ki birseyler lazimdir kodu anlatacak, kodun kendisinden baska diye dusunuyorum. ama illa UML kullanacam, dunya guzel olacak demek de sacma tabi. Projeye, ekibe gore cok degisebilecek seyler..

FZ
19 yıl önce

Kendi adıma bazı yanlış anlamaları peşinen engellemek isterim. UML´den yana ya da UML´ye karşı değilim. UML ve RUP ile ilgili şeyler okudum. Benimle beraber çalışan ve yıllardır yazılım geliştiren arkadaşlarım da okudu. Bununla da yetinmedik ekip olarak gittik Bildem ofisinde UML, RUP, Rational, vs. hakkında konuştuk, tartıştık filan. Nedir ne değildir kullanan insanlara sorduk. Kafa patlatıp anlamaya çalıştık. Halen de konu ile ilgili araştırmalarımıza devam ediyoruz (bir yandan da geleneksel yöntemlerle yazılım geliştirmeye devam ediyoruz çünkü şu anda yepyeni yöntemler deneyecek vaktimiz yok, en kısa sürede iş çıkarmamız ve insanlara sunmamız gerekiyor).

Ekiple karmaşık yazılımlar geliştiren bir yazılımcı olarak beni ve ekibimi rahatlacak, çok daha keskin, hedefe yönelik ve sorunsuz çalışmamı sağlayacak yöntem Çin´de de olsa gidip alırım, Japon bir Hıristiyan geliştirmiş olsa bile gidip kurcalarım ;-)

Burada benim görmek istediğim daha ziyade bir beyin fırtınası.

Bakın, o yazıda DSM diyor, Domain Specific Modelling diyor. İçinde çalıştığınız alanın terimlerini belirleyip, bunlarla model oluşturup bundan otomatik kod üretme diyor. UML´den, RUP´den farklı bir şey olduğunu, çok daha anlamlı ve yetkin bir şey olduğunu iddia ediyor. Bu konuda bilgisi olan var mı? Ya da daha detaylı kaynak gösterecek olan? Yapılmış somut projelere, edinilmiş deneyimlere dair bilgisi olan? İlk okuduğumda (ve hala) bana fantazi ve rüya gibi geliyor. Peki bu rüya gerçekleşti mi? DSM gibi bir yöntem benim (ya da sizin) işinize yarayabilir mi? Muhtemelen araçlar henüz emekleme aşamasındadır ve gelişmiş araçlar olmadıkça da bir manası yoktur. Ama belki de ben yanılıyorumdur, araçlardan ve avantajlarından haberdar olan var mı? Ya da var olana bakıp yepyeni fikirler üretebilecek olanlar?

Matematikle, fizikle, mekanikle, mühendislikle uğraşanlar notasyonun, soyutlamanın gücünü ve farklı farklı alanlarda insan düşüncesini ne kadar ileri götürdüğünü, tabiri caizse zıplattığını, sıçramaya yol açtığını bilirler. İşte yazılım geliştirme anlamında da bu tür şeyler önemlidir ve ben de bunlara dair bir şeyler keşfetmeye çalışıyorum.

malkocoglu_2
19 yıl önce

||Matematikle, fizikle, mekanikle, mühendislikle
||uğraşanlar notasyonun, soyutlamanın gücünü ve
||farklı farklı alanlarda insan düşüncesini ne kadar
||ileri götürdüğünü, tabiri caizse zıplattığını,
||sıçramaya yol açtığını bilirler.

FZ, yaklasimi cok iyi anliyorum, cunku ben de yazilim muhendisligine bir sure once boyle yaklasmistim. Benim su anki fikrim su: Yazilim muhendisligi netlik (rigour) konusunda matematigin yuzyillar kadar gerisinde. Dogal bilimlerde gorulen turden netlik, ve tekrarlanabilir sonuclar, kurallar da uygulanamiyor. Bunun sebebi, zannediyorum, yazilim muhendisliginin malzemesinin aslinda programlar degil insanlar olmasi. Insan derken, baktigimiz veri insanlarin en tanimsiz olan kisimlari, nasil is yaptiklari, neyi nasil ne sekilde en iyi sekilde yaptiklari gibi, uzerinde dogru durust modeli birakin, fazla "veri" bile olmayan konular.

Bu yuzden, projelerde metadolojiyi ince tutarak, "kodlamada" disiplinler getiren takimlar kazaniyorlar. "Once test" metadalojileri gibi.

UML, RUP, vs.vs.. den ziyade, projelerde en onemli sey (kusbakisi olarak) bir mimarinin tanimlanmasi. Hani o her ozellikten ozellige tekrar eden seylerin ortak noktasinin merkezi olan $ey. :) Amma uzun tarif oldu. Iste bu mimari, uzerinde bastan dusunulmesi ve UML ile gosterilebilecek bir sey, ama onu da zorunlu yapmak gerekmez. Burada eklemek gerekir, danismanllik dunyasinda cogu zaman, UML gibi diyagramlar "musteri bir seyler gorsun" diye yapiliyor. "Yani bakin calisiyoruz", ve ya "dikkatli temkinli insanlariz"... gibi.. ve "kodlamadan once dusunuyoruz" . RUP gibi metotlari bu hale getiren (buyuten) titresimlerin hangi dunyadan geldigini biraz incelemek lazim, danismanliktan geldigim icin bu cenahtan bu sekilde titresimler verildigini biliyorum. Otekileri bilemem, fakat Boeing sirketinin CTO'sunun soyledikleri ne bakilirsa onlarin fazla heyecanli olmadiklarini gozukuyor.

FZ
19 yıl önce

Son kullanıcıya yönelik uygulama yazılımı geliştirme dediğimiz şey kaç yıldır kaç kişi tarafından yapılıyor ki bir matematik, bir fizik kadar netliğe, disipline, literatüre sahip olsun. Bir yanda yüzyıllar var. Öte yanda ise taş çatlasa 40 yıl, belki de 30 yıl diyebiliriz. 1980´lerden öncesini belki de çok kaale almanın manası yok (uygulama yazılımlarından filan bahsediyorum, FORTRAN ile bilimsel uygulama geliştirenleri, Lisp ile editör yazanları ya da C dili ile UNIX araçları geliştirenleri değil).

Malzeme ve bileşenler makina parçaları gibi değiller, anında müdahale, anında değişim söz konusu, ``katı´´ değil gibi. Bu yüzden de evet çok kaypak zeminde kafa göz yara yara ilerleniyor ancak bu, yepyeni yaklaşımların getirilemeyeceği anlamına gelmiyor. Boeing´deki deneyimli bilgisayarcının söyledikleri yalan yanlış şeyler değil, ne dediğini bilen sağlam bir adamın sözleri, evet bu doğru ancak benim derdim şu değil: ``Bakın binlerce yazılımcı UML olmadan karmaşık sistemleri nasıl da güzel geliştirdi, ne gerek var soyutlamaya´´ türünden bir yaklaşım değil. Benim derdim şu: Elimdeki yazılım geliştirme işini alabildiğine soyut seviyeye çıkarıp, performanstan ve üretim songünlerinden taviz vermeden beni çok daha verimli çalıştırtacak araçlar, yöntemler geliştirilebilir mi?

Bu bir prensip meselesi belki de. Diyebilirsiniz ki: Hayır efendim, öngörülebilir bir gelecekte böyle bir şey söz konusu olamaz, öyle ya da böyle oturacaksın her türlü modül için her seferinde yeni baştan yüzlerce, binlerce, onbinlerce satır kod yazacaksın. Ya da diyebilirsiniz ki, evet bu mümkün olabilir, 50 sene sonra ``yazılım´´ geliştiren insanlar artık ``kodlamaktan´´, ``program geliştirmek´´ten falan bahsetmek yerine bambaşka kavramlardan bahsediyor olabilirler. Yapacakları iş model geliştirmek ve bunları test etmek olur ve bugün bizim hayal edemeyeceğimiz türden araçları kullanıyor olurlar, satır satır geleneksel dilde bir program kaynak kodu okumak gibi bir iş hemen hemen hiç yer almaz günlük uygulamalarında. Ben ümitliyim çünkü eğer 2054 yılına geldiğimizde hala bugünküne benzer şekilde yazılım geliştiriyor olursak o zaman hemen hemen hiç ilerlememişiz ve insanlık olarak da biraz aptalız demektir (ya da yazılım geliştirme denen şey o kadar garip, o kadar garip bir şeydir ki 100 yıl geçmiş olmasına rağmen hala ilkel (primitif) bir düşünce ve uygulama yapısının ötesine geçememiştir, hamallığı yoğun bir iş olarak devam etmektedir).

malkocoglu_2
19 yıl önce

Bence, direk bilgi islem icin konusuyorum, ileride su anda yaptigimiz sekilde programcilik olmayacak, olmamali. :) Yaptigim isin birgun kaybolacagini hissediyorum, ve umuyorum.

UML hakkinda: Tavsiyelerim galiba RUP ve UML'i herseyin merkezine oturtanlar, oturmak isteyenler icin. Oldukca uc bir noktadan bahsediyorum. Holding der ki: "Bugun karar aldik, butun sirket boyle yapacagizdir" gibi bir secim. Digerleri UML'i belli olculerde, bir belgeme araci olarak kullanirlar, ve memnun kalacaklardir. Resimler guzel oluyor.

Bilim karsilastirmasi hakkinda: Yazilim muhendisligi, mesela Newton zamanindaki doga bilimlerinden bile DAHA GERIDEDIR. (Newton'u doga bilimlerinin babasi olarak alirsak). Yani zaman farkini offset edip karsilastirirsaniz, durumun cok vahim oldugunu gorursunuz. Bunun en komik sonuclari da bunun her nasilsa farkina varmayan arkadaslar ile tartisirken cikiyor: Bir Javaci bilgi islemci/teknik lider benimle "cok sayida ufak Java nesnelerimi iyidir, yoksa daha az sayida daha buyuk nesneler mi" gibi garip bir konuda (ona gore cok onemliydi) muthis atesli savunmalar, vs yapiyordu. Yani, biz de dedik, iki turlu de yaptik, kistas dogru ya da yanlis, belki de yanlis yerde. Nereden bilecegiz? _Bilemiyoruz_. Isin ilginci, bu arkadas bilgisayar bilim doktora ogrencisi ve cok daha net (rigourous) islerle aslinda ugrasabilir, fakat gelmis sifir rigour olan yerde deney verisiz filan falan desturlar salliyor. Biz de bu sektorden bir an once cikip ta dogru olan ispatlaninca dogru oldugu kabul edilen bir alana kaymaya ugrasiyoruz. :) Bir acaip!

malkocoglu_2
19 yıl önce

||``Domain-Specific Modeling´´ soyutlama seviyesini
|| programlamanın üzerine yükseltmekte

Amma yorum yazdim. Elimde degil, uzerinde yillardir dusunmus oldugum konular bunlar! :)

DSM hakkinda, Hibernate proje lideri Gavin King'in guzel bir soylemi var. Soyle diyor

"İlkin belirteyim, her uygulamanın bir alan modeline ihtiyacı yoktur. Öyle uygulamalar var ki, alan modeli bu uygulamalar için fuzulidir. Meselâ öyle uygulamalar var ki "veri tabanından gelen veri kümeleri" görüşü onlar için cuk oturur..[atlama].. Öte yandan, diğer bir sınıfa giren uygulamalar var ki aşırı miktarda işlem mantığı işletmenizi gerektiriyor. Ama hemen ekleyeyim, bu her uygulama değildir. Ne yazık ki revaçta olan çoğu Java kitabı, insanlara, "işlem mantığını görsel mantığın olduğu kodlardan kesinlikle çıkarmaları" gerektiği görüşünü dayatıyor. Fakat yeteri kadar iş mantığınız yoksa, o seviyede bir ayırıma, o tür bir soyutlamaya ihtiyacınız olmayacaktır. "

http://www.bilgidata.com/yazi.jsp?dosya=a_gavin_king_mulakat.xml

FZ
19 yıl önce

Belli bir alandaki terimleri bilgisayarda tanımlamak sonra da detaylarla uğraşmadan doğrudan bu terimlerle düşünmek ve program geliştirmek. Biz insanlar, belli bir sektördeki insanlar bunu zaten yapmıyor muyuz, söz gelimi doktorların kendi terminolojisi yok mu? Tıp eğitimi almamış biri iki uzman beyin cerrahının diyaloğundan ne anlayabilir? Yüzde kaçını anlayabilir? Hadi diyelim bu adamlar bir sürü Latince terim kullanıyor olsunlar, peki iyi Latince dil bilen bir klasik Latin edebiyatı uzmanı getirsek, o anlayabilir mi doktorların dediğini? O alana özgü kavramlar, düşünce şekilleri, terimler, vs. Doktorlar kendi alanlarının terimleri ile konuşurlar ve bu sayede soyutlamaları kullanarak iletişim kurarlar.

Bir başka örnek: Yukarıdaki kavramı geliştirdiği programlama dili Rebol [www.rebol.com]´un bir parçası yapan Carl Sassenrath benzer bir yaklaşımdan ve bunun öneminden dem vurmaktadır.

UNIX dünyasına bakalım: make, lex, yacc, ant, sed, grep. Bazılarımız ne alaka yahu, bunlar birer ``utility´´ diyebilir. Benim cevabım: Hayır, bunlar bir hayli üst düzey soyutlamayı bünyelerinde barındıran ``programlama dilleri´´. Bu sistemlerin kendine özgü dilleri var, belli bir alana özgü, o alanın terimleri ile konuşuyorlar, belki bazılarına çok ilkel gelebilir ama yaptıkları şey tam da bu değil mi? Tam da UNIX geleneğinin içinde yok mu, belli bir işe uygun ``semantik´´ yapısı olan bir dil geliştir ve sonra o işin alanındaki problemi geliştirdiğin bu yeni dil ile formüle et ve çözüme o şekilde eriş. Bırak o araç gereken C kodunu ya da Assembler ya da binary, her neyse, o kodu senin için üretsin, sen problem alanında düşün. Yani: Sen bilgisayara uyma, bilgisayar sana uysun

Bir başka örnek, doğal dil işleme (NLP - Natural Language Processing) alanından; bu alanda en çok kullanılan iki dil Lisp ve Prolog dilleridir ancak NLP için DCG (Definite Clause Grammar) diye başka bir yapıyı bu diller içinde kullanabilirsiniz, size çok daha üst seviyeli düşünme imkânı sağlar.

Son bir örnek: Son kullanıcıya yönelik ve yoğun veri işleme işi ile uğraşıp da SQL dilini kullanmamış olan var mı? SQL dilini kullanan bir programcı çok çok soyut bir seviyede düşünür, alttaki mimari umurunda değildir, SQL sonucunda üretilen düşük seviyeli kodlar, veritabanı motorunun atacağı taklalarla hiç uğraşmaz bile. Birkaç tabloyu birleştirip sonuç üreten birkaç satırlık SQL sorgusu belki de yüzlerce satırlık düşük seviyeli veritabanı koduna karşılık gelir! SQL dili ile ilgili ilk fikirler 1970´lerde ortaya atıldığında atan adamla dalga geçmişlerdi: Evet, tabii güzel bir fantazi ama yani bunu somut olarak gerçekleştirmek çok zor, çok kastırır bizi ve de makinaları, sen öyle akademik akademik fantaziler üretmeye devam et. Sene 2004, aradan 34 yıl geçmiş, bugün Internet´te dinamik site yapmak isteyen 16 yaşındaki veletin PHP´den sonra ilk duyduğu şey: MySQL öyle değil mi? ;-)

Örnekler çoğaltılabilir. Yani insanlar zaten mümkün olduğunca soyutlama, birleştirme yapıp işlerini kolaylaştırmaya çalışıyorlar. Bana öyle geliyor ki, DSM´ye günümüzde tekabül eden araçlar iyi ya da kötü, bazı yerlerde tamamen anlamsız filan görünebilir ama DSM kavramının kendisi çok önemli ve geliştirilmesi gereken bir kavramdır, buna paralel olarak da somut araçların geliştirilmesi gerekir.

Nightwalker
19 yıl önce

Bu ikinci... Tam bir konuya aklım takıldığı zaman o konuyla ilgili bir makale FM'de beliriyor :)
ilki tam ben yaw bu sisteme güvenli ftp erişimini nasıl sağlarım dediğim gün conan'ın sftp makalesini gördüm.
İkinci olay üniversitenin son sınıfına yaklaşıp aklında süper paralar kazandıracak yazılım projeleri belirmeye başlayan her öğrenci :) gibi yaw bu iler nasıl oluyormuş hani yazılım mühendisliği falan diye birşeyden bahsediliyor bu neymiş acep ?
Biz bu güne kadar oturup makinenin başına yazdık programları ama nasıl oluyor bu işler piyasada bu uml de ne olaki yok efendim oop derken bu makale çıktı karşıma... Gene çok karıştırdım lafı olayın özeti şu ;

Şu ana kadar görüp okuduklarımdan anladığım şu;

1.XP verimliliği arttıran en azından programcının üzerindeki stress yükünü azaltan birşey.

2. Ancak Bruce Eckel'in (Thinking in C++, 2nd ed. Volume 1 de) ve Martin Fowler'ın
("Is Design Dead?" adlı makalesinde) söylediğine göre tasarım en azından yazılımın iskeletini tasarlanmasını,
dokuların ise evrimsel bir yaklaşımla kod yazarken oluşturulmasını öneriyor.

3. Sanırım doğrusuda bu...

Not: Martin Fowler in "Is Design Dead?" adlı makalesinden Türkçesini aşağıdaki adreslerde bulabilirsiniz.

http://www.yazilimmuhendisi.net/modules.php?op=modload&name=News&file=article&sid=22&mode=thread&order=0&thold=0
http://www.yazilimmuhendisi.net/modules.php?op=modload&name=News&file=article&sid=23&mode=thread&order=0&thold=0
http://www.yazilimmuhendisi.net/modules.php?op=modload&name=News&file=article&sid=24&mode=thread&order=0&thold=0

malkocoglu_2
19 yıl önce

Bu ozetlemeye katiliyorum. "Tasarim Öldü mü?" makalesi onemli bir makaledir... Tercumesinin yapilmis olmasina sevindim.

FZ
19 yıl önce

Aynı sitede benim asıl ilgimi çeken başka bir makale oldu:

- http://www.yazilimmuhendisi.net/modules.php?op=modload&name=News&file=article&sid=18

Dikkati çeken alıntılar:

... Bugün, yazılım mühendisi ortalıkta dolaşan altı doldurulmamış piyasavari bir slogandan öteye geçemiyor. Bu şanssızlıktır. Fakat terimin suistimal edilmiş olması onun hiçbir meşruiyetinin olmadığı anlamına gelmez. Yazılım geliştirme, 30 yıl içinde epey yol kat etti. Hala mutlak kararlı temel bilgiden yoksunuz ve bazı özel teknolojik alanlarla ilgili bilgimiz hiçbir zaman kararlı bir yapıya ulaşamayacak, fakat şu anki bilgi yapımız yazılım mühendisliği diye bir olgudan bahsedebilmek için yeterli derecede kararlı. Bu temel şu alanlardaki pratikleri kapsıyor: ihtiyaçların geliştirilmesi, işlevsel tasarım, kod yapımı, entegrasyon, proje tahmin, maliyet/yarar analizi ve tüm bunların kalite güvencesi.

... Bir başka itiraz da yazılım geliştirmenin, mühendislik olarak ele alınması, tüm eğlenceyi sonlandıracak. Uzun zamandır yazılım geliştirme ikiyüzlü bir zanaat konumunda ve çok sayıda zanaatçı üstün geliştirme metotları hakkında pek bir şey bilmeseler de fantastik gelirler elde etmekte. Hiçbir eğitime sahip olmayıp doktorlar kadar kazanan bu bilgisayar programcılarına halkın ne kadar tahammül edeceğini Allah bilir, ama 2000 yılında yaşanan problemlerin beraberinde yazılım geliştirmenin düzenlenmesi yönünde bir kamuoyu baskısını getireceğini tahmin ediyorum. Diğer mühendisliklerin tamamı kendi tanınmışlıklarını ve düzenlenmişliklerini içermekte; yazılım geliştiriciler ya gönüllü olarak yazılım mühendisliği hapını yutacaklar ya da zorla ağzımıza tıkılacak. İlaçlarımı almak için hangi yolu tercih ettiğimi biliyorum. Bu alandaki roller belirlendiğinde, yazılım mühendisliğiyle diğer mühendislik disiplinleri arasındaki eşgüdümün büyük oranda arttığını görmek şaşırtıcı olmayacak. Yazılım üzerine uzmanlaşan elektrik ve havacılık mühendisleri projelerin yazılımla ilgili kısımlarına liderlik yapabilirken, sadece elektrik ve havacılık mühendisliğine yönelenler için aynı şey söz konusu olmayacak. Bazı öğrenciler genel yazılım mühendisliği diplomalarına sahip olacak.

... Bir başka itiraz da yazılım geliştirmenin, mühendislik olarak ele alınması, tüm eğlenceyi sonlandıracak. Uzun zamandır yazılım geliştirme ikiyüzlü bir zanaat konumunda ve çok sayıda zanaatçı üstün geliştirme metotları hakkında pek bir şey bilmeseler de fantastik gelirler elde etmekte. Hiçbir eğitime sahip olmayıp doktorlar kadar kazanan bu bilgisayar programcılarına halkın ne kadar tahammül edeceğini Allah bilir, ama 2000 yılında yaşanan problemlerin beraberinde yazılım geliştirmenin düzenlenmesi yönünde bir kamuoyu baskısını getireceğini tahmin ediyorum. Diğer mühendisliklerin tamamı kendi tanınmışlıklarını ve düzenlenmişliklerini içermekte; yazılım geliştiriciler ya gönüllü olarak yazılım mühendisliği hapını yutacaklar ya da zorla ağzımıza tıkılacak. İlaçlarımı almak için hangi yolu tercih ettiğimi biliyorum. Bu alandaki roller belirlendiğinde, yazılım mühendisliğiyle diğer mühendislik disiplinleri arasındaki eşgüdümün büyük oranda arttığını görmek şaşırtıcı olmayacak. Yazılım üzerine uzmanlaşan elektrik ve havacılık mühendisleri projelerin yazılımla ilgili kısımlarına liderlik yapabilirken, sadece elektrik ve havacılık mühendisliğine yönelenler için aynı şey söz konusu olmayacak. Bazı öğrenciler genel yazılım mühendisliği diplomalarına sahip olacak.

... Yazılım geliştirme bir mühendislik mi? şeklindeki aldatıcı soruyu terk edip gerçek soruyu sorduğumuzda: Yazılım geliştirme mühendislik olmalı mıdır?, işte ancak o zaman gerçekten önemli sorulara yanıt aramaya başlamış olacağız. Yazılım mühendisliğinin temel bilgileri nelerdir? Yazılım mühendisleri nasıl eğitilmelidir? Yazılım mühendisleri nasıl geçerlilik kazanabilir? Ve sanırım belki de en zoru, tüm bunlar için daha ne kadar var?

malkocoglu_2
19 yıl önce

Belki de yazilim dunyasinda muhendislik arayanlar, bazen yanlis tarafinda ariyorlar.

Bir, bireyin/programcinin kendine dusen gorevler cercevesinde yaptigi bir muhendislik var. Bu bir aci.

Oteki bir muhendislik te, projenin geneli uzerinden yapilan bir tur muhendisliktir. Teknik lider tarafindan yapilir, ve baska bir seviyededir.

Iste bu seviyedeki muhendislik, mesela Extreme Programcilik baglaminda artik doga bilimin yaptigi gibi veri toplamaya ve bu veriler uzerinden bir takim kararlar vermeye baslamistir. XP'nin programcilar uzerinde bitiszamani olarak hicbir zorunluluk koymamasi kalp krizi kadar ciddi bir gelismedir. Kent Beck'in bu sureci ve mantini tarifi, bende bir yapay zeka algoritmasinin isleyisine benzeyen bir eniyilesme ve gelismesi teknigin benzerlligini hatirlatmisti. EM algoritmasi, ideal olana yaklasan (converge) bir algoritmadir, herhangi bir faraziyeden baslar, ve eniyi olana dogru ilerler. Yavas yavas.

XP, programcilara "sunu su kadar hizli yap" demez, sadece onlarin performansini "olcer". Projenin basinda her donem (iteration) icine konan ozellik miktari ilk basta sadece bir tahmindir, ama olcumler ele gectikce daha net olabilmeye baslar. Cunku artik elde dogru rakkamlar vardir.

Sistem kurarken, projelerde hep "geneli" dusunuruz, ve herkesin ayni yapmasi gereken teknikler uzerinde odaklaniriz. XP, parmagini programcinin sahsi dunyasina sadece kodlama tavsiyeleri baglaminda sokar, gerisine karismaz. Ikili programcilik, iletisimin artmasi acisindan yapilmistir. Musteri programci iliskileri, genelde yapilan bir karardir, ve bence XP'nin en muhim saptamalarindan birinin sonucudur. Olcum, her doneme alinacak ozellikler, musteri ve teknik lider tarafindan yapilir. Otomize ve toptan calisan derleme ve birim testlerinin toptan isletimi, bir merkezi makina tarafindan yapilir.

Izlenecek kurallar uzerinde mutabakat kurmaya calisirken, "izlenebilecek" kurallar bulmaya calismak cok muhimdir. Oklar ve kutulari herkezin cizmesi, ve bu kutulardan kod uretilmesi, ve koddan geri oklar ve kutular uretilmesi, bireye dayatilmasi/ogretilmesi/uygulatmasi zor, gercekci olmayan bir teknik oldugu icin, bireyin performansini azaltir.

Birey seviyesinde su anda yapilabilecek en temel sey, onu tavsiyeler, kodlama standartlari ile destekleme, ama onun haricinde yolundan cekilmek olmalidir.

Bu soylemin ruhunu en iyi icsellestirmis olan sistemler de, su anda cevik metotlar kategorisinden cikiyor.

Görüş belirtmek için giriş yapın...

İlgili Yazılar

Tembel FM Kare

redogre
26 Kasım 2008, 1 dakika okuma süresi

Ian Murdock Burada, Richard M. Stallman Burada FM Okurları Nerede?

FZ
26 Şubat 2004, 1 dakika okuma süresi

Ziyaretçiler bir bir gelmeye başladı. Debian projesinin kurucusu Ian Murdock şu anda Bilgi Üniversitesi kampüsünü ziyaret ediyor. Diğer yabancı konuklar da gelmeye başladı. Richard Stallman da varmak üzere.

27 Şubat, yani Cuma, yani yarından itibaren İstanbul Bilgi Üniversitesi gümbür gümbür 3 günlük bir Özgür Yazılım ve Açık Kaynak etkinliğine ev sahipliği yapacak.

Gelebilecek tüm FM takipçilerine kapılar ardına dek açıktır, herkesi bekliyoruz. Gelmeyenleri kara listeye alıp dövücez :-P

Neden Ordu Parası ile Araştırma Yapılmaz?

butch
26 Eylül 2006, 1 dakika okuma süresi

Akademik Dürüstlük ve Ödevlerini Başkasına Yaptırmak Üstüne

FZ
16 Kasım 2005, 1 dakika okuma süresi

Columbia Üniversitesi Bilgisayar Bilimleri bölümünden Kenneth Ross, ACM Communications için yazdığı son yazıda Academic dishonesty and the Internet başlıklı yazısında verdiği B+ tree konusuyla ilgili ödevi ve bir öğrencisi üzerinden rentacoder bağlantılı macerasını anlatıyor. Aynı yazının PDF halini de okumak mümkün.

Internet üzerinden "ödev araştırması" yapanların kulaklarına küpe olabilecek türden bir ibret-i alem vakası...

fazlamesai.net'e soralım: Özgürlük mü, kaliteli yazılım mı?

FZ
22 Mart 2006, 1 dakika okuma süresi

Günlüğüme girmiştim ama FM camiası ile de paylaşmadan edemedim.

Bu aralar iki yazılım kurcalıyorum iş için: Confluence ve JIRA. Her ikisi de kapalı kodlu, kaliteli ticari lisanslı yazılımlar.

Fark ettim ki ticari bir yazılım olan JIRA'yı Apache Foundation da tercih ediyor ve yoğun olarak kullanıyor. Neden tercih ettiklerini burada açıklamış. Gelelim FM camiasına sormak istediğime: