Java Günlüğüm
Yazılım, Java, BT, azıcık felsefe, biraz mizah...
  • Udemy Eğitimleri
  • Temiz Kod
  • Tasarım Kalıpları
  • Hakkımda
  • Arşiv
RSS
24 Kasım 2014

Programlama Nedir: Programlama’nın Tabiatı ve Programcılık Üzerine – III Bilim mi, Mühendislik mi Yoksa Sanat mı?

Akin Bilgisayar Bilimleri, Programlama, Yazılım Mühendisliği programlama, programlama nedir

Bu konu ile ilgili yazdığım bir önceki yazı ışığında hem kendi düşüncemi hem de ülkemizdeki anlayış ve pratikleri değerlendirmek isterim.

Evet kategorizasyon anlamamızı kolaylaştırır, bu doğrudur, ama aynı zamanda indirgemeci bir tutumdur, detayları atlar. Bundan dolayı karmaşık şeyleri kategorize etmek zordur. Bu yüzden programlamanın ve yazılımın tabiati ile ilgili tonla farklı kategorizasyon var. Ben ise şöyle düşünüyorum: İşe en çekirdekten başlarsak öne programlamayı ele almamız gerekir. Sonuç itibariyle programlama, algoritmik düşüncenin uygulanmasıdır. Yani programlamada aslolan algoritmik düşüncedir. Dilleri kullanılarak yazılan kodlar, algoritmik düşüncenin hayata geçmiş halidir. Programlama faaliyetinin arkasındaki bu esas noktayı görmemek, programlamayı tamamen yanlış değerlendirmek anlamına gelir.

Bakın, hepimizin malumu, ABD’de başlayan ve dünyaya yayılmakta olan, “herkes kodlama öğrenmeli” (everybody should learn to code) sloganıyla ifade edilen bir yeni heyecan var. ABD başkanı Obama’dan tutun da Facebook kurucusu Zuckerberg’e kadar herkes, “haydi çocuklar kodlamaya” gibisinden çağrılarda bulundular. Code.org gibi konuyu sosyal sorumluluk bağlamında ele alan yerler olduğu gibi, akademik olarak değerendirmeler yapanlar da var. Kimileri ve bazıları modern çağın dinamiklerini öğrenmek için herkes en basitinden Javascript’le biraz uğraşmalı derken, diğer kimileri “hayııııııırrrr” diye haykırarak bu çağrıya karşı çıkıyor. Bunlar işin biraz daha üst tarafını gören yaklaşımlar. Bence bu konudaki en güzel yaklaşımı Grady Booch sergiledi. Booch, IEEE Software dergisinin Eylül-Ekim 2014 sayısında bir yazı yayımladı. Yazının başlığı “To Code or Not To Code: That’s the Question” şeklinde, yani “Kodlamak mı yoksa Kodlamamak mı: İşte soru budur.” Booch’a göre başlatılan bu kampanyanın düşmesi muhtemel yanlışı, insanlara meslek olarak kodlamayı öğretmektir. Evet Booch’a göre bu bir yanlıştır çünkü aslolan onun “computational thinking” dediği ve benim yukarıda “algoritmik düşünce” diye anlattığım düşünce şeklini öğrenmektir. Ona göre, programlamanın temeli, dilimize belki “hesaplamasal düşünce” diye kelime çevirisi yapabileceğimiz ama benim “algoritmik düşünce” demeyi tercih ettiğim, zihnimizin kazanması gereken bir düşünme şeklidir. Bu düşünme şekli, programlamadan önce, bir işi veya süreci algoritmik olarak ifade edebilmek gibi, pek çok zihni yetkinliği ve aracı barındırıyor. Bu zihni araçların gerekliliğinden habersiz bir şekilde Bilgisayar Mühendisliğine girip, beni “lütfen sen kod yazma, mümkünse Eclipse’i de makinandan kaldır” diye yalvartan programcı adaylarına çok sık rastlıyorum. Öte taraftan doğuştan algoritmik düşünceye yatkın olan kişilerin, üzerine herhangi bir mühendislik gibi güzel bir Matematik ağırlıklı eğitimle çok başarılı programcılar olduklarını da görüyorum. Bu anlamda programlama, algoritmik düşüncedir ve nihayetinde Matematik’in bir konusudur ve saf bir bilimdir.

