Yazılım Mühendisliği

Clean Code Ya da Temiz Kod – Kaliteli Kod

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

Clean Code, ya da Temiz Kod – Kaliteli Kod, uzunca bir süredir etrafta dolaşan etkileyici  tamlamalardan birisi. Malum, böyle terimlere “buzzword” diyorlar İngilizce’de.

Google’da “Clean Code” araştırması yapınca karşınıza ilk iki sırada Robert C. Martin’in kitabı ve değişik bir tarzda hazırlanmış “Clean Code” eğitim videolarının bulunduğu Clean Coders sitesi geliyor. Martin’i ben 90’lı yıllarda C++ Journal gibi dergilere yazdığı nesne-merkezli programlamayla ilgili yazılarından tanıyorum. Kendisi bu dünyanın en eskilerindendir, 1964 yılında programlama başladığını kendisi ifade ediyor. Şu anda da “Clean Code” yaklaşımının öncülüğünü yapıyor.

Clean Code’un ne olduğu  ile ilgili bazı kısa tanımlar var. Örneğin Bjarne Stroustrup “elegant and efficient” yani “zarif ve etkin” derken Grady Booch “simple and direct” yani “basit doğrudan” diyor. Michael Feathers ise biraz daha uzun bir şekilde “dikkatli, önem veren birisi tarafından yazılmış görünen koddur” diyor Clean Code için. Bu konuda belki de en uzun tanımı Dave Thomas yapıyor:

“Temiz kod, orijinal yazarından başka developer tarafından okunabilir ve geliştirilebilir. Birim ve kabul testlerine sahiptir. Anlamlı isimleri vardır. Bir şeyi yapmanın pek cok yolundan ziyade tek bir yolunu saglar. Açık-seçik olarak tanımlanmış minimal bağımlılıklara sahiptir ve temiz ve minimal bir API sunar. Kod okunabilir olmalıdır, çünkü sadece programlama diline bağlı kalınırsa, her türlü gerekli bilgi kodda açık bir şekilde ifade edilemez.”

Clean Code’u ben ise şöyle tanımlıyorum:

Yazılım asli yapısı itibariyle karmaşıktır ve yazılımda aslolan geliştirmek değil değiştirmektir. Yazılım geliştirmek zordur, değişebilen yazılım geliştirmek daha da zordur. Clean Code, zaten zor olan kodlamayı, insan yapımı zorluklarla daha da zorlaştırmamaktır. Bu anlamda Clean Code, teknolojiden ve sektörden bağımsız olarak basit, odaklı, tam ve güvenilir kod yazmaktır.

Clean Code ile ilgi bir seminer ve bir de eğitim hazırladım. Seminerleri bedelsiz olarak yazılımcılara, kurumlarında 1,5 saatlik bir sunumda anlatıyorum. Bu sunumun PDF dosyasına buradan ulaşabilirsiniz. Eğer bu semineri siz de almak isterseniz benimle irtibata geçebilrisiniz. Arzu ederseniz sonrasında daha geniş eğitim için de görüşebiliriz.

Clean Codelu günler dilerim 🙂

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

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ı: 2836

Neden Üniversitede Java?

Bilgisayar Bilimleri, Java, Kültür, Bilgi ve Düşünce, Yazılım Mühendisliği

Bir kaç gün önce, Oracle Partner Hub’da, Oracle’ın daveti üzerine gelen üniversite öğretim üyelerine bir dizi seminer verildi. Bunlardan bir tanesi de üniversitelerde neden Java’nın öğretilmesi gerektiği üzerine idi. Bu semineri ben verdim ve yaptığım sunumu da burada yayınladım. Şimdi ise daha ayrıntılı olarak bu konuyu burada ele almak istiyorum.

Aslında akademiye ilgi duyan birisiyim, gençliğimde gerek yurt içinde gerek ise yurt dışında bir miktar akademi içerisinde bulunmuşluğum da vardır. Hatta bir zamanlar iyi bir akademisyen olmak için de hayal kuran birisiyim. Ülkemiz yazılım sektöründe bizzat tecrübe ettiğim noktalardan dolayı da özellikle üniversiterin bilgisayar mühendisliği vb. eğitim veren bölümleri ve müfredatları üzerine de düşünmekteydim. Sağolsun Oracle’dan arkadaşlarımın bu konuda benden bir sunum istemeleri, beni teşvik etti ve biraz araştırıp kendimce bazı sonuçlara ulaştım. Bu yazıda da yaptığım sunumu sizlere açıklamak istiyorum.

