Öğrenme Sürecinde Programlamadan Yazılım Geliştirmeye Geçişte Workshop Çalışmasının Önemi

Eğitim hayatımda bana sıkça sorulan birisi de bir programlama dilini öğrenmekten proje geliştirmeye nasıl geçileceği konusudur. Çok sık duyarsınız “Java’yı biliyorum ama bir proje nasıl yapılır, neresinden başlanır, nasıl ilerlenir bilmiyorum” şeklindeki konuşmaları. Doğrudur, bu durum herkesin kariyerinin başında yaşadığı cinsten sıkıntılardandır. Bu yazıda bu sıkıntının nasıl aşılabileceğini ele almak istiyorum.

Programlama, bir programlama dili yoluyla bilgisayara bir iş yaptırmaktır. Programlama dili ise bir araçtır, bilgisayara iş yaptırmanın en temel yoludur. Programlama dilleri dışında da bilgisayara iş yaptırmanın yolları vardır ama bir uygulama kadar geniş ve detaylı iş yaptırmaktan bahsediyorsak, hele işin içinde kullanıcılarla iletişim varsa, programlama dilleri dışında pek alternatifimiz yok gibi. Fakat bir programlama dili öğrenmek, temelde onun anahtar kelimelerini, kullanışlarını ve söz dizimini öğrenmek demektir. Her ne kadar programlama dilini öğrenmek ile onu kullanarak problem çözmek içe içe geçmiş süreçler olarak görünüyorsa da işin başında daha çok programlama dilinin kendisi ile uğraşılırken ilerleyen zamanlarda, özellikle dilin temellerinde belli bir noktaya gelince, problem çözme tarafı daha ağır basmaya başlar. Örneğin üniversitede, algoritmalar, veri yapıları, ağlar, derleyiciler (compilers) vb. ders ya da konularla bir programlama dilinin bir problemi çözmek için nasıl kullanılacağını öğreniriz. Örneğin pi sayısını hesaplamanın farklı yöntemleriyle if-while-for vb. pek çok kontrol yapısını, bir sayıya kadar olan tüm asal sayıları bulmada kullanılan Sieve of Eratosthenes algoritması ile dizileri kullanırız ve nihayetinde hem dile olan hakimiyetimizi geliştiririz hem de dil ile problem çözme yöntemlerini öğreniriz. Sonrasında ise compilers, ağlar ya da bilgisayar grafiği gibi derslerde muhtemelen daha büyük programlama hatta proje ödevleri yaparız. Tüm bu pratikler bizim hem programlama gücümüze katkıda bulunur hem de ağlar, veri tabanı, bilgisayar grafiği vb. temel bilgisayar ve yazılım yapılarıyla ilgili bilgi ve tecrübeye sahip olmamızı sağlar.

Peki tüm bu konularda son derece iyi olmak bir proje geliştirmek yeterli midir? Tabi ki değildir. Çünkü yazılım, programlamadan daha fazla şeyi ifade eder ve ancak proje ile yazılım geliştirilir. Genelde yazılım projelerini, programlamadan ibaret olarak görme eğilimdeyiz, hatta yazılım sistemlerini “program” olarak adlandırıldığına da sıklıkla şahit oluyorum. Yazılımın, programın daha büyüğü olarak görecek şekilde bir basitleştirme mümkün olsa bile, gerçekte böyle bir algıya sahip olmak bizi yazılımla ilgili çok ciddi yanlışlara götürür. Aynen gerçek bir uçağın geliştirilmesini, model uçak yapımının sadece daha büyük hali olarak görmekteki gibi. Zaten bu yazının başında bahsettiğim sıkıntı tam da budur: Programlamayı bilmemize rağmen proje yapmakta zorlanmamız. Sistemlerin büyümesinin getirdiği karmaşıklık çoğu zaman doğrusal değil de doğrusal olmayan şekilde artar ve bu durum zaten başlı başına bir sorundur.