Problem şu ki ülkemizdeki programlama yapanların pek çoğunun, programlamanın üzerine bina edildiği bu algoritmik düşünceden haberi azdır. Bu durum malesef sadece alaylılar için değil, BM okumuş kişiler için de geçerlidir, çünkü sektörümüzde sağlıklı bir bilimsel formasyondan bahsetmek mümkün değildir. Biz okulu bitirirken bir sayfayı kapatırız, işe girince sanki beynimizi sıfırlamışcasına, okuldan gelen her şeyi geride bırakıp, her şeye baştan başlarız. Bitirdiğimiz okul, diploma olarak işe yarar. Bu yüzden BM mühendisi çok kişi kendisini tanımlarken “bize okulda .NET öğrettiler” ya da bitirme projesinde “JSP ile e-kütüphane ya da e-ticaret sitesi yaptım” diyor.

Java eğitimlerinde algoritmalar için big-O  notasyonundan bahsettiğimde ya da örneğin float ve double’ı (floating-point) açıklarken sayılabilirlikten (countability) dem vurduğumda en iyi okulları bitirmiş gençlerin nasıl sanki ilk defa duyuyormuş gibi davrandıklarını hayretle izlemişimdir. Memleketimdeki kurumsal projelerin hemen hepsinin bir performans ve ölçeklenirlik problemi yaşamasının bence en temel sebebi, o projelerde bulunan kişilerin, eğitimleri ne olursa olsun, yukarıda bahsettiğim programlama için sahip olmaları gereken sağlıklı bir algoritmik düşünce yetkinliklerini taşımamalarıdır. Çünkü bizim için çoğu zaman aslolan şey, malesef sadece programlama dilini kullanmaktır. Bu tipte olan programcılar örneğin bir “for” döngüsü yazmayı sadece dil bağlamında bilirler, soyut olarak bir döngüyü algılamanın ne anlama geldiğinden uzaktırlar. Ben bir SQL sorgusu yazarken, veri tabanının arkada kaç tane işlem yapacağını anlamaya çalışan bir programcı göremedim örneğin bu ülkede. Ama “Oracle yavaş” diyenini gördüm. Bu yüzden işe alırken programlama yetkinliklerini ölçmek kadar algoritmik düşünce yetkinliklerini ölçmeye önem veren iş yerlerine çok saygı duyuyorum.

Bu anlamda programcılığın bilimsel arka planını ıskaladığımızı düşünüyorum. Bu anlayıştan dolayı, toplumuzda programlamanın harcı alem bir faaliyet ve meslek olarak görüldüğünün farkındayım. Daha önce de yazmıştım sanırım, bu ülkede yakaladığı doktor tanıdığına “doktor olmak istiyorum abi/abla ama tıp okumama gerek var mı” diyen bir genç yoktur herhalde. Ama ben tonla “programcı olmak istiyorum, BM okumama gerek var mı” diye soran genç arkadasımdan öte bir o kadar da “programcı olmak istiyorum, üniversite okumama gerek var mi” diye soran gençlerle karşılaşıyorum. Dahası, BM okurken en temel algoritmalar, işletim sistemi vb. derslere devam etmeyip, Php ile dışarıya ufak tefek site yapmayı amaç ve başarı olarak gören gençlerle de çok sık karşılaşıyorum. Halbuki örneğin algoritmalar ve veri yapıları, algoritmik düşüncenin geliştirildiği, disipline edildiği en temel derslerdir. Programlama dilleri dersi, dillere farklı yaklaşımların ele alındığı, örneğin veri kavramının farklı dillerde nasıl modellendiğinin ya da fonksiyonel algoritmik düşüncenin nasıl olabileceğinin tartışıldığı derslerdendir. Benzer şekilde veri tabanlarını sadece bir araç (tool) olarak görmek, ardındaki ilişkisel veri modeli altyapısını ele almamak, örneğin ilişkisel cebirden habersiz bir şekilde kalmak, nihayetinde veri modeli kavramından uzak bir şekilde, koskoca Oracle’ı, akıllı bir Excel olarak kullanmak gibi alışkanlıklar kazanmamıza sebep oluyor. Aslında tüm bu disiplinler hep kafamızdaki soyut, algoritmik düşünceyi beslemek ve gerçekleştirmek için vardırlar. Bu açıdan bakıldığında evet, programlama bir bilimdir ve biz programlamanın bu yönünü ıskalamaya devam ediyoruz.