“Neden Üniversitede Java?” aslında üniversitelerimizde Java öğretilsin demek değildir. Çünkü akademik açıdan öğretilecek olan şey bilgisayar mühendisliği ile ilgili kavramlar, yaklaşımlar ve tekniklerdir. Programlama dilleri, bunları öğrenirken kullanılması gereken araçlardandır. Yani örneğin, öğrenciye algoritmik düşünce, algoritmik karmaşıklık vb. kavramlar öğretilirken, anlamayı kolaylaştırmak ve nihayetince öğrenileni uygulamak için programlama dillerine ihtiyaç duyulur. Bu durum özellikle liseden yeni gelmiş ve konuya uzak gençlerin karmaşık ve soyut yapıları öğrenmelerini kolaylaştırmak için elzemdir. Benzer şey computer graphics, compiler ya da artificial intelligence derslerinde de geçerlidir. Dolayısıyla aslolan kavramlar ve teknikler ama bunların soyut düzlemden çıkarılıp, uygulanabilmesi için gerekli olan ise programlama dilleridir.

Bahsetmem gereken bir diğer nokta da Java’nın öğretilmesinden kastettiğim şeyin, sdece giriş dersi olarak değil de genel olarak BM öğrencilerinin girişten mezun oluncaya kadar bir kaç derste bir şekilde Java ile uğraşmış olmalarıdır. Çünkü açıkçası bu ülkede BM mezunu olduğu halde Java’yla hiç bir şekilde uğraşmamış kişilerle karşılaşıyorum. Bu konuda sadece Java öğretilsin gibi bir şeyi savunmuyorum elbette ama diğer pek çok dil yanında Java da öğretilmeli diyorum.

Üniversitede Java öğretmenin ya da öğretmemenin pek çok akademik sebebi olabilir. Örneğin:

  • Java, C/C++’a göre çok daha düzenli ve soyut bir dildir.
  • Java, Smalltalk gibi tamamen, saf object-oriented değildir.
  • Python, syntax açısından bir lise mezunu için Java’dan daha basit ve anlaşılırdır.

Tüm bunlar akademik olarak geçerli sebepler olabilir, fakat ben daha çok kalkınmakta olan bir ülke olarak, endüstrimiz açısından, üniversitelerde neden Java’nın da öğretilmesi gerektiğine dair bir kaç sebepten bahsetmek istiyorum. Bu noktada yazılım endüstrisinde de treni kaçırma durumunda olduğumuzu düşünüyorum.

Bu konuya girmeden önce şu noktayı da tespit etmenin faydalı olacağını düşünüyorum:  Ülkemizde sağlıklı ve derin bir programlama ve yazılım geliştirme kültürü malesef yok. Var olan kültürümüz daha çok ya Microsoft teknolojileri (özellikle VB) ya da Cobol-RPG gibi eski diller ve Progress, Oracle’in Forms-Reports gibi dördüncu nesil (4th GL) yapılar ve diller üzerine kurulu. Bu noktada yazılım geliştirme şeklimizi belirleyen çok temel iki nokta şunlardır:

  • Sürükle – bırak, ya da şip-şak programlama (drag-n-drop),
  • Veri merkezli (data-oriented) anlayış.

Bundan dolayı, uygulama yazılımı geliştirme tecrübemiz çok sığ.  Yazılım geliştirmeyi harc-i alem bir iş olarak görüyoruz. Çoğu zaman yazılım geliştirmekten  anladığımız, kahramanca yöntemlere sahip kahraman programcılarımızla geliştirdiğimiz derme çatma programlardır. Programlama birikimimiz çok sığ olduğu gibi bir mühendislik süreci de işletemiyoruz, dünyada yazılım sektöründe rekabet edemiyoruz.

Şimdi konumuza dönersek, Java üniversitelerimizde öğretilmeli çünkü Java,

  • dünyada ve ülkemizde, pek çok sektörde ana yazılım geliştirme dilidir ve uzun süre ana akımda olacaktır,
  • çok paradigmalı bir programlama dilidir,
  • çok geniş bir ekosistem yaratmıştır,
  • güçlü ve sağlıklı bir yazılım ve programlama kültürü kazandırır,
  • ve açık kaynak kod yaklaşımının destekçisidir.