Proje yazılıma özel bir kavram değildir elbet ve yazılım projelerinin de diğer disiplinlerdeki projeler gibi belirlenmesi gereken bazı tarafları vardır. Peki öğrenme sürecinde dile ciddi bir hakimiyet sağlama safhasını geçtik ve geldik kendi kendimize bazı projeler yapmaya. Neler yapmamız gerekli?  (Bu yazıda daha çok kişilerin öğrenme sürecinde, kendi kendilerine yaptıkları projeleri göz önüne alacağımdan, bu gereklilikleri çok ciddi ve formal bir çerçevede düşünmeyeceğim.)

Öncelikle bir yazılım projesinin, iyi ya da kötü ihtiyaçları belirlenmiş ve sınırları çizilmiş olmalıdır. Dolayısıyla programlamadan yazılım geliştirmeye geçerken ele alacağınız projeninizin belli bir detayda çerçevesi olmalıdır. İhtiyaçları belirlenmeden girişilecek bir projenin bitmesi pek de mümkün olmayacaktır, bundan dolayı da yapılan geliştirme “proje” olmaktan çıkacaktır. Eğer ihtiyaçları belirlemede, projenizin çerçevesini çizmede zorlanıyorsanız, en basit ve gerekli olanlara odaklanın ve detayını çıkarmakta zorlandığınız kısımları ileriki sürümlere atın ve bir an önce ilk sürümünüzü çıkarmanızı sağlayacak kısımlara öncelik verin derim.

Öte taraftan bir yazılım projesinin, ihtiyaçları çerçevesinde belirlenmiş bir mimarisinin de olması gereklidir. Nasıl ihtiyaçlar belirlenmediğinde projede pek çok yaz-boz oluyorsa benzer durum mimari belirlenmediğinde de söz konusudur. Mimari yapılar ise belli bir teorik alt yapıya sahip olarak kurgulanmakla birlikte genelde tecrübe tabanlıdır ve mimari algı, okumaktan daha çok deneme-yanılma ile gelişir. Gerçi mimari bilgi birikimimiz de gittikçe daha formal hale geliyor ve çeşitleniyor; bu yüzden gittikçe daha fazla okumak ve uygulamak önemli hale geliyor. Özellikle kullanılan dil vb. teknolojilerin temel kalıplarının (pattern) ve  mimari best practicelerinin bilinmesi bu anlamda çok önemlidir. Örneğin katmanlı yapılar kullanacaksınız, AOP ile aspectleri ayıracaksınız ve olabildiğince durumsuz (stateless) yapılar kullanacaksınız şeklidne üst prensiplerden yola çıkarak detaylara inebilirsiniz. Dolayısıyla projenizin mimari konularına da çala kalem dalmayın, biraz düşünün, okuyun, araştırma yapın ve ihtiyaçlarınızın sizi ne tür bir mimariye doğru ittirdiğini anlamaya çalışın, aksi taktirde projenin büyüklüğüne bağlı olmak üzere sıkıntılı sonuçlarla karşılaşabilirsiniz. Bu tür durumlar aslen öğrenmenizin bir parçasıdır ve doğrudan vakit kaybı olarak da görülmemelidir ama atış yaparken de olabildiğince destekli atmak gereklidir. Aşırı yaz-boz hem kaliteyi düşürür hem de motivasyonu.

Projelerinizde fonksiyonel tasarıma da önem verin. Sınıflar, arayüzler, “is-a” ve “has-a” ilişkileri, hem statik hem de dinamik görüntülerin neler olduklarına, sorumluluk tabanlı yaklaşımla karar verin. Bu gibi çalışmalar için UML kullanabilirseniz çok şık olur ama kullanamıyorsanız çok da takılmayın, bulgularınızı kendinize has bir şekilde, beyaz bir kağıda da olsa ifade edin. Bu sırada yani kavramsal olarak düşünürken nesneler arasındaki ilişkileri tasarım kalıplarıyla nasıl daha rahat hale getirebileceğinizi, nesnelerin nasıl daha sağlıklı olabileceğini de düşünün. Bu tür düşünmeler yazılım üzerine soyut düşünme kapasitenizi arttırarak size çok şey kazandıracaktır.