Programlama sadece algoritmadan ibaret degil elbette. Programlama dilleri, altyapı sağlayan işletim sistemleri, dillerde geliştirilen bileşenler (components) ve çerceve (framework) yapılar, aslında bilimsel bir alt yapıya sahip programlamayı, hızla ve her şartta tekrar edilebilir ve iyi tanımlanmış bir sürece çevirme çabasından ibaret. İşin burası ise mühendisliktir. Zaten tek kişi anlamında bile bu şekilde uygulanabilir olarak bir mühendislik haline gelen programlama, birden fazla kişinin bulunduğu ortamlarda tamamen bir mühendislik disiplini olmaktadır. Örneğin yazılımın mimarisinden tutun da üretilen bilginin paylaşılmasına, kaynakların etkin kullanılmasına, değişimin yönetilmesine kadar ortaya çıkan farklı alt süreçler, yaptığımız şeyin programlamadan çıkıp yazılım geliştirmeye dönüsmesini sağlıyor. Bu haliyle yazılımı geliştirme, tamamen bir mühendislik disiplini haline gelmektedir.

İşin açıkçası, yazılım geliştirme faaliyetini “programcıların yaptığı iş” olmaktan çıkarıp bir mühendislik projesi olarak ortaya koymada da ciddi sıkıntılarımız var. Pek çoğumuza göre hala yazılım geliştirmek, program yazmanın çok az fazlası anlamına geliyor. Bu durum BT yöneticileri için de böyle malesef. Ya da mesela zaman zaman, yetkinliği ve yaptığı iş sadece programcılık ya da development olan bir kişiyi, kendisini Yazılım Mühendisi olarak tanıtırken de buluyorum.  Bu gibi karmaşıklıklardan dolayı da zaten sağlıklı bir Yazılım Mühendisliği mesleğine sahip olamıyoruz.

Pek çokları, yazılımı zanaat olarak da görüyor. İngilizce’de “craftsmanship” olarak ifade edilen bu kavram, bir el mahareti isteyen ve çoğunlukla usta-çırak ilişkisiyle geliştirilen bir melekedir. Yaptığımız iş, programlama, bu tanıma ciddi bir şekilde uyuyor. Hatta işimizi bu şekilde bir zanaat olarak görenlerin bir manifestosu da var. Bu topraklardaki yazılım ve Java kültürüne çok değerli katkılar yapan arkadaşımız Özcan da programcılığın neden bir zanaat olduğunu burada açıklıyor. En ünlü temiz kodcu olan Robert Martin de kitabının alt başlığını “A Handbook of Agile Software Craftmanship” olarak seçmiş. Yazar kitabının önsözünde kaliteli ya da “temiz” kod elde etmenin ancak “craftmanship” ile erişilebileceğini söyleyerek, aslında kaliteli ve temiz kodun ince iş ya da tabiri caizse zanaatkarın “göz nuru” ile ortaya çıkabileceğini vurguluyor. Benzer şekilde “Software Craftsmanship” kitabının sahibi olan Pete McBreen de kitabında bu işin usta-çırak yöntemiyle öğrenilmesini vurguluyor. Usta-çırak ilişkisi, Ingilizce’de “coaching” terimiye kastedilen şeydir ve ben danışmanlık ve eğitim vesilesiyle karşılaştığım pek çok pırlanta ayarında genç arkadaşın, bu ilişkiye sahip olamadığı için bir zanaatkar seviyesine gelemediğine ve ciddi vakit kaybettiğine şahit olmuşumdur.

Ben tüm bu açıklamalara katılıyorum, evet yaptığımız işin ciddi bir zanaat yönü var. Ama bu terim aynı diğer bilim, sanat ve mühendislik, terimleri gibi, işimizi tamamen açıklamıyor, bu anlamda zanaat da tamamlayıcı bir terim. Özellikle usta-çırak ilişkisi ile aktarılabilmesi, kaliteli iş için ciddi bir meleke gerektirmesi, işimizin zanaat tarafını destekleyen yönleri. Bundan dolayı şöyle diyebilirim: programcılığı, bir cam zanatkarının yaptığı gibi, prensipleri tamamen tecrübe ile elde edilmiş, usta-çırak ilişkisiyle yaşatılan bir meslek olarak görmek bence işimizin özellikle bilimsel ve mühendislik yanını ihmal etmek anlamına gelebilir. Ama öte yandan özellikle işimizi iyi yapmak için sabır ve melekelerimizi geliştirmeliyiz ve öğrenme sürecinde, önümüzdeki üstatlardan faydalanmalıyız.