Bu sebepleri sırasıyla biraz açalım.

Java dünyada ve ülkemizde, pek çok sektörde ana yazılım geliştirme dilidir ve uzun süre ana akımda olacaktır. Java, dünya çapında en büyük geliştirme toplumuna sahip olan dildir, TIOBE indexinde Eylül 2014’de ikincidir ki bu durum Java için en düşük durumdur. LangPop.com’da göre de ikincidir. Dünya çapında var oln 40 küsür milyon civarında geliştiricinin 7 ila 10 milyonunun Java kullandığı tahmin edilmektedir. Bir başka deyişle, dünyadaki programcıların TIOBE’ye göre %17’si, Langpop’a göre ise %15’i Java kullanmaktadır.

Java toplumu, dünya üzerindeki Javacılara, yıllık konferanslar, kitaplar, web üzerinden erişilebilen dergi, blog, forum, tutorial vb. yazılı ve video kaynaklar ile çok zengin bir bilgilenme ortamı sunar. Sayısı 250’nin üzerinde JUG’lar, Javacıları bir araya getiren son derece faal topluluklardır. 9 Eylül’de yaptığım sorgulara göre, Amazon’da Java için 22,710, C++ için 7,322, Python için 3,975, C# için ise 5,016 kitap sonucu gelmektedir. Bu da Java dünyasında öğrenmeyi destekleyen kaynakların diğer programlama dillerine kıyasla nasıl bir zenginlik teşkil ettiğini göstermektedir. Ayrıca Java Community Process (JCP.org), Javacıların Java’nın gelişimini etkileyebilecekleri bir mecradır. Bu anlamda Javacılar için Javanın gelişimini yönlendirmek sözkonusudur.

Böyle büyük rakamlara ulaşmış bir topluluk, Java’nın yaygın kullanımına ve daha uzunca bir müddet de böyle gideceğine işaret ediyor.

Java, çok paradigmalı bir programlama dilidir. Yani Java kullanarak faklı programlama paradigmaları üniversitedeki derslerde ele alınabilir.:

  • Standart prosedürel mekanizmaları ile structured programming öğretilebilir,
  • Güçlü nesne soyutlamaları ile OO programlama
  • Java SE 7 ile gelen fonksiyonel yapılar
  • Scala gibi JVM dilleriyle tam fonksiyonel programlama desteği

Nitekim bazı üniversiteler örneğin programlama ile ilgili ilk derste Java’nın prosedürel yapılarını, ikinci derste ise nesne yapılarını ele alıyor. Bu anlamda Java programlamaya giriş dersinde kullanılabilir çünkü Java

  • statik tiplidir,
  • söz dizimi açısından ne Python kadar çok soyut ne de C/C++ gibi çok aşağı seviyededir, anlaşılması kolay (intuitive) bir yapıdadır,
  • Hem prosedürel hem de nesne yapılarına sahiptir,
  • Greenfoot, BlueJ, Dr. Java, Alice vb. giriş seviyede, etkileşimli öğrenme ortamları ve araçları mevcuttur,
  • Eğitim amaçlı geliştirilmiş, grafik, oyun vb. kütüphanelere sahiptir.

Java, BMnde ele alınan konuları öğretmek için de gerekli bileşen, API vb. yapılara sahiptir Aşağıda sıraladığım konuları ilgili derslerinde öğretirken Java’yı kullanmak mümkün oluğu gibi buna dünya üniversitelerinden pek çok örnek de vardır.

  • Algoritmalar ve veri yapıları.
  • Network-web-mobile programlama,
  • Veri tabanı programlama
  • Grafik programlama
  • İşletim sistemleri, compilerlar,
  • Paralel programlama, vb.

Örneğin pek çok üniversite, computer graphics dersinde C yanında Java’yı da uygulama dili olarak kabul ediyor.

Java, hem bir dil hem de bir platform olarak, sağlıklı bir programlama ve yazılım geliştirme kültürü sağlar. Bence bu madde belki de ülkemiz açısından en önemlisi. Java kültürü, C++ ve Smalltalk üzerine inşa edilmiş ve kaliteli yazılım üretmeye odaklanmıştır. Bu noktada tarihi olarak Java modern programlama ve yazılım geliştirme teknik ve yaklaşımlarına öncülük eden bir kültüre sahip olmuştur.

