Search Results for: java

ABD Üniversitelerinde Giriş Seviyede Programlama Dili Olarak Ne Ögretiliyor?

Bilgisayar Bilimleri, Java, Yazılım Mühendisliği

“Neden Üniversitede Java?” konulu çalışmam sırasında ABD’deki üniversitelerin Computer Science (CS) bölümlerinde hangi dillerin kullanıldığına bir miktar göz attım. Konu ile ilgili zaten yakın tarihte “Python is Now the Most Popular Introductory Teaching Language at Top U.S. Universities” başlıklı tahrik edici bir yazı yayınlanmıştı. Bu çalışma bilgi verici olmakla birlikte verilerin ve sonucun sıhhatı hakkında belli şüpheler de oluşturuyor. Örneğin yazının sonunda ögrenci ve hocalardan gelen pek çok cevapta düzeltmeler söz konusu.

Bu yazıya göre ABD’nin en iyi 39 CS bölümünün programlamaya giriş derslerinde ağırlıklı olarak Python kullanılıyor ve Java bu sıralamada ikinci sırada görülüyor. 39 bölümün 27sinde Python, liseden gelen öğrencilere ilk gösterilen dil. 22 bölümde Java ilk gösterilen dil olarak belirtilmiş. 27 ve 22 sayılarının toplamının 39’dan yüksek olmasının sebebi, bazı bölümlerde programlamaya giriş derslerinin birden fazla olmasi, bazı bölümlerde de iki dilin birden ele alınıyor olmasıdır.

Dikkatimi çeken şey, hatta tuhaf gelen, programlamaya giriş derslerinde Matlab’in de bazı bölümlerde ele alınıyor olması. Çünkü Matlab, bir programlama dili değil, yüksek seviyeli, declarative bir hesaplama ortamıdır. Listede Matlab’i kullanan okullara biraz göz attım. Örneğin UCSD’de listede belirtildiği gibi Matlab okutuluyor ama programlamaya ilk giriş dersi Matlab’in olduğu CSE 7 değil, C okutulan CSE 5A. Listede CSE 5A da görünmekte ama CSE 7’yi ne kadar ilk okutulan giriş dersi olarak görmek mümkündür, bunun daha özelde araştırılması gerekli.

Benzer şey UIUC’de de giriş dersinde Matlab’in okutulduğunun iddia edilmesinde de söz konusu. CS101’de hem Matlab hem de C kullanılıyor ve bu bölümde CS125 nolu “Introduction to Computer Science” dersinde ise Java kullanılıyor. Belli ki pek çok bölümde farklı tipte öğrencilere yönelik farklı giriş dersleri var. Bu karışıklık biraz da bundan kaynaklanıyor.

Açıkçası, Python’un giriş derslerinde gösterilen en gözde dil olması kimseyi şaşırtmamalı. Liseden gelmiş gençlere algoritmik düşünceyi, bilgisayara programlama yoluyla işler yaptırmayı öğretmek kolay şey değil. İşin akademik tarafından daha önemlisi belki de pedagojik tarafı. Ben zaman zaman üniversite öğrencileriyle eğitim yapıyorum, yaşadığım zorlukları biliyorum. Karmaşık kavramları onların anlayacağı hale sokmak kolay bir şey değil. Bunu yapınca açıkçası ben de çok şey öğreniyorum ama yorucu bir iş.

Python’un son derece basit ve yüksek ifade gücüne sahip söz dizimi (syntax), dinamik tipli bir dil olması, yorumlanan bir scripting dili olması belli ki giriş dili olarak ABD’de üniversitelerin çoğunluğu tarafından tercih ediliyor. MIT, Carnegie-Mellon gibi önde gelen üniversitelerde programlamaya giriş dersinde Python kullanılıyor. (Bu konudaki bir yazıya buradan ualşabilirsiniz.)

Python kullananlar, bu dil ile çok daha hızlı bir şekilde program yazmaya başlayabildiklerinden bahsediyorlar. Belli ki bu sebeplerden dolayı Python, sektörde kullanımı açısından ilklerden birisi olmasa da öğrenme açısından pek çok avantajı var. Ülkemizde benzer şekilde Python’u giriş dersinde kullanan bölüm var mı bilmiyorum ama bu dilin alternatif olarak değerlendirilmesi gerekiyor. Dünyada Python’u kullanan okulların listesine buradan ulaşabilirsiniz.