Matematiğin soyut dünyası, kapılarını yaratıcılığa çok geniş bir şekilde açar. Matematik, özellikle de sayılar teorisi, aslen bir sanat eseri güzelliğindedir. Sayılar teorisininin çok güzel bir uygulaması olan algoritmalar ya da algoritmik düşünce de içerdiği aşırı karmaşıklık ve elverdiği yaratıcılıktan dolayı, evet bir sanattır. Biz programcılar ise işimizin sanat tarafını daha çok tasarım (design) olarak ifade ediyoruz. Ve muhtemelen biz programcılar, program yazarken aldığımız hazzı, bu işin sanatsal doğasından çıkarıyoruz. Hatta bu sanatsal haz bizi, yaptığımız işi sanat seviyesinde tutup, mühendisliğe dönüştürmekten de alıkoyuyor.

Sonuç olarak şunu diyebilirim: Birey olarak işimin bilimsel temellerinden haberdar olmalıyım. Bu ise ancak formal bir eğitimle mümkün olabilir. Birey olarak program yazarken, yazılım geliştirirken, bir zanaatkar edasıyla, ürettiğim şeye ve kalitesine önem vermeliyim, biriktirdiğim tecrübemi başkalarıyla, özellikle arkamdan gelenlerle paylaşmalıyım. İşimin yaratıcılık yönünün, zaman zaman kendimi bir sanatçı gibi hissettirmesine izin vermeliyim, bu yüzden yaratıcılığımı daima yaşatmalıyım. Ve tüm bunları, tekrarlanabilir ve değer katacak şekilde, takım arkadaşlarımla birlikte, müşterimin ihtiyaçlarını çözen bir mühendislik disiplini olarak uygulamalıyım.

Bol programlamalı günler dilerim 🙂

Toplam görüntülenme sayısı: 1343

12 Bunu beğendim 🙂
Tweet
Follow me
Tweet to @kaldiroglu
09 Kasım 2014

Programlama Nedir: Programlamanın Tabiatı ve Programcılık Üzerine – II Bilim mi, Mühendislik mi, Sanat mı Yoksa Zanaat mı?

Akin Bilgisayar Bilimleri, Programlama, Yazılım Mühendisliği programlama, programlama nedir

Farklı vesilelerle “programlamanın neliği” hakkında konuşuyoruz, okuyup yazıyoruz. Ben de burada daha önce “Programlamanın Tabiatı ve Programcılık Üzerine – I” başlıklı bir yazı yazmıştım. Bu konu üzerine düşünen ve bizzat çalışan farklı kişiler de yazıp çiziyorlar. Örneğin arkadaşım Özcan Acar burada programcılığın sanat mı yoksa zanaat mı olduğunu tartışırken burada da bu konuda bir başka programcının yazdıklarını eleştirmiş.

Sıklıkla programlama ve programcılık, mühendis olup olmamak, okullu-alaylı vb. bağlamlarda tartışılıyor. Ben “üniversiteli mi alaylı mı” konusunu burada ele almıştım. Orada da açık bir şekilde ifade ettiğim gibi aslolan, “bilerek yapmak”tır. Yapmayı sürdürülebilir halde tutan şey bilmektir. Yapamadıkça zaten o şeyi bilmiyoruz demektir. Dolayısıyla her şart altında yapabilen ve başkalarına aktarabilen kişi, yapabilmeyi sürekli bir davranışa dönüştürmüş ve onu herkesin anlayabileceği yapıda ifade etmiş kişi, gerçekten bilendir.

Öte taraftan, gerek akademide gerek ise pratisyenleri arasında, yazılım mühendisliği olsun, onun çok temel ve belirleyici bileşeni olarak programlama olsun, tüm bunların gerçekte ne oldukları üzerine eskiden bu yana tartışmalar yapılmakta. Yani yaptığımız iş, bir bilim midir, yoksa mühendislik midir yoksa sanat mıdır yoksa zanaat mıdır? Ya da hepsi bir arada mıdır?

ABD’de yazılım sektörüne nitelikli insan yetiştiren bölümler ağırlıklı olarak “Computer Science” olarak adlandırılmalarına rağmen, bu bölümlerin yaptığı seyin ne kadar “bilim” olduğuyla ilgili şüpheler çoktur. Belki de bu isimlendirme bir öykünmedir ya da bu bölümlerin tarihi olarak Matematik’ten çıkmış oldukları düşünülerek isimlerine “science” eklenmiştir. Aslında iki kelimeden oluşan bu ismin problemi sadece “science” kelimesinden kaynaklanmıyor, esas problem”computer” kelimesinde. Dijsktra bir zamanlar “astronomy ne kadar teleskoplarla ilgiliyse, computer science da ancak o kadar bilgisayarlarla ilgilidir” (“computer science is no more about computers than astronomy is about telescopes.”) demişti.