Java, hem mimari hem sınıf seviyesinde lowly-coupled ve higly-cohesive yapılar kurgulamayı destekler, APIleri ile “program to an interface, not an implementation” prensibini uygular, katmanlı yapılar, layers-tiers, yoğun design patterns kullanımı, component-based yaklaşım, TDD’dan, continuous integrationa, JavaDoc’a kadar pek çok teknik ve yaklaşım, ya Java dünyasında keşfedilmiştir ya da gelişip yaygınlaşmış ve diğer dillere uygulanmıştır.

Üniversitelerde Java’nın öğretilmesi, ülkemizde yaygın olan ve benim “drag-n-drop” ya da “şip-şak programlama” olarak tasvir ettiğim ve programlama ve yazılım geliştirmeyi harc-ı alem bir iş olarak gören zihniyetin değişmesi açısından çok önemlidir. Ben malesef, üniversitelerin BM bölümlerinden mezun olup, hala yaptığı işin tabiatını dolayısıyla da karmaşıklığını kavrayamamış, hacker modunda, deneme-yanılma yöntemiyle, aşırı zaman harcayarak yazılım geliştiren kişilerle tanışmaya devam ediyorum. “Google programcısı” olarak da nitelenebilecek bu tür yaklaşımların ülkemiz .NET topluluğunda malesef daha yoğun olarak bulunduğunu ama Javacıları da etkilediğini düşünüyorum. Eski VB kültürünün devamı olan bu yaklaşım, ülkemiz .NET topluluğu için de bir sıkıntıdır. Üniversitelerimizin bu durumu düzeltici etkide bulunması gereklidir, çünkü agaç yaşken eğilir.

Java çok geniş bir yazılım geliştirme ekosistemidir. Bu anlamda Java, klasik programlama dili anlayışından çok daha kapsamlı bir yapıya sahiptir.

  • Java SE, standart programlama dili,
  • Java EE, kurumsal ölçekteki uygulamalar için her türlü bileşene sahiptir,
  • Java ME, mobil platformlar için ciddi bir alternatiftir,
  • JavaFX, rich internet applications (RIA) için geliştirilmiştir.

Java ekosisteminde ortaya çıkan ve yazılım ve bilgi teknolojileri dünyasını derinden etkileyen teknolojiler ve yaklaşımlardan bazılarını şöyle sıralayabiliriz:

  • JUnit ile TDD,
  • Hadoop ile big data yönetimi,
  • Android ile mobil işletim sistemi,
  • ve Apache Software Foundation’da pek çok proje…

Java’nın çalışma zamanı yapısı olan JVM, bir mühendislik harikası olarak, sanal bir makinadan çok daha fazlasıdır. JVM son derece yaygındır hatta pek çok veri tabanı ve SAP gibi uygulamayla beraber gelmektedir.

Ayrıca JVM, üzerinde onlarca farklı amaçlarla geliştirilmiş dilin çalışmasına izin veren sanal bir ortamdır. JVM üzerinde 100’den fazla dil geliştirilmiştir. Bu diller Java’nın bazı kısıtlarını aşmak ya da ona bazı yetkinlikler kazandırmak için geliştirildiği gibi, pek çoğu scripting dili olarak bir sistemin değişik yerel bölgesinde, çok özel sorunların üstesinden gelmek üzere kullanılacak şekilde konumlandırılmaktadır.

  • Groovy: Dinamik tipli bir dil
  • Scala: Fonksiyonel destek
  • Jython: JVM’deki Python
  • Closure: Fonksiyonel Lisp dialekti
  • JRuby: JVM’deki Ruby

Java, kendini açık kaynak kod kültürüne elveren bir yapıya sahiptir. İnternet’teki açık kaynak projelerinin bulunduğu ortamlarda Java çok yoğun bir şekilde kullanılmaktadır. Java JDK’in kodu bile Mayıs 2007’den bu yana açıktır. OpenJDK tamamen açık kod felsefesiyle geliştirilmekte olan bir çekirdek Java ürünüdür. Java, standardlar üzerine bina edilmiştir ve bu standartlar diğer dillere göre programcı topluluğunun yönlendirmesine çok daha açık bir şekilde JCP (JCP.org) yapısında belirlenmektedir.