Python ülkemizde pek kullanılan bir dil değil. Üniversitelerin de pek gündeminde değil bildiğim kadarıyla. Lakin ABD’de özellikle finans sektöründe veri işleme (data science) konularında yoğun olarak kullanılıyor. Belli ki Python, veri işleme ve istatiksel programlama konularında ciddi desteğe sahip ve cekirdek programcı olmayan data analistler ve matematikçiler big data ile ilgiliişlerini Python ile gorebiliyorlar. Bu konuda buradaki yazıya göz atabilirsiniz.

Tipik bir CS eğitim planını sizlerle paylaşmak istiyorum. Malum, Stanford Üniversitesi, gerek genel eğitim kalitesi gerek ise CS ve mühendislik eğitimiyle son derece saygın bir yer. SU’da CS eğitimine başlayanlar tipik olarak şu dersleri takip ediyorlar:

  • cs106A Programming Methodology: Java ile programlamaya giriş yapılıyor.
  • cs106B Programming Abstractions: C++ ile daha ileri programlama ve
  • cs106L Standard C++ Programming Laboratory: Bu ders ise cs106B’nin laboratuvar dersi.
  • cs108 Object-Oriented Systems Design: Bu ders ise Java ile derinlemesine nesne yapılarının ele alındığı ders. Bu derste Java Se’nin standart konualrı yanında servlet-JSP gibi web development konuları da ele alınıyor.

Bu liste 2014-15 Sonbahar çeyreği için verilmiş olup buradan ulaşılabilir durumda.

Bu yazıda ABD üniversitelerinin CS bölümlerindeki derslerde kullanılan dillerden bahsettim ama bu programlara yakından baktığınızda göreceğiniz şey, odak noktalarının dil olmadığı gerçeğidir.

Hoşcakalın.

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

Nasıl Yazılımcı Olalım? – I: Üniversiteli mi Alaylı mı?

Kategorisiz

Sıklıkla yazılımcı olmak isteyen arkadaşlardan bana fikir soran emailler geliyor. “Yazılımcı olmak istiyorum, ne okuyayım?” diye soruyorlar. Gerçi bu soruyu “Yazılımcı olmak istiyorum, ne yapmalıyım?” şeklinde soranlar da oluyor ama ben her halukarda “Yazılımcı olmak istiyorum, ne okuyayım?” sorulmuş gibi cevap vermeye çalışıyorum 🙂

Öncelikle şunu belirteyim en baştan: Bir şeyi ögrenmenin tek yolu üniversite okumak değildir. Hatta lise ya da ilkokul okumak ta değildir. Ama ilkokul-ortaokul-lise-üniversite gibi formal kurumlarla eğitim ve öğretim almak ve bir konuda bu yolla yetkinlik sahibi olmak, bir şeyi öğrenmenin zamanımızda en temel, en yaygın ve en kolay yoludur.

Alternatif öğrenme yolları olan insanlar farklı şeyleri deneyebilirler. Örneğin ABD’den bildiğim “home schooling” ya da “evde öğretim” bir alternatiftir. Okuldaki örgün egitimi değişik sebeplerle istemeyen ve evinde kendisi ve tuttuğu ögretmenlerle ya da ücretli kurslar yanında kilise-cami gibi cemaat organizasyonları vs. desteklerle çocuğunu eğiten ve ilkokul-ortaokul-liseyi bu şekilde bitirmesini sağlayan çok ciddi bir kitle var orada. Keşke bizde de devlet bu özgürlüğü bize tanısa; açık ki hem devlet olarak böyle bir özgürlük hem de toplum olarak böyle bir sorumluluk anlayışından çok uzağız malesef.