“Computer Science” isimlendirmesi ilk defa 1959’da kullanılmasına rağmen yerine zaman zaman farklı kelimeler teklif edildi. “Datalogy” ya da “computics” bu alternatif isimlerden bir kaçı. Bu anlamda sanırım Avrupalılar daha düzgün bir isimlendirme yapmışlar. Bu alan için Avrupa’da genel olarak “automatic information” anlamlarına gelen “informatics”in türevleri kullanılıyor. Aslen yapılan iş de zaten verinin ve bilginin otomatik olarak işlenmesidir. “Computer” ya da “bilgiayar” sadece bir araç. Biz ise bu durumu dilimizde “bilgi” ve “saymak” kelimeleri ile ifade etmişiz. Başlarda, 70li yıllarda yani, bilgisayar yerine “elektronik beyin” dendiğini de hatırlıyorum ben. (Ülkemizde bu alanın “Bilgisayar Mühendisliği” olarak ifade edilmesi, hele benim üniversitemin, İTÜ, “Kontrol ve Bilgisayar Mühendisliği” gibi dahiyane bir isim 🙂 bulması ise başka bir tartışma konusu.) (Bu konudaki isimler için hızlıca Wikipedia‘ya bakabilrisiniz.)

Tanınmış ve tecrübeli bir bilim adamı olan Peter J. Denning, savunma amacıyla yazdığı “Is Computer Science Science?” başlıklı makalesinde, “Computer Science”ın (CS) ne kadar bilim olduğunu tartışıyor. Yazar makalesine alt başlık olarak şunu koymuş: “CS bilim olmanın tüm şartlarını taşıyor fakat kendinden kaynaklanan bir güvenirlik problemi var.” Yazara göre CS’i oluşturan 3 farklı disiplin vardır: Matematik, bilim ve mühendislik. Denning, CS’in, Fizik ve Kimya gibi bir “exact science” (bu terimi dilimizde nasıl ifade ediyoruz bilmiyorum, “kesin bilim” mi, bir kaç yere çevirisine baktım, “pozitif bilim” olarak karşılık verilmiş ki bu durum doğru bir çeviri değil bence) olduğunu savunuyor. Çünkü CS, adında “computer” kelimesini barındırsa da aslen bilgiyi işlemenin bilimidir. Algoritmalar ve hesaplamalı bilim (computational science) CS’i bilim yapan alanlardandır ve sayısal kesinliğe sahip çalışmalardır. Yazılımı tasarlama ve geliştirme ise temelde mühendislik çalışmasıdır. Yazar CS’in ne kadar bilim olduğu konusundaki itirazlara cevap vermeye çalışırken, “Computer Science”daki “science” yani “bilim” kısmının, diğer iki disiplin olan mühendislik ve matematikten daha geride kaldığını kabul ediyor ve ekliyor: Bu durum yakında düzelecektir.

Ben yaptığımız işin bir bilimsel tarafının olduğunu bir gerçek olarak kabul ediyorum. Programlama ve yazılım geliştirmenin son derece matematiksel dolayısıyla da bilimsel bir “hesaplama” alt yapısı var. Zaten bizim “bilgi” ve “saymak” kelimelerini yanyana getirerek ifade ettiğimiz şey İngilizce’de “computer” yani “”hesaplayıcı”dır. Veriyi ve bilgiyi işlemenin yöntemi olan her türlü algoritmik yapı, doğrudan matematiğin de konusudur. Algoritmaların karmaşıklığı, zaman ve bellek açısından ihtiyaçları, daha etkin şekilde ifade edilmeleri, tipik bir uygulamalı matematik ve sayılar teorisi konusudur. Sonuçta yazılan her program bir şekilde bir algoritmadır dolayısıyla da matematiğin ve bilimin konusudur.

Donald Knuth, programlama dünyasının muhtemelen yaşayan en ünlüsü olup, uzun yıllar Stanford’da hocalık yaptı. 1962 yılında tek cilt olarak yazmayı düşündüğü temel programlama kitabı, şu anda 4 cilt olarak yayınlanmış durumda. Hala yayınlamayı planladığı 3 cilt daha var. Knuth, programlamanın en temel kitabı olarak bilinen bu diziye, “The Art of Computer Programming” ismini vermiştir.  Çünkü Knuth’a göre programlama, bir sanattır.