Java’nın ve bileşenlerinin ve araçlarının ticari lisansa tabi olanları kadar açık kaynak kod lisanslarına tabi implementasyonları da mevcuttur. Uygulama sunucuları, veri tabanları, bileşenler, araçlar, iş yazılımları, vs. hepsi açık kaynak kod anlayışına uygun olarak gelişitirilmiş Java uygulamalarıdır.

Açık kaynak kod kültürü, malesef ülkemizde ciddi bir şekilde ihmal edilmektedir. Halbuki, açık kaynak kodlu ürünler, kaynakları kısıtlı ve girişimcilik ruhu yetersiz olan ülkemizde çok rahatlıkla bize yardımcı olabilir, açık kaynak kodlu yapılarla geliştirilen yazılımlar, lisanslı ürünler kullanan yazılımlara karşı piyasa avantajına sahip olabilir. Ülkemizde pek çok ticari iş uygulamasının, belli kritiklik seviyesine gelinceye kadar, açık kaynak kodlu ürünlerle geliştirilebileceğini ve piyasaya sunulabileceğini düşünüyorum. Bu büyümekte olan girişimler için çok ciddi maddi avantajlar sağlayacaktır.

Açık kaynak kodlu ürünler, pek çok projenin başlangıç, AR-GE safhasında kullanılabilir. Ayrıca açık kaynak kodlu projeler, çok güzel bir öğrenme ve yardımlaşma ortamı yaratmaktadır, örneğin Apache Software Faundation’da (ASF) yüzlerce projede 3000 civarında gönüllü çalışmaktadır. Bu gönüllüler dünya üzerindeki değişik coğrafyalardan katılmakta ve çoğu kez gerçek ortamlarda biraraya gelememektedirler.

Tüm bunlardan dolayı, açık kaynak kod kültürünün, ülkemiz için de stratejik olarak önemli olduğunu düşünüyorum. Bu noktada malesef üniversittelerimizde bu kültüre yeterince destek verilmediğinin, hatta bu kültürden tamamen uzak bir anlayışa sahip olunduğunun da farkındayım. Bu durum yazılım sektörümüzde de aynen devam etmektedir.

Tüm bunlardan sonra ülkemiz üniversitelerindeki duruma kısaca değinmek isterim. Bu konuda bir araştırmaya rastlamadım ama tecrübem şunu gösteriyor ki .NET ve C# kullanımı, ülkemizde çok yüksek boyutlarda. Üniversitelerimzde .NET ve C# gosterilmesin diye bir düşüncem yok. Hem dünyada hem de ülkemizde Java’nın en temel alternatifi olarak bu dil ve ortamın da tabi olarak öğretilmesi gereklidir. Fakat hem bu platformun yukarıda bahsettiğim kültürü hem akademik ihtiyaçlara çok elveren yapıda olmaması hem de son derece kapalı tabiatından dolayı, özellikle ABD üniversitelerinde çok az oranlarda ele alınırken, ülkemiz üniversitelerinde bu kadar yüksek oranda kullanılması bana ters geliyor. Bunda muhtemelen Microsoft’un ülkemiz üniversitelerine daha fazla ilgi göstermesi, VB kültürünün bir devamı olarak “Java zor, .NET kolay” şeklindeki bir algının yaygın olması ve nihayetinde ünivesitedeki hocalarımızın tembelliği rol oynuyor.

Geniş kullanım alanına sahip olması, sağlıklı bir programlama ve yazılım kültürü kazandırması, üniversitede öğretilebilecek/kullanılabilecek yapıda olması ve açık kaynak kod kültürünü desteklemesinden dolayı üniversitede Java öğretilmeli!

Bir uygulayıcı olarak, tutkulu, kavram ve teknikleri iyi bilen ve Java ile uygulayan mezunlara ihtiyacımız var diyorum.

Kaynaklar

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

Analitik Olmayan Analistler Neye Mal Olur?

İş ve İhtiyaç Analizi, Yazılım Mühendisliği

Karşı karşıya olduğu iş bilgisini, analitik olarak irdeleyemeyen analistler, ne sağlıklı bir iş bilgisine sahip olabilirler, ne müşterilerinin ihtiyaçlarını anlayıp uygun çözümler bulabilirler, ne verimli toplantılar yapabilirler ne de işe yarar dokümantasyon yazabilirler.

