Java

Corona Günlerinde Java

Eğitim ve Seminer, Java, Kariyer

Merhaba Java-severler

Corona günlerinde hepimiz eve tıkıldık, malum. Önce kaç gün sürer diye sorduk birbirimize ama baktık ki durum tamamen belirsiz, bu durumu fırsata çevirelim diye düşünmeye başladık. Hem akıl-ruh sağlığımızı kaybetmememiz gerekli hem de kriz sonrasında mesleki olarak daha iyi durumda olabilmeyi umuyoruz. Çünkü teknoloji dünyası o kadar geniş ve hızla ilerliyor ki krizle de olsa böyle bir zaman bize iyi gelecek gibi. Öte taraftan aklımızın bir köşesinde olan ama iş-güç telaşından hiç vakit ayıramadığımız meraklarımız da var. Bu zamanlar tüm bunlar için bir fırsat. Tabi sonrasının daha iyi, hayırlı olacağını umuyoruz.

Biz de Selsoft olarak corona günlerini değerlendirmek isteyenler için “evde kal ama geri kalma” düşüncesiyle bir dizi canlı sanal sınıf eğitimi hazırladık. Bu eğitimlerle ilgili detaylı bilgiyi http://www.selsoft.com.tr adresinde bulabilirsiniz. Canlı sanal sınıfın her türlü imkanını kullanarak, tartışarak, birlikte kod yazarak, kodlarımız üzerine konuşarak, sıcak ve paylaşımcı bir ortam oluşturmaya çalışacağız.

İlk eğitimimiz Java ile Nense-Merkezli Programlamaya Giriş (Introduction Object-Oriented Programming with Java). Java’nın en son sürümü 14 ile gelen özelliklerin de ele alınacağı bu eğitimde Java’nın makinaya kurulumundan en temel ayarlarına ve adım adım, nesnelerle algoritmaları ve ufak iş problemlerini modelleyip yazmaya kadar yapacak çok işimiz olacak.

Öğrenciyseniz Java ile çok iyi bir OOP temeline sahip olmaya başlarsınız, kariyer değişikliği yapmayı düşünüyorsanız, bunu en temelinden Java öğrenerek başlatabilirsiniz ya da hali hazırda zaten Java ile geliştirme yapıyorsanız, belki OCA/OCP olma yolunda değerlendirebilirsiniz bu eğitimi.

http://www.selsoft.com.tr adresine gittiğinizde Design Patterns, Spring ile Kurumsal Yazılım Geliştirme ya da Java ile RESTful Web Servisi Geliştirme gibi başka eğitimler de göreceksiniz. İlginize göre bu eğitimleri de sırayla açmayı planlıyoruz. Bu sayfadaki formları doldurarak bizimle iletişime geçebilirsiniz.

İlk oturumumuz her zaman ücretsizdir, herkese açıktır, buyrun gelin.

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

Java Nedir?

Java, Java Dersleri , , ,

Bundan taa 8 sene kadar önce, bu bloğun ilk yazılarından birisi olarak “Java Nedir?” başlıklı bir yazı yazmıştım. Tabi o zamandan bu yana köprünün altından çok sular aktı ve ben de biraz hatırlatma biraz yeni bilgilerle “Java Nedir?” sorusuna tekrar cevap vermek istedim.

Java’nın Kısa Tarihi

Sun Microsystems, 1982  yılında iki mühendis ve iki  işletmecinin ortak girişimi olarak kuruldu. Sun, Solaris işletim sistemi  ve Sparc CPU ve makinaları  (workstation) ile kurumsal  Unix platformlarında  başarılı bir markaydı. Sun yeni imkanlar aramak adına 1991’de Sun, Patrick Naughton, Mike Sheridan ve James Gosling  önderliğindeki küçük bir takımla bir AR-GE projesi başlattı. “Green Team” (Yeşil Takım) adlı bu takımın amacı  ICT (Information & Communication Technology)  dünyasına yönelik AR-GE yapmaktı.

Green Team