Knuth gibi programlamanın bir sanat olduğunu iddia edenler, ondaki yaratıcılığa (creativity) ve bu yaratıcılığı ortaya çıkaran ilham (inspiration) kavramına vurgu yaparlar. Evet, yazılım geliştirmek de programlamak da zihinsel dolayısıyla da kavramsal, soyut ve son derece karmaşık uğraşlardır. Yazılım geliştirmenin bir sanat olduğunu iddia edenler, onun deterministic olmayan, yani başından, sonunun öngörülemeyeceği gerçeğini öne çıkarırlar. Bence de programlama, bilim ile sanatın iç içe geçtiği alanlardandır.

Mahiyeti itibariyle program yazmak ile bir film senaryosu yazmak ya da ne bileyim beste yapmak çok farklı şeyler değil. Yola çıkarken tüm detayını kestirmiş olamazsınız çünkü, ancak nereye gitmek istediğinizi bilirsiniz, hedefiniz vardır ama arasını ancak yolda anlarsınız çünkü kavramsal bir sentezlemeden bahsediyoruz. Programlama bir sanattır, çünkü doğru yoktur, aynı şeyi herkes tamamen farklı şekillerde yapabilir.

Sanatta da programlamada da çoğu kez ortaya koyduğunuz şey hiç bir zaman bir seferde mükemmel olmaz, muhtemelen pek çok yazarın, bestecinin eserlerine son halini vermeden, üzerinde senelerce çalıştıkları gibi yazdığımız programların da üzerinden tekrar tekrar geçmemiz gerekir. (Biz buna refactoring diyoruz.) Ve her bir üzerinden tekrar geçiş eserimizi daha mükemmel kılar ve bize muthiş bir haz verir. Hangimiz şöyle bir şey yaşamamıştır: Daha önce defalarca baktığınız, gördüğünüz kodunuzun öyle bir yönünü farkedersiniz ki, çok ufak bir değişiklikle örneğin müthiş bir kısaltma, hızlandırma yaparsınız ya da o ana kadar gözünüze çarpmamış bir hatasını giderirsiniz. İşte bu yaratıcılıktır, öngörülemezliktir ve böyle bir tecrübe sizin egonuzu tavan yaptırır. Belki de bu sanat ruhudur programcıları, diğer insanlar gözünde “farklı” kılan. Belki de bizi bilim adamlarından ayıran, “benimkisi daha güzel” düşüncesinin çok yaygın olmasıdır. Belki de başkalarının “ne anlıyorsun bundan” diye sorduğu durumda, o garip ifadelere bakarak sanki bir Mevlevi ayinindeymişcesine haz almaktır programlama.

Ben bu satırları yazarken Knuth’ın The Art of Computer Programming serisinin ilk cildini indirdim Internet’ten ve önsözünü okumaya başladım. Bakın ne diyor üstad:

“The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music.”

Yani

“Dijital bir bilgisayar için program hazırlama süreci çok çekicidir, (bu durum) bunun sadece ekonomik ve bilimsel olarak mükafatlandırıcı/faydalı olmasından dolayı değil, aynı zamanda bir şiir yazmak ya da müzik bestelemek gibi estetik bir tecrübe olmasından dolayıdır.”

(Bu arada bu kitabı okuyanların CVlerini Bill Gates’e gönderebilirler, çünkü kendisi bu kitabı okuyabilenlerin nasıl bir tip olabileceğini biliyor 🙂 Kaynak, Wikipedia.)

Yazılım projesi de programlama da bir sanat eseri gibi yolda nelerin gündeme geleceğini ve nihayetinde detayda neyin ortaya çıkacağını çok da bilmeden girişilen bir çalışmadır. Bilimin prensipleri vardır, halbuki sanat daha çok çalışmayla ortaya çıkar, defalarca denersiniz. Bilim sizi sınırlar, sanat ise ancak serbest kılar. Bilim var olanı açıklar, sanat ise sentezler, yeni şeyler ortaya koyar, bu anlamda bilim bulur ama sanat yaratır.

Yaptığımız işin sanatsal tarafı olduğu kesin, tamamen sanat olmadığının kesin olduğu gibi. Bilimsel tarafı olduğu da kesin, tamamen bilim olmadığı gibi. Ama aslolan, nasıl olması gerektiği. Code Complete’in yazarı Steve McConnell da bu konuyu düşünenlerden. Buradan ulaşabileceğiniz yazısında “Yazılım Mühendisliği ne olmalıdır?” sorusunun daha doğru olduğunu ifade eder ve bu soruya “mühendislik” olarak cevap verir. YMnin örneğin iş analizi son derece subjektif dolayısıyla yaratıcılığa el veren, sanatsal öğeler içerebilir, programlama kısmı gibi. Ama belli ki bu tür pek çok farklı çalışmayı bir süreç halinde ve tekrar edilebilir olarak formüle edebilmek, onu mühendislik disiplini haline getirebilmekle mümkün olabilir. Gittikçe daha hızlandırmak, daha verimli hale getirmek örneğin ve çıktı kalitesini arttırmak, böyle bir mühendislik disiplinin amacı olabilir. Böylelikle bilimsel YM süreçleri ve metotları oluşur ve bunları uygulayanlar iyi yazılım ürünleri üretirler.