Sıklıkla karşılaşıyorum ciddi tecrübeye sahip analistlerle. Sık sık danışmanlıklarda ve eğitimlerde, bazen de iş görüşmelerinde. Mesela iş görüşmesinde karşılaşıyorum örneğin finans sektöründe 10 senedir analist olarak çalışan adayla ve şunu soruyorum: “İş analizi ile yazılım ihtiyaç analizi arasında herhangi bir fark görüyor musunuz?” Pek fazla bir şey çıkmıyor. Peki diyorum, “yazılım ihtiyaçlarını kategorilere ayırmak istersek ne gibi farklı tipler aklınıza gelir?” Yine pek hikmetli bir cevap gelmiyor. Yaptığı işi ise genel olarak “müşteriyle görüşürüm, isteklerini bir dokümana yazarım, sonra ekran tasarımını yaparım, …” diye özetliyor. “Ekran tasarımı” işinin bir tasarım-design olduğunu ve bir “analiz” faaliyetinde nasıl yer aldığını sorunca bazen önce cümlemi tekrar etmemi istiyor ve “evet haklısınız” diye devam ediyor, bazen bu kadar da ilerliyemiyoruz. Gerçi ben isminde hem “ihtiyaç” hem de “tasarım” kelimeleri bulunan ihtiyaç analizi dokümanları çok sık gördüğümden alışkınım ama yine de sormadan duramıyorum 🙂

“Yazdığınız dokümana gelelim” diyorum ve “dokümanda ne gibi başlıklarınız var?” diye soruyorum. Amacım hiç olmazsa pratik olarak yaptıklarına bakarak iş ve ihtiyaç analizi ile ilgili ne kadar “analitik” olduğunu anlamak. “İhtiyaçlar” diyor dokümandaki ilk başlık içın. Tabi diyorum, sonuçta “İhtiyaç Analizi” dokümanında ihtiyaçlar olur 🙂 İhtiyaçlar başlığı altında ne gibi alt başlıklar olduğunu sorunca da, olmadığını, ihtiyaçları alt alta sıraladığını söyluyor adayımız. “Müşteri anlatır ihtiyacını, ben de yazarım” diyor. Buna da şükür, çünkü daha kötüsü var: Müşteri kısa bir emaille, bir telefon konuşmasıyla ya da bir araç yardımıyla iki satırla gönderebilir ihtiyacını. Ama müşterinin ihtiyacını anlatıp, analistin de hiç bir analitik süreçten geçirmeden anlatılanı yakalayıp yazılım geliştirenlere ilettiği bir süreçte analiste “postacı” demek daha uygun olmaz mı? “Sonra niye programcılar bizden memnun değiller?” diye sormanın ne alemi var ki?

Demeye çalıştığım şey şu: İşini yapışı açısından, pozisyonun ya da rolün isminde var olan “analitik” olma ile yakından uzaktan ilgisi olmayan kişilerin, iş bilgisini ve yazılım ihtiyaçlarını analitik olarak ele almaları mümkün değil. Bu durumda tonlarca iş bilgisi, bir şekilde bir araya getirilmiş cümlelerden ibaret olacak, yani “malumat” olarak kalacak. Analitik olarak ele alınmadığı için, içinde herhangi bir soyutlama da içermeyecek. Gittikçe büyüyen ve karmaşıklaşan iş bilgisini ve yazılım ihtiyaçlarını, bölük-pörçük malumat öbekleri olarak ele almak sanırım bir BT kurumu içın yapılabilecek en büyük hatadır.