Ya da belki farklı toplumlarda etraftaki ilim sahiplerinden diz-dize eğitim alan kişiler vardır ya da aklıma gelmeyen başka yöntemler. Ama açık ki ülkemizde ne evden öğretim var ne de sektörümüzdeki bilgi ve tecrübeyi klasik yöntemlerle elde edebiliriz. Sektörümüze yönelik kurs vb. ögretim merkezlerinin zaten eğitim vermek gibi bir hedeflerinin olmadığını, öğretmek noktasında da yoğun bir bilgi ve eğitmen kirliliği içinde boğulduğunu, dersanecilik mantığıyla, daha çok umut sömürüsüne dönüştüğünü görmemek mümkün değil diye düşünüyorum. İyi hatırlıyorum, üniversite sınavında 3-4 sene bir şey yapamamış birinin bana elinde bu tür kurslardan birisinin broşürüyle gelip, 8-10 bin TL ödeyerek “Yazılım Mühendisliği” kursuna gitmek için bana akıl danışması, hele benim gibi birine bu yapması büyük cesaret işiydi 🙂 Burada bu konuyla ilgili güzel bir yazı var.

Yukarıda da bahsettiğim gibi, üniversite okuyarak formal bir yolla bir konuda bilgi sahibi olmak, bir şeyi öğrenmenin zamanımızda en temel, yaygın ve kolay yoludur. Lakin daha önce de bu blogda belirttiğim gibi, aslolan tutku, yetenek, gayret, azim ve disiplinli çalışma gibi sıfatlardır bir insanı bilgili, yetkin ve başarılı kılan. Bence bu noktada aslında bir insanın liseyi nerede ve nasıl okuduğu muhtemelen üniversiteyi nerede nasıl okuduğundan daha önemlidir.

Yazılım ve etrafındaki teknolojilerle ilgili herhangi bir formal eğitim görmemiş yani işletme, felsefe vb. çok farklı konularda eğitim görmüş ama belli ki tutukusu, gayreti, zekası ve akıllıca kararlarıyla kendini yetiştirmiş son derece yetkin insanlar gördüm ve beraber çalıştım. Bu insanlar bilgisayar mühendisliği vb. konularda eğitim görmemişlerdi ama şurası kesindi ki iyi eğitim almışlardı, disiplinli, çalışkan ve akıllı insanlardı. Ve bilgiye ve bilenlere karşı tevazu içindeydiler ki o seviyelere gelebildirler.

Bu duruma bir de tersinden bakalım. Üniversite okumuş olmak bilgilenme ve yetkinlik kazanma için her şeyi çözüyor mu? Tabi ki çözmüyor. Bilgisayar mühendisliği eğitimi almış olmasına, hatta lisede çok iyi yerlerde okumuş, üniversiteye giriş sınavlarında derece yapmış olmasına rağmen herhangi bir sistemli çalışma disiplini kazanmamış (daha doğrusu muhtemelen çok iyi sahip olduğu halde üniversitede ya da sektörde çalışırken kaybetmiş), bakkal vari iş yapan, ya da en temel örneğin işletim sistemi kavramlarından habersiz, yazdığı programın karmaşıklığı sorulduğunda ilk defa duymuş gibi davranan kişilerle de karşılaştım. İyi BM bölümlerinden mezun olup, daha doğru düzgün isimlendirme yapamayan, örneğin bana “Akın bey şöyle 5 dakikada bize threadleri anlatırmısınız” diyen insanlarla da karşılaştım. Bilgi ve tecrübe bu kadar da aşağılanmaz ki? Değişik kişilere atfedien “Bu kadar cehalet ancak tahsille mümkün olur” bu olsa gerek. Benim 10 yaşındaki kızım, bilgiye ve bilene böyle yaklaşmıyor.

İki senelik meslek yüksek okulu bilgisayar programcılığından mezun ama pek çok bilgisayar mühendisinden daha çalışkan, daha güzel iş çıkaran kişiler de gördüm.

Sonuçta durum şu: Kimse kalkıp ta “doktor olmak istiyorum, tıp okumalı mıyım?”diye sormuyor. Bereket sormuyor 🙂 Ama “yazılımcı/programcı olmak için üniversite okumak gerekli midir?” sorusu üzerine internette tonla tartışma var. Nedir yazılımcı/programcı olmayı bu kadar basit gösteren şey bize? Ben en temel Java eğitimlerine “java” kelimesinin tarihi ve batılı dillere geçişiyle başlıyorum. Anlamak böyle bir şey çünkü, kendisinin bile 10 gün sonra ne yaptığını anlamadığı, üç-beş PHP cümlesini bir araya getirerek bir web sayfası yapmayı programcılık ya da yazılımcılık olarak gören zihniyetteki kişileri, diş çektirmek için eli alet görmüş bir nalbanta falan göndermek lazım bence 🙂