Aslında McConnell’in Code Complete isimli kitabının 2. bölümünde de belirttiği gibi, yazılımda da diğer pek çok şeyde olduğu gibi metaforlar kullanırız. Bu metaforlar konuyu anlamamızı kolaylaştıran benzetmelerdir. Ve bu metaforların hiç birisi kendi başına doğru değildir. Örneğin, projelerin sonunda, canlıya geçiş sırasında çalışanların kendilerini “itfaiyeci” gibi hissetmeleri, yaptığımız işin tamamını resmetmez.

Söyle diyor McConnell:

“A confusing abundance of metaphors has grown up around software development. David Gries says writing software is a science (1981). Donald Knuth says it’s an art (1998). Watts Humphrey says it’s a process (1989). P. J. Plauger and Kent Beck say it’s like driving a car, although they draw nearly opposite conclusions (Plauger 1993, Beck 2000). Alistair Cockburn says it’s a game (2002). Eric Raymond says it’s like a bazaar (2000). Andy Hunt and Dave Thomas say it’s like gardening. Paul Heckel says it’s like filming Snow White and the Seven Dwarfs (1994). Fred Brooks says that it’s like farming, hunting werewolves, or drowning with dinosaurs in a tar pit (1995). Which are the best metaphors?”

Yani

“Yazılım geliştirme etrafında şaşırtıcı sayıda metafor türemiştir. David Gries’e göre yazılım yazmak bir bilimdir (1981). Donald Knuth ise o bir sanattır der (1998). Watts Humphrey, o bir süreçtir der (1989). P. J. Plauger ve Kent Beck ise onun bir araba sürmek gibi olduğunu söylerler, ama buna rağmen tamamen zıt sonuçlara ulaşırlar (Plauger 1993, Beck 2000). Alistair Cockburn ise o bir oyundur der (2002). Eric Raymond ise onun bir pazar yeri olduğunu söyler (2000). Andy Hunt ve Dave Thomas ise o bir bahçıvanlıktır der. Paul Heckel ise o bir “Pamuk Prenses ve Yedi Cüceler” (Snow White and the Seven Dwarfs) (1994) filmini çekmek gibidir der. Fred Brooks ise o, kurtları avlayan ya da dinazorları bir tuzakta boğan çiftçilik gibidir der (1995). Sizin en iyi metaforunuz hangisi? ”

İşte size bir kaç tartışma daha: SD Times, Jason Gorman, CodeSqueeze, Research Gate’de iki tane, 1 ve 2 ve Jonah Kagan.

Eskiler “barika-i hakikat müsademe-i efkardan çıkar” demişler, neticede kimsenin aksi fikir belirtmediği yerde hiç kimse zaten düşünmüyor demektir. Neticede düşünmek, yazarak paylaşmak ve eleştirilmek hem cesurca hem de güzel bir şey. 

Toplam görüntülenme sayısı: 1952

15 Bunu beğendim 🙂
Tweet
Follow me
Tweet to @kaldiroglu
03 Kasım 2014

“Java ile Nesne Merkezli Programlama” Dersi Sunumları Güncellendi

Akin Java

Sevgili Java severler 🙂

Java Dersleri sayfasından ulaşılan “Java ile Nesne Merkezli Programlama” sunumlarının ilk 8 bölümü güncellendi. Eskiden Scribd.com’da olmalarından dolayı erişim problemi oluyordu, dosyaların yerlerini değiştirdim, artık böyle bir problem olmayacak.

Sunumlarım ne kadar faydalı olursa benim için o kadar keyifli bir durum olur. Bu yüzden sunumlarda bulduğunuz, yanlış, eksik, anlatım bozukluğu vb. sıkıntıları bana bildirirseniz sevinirim, isminizi de ilgili sayfalarda listelerim 🙂 Nihayetinde hatasız iş, insanların yapabileceği bir şey değil.

İyi okumalar.

 

Toplam görüntülenme sayısı: 1475