İş bigisini ve yazılım ihtiyaçlarını analitik ya da çözümleyici olarak ele almaktan kastımız şu: Öncelikle bir ihtiyaç kategorizasyonu olmalı. Örneğin fonksiyonel olan ve olmayan ihtiyaçlar olarak ayırım. Sonrasında iş ihtiyaçları, kullanıcı ihtiyaçları ve fonksiyonel ihtiyaçlar şeklinde farklı soyutlama seviyelerinde ihtiyaç hiyerarşisinin kurulması gerekli. Ayrıca kullanıcı ihtiyaçlarının, kullanıcı süreçleri olarak “süreç” tabanlı ifade edilmesi çok önemlidir. Yani içinde insan olan farklı roldeki kullanıcılarla birlikte haberleşilen farklı yazılım ve donanım sistemlerinin de olduğu ki bunların tümüne birden biz aktörler diyoruz, kullanıcı iş akışlarının ortaya konması. İş akışlarındaki alternatif ve sıra dışı durumların belirlenmesi, yani olumlu sonuçlanan senaryolar dışında olumsuz ve alternatif senaryoların da ortaya konması, süreç analizi için olmazsa olmazdır. Kurum seviyesindeki iş süreçleri öncelikle kurum çapında çizilip detaylandırılabilir. Kullanıcıların iş sureçleri ise örneğin use-case (kullanım şekli) olarak yakalanabilir ve UML’in aktivite diyagramlarıyla daha görsel ve analitik hale getirilebilir.

İş süreçlerindeki farklı tipteki iş kurallarının ayrı bir başlık altında toplanması da çok önemlidir, çünkü iş süreçleri pek çok hesaplama, kısıtlayıcı ya da tetikleyici cinsten kurallar içerir. İş süreçleri ve kurallarından sonra süreçlerdeki atomik olan fonksiyonel ihtiyaçların ayrıca tek tek yakalanması ve bunların süreçlerle ilişkilendirilmesi en detaylı fonksiyonel ihtiyaçları ortaya çıkarır. İnsan aktörlerin dahil olduğu süreçlerde, aktörün sistemle etkileşiminin detaylandırılması amacıyla kullanıcı arayüz analizinin (tasarımı degil!) yapılması da unutulmaması gereken analiz çalışmalarındandır.

Ayrıca iş süreçlerindeki kısıtların, kalite ve uyum standartlarının ortaya konması, entegrasyon detaylarının belirlenmesi, sistem ihtiyaçlarının çıkarılması ve mimari ihtiyaçlar olarak fonksiyonel olmayan ihtiyaçların hem süreç hem de sistem tabanında ortaya konması, analitik ve tam bir ihtiyaç analizi çalışmasının olmazsa olmazlarındandır. Tüm bunlar, aslında “malumat” seviyesindeki iş bilgisi ve yazılım ihtiyaçlarının “bilgi” seviyesine çıkarılması faaliyetlerindendir. Bir konunun öğlerini analitik olarak kategorilere ayıramazsanız, hiyerarşiler kurgulayamazsanız, o konu hakkında da düşünemezsiniz, dolayısıyla aklınızdaki sadece ezber olur, malumat ya da information olur ama bilgi ya da knowledge olmaz. Ayrıca farklı iş ve yazılım ihtiyaçları arasında öncelik-sonralık, sebep-sonuç ilişkilerinin belirlenmesi, benzer şekilde yazılım ihtiyaçlarının maliyetlerinin, karmaşıklıklarının ve risklerinin ortaya konması, yine analitik olmanın parçalarındandır. Dikkat ederseniz bu paragrafta saydığımız maddeleri bilebilmek için önceki paragraflarda bahsettiğimiz “analitik-çözümleyici” çalışmaların yapılmış olması şarttır. Örneğin, malumat seviyesinde kalmış, kategorize edilip, alt parçalarına ayrılmamış ihtiyaçların maliyetini nasıl hesaplarsınız ki? Tecrübeliyseniz biraz destekli atış yapabilirsiniz ancak.