Her hangi bir üniversite bitirmediği halde kendini yetiştirmiş kişiler de gördüm ama hakikatten iyi olanları o kadar nadir ki. Bu türden kişilerin, ileri konularla uğraşacak noktalara gelebilmesine rağmen, en temel konularda hem bilgi ve beceri hem de yöntem açısından eksik ve sıkıntılı olduklarına defalarca şahit oldum. Bunun en temel sebebi ise “eğitim” eksikliği, yani formal olarak bilgi ve beceri aktarımının olmaması. Bilgi ve beceri, aynen bir binanın temelsiz olamaması gibi ancak sistemli bir şekilde üst üste konarak elde edilecek şeylerdendir. Bir şeyi öğrenmenin en kolay, en basit yolu ise olsa olsa sistemli öğrenme olabilir. Sadece birilerinin yaptıklarına bakarak, internetten kod örnekleri indirip çalıştırarak hatta sağlam ve ciddi bir şekilde kitap okuyarak bile gerekli yetkinlikleri elde etmek hem zordur hem de uzun yoldur, çok vakit kaybettirir. Nihayetinde bu riskleri almak yerine doğru düzgün, sistemli bir eğitim almak zaruridir.

Bu noktada “yazılımcı/programcı olmak için bilgisayar mühendisliği okumak gerekli midir?” sorusunun cevabını bir sonraki yazıda vermeye çalışacağım.

 

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

Programcı Psikolojisi ve Yazılım Kalitesi

Java, Yazılım Mühendisliği

Aslında programcı psikolojisi malesef yazılım dünyasında üzerine çok da eğilinen bir konu değil. Halbuki, programcılar ve developerlar, sonuçta yazılımın esas çalışan kısmını, executable codeu, üretenler kişilerin nasıl düşündükleri, işlerini yaparken hangi düşünsel süreçlerden geçtikleri, bu kadar zor, odaklanma isteyen ve çok yönlü ve faktörlü, matematiksel bir işi yaparken neleri, nasıl göz önüne aldıkları son derece önemli.

Takip edebildiğim kadarıyla, aslında pek çok psikolojik ve bilişsel (cognitive) akademik ve uygulamalı çalışmalara konu olabilecek zengin bir alan olmasına rağmen ben bu konuda aktif bir çevre pek yok. Gerald Weinberg’in ünlü “Psychology of Computer Programming” dışında özel olarak bu konuya hasredilmiş pek bir çalışma yok gibi. Ama ben bu yazıda bu konuda yapılmış eski de olsa son derece yol gösterici bir çalışmadan bahsetmek istiyorum.

1976 yılının Şubat ayında, “Human Factors: The Journal of the Human Factors and Ergonomics Society” isimli dergide, G. Weinberg ve E. L. Schulman “Goals and Performance in Computer Programming” başlıklı bir makale yayınladılar. Bu makale aslında onların, programcılar üzerine yaptıkları deneysel bir çalışmayı anlatıyordu. Kısaca özetlemek gerekirse deney şöyle: Programcılardan oluşan 5 farklı takıma aynı programlama görevi verilir. Görev, Gaussian eleminasyon yöntemini kullanarak bir lineer denklem takımını çözecek programı yazmaktır. Fakat, görevle birlikte her takıma, yazacakları programın kalitesiyle ilgili birer de hedef verilir. Örneğin bir takıma en az çalışmayla bu görevi bitirme hedefi verilirken diğer takıma en az statement kullanarak programı yazmaları söylenir. Diğer hedefler ise, en az bellek kullanmak, en rahat anlaşılır kodu (clearest code) yazmak ve en rahat anlaşılır çıktı (clearest output) üreten kodu yazmaktır.

