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

Bilgi Teknolojilerinde Yetenek Yönetimi – II: Tanımlar ve Eleştiriler – I

Yetenek Yönetimi ,

Bir önceki yazıyla genel olarak yetenek yönetimine giriş yapıp,Bilgi Teknolojilerindeki öneminden bahsetmiştik. Şimdi ise Yetenek Yönetiminin ne olduğuna daha detaylı ve eleştirel bakabiliriz.

Tanımlar ve Eleştirileri

Her  revaçta olan kavram gibi Yetenek Yönetimi’nin de farklı açılardan pek çok tanımı yapılmıştır. Society for Human Resource Management (SHRM)’nin tanımına göre Yetenek Yönetimi (ya da bundan sonra YY), “o anki ve gelecekteki iş ihtiyaçlarını karşılayacak şekilde, gerekli yetkinlik ve tavra sahip kişileri, kuruma çekmek, geliştirmek, elde tutmak ve değerlendirmek için geliştirilmiş süreçlerle, işyeri verimliliğini arttırmak amacıyla oluşturulmuş, bütüncül olan strateji ve sistemlerin uygulanmasıdır.“ (Broadly defined as the implementation of an integrated strategies or systems designed to increase workplace productivity by developing improved processes for attracting, developing, retaining and utilizing people with the required skills and aptitude to meet current and future business needs.) (SHRM’in “Glossary of Human Resources Terms” isimli çalışmasına https://www.slideshare.net/freeKhan/glossary-of-human-resources-management-terms adresinde erişilebilir.).

American Society for Training and Development (ASTD)’ye göre ise YY “iş hedeflerine uygun olan bütüncül yetenek kazandırma, geliştirme ve yerleştirme süreçleri ile kültür, iş yapış şekli, kabiliyet ve kapasite oluşturarak insanları yönetmeye kurumsal bir yaklaşım” olarak tanımlamaktadır.  (ASTD defines talent management as an organizational approach to leading people by building culture, engagement, capability, and capacity through integrated talent acquisition, development, and deployment processes that are aligned to business goals.) Pek çok makale ve kitapta, yukarıdakine benzer, muhtemelen aynı ve farklı terimleri kullanarak yapılmış YY tanımlarına rastlanabilir.

Lewis ve Hackman (Talent management: A critical review. Human Resource Management Review 16 (2006) 139–154), literatürdeki YY tanımlarıyla ilgili değerlendirmelerde bulunup, bu tanımların genel olarak şu üç kategoriden birinde ele alınabileceklerini iddia ederler:

  • İlk gruba göre YY, İnsan Kaynakları’nın (bundan sonra İK) yeni adıdır çünkü bu gruba giren tanımlarda YY, klasik İK faaliyetlerinden olan, aday bulma, işe alma, geliştirme, motive etmenin artık Internet vasıtasıyla daha hızlı olarak ve bir departman yerine tüm kurum çapında yönetilmesidir. Onlara göre YY eskiden sadece yüksek seviyeli yöneticilerin yetiştirilmesi ve yerleştirilmesine odaklanmışken artık kurumdaki her seviyede işletilmelidir. Bu anlamda, bahsedilen makalede örneğin, eskiden risk yönetimi çerçevesinde gerekli görülen pozisyonlardaki çalışanların değiştirilmesi/yedeklenmesi ile ilgili planlamanın (replacement planning), tarihi olarak önce stratejik personelin geliştirilmesi ve yerleştirilmesi amacıyla terfi planlamaya (sucession planning), sonra da nihai olarak, daha geniş çaplı kaynak bulma ve geliştirme amaçlı olarak YYne dönüştüğü açıklanır. YY’nin, İK anlayışının tarihi olarak gelişmesinde şu an itibariyle gelinen son nokta olduğu su götürmez bir gerçektir. Fakat bu anlayışta problem en temelde, “yetenek” ve YY kavramının ve ilgili anlayış ve tekniklerin, İK’nın kurum içindeki yerini ve çalışmasını nasıl değiştirdiğini ya da değiştirmesi gerektiğini açıklamadan, YY’nin İK tarihi açısından sadece bir nokta olduğunu savunmaktır.
  • Lewis ve Heckman’ın sınıflandırmasında ikinci tipteki tanımlar genelde YYni, insan kaynakları planlaması ve terfi (succession) amaçlı olarak, eldeki yetenek havuzunun devamlı dolu tutulması çalışmalarına hasrederler. Örneğin “Talent Management Systems” isimli kitabında Allan Schweyer, işgücü planlamasından (workforce planning) çok sıklıkla bahseder ve YY sürecinin, iş gücü analiziyle başladığını söyler. Kitap, yetenek ve yetenek yönetimi kavramlarını tam olarak irdelemeden, yetenek yönetimi sistemlerinin daha çok pratik olarak uygulanması ve teknolojik taraflarıyla ilgilenir.
  • Lewis ve Heckman’a göre üçüncü tipteki YY anlayışları, yetenek kavramını genel olarak ele alırlar ve yetenekten daha çok performansı anlarlar. Bu anlamdaki yaklaşımlarda, YYnden, yukarıdaki ikinci anlayışta olduğu gibi sadece terfi/yerine koyma yönetimini anlamazlar çünkü onlara göre yetenekli çalışanlar her zaman önemlidir ve doğru yönetilmelidirler. Bu yaklaşıma örnek olarak yazarlar, Axelrod, Hanfield-Jones ve Michaels’in “A New Game Plan for C Players” isimli makalesini örnek olarak vermektedirler. Makalede yöneticilerin yetenek yönetimi için performans tabanlı bir yaklaşım izlenmekte ve yöneticilerin performansları ölçülerek, A, B ve C isimli üç farklı seviyede ifade edilmeleri önerilmektedir. Bu yaklaşıma göre C seviyesinde performans gösteren yöneticiler, ne yenilikçidirler ne de başkalarını motive edebilirler. Daha önce A ya da B seviyesinde olmalarına rağmen farklı sebeplerden dolayı artık C seviyesinde bir performansa sahiptirler ve bu tip yöneticilerin, “kadife eldivenli bir demir yumruk” tarafından kurumdan uzaklaştırılmaları gereklidir.  Bu makalede de “yetenek” kavramına herhangi bir altyapısal bir tanım, verilere dayalı bilimsel bir teorik açıklama getirilmeksizin, sadece performansa bağlı olarak, daha kötü durumda olanların işten çıkarılmaları gerektiği savunulmaktadır.

Lewis ve Heckman, çalışmalarında, bu üç yaklaşıma örnekler verdikten sonra bu yaklaşımlara getirdikleri eleştirileri de sıralarlar. Eleştirilerin ilki, yöntem açısındandır: Bu üç yaklaşımın örneklerinin hiçbirisinin, yetenek ve yönetimiyle ilgili bilimsel, verilere dayalı, bir teoriyle desteklenmiş, açıklanmış  ve test edilmiş bir yaklaşım getirmemiş olmalarıdır. Bu yaklaşımlarda bir başka temel problem ise, YYni, temelde “stratejik İK” gibi algılamaları ama İKnı neyin “stratejik” yaptığı konusu ise hala muğlak bırakmalarıdır. Dolayısıyla bu iki yazar, YY ile strateji arasındaki ilişkinin sistemli bir şekilde kurgulanmadığını iddia ederler.

Bu yaklaşımlardaki bir başka problem ise, “yetenek” kelimesinin artık “insan” ya da “çalışan” kelimesinin yeni şekli olmasıdır. Dolayısıyla Lewis ve Heckman bu makalelerinde, “yetenek” kavramının ne olduğu iyice irdelenmeden ve analitik olarak bileşenleri bulunmadan oluşturulacak bir YY yaklaşımının, klasik İK algımıza yeni hiç bir şey katmayacağını savunurlar. Benzer şekilde, iş gücü ve terfi planlamasının son derece önemli bir faaliyet olmasına rağmen, bu çalışmaların YY olarak adlandırılmasındaki probleme de dikkat çekerler. Gerçek şu ki, gerek şu an için gerek ise ileriye yönelik öngörüler ışığında, kurumu dara da sokmayan ama öte taraftan israfa da götürmeyen, sağlıklı bir iş gücü planlamasın, kurumun rekabet gücü ve verimliliği açısından hayati bir önemi haiz olduğu bir gerçektir. Geleceği öngörmedeki zorluklar ve olası durumlar karşısında İK ve ilgili iş birimlerinin farklı çözümler geliştirmesi gibi bir çalışmanın YY’nden ayrı düşünülemeyeceği ne kadar doğru ise, YYni, sadece böyle bir amaca hasretmek, işgücü planlamasının YY’nin temeli olduğunu ifade etmek de o derece sıkıntılıdır.

Lewis ve Heckman, YY’ne üçüncü yaklaşımın en problemli olduğunu ifade ederek, çalışanların tek tek performanslarına odaklanmanın ne kadar kritik, stratejik ve ekonomik olduğunu sorgular. Nitekim literatürde, doğrudan performansa bağlı değerlendirmelerin ne kadar sağlıklı olduğu ya da performansın kendisinin ne kadar stratejik bir faktör olduğu ya da en yüksek performansın her zaman en iyi durum olduğuyla ilgili şüpheleri ifade eden çalışmalar mevcuttur. Zaten performans yönetimi, eskiden bu yana İK’ın görevleri arasındadır ve bunu YY olarak tanımlamak, YY’yi İK’nın yeni ismi olarak görmekten başka bir şey değildir.

Lewis ve Heckman’a göre YY ile ilgili anlatılanların ciddi bir kısmı veri yerine hikaye ve kişisel yorumlara dayanmaktadır. Makalede, sıklıkla duyulan, “XXX firması, YY sayesinde şu kadar zamanda şu kadar kar etti ya da büyüdü” cinsinden ifadeler üzerine bir YY anlayışı bina etmenin nasıl problemli olduğundan bahsedilir. Nihayetinde yazarlar, ele alınan üç kategorideki YY yaklaşımının, genel olarak, İK prensiplerinin bir uygulamasından ibaret kaldığını saptayarak eleştirilerini bitirirler.

Lewis ve Heckman makalede daha sonra sağlıklı bir YY anlayışının neler üzerine bina edilmesi gerektiğini tartışmaya başlarlar. Onlara göre YY, mimaridir çünkü yeteneği yönetmek hem sistem seviyesinde hem de stratejik olmalıdır.  Bu anlamda kurumun stratejik hedefleri ve öncelikleri, kurgulanacak olan YY için, en baştan itibaren en belirleyici olmalıdır. İleride kurumun stratejilerinde bir değişiklik olduğunda, YY, bu değişiklikler doğrultusunda hızlıca gözden geçirilip yeni stratejilere uygun hale getirilebilmelidir. Bu durum da stratejilerin YY’nde nasıl belirleyici olduğunun, hangi noktaları nasıl yönlendirdiğinin bilinmesini en başından gerekli kılmaktadır.

 

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

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

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

«< 2 3 4 5 6 >»