Yukarıdaki gibi yazılım ihtiyaçlarına analitik olarak yaklaşmayan analistlerin gerek müşterilerle gerek ise geliştiricilerle toplantılarının verimli olmasını beklemek de nafiledir. Onlarca insan, saatlerce konşurlar ama yine de ortaya doğru düzgün bir şey çikmaz. Bir toplantının başarısı öncelikle o toplantının ne kadar odaklı olduğuyla ilgilidir. Son derece genel, odaklı olmayan konuları ele alma niyetiyle yapılan toplantılar çok sık görülen cinstendir. Odaklı olmadığı için de önüne gelen ya çağırılmıştır ya da duyup gelmiştir. Başarılı analiz toplantıları ekranlar üzerinden yapılmaz örneğin! Başarılı analiz toplantılarının önceden belirlenmiş, hangi konularda nasıl kararlar alınacağı listelenmiş, bunlar dışındakiler gündeme geldiğinde unutmamak için ve bir sonraki toplantıda ele alınmak üzere not alıp devam edilen, az ama özü tartışan ve olabilidiğince 1,5-2 saati geçmeyen, maximum 6-7 kişinin bir araya gelişleri olması gerekir. Bir analiz sürecindeki bir toplantı iki saati geçiyorsa, katılımcı sayısı 10’dan fazla ise, zaman zaman bazı katılımcılar makinalarında Facebook vs. ortamlarda vakit geçiriyorlarsa, bilin ki orada hata analisttedir, çünkü toplantıyı düzgün organize edememiştir. Bunun da sebebi aslında organizasyonsuzluk değildir, aksine analistin kafasında herhangi bir analitik yaklaşım olmaması, dolayısıyla “şu sürecin şu akışı ya da akıştaki şu iş kuralları” şeklinde odaklı bir toplantı organize edememesidir. Bu şekilde çalışmayan analistlerin çoğunlukla ya var olan ekranlar ya da yaptığı ekran tasarımları üzerinden toplantı yaptıklarına çok defa şahit olmuşumdur.

İş bilgisine ve yazılım ihtiyaçlarına bu şekilde yaklaşan analistlerin, ne malumat dolu konuşmalarının yazılımcıları tatmin ettiğini ne de aynı yapıdaki dokümanlarının yazılımcılar tarafından okunduğunu söylemek mumkündür. Bunun sonucunda da yazılımcı, programı yazarken karşılaştığı boşluklar, çelişen noktalar vb. konularda çok sık bir şekilde analiste döner.  Analist haliyle zaten cevap veremeyeceği bu tür noktalar içın çok sıklıkla müşteriye döner. Çünkü programcı, gerçekliğe analistten daha yakındır bu yüzden analistin analitik bir süreç işletmemesinin getirdiği sıkıntılarla hemen yüzyüze gelir. Hem müşteri hem de programcı tarafında “patinaj” olarak algılanan bu kifayetsizlik, sonuçta analistin devre dışı bırakılıp, müşterinin doğrudan programcıyla görüşerek ilerlemelerine sebep olur. “Ne vereyim abime/ablama” sendromu olarak isimlendirdiğim bu durum olabilecek en kötü haldir ve sebebi ise kesinlikle “postacılık”tan öteye gidemeyen analist ve onu doğru bir şekilde eğitip yönlendirmeyen yöneticisidir.

Analitik bir süreçten geçmeyen ihtiyaçlar üzerine ne doğru düzgün bir mimari bina edebilirsiniz ne de fonksiyonel bir tasarım ortaya koyabilirsiniz. Yapacagınız tek şey, programlama olabilir. Ama bunun da gideceği yer aşırı refactoring, bol copy-paste ve nihayetinde daha ilk baştan yamalı bohça görünümlü, kalitesiz koddur. Böyle geliştirilmiş yazılımların bakım maliyetleri çok ama çok yüksektir.

Benzer şekilde analitik bir süreçten geçmeyen ihtiyaçlar üzerine sağlıklı bir proje planlaması yapılamaz, efor tahminleri çok afaki olur. Analitik olarak bileşenlerine ayrılmamış müşteri ihtiyaçlarını test etmeniz de çoğu zaman ya çok meşekkatlidir ya da hepten imkansızdır. Olan biten şey, gerçek testin ancak canlı kullanımda, operasyonel kullanıcılar tarafından yapılmasıdır. Ama problem şu ki, hatalar hem müşteride memnuniyetsizlik yaratır hem de bu hataları düzeltmek için çok geç bir zamana gelinmiştir, maliyet çok artmıştır.

Yazılım projelerinde, en analitik olması gereken rol, sanılanın aksine programcılar değil, analistlerdir. Ama gerçekte analistlerin yaptığı ya postacılıktır ya da malumat biriktirme ve aktarmadır. İlki çoğunlukla analistleri ortadan kaldırmaya ikincisi ise son derece maliyetli bir yazılım geliştirme sürecine sebep olur. Analitik bir süreç izlemeyen analistlerin bulunduğu kurumların sadece bugünleri vardır, yarınları yoktur.

Analitik analistlerle çalışmanın keyfi bambaşkadır…

 

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

«< 12 13 14 15 16 >»