Takımlar görevlerini başarıyla bitirirler. Beş takımın dördü, kendisine verilen hedef açısından en iyisini yapmıştır, bir takım ise hedefinde 2. olmuştur. Yani takımlar programlama işini yaparken kendilerine verilen kalite hedeflerini tutturmuşlardır denebilir. İlginç olan taraf burası değil, diğer sonuç: Takımlar, kendilerine verilen hedef dışındaki diğer kalite konularında tutarsız bir şekilde davranmışlardır. Yani hedefleri olan dolayısıyla da odaklandıkları noktalarda çok iyi performans gösterirken, diğer takımların kalite noktalarında ciddi şekilde çuvallamışlardır. Bu durumu aşağıdaki tablo iyi bir şekilde gösteriyor.

Weinberg Experiment

Yukarıdaki tablodaki sonuçlardan, her takımın kendi hedefi olan kalite noktasında en iyisini (birisi en iyi ikincisini) yaparken, diğer kalite noktalarında gelişi güzel davrandıklarını anlıyoruz. Peki, bu sonuçları nasıl açıklayabiliriz ya da yorumlayabiliriz? Bu deney üzerine konuşan bir kaç yazar, bu durumu şöyle özetliyordu: “Be careful what you ask for – You may get it”, yani “Ne istediginize dikkat edin, elde edebilirsiniz”. Bunu diyenlerden birisi de bu dünyanın en iyi bilinen kişilerinden Barry Boehm. Ona göre bu bu çalışmanın iki sonucu var:

  • Yazılım geliştiriciler, motivasyonu yüksek insanlardır. Yani onlara bir hedef verdiğinizde, o hedefe ulaşmak için son derece ciddi ve sıkı bir şekilde çalışırlar.
  • Pratikte, farklı yazılım geliştirme hedefleri birbirleriyle çelişir. Örneğin yukarıdaki tabloya göre, ilk takım işi en az eforla yapmaya odaklanmıs ve bunu da başarmıştır. Ama belli ki ortaya çıkardıkları program anlaşılır olmakta en kötüsüdür ve kullanılan statement sayısı ve bellek miktarı açısından da sondan ikinci durumdadır. Benzer şekilde anlaşılır program yazan grup aynı ayarda anlaşılır çıktı üreten programı da yazmışlar ama

Yukarıdaki Boehm’in yorumalarını biraz geliştirebiliriz. Evet yazılımcıların ciddi çoğunluğu, program yazmaktan, değişik dil, araç ve teknikleri öğrenmekten zevk alan, öğrenmek için sürekli fırsat kollayan insanlardır. Tabi ki bunun pek çok istisnası var. İstisnaların büyük çoğunluğu ise bence ileri yaşlarda ortaya çıkıyor. Bu kadar yorucu bir işi, bu ülkedeki şartlarda yapmak uzun süre sonunda ciddi zihni ve ruhsal bozukluklar, en azından yorgunluklar oluşturuyor. Motivasyon konusunda kurumların tavırları, oradaki liderlikler de çok önemli rol oynuyor. Olumsuz yönetim ve eksik liderliğin olduğu ortamlarda da motivasyonu yüksek yazılımcıların her şeye rağmen uzunca bir müddet var güçleriyle çalışmaya devam etmenin yollarını bulduklarını çok sık gözlemledim. Fakat haklı olarak bu durum uzun sürmüyor, bir kaç yorucu pozisyon, yazılımcıyı idealistlikten, okuyup, araştırmadan uzaklaştırıyor ve bu durum işten ayrılma ile devam ediyor. Bence kötü yönetim ve eksik liderlikten kaynaklanan problemler sektörümüzdeki işten ayrılmaların en temel sebebidir.

Diğer yorum ile ilgili ise aklıma şunlar geliyor. Yazılım geliştirme, karmaşık ve pek çok kalite faktörü olan bir çalışmadır. Bu kalite faktörlerinin hepsini birden yerine getirmek zor hatta imkansızdır. Bu zorluğun ve imkansızlığın bence iki sebebi var. İlki, Boehm’in de belirttiği gibi, çelişen istekler. Örneğin yukarıdaki örnekten de açıkça görüldüğü gibi, programı geliştirmek için harcanacak efor konusunda bir hedef konduğunda, yazılımın en temel kalite unsuru olan anlaşılırlık doğrudan düşüyor. Bu duruma ülkemizde daima sahit oluyoruz. Yazılımcılar olarak en büyük rahatsızlıklarımız, birbirine çelişen isteklerle karşılaşmak ve bizden bunları isteyenlerin, aslında biraz sağ duyu sahibinin bile anlayabileceği şeyler olmasına rağmen, isteklerdeki çelişkiler konusunda duyarsız davranmaları. Bu durumu ancak BTye stratejik olarak bakabilen kurumlar ve onların içındeki güçlü BT birimleriyle çözebiliriz.