18 aylık bir çalışmadan sonra 1992 yazında “*7”, (Star Seven) isminde, dokunmalı ekrana sahip  bir kontrol cihazı geliştirdirler. “*7”, TV, video oynatıcısı ve müzik seti gibi pek çok ev cihazını kontrol edebiliyordu. Bu konuda Gosling’in şu videosunu seyredebilirsiniz: https://www.youtube.com/watch?v=1CsTH9S79qI

Gosling, projede önce C++’ı kullanıp, ona bazı eklentiler yapmasına rağmen sonrasında yepyeni  bir dil geliştirmenin daha iyi olacağını düşündü. Oak ismini verdiği bu dil, C/C++’a çok benzer söz dizimine sahip, nesne-merkezli ve platformdan bağımsızdı.  Basit olması için, C/C++’ın pek çok özelliğini dışarıda  bırakacak şekilde tasarlanmıştı

Green Team’in projesi ticari olarak başarılı olamadı. Ama takımın ileri gelenleri o sırada, geliştirdikleri alt yapının ve Oak dilinin Internet’e çok uygun
olduğunu farkettiler ve hemen yönlerini değiştirip, ismi daha sonra  resmi olarak HotJava olan Java-tabanlı bir tarayıcı  geliştirdiler: WebRunner

Bu konuda Gosling daha sonra şöyle demişti: “We had already been developing the kind of `underwear’ to make content available at the same 9me the Web was being developed. Even though the Web had been around for 20 years or so, with FTP and telnet, it was difficult to use. Then Mosaic came out in 1993 as an easy-to-use front end to the Web, and that revolutionized people’s perceptions. The Internet was being transformed into exactly the network that we had been
trying to convince the cable companies they ought to be building. All the stuff we had wanted to do, in generali9es, fit perfectly with the way applications were written, delivered, and used on the Internet. It was just an incredible accident. And it was patently obvious that the Internet and Java were a match made in heaven. So that’s what we did.”

Java, Sun tarafından 23 Mayıs 1995’te genel amaçlı bir programlama dili olarak piyasaya sunuldu. Java ilk çıktığında, yukarıda anlatılan sebeplerden dolayı pek çokları tarafından “Web’in dili” olarak algılandı. Nitekim Netscape’in web yenilikleriyle ile Java birlikte gelişti. Oracle’ın 2010 yılında Sun’ı satın almasıyla Java, Oracle’ın sahipliğinde hayatına devam etmektedir.

Java’nın çıkışıyla ilgili hala erişilebilen şu online kaynağa bakabilirsiniz: http://tech-insider.org/java/research/1998/05.html

Java’nın Temel Özellikleri

Java, söz dizimi (syntax) açısından C++’a çok benzeyen ve temelde Smalltalk ve C++ kültürünü benimseyen bir dildir. Java, 90lı yıllarda en yaygın sistem geliştirme dili olan C/C++’ın yerine geçecek şekilde geliştirildi. C++’dan daha küçük, daha soyut ve daha yetenekli bir dil olması amaçlandı.

1995 yılında büyük bir beklenti ile karşılanan Java’nın, o günden bugüne bu beklentileri karşıladığı söylenebilir. Java, muhtemelen, şu anda dünyada en geniş geliştirici topluluğu tarafından kullanılan, en büyük kapalı ya da açık kaynak kodlu kütüphanelere sahip, en çok kullanılan yazılım geliştirme dilidir.

Java Nedir?

Sun, 1995’te Java’yı sunarken yayınladığı ve “Java’nın babası” James Gosling’in kaleme aldığı bir yazıda (bu yazı “Java Whitepaper” diye anılan ve 1994 ve 1995 yıllarını tarih olarak içinde barındıran makaledir. Bu makaleyi Oracle’ın sitesinde bulamadım, bu adreste buldum. Bu tanıtıcı ve kısa makalenin daha uzun hali, 1996 Mayıs tarihli olarak ve yine James Gosling’in elinden çıkmış bir şekilde, “The Java Language Environment” başlığıyla yayınlandı ve şu anda da Oracle’ın Java sayfalarında bulunmakta.) Java’yı şöyle tanıtıyordu:

Java: A simple, object-oriented, network-savvy, interpreted, robust, secure, architecture neutral, portable, high-performance, multithreaded, dynamic language.

ya da
Java: Basit, nesne-merkezli, ağlarda yetenekli, yorumlanan, sağlam, güvenli, mimari olarak tarafsız, taşınabilir, yüksek performanslı/ba.arımlı, çok kanallı, dinamik bir dil.

Java Basittir

Java, ataları olan C ve C++’tan daha basittir. Çünkü onların pek çok karmaşık özelliğini budamıştır:

  • Pointer aritmetiği,
  • Programcıya bağımlı bellek yönetimi (memory management),
  • İşlemci çoklu kullanımı (operator overloading),
  • Platforma bağımlı yapılar.

Budanan ve yeni gelen özellikler ile Java, C/C++’tan daha küçük ama özellikle genel amaçlı kullanım ve iş uygulamaları için, nesne-merkezli ve daha soyut yapısı sayesinde daha güçlü bir dil oldu. Budanan özellikler ve soyut yapısı, Java’yı daha rahat kullanılabilir hale getirdi.

Diğer Özellikleri

Nesne-merkezli (object-oriented), ağlarda yetenekli (network-savvy), sağlam (robust), güvenli (secure) ve çok kanallı (multithreaded) gibi
özellikleri, 90’lı yılların şartlarında ve C/C++’a göre yorumlamak daha anlamlıdır. Bugünlerde bir dilin bu özelliklere sahip olması sıradan bir durum olarak görülür.

Dinamik Dil
Java, dinamik tipli (dynamically-typed) değildir, aksine statik tipli (statically-typed) bir dildir. Java’nın dinamik olmasıyla kastedilen, tipleri
çalışma zamanında (run-time) yükleyebilmesidir. Dolayısıyla Java’da bir programın kullanacağı tipler,
uygulamanın derlenmesi ya da ayağa kalkması sırasında hazır olması gerekmez. Webin tabiatına daha uygundur.

Mimari Olarak Tarafsız
Mimari olarak tarafsız (architectural-neutral) olması, Java’nın herhangi bir platforma (donanım ve işletim sistemi) bağımlı olmaması demektir. Java, standartlar üzerine kurulmuştur. Örneğin, int her platformda 32-bittir. Ayrıca, Java ve JVM, platformlarla alakalı sadece en genel ön kabullere sahiptir

Taşınabilir
Java’nın platformlardan bağımsız olması ve yorumlanan (interpreted) tabiatı, onu aynı zamanda taşınabilir (portable) kılmaktadır. .java uzantılı dosyalarda saklanan Java kaynak kodu derlendiğinde (compiled), .class dosyasında bytecode olarak saklanır ve bytecode, platformdan bağımsızdır, JVM’in olduğu her ortamda çalıştırılabilir. Aşağıdaki çizimlerde bu mekanizma anlatılmaktadır.


WORA ve WOTA
Başından bu yana Bir Kere Yaz Her Yerde Çalıştır (Write Once, Run Anywhere, WORA) Java’nın taşınabilirlik konusundaki hedefidir. Tabi olarak bu prensibin geçerli olması için Java programcısı da platforma özel kod yazmamalıdır. Ama pratikte geçerli olan, Bir Kere Yaz Her Yerde Test Et (Write Once, Test Anywhere, WOTA) prensibidir.

Yüksek Başarımlı
Yüksek başarımlı (high-performance) ile aslen, tüm bu özelliklerine rağmen performans açısından iyi bir seviyede olduğu/olabileceği/olma hedefi vurgulanmıştır. Aslen Java’nın performansı ilk yıllarında iyi değildi. Fakat özellikle 2. sürümünden itibaren HotSpot JVM ile performansı iyileşti. Sonraki sürümlerinde özellikle kullanılmayan nesnelerin toplanmasından sorumlu çöp toplayıcı (Garbage Collector, GC) noktasında yapılan iyileştirmeler, Java’yı hemen her türlü yüksek performans ve ölçeklenirlik gerektiren uygulamalar için uygun hale getirmiştir. Her halükarda Java geliştirenlerin performans konusunda bilgili ve dikkatli olmaları gereklidir.

Nesne-Merkezli
Java nesne-merkezli bir dildir. Nesne-merkezli diller, prosedürel/yordamsal dillerden çok farklıdırlar. Yordamsal dillerde en önemli kavram/soyutlama yordam/prosedür/fonksiyondur ve bu yapılar, bir problemi alt problemlere bölüp, her birini adım adım (step-wise decompositioon) tanımlamakta kullanılır. Fakat nesne-merkezli diller tamamen nesne kavramı üzerine otururlar.

Nesne, insan zihninin kendisine yöneldiği, özellik ve davranı.lara sahip, fiziksel olan ya da olmayan herhangi
bir olgudur. Yazılımda her tip nesne için, verisi ile davranışını bir paket haline getirip sarmalayan ya da kapsülleyen (encapsulation) ve adına genelde sınıf (class) denen kalıplar (şablonlar) oluşturulur.
             

            Sınıf = Veri + Davranış

Nesneler, sınıflardan üretilmiş çalışma zamanı yapılarıdır.

Java Derlenir
Derleme (compilation) ve yorumlama (interpretation), programlama dilleri dünyasının en temel kavramlarındandır. Genel olarak derleme, kaynak kodun bir formdan
başka bir forma çevrilmesidir. Özelde ise kaynak kodun, çalıştırılabilir (executable) makina koduna çevrilmesidir.

Yorumlama ile kaynak kod, başka bir forma çevrilmeden, makina kodundaki bloklar çağırılarak çalıştırılır, yorumlanır.

 

Derlenen kodlar, çok daha etkindirler çünkü hem hatadan temizlenmişlerdir hem de çalışma zamanına daha az iş bırakmışlardır. Ama makina koduna derleme, kodu platforma bağımlı kılar. Yorumlama, kodu daha kırılgan ama dinamik ve platformdan bağımsız yapar, çünkü, platform bilgisi ancak çalışma zamanında gerekir.

Java hem derlenir (compiled) hem de yorumlanır (interpreted). Java’nın çıktığı zamanın paradigması genel olarak güçlü sistem dillerinin derlenen olmasıydı. Bu durum programları hem daha az hatalı hale getiriyor hem de çok ciddi performans avantajı sağlıyordu. Java ise iki tarafın da avantajlarını kullanabilmek için hem derlenen hem de yorumlanan bir yapıda tasarlanmıştır. Bu sayede Java hem olabildiğince sağlam (robust) bir çalışma-zamanı yapısı geliştirmiş hem de platformadan bağımsız olmuştur. Bu  sebeple Java’nın yorumlanan yapısı daha fazla vurgulanmıştır.

Java kaynak kodları (.java dosyaları) doğrudan makina koduna derlenmez, bytecodelardan oluşan .class dosyalarına derlenir. Bytecodelar ise çalışma zamanında JVM tarafından yorumlanır. Bytecodelar, JVM’in komutlarıdır, Bir byte uzunlu.unda olduğu için böyle adlandırılmıştır. Bytecode, herhangi bir işlemciye özel değildir yani sadece JVM’e özeldir. Bytecodelar, JVM tarafından çalışma zamanında platforma özel komutlara çevrilir, yorumlanır. Bu şekilde Java’nın platformdan bağımsız ve taşınabilir olması sağlanır.

JVM
JVM (Java Virtual Machine ya da Java Sanal Makinası), platform üzerinde çalı.an sanal bir makinadır. Derlenmiş Java kodlarını, bytecode, çalıştıran sistemdir. JRE’nin (Java Runtime Environment) ana parçasıdır, C/C++ ve Java ile yazılmıştır. Java’nın çalışması beklenen her platformda kurulu bir JVM olmalıdır. JVM’i, geliştiriciye bakan yüzü standart ama platforma bakan yüzü, onunla konuşan bir ara katman olarak düşünebilirsiniz.

Java’nın Tipleri

Farklı türde uygulamalar için 3 farklı Java sürümü ya da paketi mevcuttur:

  • Standart Java (Standard Edition, SE), çekirdek dildir. En son 9. sürümü çıkmıştır.
  • Mikro Java (Micro Edi5on, ME), gömülü ve mobil ortamlar içindir. En son 8. sürümü çıkmıştır.
  • Kurumsal Java (Enterprise Edition, EE), kurumsal uygulamalar içindir. En son 8. sürümü çıkmıştır.

21 Eylül 2017’de Java SE’nin 9., Java EE’nin 8. sürümü yayınlandı. Java EE ve ME, Java SE üzerine bina edilmiştir. Dolayısıyla önce Java SE öğrenilmeli, daha sonra ihtiyaca göre örneğin Java EE’nin web, entegrasyon ya da transactional yapılarına geçilmelidir.

Java’nın Popülerliği
(Dillerin popülerliği ile ilgili pek çok index vardır. Kesin bir şey söylemek zor olsa bile muhtemelen Java en çok kullanılan 2-3 dilden birisidir. İddia edilen şey, Java’nın muhtemelen, dünya çapında en büyük geliştirme toplumuna sahip bir dil olduğudur. Örneğin Java TIOBE indexinde Ekim 2017’de birincidir. Dünya çapında 7 ila 10 milyon civarında geliştirici sayısından bahsedilmektedir. TIOBE’ye göre dünyadaki programcıların %17’si Java kullanmaktadır. Ya da Amazon’da farklı dilleri kullanarak kitap araması yapıldığında Java kitaplarının en zengin grubu oluşturduğunu görebilirsiniz.

Pek çok ülkede olduğu gibi ülkemizde de iyi yetişmiş programcı/developer eksikliği söz konusudur. Bu konuda kesin bir ölçüme ya da niceliksel bir çalışmaya rastlamamış olmakla beraber, kurumsal uygulamalar (örneğin 10 ya da daha fazla programcıya sahip olan yazılım evleri ve BT birimlerinin projeleri bu tanıma girsin) açısından bakıldığında muhtemelen ülkemizde de Java dünyası en geniş dil topluluğunu oluşturuyor olabilir.

Bol Java’lı günler dilerim 🙂

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

Alelade Hikayeler – II: Bir Başka Performans Problemi

Hikayeler, Java, Performans , ,

Bugünkü hikayemizde yine bir performans problemi var. Problem, Java EE ile geliştirilmiş ve Weblogic AS üzerinde çalışan, transactional, web üzerinden tamamen internete açık ve sorgulama arayüzlerinin yoğun olarak kullanıldığı bir bilgi sistemiydi. Sistem çoğunlukla mesai saatleri içinde kullanılıyordu, sonrasında erişilebilir olsa bile kullanımı çok azdı. Problem ise, tamamen gelişigüzel ya da random olarak seyreden yavaşlıktı. Sistem yöneticileri yaptıkları gözlemlerde zaman zaman, ön taraftaki use caselerle ilişkilendiremedikleri yavaşlamaların sebebinin aşırı bellek tüketimi olduğunu belirlemiş durumdaydılar. Sistem clustered bir ortamda çalıştığından herhangi bir kesinti yaşanmıyordu ama bu problemin de çözülmesi gerekliydi.

Sistem yöneticilerinin verdikleri bilgilerden sonra lider developerlarla görüştüğümde, bazı usual suspect araştırmalarımı yaptım. Örneğin veri tabanı sorgulamaları, sorgulardan dönen verinin mahiyeti, bu verinin uygulama tarafından nesnelerle nasıl yönetildiği, web tarafındaki oturum (session) yönetimi vs. konulardaki yaklaşımlarını öğrenmeye çalıştım. Developerlardan bir şey çıkmadı, dahası her şeyi düşünerek ve iyi bir şekilde yaptıklarını, bundan dolayı da bu bellek problemine anlam veremediklerini söylediler. Biraz da “bizim problemimiz” değil havasındaydılar izlenimi elde ettim.

Sonrasında, sistemin kullanımda olmadığı, gece yarısı gibi bir zamanda, canlı ortamdaki uygulama sunucularının bize daha fazla bilgi verecek şekilde çalıştırılmalarını sağladım. Ben de test amaçlı kullanılan, pre-production sistem üzerinde çalışmaya başladım. Ortama girmek, genel de olsa mimariyi öğrenmek, sistemin ayağa kalkarken kullandığı parametrelerini bulmak vs. nihayetinde böyle ortamlarda sıklıkla yaptıklarımdandır. Sistemler büyüdükçe, onlara dokunmak ve bilgi almak daha da karmaşıklaşır. Erişebilmek bile bir problem haline gelir.

Neyse, test sistemi üzerinde bunları elde ettikten sonra, olabildiğince çok kişinin, sistemi kullanması sağlandı ve ben de JVM içindeki olup biteni gözlemlemeye başladım. Fakat bu çalışma çok da işe yaramadı, çünkü problemli durumu üretmedi. Sebebi, kullanıcı sayısını azlığı yanında, hep bildiğimiz, developerların tester olarak kullanılmasının getirdiği yapaylıktı. Fakat sebebini bilmediğimiz bir problemi ararken, şansımızı olabildiğince arttırmak için yapılabilecek her şeyi yapma eğiliminde oluruz. Hatta bu çalışmalar sırasında, performansla pek de alakası olmayan konularda gözlemler yaptım ve bunları paylaştım. Mesela isimlendirme ile ilgili konulardan tutun da çok karmaşık metot ve sınıflara kadar, cohesion ve coupling problemleri, gerekli gereksiz kullanılmış wrapper sınıflar, çok threadli ortam olmasına rağmen bu göz önüne alınmadan yazılmış kodlar vs. Tonla teknik borç çıkar o sıradaki çalışmalardan ama bunları kim duyar da kulak verir, onu sormayın.

Performans problemlerinin sebebini bulmak çoğu zaman onları düzeltmekten daha zor olabilir. Çok basit bir kod hatası, deadlock ya da sonsuz döngü problemi, hemen hiç bir şekilde koda bakarak anlaşılacak tipten bir problem değildir örneğin. Dolayısıyla o hatayı tekrardan üretemezseniz, probleme yol açan durumu tekrar, kontrollü bir şekilde gözlemleyemezseniz, problemi bulmak için çok da şansınız yoktur. Zamanınız ve imkanınız varsa, sistem üzerinde otomatik test araçlarıyla çalışıp yük üretebilirsiniz ama hala problemi oluşturacak durumu yaratamayabilirsiniz. Örneğin, yüzlerce arayüzün belki de çok basit bir noktasından tetiklenen bir problemdir peşinde koştuğunuz ama siz boş yere farklı use caselere yüklenerek arka tarafta, JVM’in içinde bir bellek problemi, çok uzun süren metot çağrıları, veri tabanından dönmeyen sorgular vs. arar durusunuz. Nitekim burada da öyle oldu.

Ertesi gün çalışmaya devam ederken, canlı ortamdaki uygulama sunucularından birinde benzer bir yavaşlık gözlemlendi ve sonrasında uygulama sunucusunun JVM’inin dumpını alıp üzerinde çalıştığımda, hiç bir filtreden geçmeden dolayısıyla “where” ifadesine sahip olmadan veri tabanına gönderilen bir sorgunun, yüzbinlerce satırı belleğe yüklediğini, JVM’in de heap belleğinin tamamını bu sorgudan dönen satırlardaki nesneleri oluşturmak için kullandığını gözlemledim. Hatta dumptan yola çıkarak o anda sistemde hangi kullanıcıların oturumlarının olduğunu, hangi kullanıcının, web arayüzünde nerede, bu sorguyu çalıştıracak use casei işlettiği vb. verilerin hepsine ulaştım. Bu arada parantezlik ufak bir bilgi: Eğer kritik bilgileri, örneğin şifreleri vs. hashlemezseniz, benim gibi çalışanlar, o anda sistemi kullananların tüm mahrem bilgilerini kolayca görebilirler!

Sonrası iplik söküğü gibi geldi zaten. Ön tarafta, arayüzde ne yapıldığı, arkada hangi metot çağrılarından sonra veri tabanına hangi sql cümlesinin gönderildiği, dönen cevaptaki satır sayısı, her satırdaki bilgi vs. hepsini ortaya koydum. Developerların gözünden kaçan bir durum, kötü bir sql sorgusu oluşturuyor ve joinlerden sonra oluşan yüzbinlerce satır, sorgunun cevabı olarak JVM’e dönülüyordu. Web arayüzünde zaten böyle bir cevap beklemeyen developerlar, herhangi bir paging de uygulamadıklarından, JVM’e, veri tabanından dönen satırlar için tonla nesne yaratmak dışında bir seçenek de bırakmıyorlardı.

Developerlara bu durumu ilettiğimizde, hızlıca gidip web arayüzüne bir kaç kontrol, zorunlu alan vs. filtreleri koydular ve problem ortadan kalktı. Problemi bulmak 2 küsür gün tuttu, çözmek en çok bir saatti! Ah şu developerlar olmasa ne kadar rahat olacak yazılım geliştirmek!

Developerlar eğer yaptıkları işi daha geniş bir perspektiften göremiyor ve “benim makinamda çalışıyor” ya da “ben test ettim, hiç bir problem yok” şeklinde konuşuyorlarsa, lütfen buna güvenmeyin. Bu tavra önem verin, bu tür sözlerin arkasını doldurmaya zorlayın onları ama sadece bu sözlerle ilerlemeyin. Ya da bir başka deyişle, her developerın bunu söyleme hakkı olmadığını bilin. Tam da bu yüzden architect/mimar vb. rollerle, sisteme çok farklı açılardan, yukarıdan, bakabilen, tecrübeli ve sistem anlayışına sahip kişilere ihtiyacımız var.

Kıssadan hisse: Yazılım geliştirme, developerlara bırakılamayacak kadar karmaşık bir iştir!

 

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

Alelade Hikayeler – I: Küçük Bir Performans Problemi

BT, Hikayeler, Java , ,

Yazılım dünyasında en sık yaşanan problemlerden birisi de, “performans” genellemesiyle anılan bir dizi problemdir. Problem bazen bir işlemin yapılmasının uzun sürmesidir, bazen son derece hızlı olan işlemlerin zaman zaman, muhtemelen sistemin yüküne bağlı olarak yavaşlamasıdır, bazen fazla bellek kullanımıdır, bazen de veri tabanından sorguların çok yavaş gelmesidir vs. Bu tür performans problemlerini çözmek bana daima en tatmin edici işlerden gelmiştir.

Bir gün ofisimde çalışırken, bir yazılım evi sahibi ve yöneticisi, feveran içinde bana ulaştı. Müşterileri için geliştirdikleri sisteme en son yaptıkları değişiklikleri devreye aldıklarında yaşadıkları ve kendilerini bir hayli zora koyan bir performans problemini çözecek kişiyi araştırırken bana ulaşmıştı. Bana telefonda söylediği şey, yeni yaptıkları deploymenttan sonra 10-15 dakika içinde sistem cevap veremez hale geliyor ve nihayetinde de çöküyordu. Sistem, Tomcat üzerinde çalışan ve tabi olarak Java ile geliştirilmiş, web arayüzlü ve kurum içinde, intranette pek çok kullanıcısı olan operasyonel bir bilgi sistemiydi.  Bundan dolayı sistemi kullanan müşterilerine karşı çok zor durumda kalmışlardı ve kendini çaresiz hissediyordu. Sistemin de tabi olarak kullanıcıları vardı ve eski sürüme dönerek hiç olmazsa işlerin devam etmesini sağlıyorlardı.

Bu konuşmadan yaklaşık 15-20 dakika kadar sonra, yaptığımız telefon görüşmeleri sayesinde, sıkıntılı olan sisteme erişmiş haldeydim. Ayrıca bu sistemin koduna da erişim sağladı müşterim. Sistem yöneticisi yardımıyla kabaca ne olup bittiğini anladıktan sonra bir-iki ufak ayar ile Tomcat’i tekrar başlattım ve ertesi sabah, kullanıcıların gelip sistemi kullanmaya başlamalarını bekledik. Tabi, ertesi sabah, çalışma saatini müteakip 10-15 dakika içinde sistem yine çalışamaz hale geldi ve JVM de bize bir dump üretti.

Elimdeki JVM dumpı ve sistemin Java kodlarına erişimim sayesinde yaklaşık 15-20 dakikada, hadi abarttım diyeyim, yarım saat içinde problemin sebebini, koddaki satırını hatta çözümünü belirlemiştim. Nihayetinde gözden kaçan çok basit bir kodlama hatasından kaynaklanıyordu problem. Kodun o parçası sonsuz döngüye giriyor ve her döngüde üretilen yeni nesneler GC tarafından toplanamadığından, çünkü nesneler bir torbaya (collection) konuyordu, belleği şişiriyordu.

Müşteriye durumu açıkladım, yapılması gerekeni de belirttim ve onlar da sistemi sorunsuz bir şekilde devreye aldılar. Onların derdi çözüldü, beni keyfim arttı ve para da kazandım.

Ama sanırım bu kısa hikayede göze çarpan başka noktalar da var. Neler mesela?

Bu hikayeden yazılım geliştirme ile ilgili olarak çıkarılabilecek olan dersler şunlardır:

  1. Eğer kodunuzu daha sakin kafayla, ne yaptığınızı düşünerek yazarsanız, çok yüksek ihtimalle böyle bir hata yapmazsınız.
  2. Eğer yazdığınız kodun birim testini yaparsanız, bu türden problemleri asla yaşamazsınız.
  3. Yazdığınız kodu makinanıza deploy edip, biraz doğru düzgün bir veri ile çalıştırsanız ki biz buna smoke test diyoruz, bu problemi yakalarsınız.
  4. Eğer kod gözden geçirmeleri (review) yaparsanız, sizin gözünüzden kaçsa bile, yorgundunuz, aile-sosyal hayatta stresleriniz vardı, vs., muhtemelen arkadaşlarınızın, daha tecrübeli olanların gözünden kaçmaz.
  5. Eğer sistemin entegrasyon testini yaparsanız, bu türden problemlerler çok daha az karşılaşırsınız.
  6. Eğer sistemin fonksiyonel testini yaparsanız, testerlarınızla, bu türden problemlerleri muhtemelen müşteri karşısına çıkmadan yakalarsınız.
  7. Yukarıdaki üç testi ve gözden geçirmeleri yaparsanız, herhangi bir test ya da tamamen informal bir gözden geçirme yapılsa bile, kesinlikle bu problem müşterinin önüne gelmez ve nerede bulduğunuza göre çok daha ucuza çözersiniz.

Bunlar, yazılım süreçlerini doğru işletmekle ilgili olarak yapılabilecek çıkarımlar. Genel prensipler açısından ise şöyle çıkarımlarda bulunabiliriz:

Belki 40-50 kişilik developer ve sistem yöneticisinden oluşan bir yazılım ve sistem ekibine sahip bir yazılım evinin ürettiği yüzbinlerce belki bir kaç milyon satırlık koddaki bir performans problemini bulmak yarım saati geçmeyen bir sürede başarılabiliyorsa, bu durumun sistemsel bir problem olduğu açıktır. Çok sıklıkla yaptığımız gibi, zeka ya da yetenek ile açıklayamayız bu farkı. Bu fark, sistemi tasarlayan, kodlayan ve deploy eden takımın içinde hiç bir şekilde bir performans farkındalığının olmamasıyla açıklanabilir. Ayrıca bu durum, bu takımda merak edip Java’nın performans problemlerini araştıran, etrafındakileri bilgilendiren meraklı kişilerin olmadığı şeklinde de okunabilir. Bu fark, sistemi tek tek developerların geliştirdiği ama kesinlikle “bir takımın” geliştirmediği şeklinde de okunabilir. Ve bu durum, gerekli temel bilgiye ve problemi bulup, analiz edip, çözme yetkinliklerine sahip bir kişinin, pek çok insanın günlerce, bilinçsizce problemle cebelleşmelerinden çok daha etkin bir şekilde sonuca ulaşabileceğini de gösterir.

Kıssadan hisse: İyi bir teoriden daha pratik bir şey yoktur. (There’s nothing more practical than a good theory. (Kurt Lewin))

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

1 2 3 4 5 >»