9 Bunu beğendim 🙂
Tweet
Follow me
Tweet to @kaldiroglu
26 Ekim 2014

Seminerler

Akin Java, Kültür, Bilgi ve Düşünce, Yazılım Mühendisliği Java, Seminer, Temiz kod, yazılım

Vemekte olduğum seminerlerle ilgili sayfaya blogumun sağ üstteki bağlantısından ya da buradan ulaşabilirsiniz.

Seminerlerim bedelsiz olup, sunumunu kurumlarda (yazılım şirketleri, BT birimi bulunan kurumlar, dernek vs. bir araya gelinen yerler ile üniversiteler) sağladığı yerlerde yapmaktayım. İTÜ Teknokent yönetiminin desteğiyle ARI-3 konferans salonunda da verdiğim bu seminerleri, buradan da duyuracağim.

Seminerleri hem tanışma, hem teknik sohbet hem de tanıtım amaçlı olarak yapmaktayım. Ben keyif alıyorum ve katılımcılardan öğreniyorum.

Davet edin, geleyim, tanışalım ve keyifli bir sohbet yapalım 🙂

Toplam görüntülenme sayısı: 670

8 Bunu beğendim 🙂
Tweet
Follow me
Tweet to @kaldiroglu
«< 30 31 32 33 34 >»

Günlüğüme Hoşgeldiniz

Bu günlükte, Yazılım Mühendisliği, Bilgi Teknolojileri, Java, kişisel gelişim ve zaman zaman da diğer konulardaki düşüncelerimi sizlerle paylaşacağım. Umarım beğenir ve hoşça vakit geçirirsiniz.

Her türlü düşüncenizi, yorum olsun, beğeni ya da eleştiri olsun, bana iletmenizi rica ediyorum sizden. Ayrıca bana akin@javaturk.org adresinden ya da Twitter'dan ulaşabilirsiniz. Videolarıma da buradan ulaşabilirsiniz.

Teşekkür ederim.

Akın Kaldıroğlu

Rahat Okumak İçin

A Decrease font size. A Reset font size. A Increase font size.

Sosyal Medya

  • Twitter
  • Facebook
  • LinkedIn
  • Youtube

Son Twitlerim

→ Takip Etmek İçin

Abone Olun

Emalinizi girerek yazılardan haberdar olun.
Loading

Son Yazılarım

  • Udemy Eğitimlerim Üzerine
  • (başlıksız)
  • Clean Code / Temiz Kod Eğitimi Udemy’de
  • Java ile Nesne-Merkezli Programlamaya Giriş Eğitimi Udemy’de
  • Selsoft Video Eğitimleri
  • Spring ile Kurumsal Yazılım Geliştirme
  • Corona Günlerinde Design Patterns
  • Corona Günlerinde Java
  • JDK 10 ve “var” Özelliği
  • Onur Özcan
  • Analist ve İş Bilgisi
  • Farklı Dillerin Bakış Açısıyla Nesne-Merkezli Programlama
  • Java Nedir?
  • Bilgi Teknolojilerinde Yetenek Yönetimi – II: Tanımlar ve Eleştiriler – I
  • Alelade Hikayeler – II: Bir Başka Performans Problemi

Yazı Kategorileri

Yazı Takvimi

Mart 2026
P S Ç P C C P
 1
2345678
9101112131415
16171819202122
23242526272829
3031  
« May    

Yazı Arşivi

Blogroll

  • Binnur Kurt'un Günlüğü
  • Ender'in Java Blogu
  • Erdem Seherler
  • Kızımın Günlüğü
  • Kurumsal Java
  • Levent Karagöl
  • Levent'in Java Blogu
  • Mert Can Akkan’s java tips,options, news…
  • Yaşar Safkan
  • Yasin Saygılı
  • Yazı Dünyası

Yazı Etiketleri

analiz Bilmek C Desen design pattern EJB Eğitim Fortran Hibernate Java Java'ya nasil baslarim Java dersleri Java EE Java Persistence API Java SE Java Sertifika Java Öğren Java öğreniyorum Java öğrenmek JPA Kalıp Kurumsal Java nesne nesne-merkezli No Silver Bullet object object-oriented Oracle Java Certifications pattern performans programlama programlama dilleri programlama nedir sertifika singleton tasarım tasarım deseni tasarım desenleri tasarım şablonu yazılım yazılım geliştirme Yazılım Mühendisliği yazılımın doğası yazılımın zorlukları Şablon

↑

© Java Günlüğüm 2026
Powered by WordPress • Themify WordPress Themes
 

Yorumlar Yükleniyor...