Bir diğer sebep de bence yazılım geliştiren kişilerin, bu faktörlerle nasıl uğraşacakları konusunda bilgisiz ve yetersiz olmaları. Örneğin üniversitelerin Bilgisayar Mühendisiliği bölümlerinde algoritmik karmaşıklıkla ilgili ciddi dersler olmasına, big-o (O) notasyonu, algoritmaların işlem sayıları dolayısıyla hem zaman hem de bellek karmaşıklığı ile ilgili bilgi verilmesine rağmen, bırakın karmaşık bir algoritmanın maliyetini hesaplamayı, normal list ile bağlı (linked) list arasındaki performans farkından haberdar olmayan o kadar çok programcı-developer gördüm ki. (Matematik ve matematik mühendisliği gibi bölümlerde de discrete matematik, combinatorics gibi derslerin olduğunu biliyorum.) İster yeni mezun olsun ister tecrübeli olsun kimsenin bunlardan haberi yok, herkes nasıl alışmışsa her yerde onu kullanarak yazıyor kodunu. Yeni mezunların ezici çoğunluğu bu konudan bahsedildiğinde ilk defa duyuyormuş gibi davranıyor. Yazılım geliştiren kişilerin liderleri, önderleri durumunda olan senior programcı ve developerların, mimarların da bu konular hakkında çok fazla sistemli bilgi sahibi olduklarını, yanındaki daha genç olan kişileri yönlendirip, eğitebildiklerinden de emin değilim. 10-15 sene yazılım geliştirme projelerinde developer olarak çalışmış ve yaşı 35’e gelmiş kişilerin örneğin JVM’in belek yönetimi ve kullanılmayan nesnelerin belleklerini geri toplaması (garbage collection) ile hiç ilgilenmemiş olmaları açıkçası bana çok garip geliyor.

Bu ülkede malesef aşırı teknoloji odaklı olduğumuz için, yeni diller ve araçlar öğrenmemize rağmen, yeni teknikler ve yaklaşımlara bu kadar ilgi duymuyoruz. Dolayısıyla, kurumsal uygulamalarda o kadar çok performans ve ölçeklenirlik problemi yaşayan sistemlerle karşılaşıyorum ki, inanılmaz. Zannedersiniz kodları yazanlar orta okul mezunları. Lise sonda üç katlı integral çözmekle övünenlerin yazdıkları kodlarda isimlendirmede bile problem var. (Tabi aslolan üç katlı integral çözmek değil, aslolan hayattan bir problemi üç katlı integral olarak tanımlayabilmek. Kendim de dahil olmak üzere çözenini çok gördüm ama tanımlayabileni pek görmedim.)

Bugünün senior programcı ve developerları ya da mimarları, yazılımın kalite kriterleriyle ilgili doğru dürüst bilgi sahibi olmayıp, yazılımda olması gereken süreçlerden de bihaber kaldıklarından, kendileri kod yazarken çektikleri sıkıntılar üzerine ciddi olarak düşünüp, araştırarak, aslında yanlış yol tutturduklarını, sebep ve çözümleriyle birlikte ortaya koyacak hale gelemiyorlar. Bu yüzden bu kişiler yönetici olduklarında, “biz böyle gördük, tırmaladık, fedakarlıkla yaptık” diye düşünüyorlar ve yönetimlerinde de bu düşünceler çok etkili oluyor.

Özet olarak söylemek gerekirse, yazılım projesinin pek çok hedefi aynı anda yerine getirmesi gerekir. Kod kalitesi de belki de maliyetle birlikte bu hedeflerden en önemli ikisidir. Ama ülkemizde malesef çoğu zaman maliyet üzerine oynarken kod kalitesini göz ardı etme eğilimindeyiz. Bunun da  en temel iki sebebi, yöneticilerin çelişen istekleri ve mühendislerin bilgisizliğidir diye düşünüyorum.