Sonrasında girişeceğiniz kodlamada birim testlerini yazmak, temiz (clean) bir şekilde kod yazmaya çalışmak ve API dokümantasyonuna önem vermek muhtemelen kodunuzu çok daha kaliteli ve anlaşılır kılacaktır. Ayrıca projenizde üçüncü el bileşen ve frameworkleri kullanmak, projenizi çok daha sağlıklı hale getirebileceğini de unutmayın. Bu anlamda tekerleği yeniden keşfetmeyip, enerjinizi koddaki orijinal taraflara saklayın.

Nihayetinde çok ilgi çekici olmasa da bir miktar test malzemesi oluşturmak, temel süreçleri test edebilmek için bir miktar çalışma yapmak ve örnek veri oluşturmak, projenizin sağlıklı bir şekilde nihayete ermesi açısından önemlidir.

Görüldüğü gibi yukarıdaki proje geliştirme sürecinde, programlama kadar analiz, tasarım ve dokümantasyon gibi çalışmalar da vardır. Dahası programlamanın dışındaki bu çalışmaların sağlıklı yapılması, ciddi bir eğitim ve yazılım mühendisliği nosyonu gerektirmektedir. Aksi taktirde usandırıcı bir git-gel girdabına girmek işten bile değildir. Fakat öte taraftan tam programlamada ilerleyelim derken ap-ayrı bir yazılım mühendisliği duvarına toslamak gibi bir durum söz konusu. Bu noktada öğrenme sürecinde programlamadan proje geliştirmeye geçişin ancak bir yol gösterici sayesinde yapılabileceğini söyleyebiliriz. Yani ciddi teknoloji ve metodoloji bilgi ve tecrübesine sahip bir öncünün yol göstermesi, gerekirse kısıtlaması ve yönlendirmesiyle, kontrollü bir şekilde bu süreci işletmek, sanırım geçişi kansız ve çok daha verimli hale getirecektir.

Ben bu amaçla eğitim faaliyetlerimde müşterilerime, eğitimde verilen malzemenin, yukarıda kısaca açıkladığım gibi, ayrıca bir workshop ile proje geliştirme çalışması olarak da uygulanmasını salık veriyorum. Ancak bu şekilde eğitimde verilenin gerçekten öğrenilmesi mümkün olabilir. Workshopu yapmak için temel bilgiye sahip olmak gereklidir. Ama verilen bilginin sağlıklı bir yazılım geliştirme bağlamında anlam bulması için de ders içi ufak örneklerden öteye geçen workshopa ihtiyaç vardır. Benzerlik kurarsak, workshopsız bir eğitim ile doğrudan gerçek projeye girmenin, tahta üzerinde taktiği alıp maça çıkmaya benzediğini söyleyebiliriz. Bu yüzden workshoplarla bir miktar pişmeyen developerların, gerçek projeyi haklı olarak öğrenme amaçlı olarak kullanmaları çok sık görülen bir durumdur. Her projede öğrenme söz konusudur ama sahip olduğu teorik bilgiyi hiç kullanma imkanı bulamamış kişilerin doğrudan projeye atılmaları, projeyi çoğunlukla çöplüğe çevirmektedir. Halbuki aslolan, gerekirse workshopı çöplüğe çevirmek ama bu sayede anlamayı pekiştirmek ve gerçek uygulama ortamına hazırlanmaktır.

Bu noktada yazılımcı olarak çalışan arkadaşlara tavsiyem, eğitim alırken muhakkak workshop da talep edin. Bence kaç günlük ya da saatlik eğitim alıyorsanız aynı miktar workshopa ihtiyaç vardır.

Bu noktada benzer yaklaşımı, JavaTürk bünyesinde açmış olduğum eğitimlerde de kullanacağım ve gördüğünüz, aldığınız eğitimlerin workshoplarını da sanal ortamda açacağım. Bu şekilde isteyen eğitimden sonra workshopa devam edebilecek, eğitim ihtiyacı olmadığını ama uygulama ihtiyacı olduğunu düşünen de doğrudan workshopa dahil olabilecektir. Workshoplarla ilgili olarak eğitim sayfasını takip etmenizi öneririm.

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