Evet, ne istediğinize dikkat edin, bakarsınız oluverir 🙂  

 

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

Yazılıma Bakalım Mı?

Yazılım Mühendisliği

Daha önceki yazılarda sıklıkla, yazılımın değişmek için geliştirildiğini ve değişmenin yazılım için kaçınılmaz olduğunu yazdım. Bu anlamda bu yazı, bu yazının devamı niteliğinde ama başlığını değiştirdim.

Yazılımın bakımı ya da kısaca İngilizcesiyle “maintenance” dediğimiz sürece biraz daha yakından bakalım bu yazıda.

IEEE’nin 1219 nolu standardına göre yazılım bakımı yani software maintenance şöyle tanımlanıyor:

“the modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment.”

Yani

“müşteriye teslimden sonra, hataları gidermek, performans ve diğer özellikleri iyileştirmek, ya da farklı bir ortama uyarlamak için yazılım ürününün değiştirilmesidir. ”

Bakım dediğimizde kabaca şu dört çalışmadan birisini anlarız:

Düzeltme ya da iyileştirme (corrective): Bu tür bakımda yazılım sisteminin hataları giderilir, yani “bug fix” dediğimiz çalışmaları içerir. Yazılım sistemindeki hatalar bazen ihtiyaçların yanlış-eksik alınmasından, bazen tasarım hatalarından bazen de her şeye rağmen yanlış kodlamadan kaynaklanır. Belli ki bu hatalar testlerde de yakalanmamış ve müşterinin önüne kadar gelmiştir.

Uyarlama (adaptive): Bu tür bakım yazılım sistemini yeni ortamlara hazırlamak içın yapılır. Yeni donanım, yeni yazılım vb., yazılımın ortamındaki yeniliklere uyum sağlamak için yapılan değişikliklerdir. Sistemi yeni donanım ya da işletim sistemi ortamına taşımak, derleyicinin (compiler) ya da örneğin JVM’in sürümünü değiştirmek bu türden uyarlama çalışmalarıdır.

Yeni geliştirme (ya da zenginleştirme)/mükkemelleştirme (enhancement/perfective): Bu tür bakımda yazılıma yeni davranışlar katılır. Yeni süreçler, yeni iş kuralları, yeni kısıtlar vb. fonksiyonel yapılar yazılıma kazandırılır. Örneğin yeni tür kullanıcılar sisteme yeni ihtiyaçlarla katılırlar.

Önleyici (preventive): Yazılımın zamanla kalitesinin düşmesi karşısında yapılan ve yazılımın kalitesini arttırmaya yönelik bakım çalışmalarıdır. Bu türden çalışmalar “reengineering” olarak da adlandırılır. Mimari iyileştirmeler, sistemin modülerliğini arttırıcı, alt yapıların birbirlerine olan bağımlılıklarını azaltıcı yöndeki çalışmalar hep bu türdendir.

Tabi olarak yazılıma yapılan bir türden değişiklik başka türden bir değişikliği tetikleyebilir. Örneğin bir hatanın giderilmesi bazı mimari iyileştirmeleri gerekli kılabilir. Ya da bazı mimari iyileştirmeler için derleyicinin sürümünü yükseltmek ya da sistemi farklı bir platforma taşımak gerekebilir. P. Grubb ve A. A. Takang’ın “Software Maintenance” isimli kitabında bu ilişkiler şöyle resmedilmektedir:

Yazılımın bakımını etkileyen pek çok faktör vardır. Yazılımın tipi, kullanıcı çeşitliliği ve eğitim seviyesi, yazılımın yerine getirdiği iş süreçlerinin ve kurallarının tabiatı, hep bakımla ilgili belirleyici etkenlerdendir.

Bakımın mahiyetini daha iyi anlamak için Robert L. Glass’ın 2002 yılında basılmış olan “Fact and Fallacies of Software Engineering” isimli kitabındaki gerçeklerden bakım ile ilgili olan beş tanesini aktarmak istiyorum.

Adı geçen kitabın 41 numaralı gerçeği de şudur:

“Maintenance typically consumes 40 to 80 percent (average, 60 percent) of software costs. Therefore, it is probably the most important life cycle phase of software.”

Yani

“Bakım yazılımın maliyetinin tipik olarak %40 ila %80’ini (ortalama olarak %60) oluşturur. Bu yüzden muhtemelen yazılımın hayat döngüsündeki en önemli kısımdır.”

Bundan daha önce de bahsetmiştik: “Değiştirmek için geliştirmek.”

Aynı kitabın 42. gerçeği ise şudur:

“Enhancement is responsible for roughly 60 percent of software maintenance costs. Error correction is roughly 17 percent. Therefore, software maintenance is largely about adding new capability to old software, not fixing it.”

Yani

“Yeni geliştirmeler yazılım bakım maliyetinin kabaca %60’ını oluşturmaktadır. Hata giderme kabaca %17sini oluşturmaktadır. Dolayısıyla, yazılım bakımı, hataları gidermekten ziyade çoğunlukla yazılıma yeni yetkinlikler kazandırmaktır.”

Glass, kitabında bu son iki gerçeği 60/60 kuralı olarak birleştirir. Yani yazılımın bakımı, tüm maliyetinin %60’ını, yeni geliştirmeler ise bakımın maliyetinin %60’ını oluşturmaktadır. Buna göre eski yazılıma yeni özellikler kazandırmak pahalı bir iştir.

Kitabın 43. gerçeği ise şudur:

“Maintenance is a solution, not a problem.”

Yani

“Bakım bir çözümdür, problem değildir.”

Bu madde gerçekten çok bir fikir gibi görünmekle birlikte ciddi bir yanlışımıza parmak basıyor. Yazılım bakımını bir dert olarak görmek sağlıklı bir bakış açısı değildir. Çoğu zaman yazılımın bakımını dert oalrak görme eğiliminde oluruz. Halbuki bakım, yazılımı yaşatan şeydir. Bakımı yapılmayan yazılım muhtemelen kısa süre içinde kullanımdan da kalkacaktır.

Kitabın 44. gerçeği ise şöyle:

“In examining the tasks of software development versus software maintenance, most of the tasks are the same—except for the additional maintenance task of “understanding the existing product.” This task consumes roughly 30 percent of the total maintenance time and is the dominant maintenance activity. Thus it is possible to claim that maintenance is a more difficult task than development.”

Yani

“Yazılım geliştirme ve yazılım bakımı işleri incelendiğinde, ‘var olan sistemin anlaşılması’  şeklindeki fazladan bir bakım işi dışında”, pek çok iş aynıdır. Bu fazladan iş ise toplam bakım zamanının yaklaşık olarak %30’unu almaktadır ve en baskın bakım çalışmasıdır. Bu yüzden bakımın, geliştirmeden daha zor bir iş olduğu iddia edilebilir.”

Kitabın 45. ve bakım ile ilgili son gerçeği ise şöyle:

“Better software engineering development leads to more maintenance, not less.”

Yani

“Daha iyi yazılım mühendisliği gelişimi daha az değil daha fazla bakıma yol açar.

Bu insana ters gelen bir durum değil mi? İlk etapta “nasıl yani” dedirtiyor insana ama şu gerçeği gözden kaçırmayalım. Daha kaliteli yazılım, daha çok değişme demektir. Çünkü kaliteli yazılımlar değişir, kalitesiz yazılımlar, değişimi zor olduğundan kenara atılırlar, yerlerine daha yeni ve kaliteli olan yazılımlar gelir. Dolayısıyla, modern zamanlarda yazılımın bakım maliyeti, önceki zamanlara göre artmaktadır:

Maintenance Cost by Years

Yukarıda bu durum resmedilmiştir. (Bu diyagramı http://www.omnext.net/downloads/Whitepaper_Omnext.pdf  adresindeki “How to save on software maintenance costs” başlıklı Mart 2010 tarihli bir Omnex araştırmasından aldım.) Konu ile ilgili buradaki Schach’in kitabından alınan diyagramlara da bakabilirsiniz.

Konuyla ilgili bazı online kaynaklar şunlardır:

 

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

«< 48 49 50 51 52 >»