Kurumsal Java Yazılımı

[Kurumsal Java Yazılımı - Özcan Acar]

Kurumsal Java Yazılımı

---

İnşaat ve Yazılım Mühendisleri Arasındaki Fark Posted: 15 Apr 2012 12:58 AM PDT İnşaat mühendisleri: Sıkıysa çok dikkatli çalışmasınlar. En ufak bir yanlış statik hesap yorumlaması bile binanın yıkılmasına sebep olabilir. Binayı sadece bir kez inşa edebilirler. Netice hoşlarına gitmeyince, boz yeniden yap yapamazlar, yani tek bir şansları var. İnşaatın maliyeti çok yüksektir. Herşey buna odaklı önceden planlanır ve uygulanır. İnşaat mühendisi ne yapacağını önceden en ince detayına kadar bilmek zorundadır. Bunu yazılımda şelale (waterfall) yöntemi ile kıyaslamak mümkündür. Aslına bakacak olursak binalar sadece şelale yönetime göre inşa edilebilir. İnşaat sona erdikten sonra müşteri beğenmedi diye örneğin temel sökülüp, yeniden yapılamaz. İnşaatı bitmiş bir bina artık hemen hemen statik ve değiştirilmesi mümkün olmayan ya da çok zor olan bir cisimdir. Mimar tarafından bina mimarisi inşaat başlamadan önce yapılır. Mimari yapı belli olmadan inşaat mühendisi binayı inşa etmeye başlayamaz, çünkü ne yapacagını bilemez. Mimar yoksa inşaat mühendisi de yoktur. Gecekondu yapıyorsanız durum farklı tabi. İnşaat mühendisi kendisine verilen statik hesaplamaları ve mimariyi harfiyen uygular. İnisiyatif kullanıp, mimariyi ve yapıyı yeniden şekillendiremez. Bir binanın yeniden yapılandırılması çok maliyetli bir iştir ve çogu zaman imkansızdır. Yazılım mühendisleri: Yazılım sisteminden bir yapı (build) oluşturmak masrafsız bir iştir. Yazılım mühendisi hergün istediği kadar yapı oluşturabilir. Yazılım mühendisi, yazılım sistemini oluştururken inisiyatif gösterip doğru bulduğu tasarım şablonlarını ve tasarım prensiplerini uygulayabilir. Yazılım mühendisi, yazılım sisteminin mimarisi belli olmadan kod yazmaya başlayabilir. Nitekim çevik süreçlerde basit ve pragmatik bir mimari ile başlanması önerilmektedir. Zaman içinde müşteri istekleri doğrultusunda mimari oluşur. Değişikliği mümkün kılan da zaten budur. Yazılım mühendisi yeni müşteri gereksinimleri ile yazılım sisteminin mimarisini revide edip, değistirebilir. Yazılım mühendisleri ile inşaat mühendisleri arasındaki en bilirgin farklılık budur. Müşteri gelip yazılım mühendisine her zaman yeni isteklerini ve değişiklik taleplerini iletebilir. Yazılım mühendisi bu isteklere her zaman cevap verebilir. Çevik süreç kullanmıyorsa, biraz zor tabi. İnşaat mühendisinin yeni müşteri isteklerine cevap vermesi hemen hemen imkansızdır, çünkü bu tür değişiklikler çok masraflıdır. Yazılım mühendisi oluşturduğu testleri kullanarak yazılım sistemini her zaman yeniden yapılandırabilir (refactoring). Yeniden yapılandırma, müşteri gereksinimlerine cevap verebilmek için kullandığı en güçlü silahıdır. Yazılım mühendisi Extreme Programming gibi bir çevik süreç kullanarak önünü her zaman açık tutabilir. Yazılım mühendisleri her zaman yoğrulabilir bir yazılım sistemi ortaya koyma fırsatına sahipken, inşaat mühendislerinin çalışmaları katılaşmış ve değiştirilmesi imkansız neticeler ortaya koyar. Aslında sonuncusu yazılım sektörü için de geçerli bir durumdur. Birçok yazılım mühendisi inşaat mühendisi gibi çalışıyor olmada da, onlar gibi katılaşmış ve yoğrulması imkansız neticeler (yazılım sistemleri) ortaya koymaktadırlar. Mental çalışma modelimiz inşaat mühendislerinin mental çalışma modellerinden çok farklı olmasına rağmen, neden onlardan farksız sonuçlara imza atamıyoruz? Yoksa bizde mi inşaat mühendisiyiz? Anneeee…. Bu arada tüm inşaat mühendisi arkadaşları buradan saygıyla selamlıyorum. Bu yazımda amacım kesinlikle onların çalışma tarzlarını tenkit etmek değildi. Onların çalışma metotları böyle. Başka türlü çalışmaları zaten bızım açımızdan sağlıklı olmazdı Bir yazılım mühendisi olduğum için çok mutluyum. Güç bende. İnşaat mühendisleri de mutlu mu acaba? Bir inşaat mühendisi arkadaş bu yazıyı okur ve yorum yaparsa sevinirim. EOF (End Of Fun) Özcan Acar

Battı Balık Yan Gider Posted: 14 Apr 2012 08:53 AM PDT Batan projeleri ben batan gemilere benzetiyorum. Batmaya meğil gösteren bir gemi nasıl bunu belli ediyorsa, batmaya meğilli bir yazılım projesi de parmak kaldırıp, dikkat ben batıyorum der. Bir projenin batacağı nasıl anlaşılır? Şöyle: Big design up front olarak isimlendirilen, kahin vari, bugünden yarının nasıl olacağını bilme kibiri ile tüm yazılım mimarisi ve tasarımının yazılım öncesi yapılması. Kutsallaşan bu tasarımı sorgulamak ve değiştirmek imkansızdır. Yazılımın ana kurallarından birisi: değişmeyen değişikliğin kendisidir. Madem bunu biliyoruz, neden proje başlamadan herşeyi ön görmeye çalışıp, acayip acayip tasarımlar yapıyoruz? Bu mimari ya da tasarımın müşteri gereksinimlerini bir zaman sonra taşımayacağı ortada değil midir? Müşterinin neye ihtiyacı olduğunu nasıl tahmin edebiliriz? Kendisi bile bunu bilemez. Piyasa koşulları bugünden yarına öyle bir değişir ki, proje müşteri için anında tüm anlamanı yitirebilir. Projelere pragmatik bir tasarım ile başlanmalıdır. Gerekli olduğu zamanlarda bu tasarım revide edilerek, güncelleştirilir. Birim, entegrasyon, regresyon, fonksiyon ya da onay/kabul testlerinin olmaması. Sıfır birim test kodunun olduğu projeler bilirim. Birim testleri olmayan bir projeyi yeniden yapılandırmak (refactoring) imkansızdır. Ya bazı kafalar bunu bilmiyor ya da umursamıyorlar. Test konseptlerini bilmeyen programcılar olabilir. Bu bir ayıp değil. Hemen oturup öğrenmeliler. Ama asıl problem ayağı yere basmayan zaman tahminleri ile proje planlaması yapan proje yöneticileridir. Baktılar proje yetişmeyecek, askerlerine emir vererek, testlerin yapılmamasını sağlarlar, çünkü test yazmak zaman kaybıdır onlar için. Böyle yapmaya devam edin! Programcıların DRY ve KISS prensiplerine sadık olmamaları. Bu kodun bakımını, değiştirilmesini ve geliştirilmesini zora sokan bir durumdur. Bir noktadan sonra (point of no return) kod tabanı o kadar katılaşır ki, yeni müşteri gereksinimleri için yoğrulamaz hale gelir. Çöpe at, yeniden yap! Sürekli entegrasyon yapılmaması. Bakımın ve geliştirmenin kolay olabilmesi için yazılım sistemlerinin modüler olması gereklidir. Modüler bir yapı entegrasyon işlemlerini gerekli kılar. Altı ayda bir entegre edilen modüler bir sistemin adam akıllı entegre edilemeyeceği ortadadır, çünkü entegrasyonun doğası sorunludur. Bu sorunu aşmak için altı ayda bir değil, yazılım sistemi her gün entegre edilmelidir. Bunun için Jenkins ya da Cruise Control gibi entegrasyon serverleri kullanılabilir. Ya sürekli entegre et, ya da bu diyarı terk et! Projelerde maliyeti düşürmek için tecrübesiz programcıların çalıştırılması. Üniversite mezunu bir gençten bir usta kıvamında kod yazması beklenemez. Usta programcılar ağaçta yetişmiyor. Zaman içinde yeni üniversite mezunu yazılımcı gençlerde tecrübe kazanıp, ustalaşacaklardır. Lakin bir projeye çok sayıda genç yazılımcı dahil edip, projenin zamanında tamamlanmasını beklemek utopiktir. Eğer projede hiç usta programcı yoksa, iş daha da kötü olacaktır. Eğer projede usta programcılar varsa, bunlar zamanlarının büyük bir kısmını gençleri eğitmek için harcayacaklardır. Bir projede genç yazılımcı olmasın demiyorum. Ama mutlaka iş bitirici usta programcılar olmalı ve bu programcıların kendi işlerine odaklanmaları saglanmalıdır. Mimari kararların firma bünyesindeki merkezi bir noktada alınması. Çoğu büyük firmada kendilerini mimar grubu olarak tasvir eden bir yapıya rastlamak mümkündür. Firmada yazılım alanında olup biten herşeye burunlarını sokma alışkanlığı vardır bu grubun. Herşeyden haberdar olmak isterler, aldıkları tüm mimari kararların uygulandığını titizlikle takip ederler. Oysaki merkezden birileri ne yaptığımıza bir göz atacak diye zaman kaybetmek anlamsızdır. Böyle kararların merkezi bir yerden, sahada ne olup bittiğini bilmeden alınması proje gidişatını zora sokabililr. Elini kirleten proje ekibindeki programcılardır. Projeyi ilgilendiren tasarım kararlarını onlar almalı ve uygulamalıdırlar. Merkez mimar grubu yine genel gidişatı yönlendirici kararlar alsın, ona birşey demiyoruz, ama lokal projelere karışmasınlar, karışmak istiyorlarsa sahaya inip, ellerini kirletsinler. Bakalım o kararları yine öyle rahatlıkla alabilecekler mi! Listemize müşterinin ne istediğini anlamamak, yanlış teknolojik araçların seçimi, yazılım ekibinin yeteneklerine güvenmemek, iteratif bir çevik süreci kullanmamak gibi daha birçok neden ekleyebiliriz. Yazılım genç bir sektör değil. Genç bir sektörde çalışıyoruz argümanının arkasına saklanarak, batan projelerin sorumluluğundan kendimizi kurtarmaya çalışmamız doğru değil. 1950, belki de daha öncesinden beri insanlar programlar yazıyor. Donanımcılara bir baksanıza. Almışlar başlarını, gidiyorlar. Bilmem kaç çekirdekli işlemciler yapıyorlar. Biz yazılımcıların onları takip etmesi bile hayal oldu. Donanımda muazzam gelişmeler olurken, biz yazılımcılar olduğumuz yerde sayıyoruz. Yazdığımız programlar birden fazla çekirdek üzerinde koşmakta zorlanıyor. Daha bu işe bile hakim değiliz. Lakin bunların hepsi yazılımdan anlamıyoruz anlamina da gelmez. Yazılım mühendisi olarak bilmemiz ve uygulamamız gereken prensip ve pratikler var. Bunlar: Extreme Programming gibi bir çevik sürecin adapte edilmesi Test Güdümlü Yazılım Sürekli Entegrasyon Yeniden Yapılandırma Tasarım Prensipleri Yazılım Testleri Tasarım Şablonları Projelerin batmasında biz yazılımcılar da rol oynuyoruz. Kendimizi geliştirip, yazılım pratik ve prensiplerine daha çok hakım olmamız gerekiyor. Bu konulara işimize olan saygımızdan dolayı daha fazla odaklanmalıyız. Bu konulara hakim olan üstatların peşlerini bırakmamalıyız. Onlardan öğrenebildiğimiz herşeyi öğrenip, işimizi daha kaliteli yapmaya çaba sarf etmeliyiz. Ama tek suçlu biz değiliz. Proje yöneticileri herşeyi doğru yapıyor denemez. Firma bünyesinde verilen yanlış politik kararlar, yöneticilerin programcıları insan olarak değil de, kaynak olarak görme eğilimleri, ayakları yere basmayan proje planlaları, maliyeti düşürme güdümlü işçi alımları, genel olarak kötü yönetim, projelerin başarısızlıkla sonuçlanması çabuklaştırmaktadır. Biz programcılar işimizi doğru yaparsak en azından projeyi siz batırdınız diye bize yüklenemezler EOF (End Of Fun) Özcan Acar

You are subscribed to email updates from Kurumsal Java Yazılımı - Özcan Acar To stop receiving these emails, you may unsubscribe now.	Email delivery powered by Google
Google Inc., 20 West Kinzie, Chicago IL USA 60610

[Kurumsal Java Yazılımı - Özcan Acar]

Kurumsal Java Yazılımı

---

Eşli Programlama, Code Review, Code Retreat ve Adada Yaşayan Programcılar Posted: 15 Apr 2012 12:54 PM PDT Bir programcıyı alıp bir adaya koysanız, diğer insan ve progcılarla bağlantı kurmasını engelleseniz, kendi başına çalışmasını ve kendisini geliştirmesini isteseniz, bu programcı programcılık konusunda nasıl bir gelişme sağlardı? Eğer programcıya o imkanı sağladıysanız ve kitap okuma alışkanlığı varsa bol bol kitap okuyacaktır. Kitap okumaktan canı sıkıldığında kod yazacaktır. Kod yazmaktan canı sıkıldığında tekrar kitap okuyacaktır. Belki de hiçbir şey yapmayacaktır. Adada olduğunu hatırlayıp yüzmeye gidecektir. Gününü gün etmeye çalışacaktır. Bu durum programcıdan programcıya değişecektir. Bu şartlar altında programcının kendisini geliştirebileceğini pek düşünmüyorum. Gelişim için insanlar arası interaksiyon ve iletişim gereklidir. Çoğu zaman başka insanların davranış biçimlerini kopyalayarak gelişim sağlamak bile mümkündür. Sıfır-altı yaş gurubu çocuklarda bunu görmek mümkün; zamanlarının büyük bir kısmını ebeveynlerinin davranışlarını incelemek ve kopyalamakla geçer. Kendi kızımdan bir örnek vereyim. Şimdi iki yaşında. Evin içinde saklanbaç oynuyoruz. O saklandıktan sonra “baba ben oturma odasında, perdenin arasındayım” gibi anonslar yapıyor. Gidip, elimle koymuş gibi buluyorum. Kısa bir zaman önce oyunu tersine çevirip, ben saklanmaya başladım ve kızımın beni bulmasını istedim. Ben doğal olarak saklandığım yeri anons etmiyorum. Bu şartlarda kızımın evin içinde beni bulması zorlaşıyor. Ufaklık olayı çakmış, şimdilerde saklandığında “kızım nerdesin” diye sormama rağmen, gıkı çıkmıyor. Benden öğrendi ve olayı çaktı. Şimdi bu yazıyı yazarken mouse-pad’imi kaçırdı. Bir saniye gidip, alıp, geleyim…. {5 dakika sonra} -Mouse-pad kayıp, bulamıyorum. Nerede kızım diye soruyorum; oturma odasındaki masada, git ara diyor… Gerçek hayatta da bazı programcılar bir adada yaşıyor gibi kod yazarlar. Diğer programcılarla bilgi alışverişinde bulunmadan ve kodu paylaşmak zorunda kalmadan işlerini görürler. Projeyi zamanında yetiştirme telaşı bu tip programcıların işine gelir. Hatta kodu sahiplenirler. Kimse ne yazdığımı anlamasın diye komplike kod yazan programcılar gördüm. Bunun maksadı Job Protection yapmaktır, yani çalıştığı iş yerini korumak ve başkalarına kaptırmamaktır. Ama bu yazımın konusu bu değil. Bu yazımda programcının kendisini geliştirmesi için neden diğer programcılarla interaksiyona girmesi gerekği konusunu incelemek istiyorum. Adada yaşayan programcılar için söylüyorum: kendi kendilerine kendilerini geliştirmeleri biraz zor gibi görünüyor. Gelişim için insanlar arası interaksiyonun gerekliliğinden bahsettim. Bu özellikle programcılar için geçerli olan bir durumdur. İnsanlar adeta bir araya gelip beraberce çözüm üretmek için yaratılmıştır. Programcılar da kendi aralarındaki iletişimi ve beraber çalışmayı güçlendirerek, birbirlerinden çok şeyler ögrenebilirler. Eğer konumuz programcıların gelişimi ise o zaman bunun sağlandığı en önemli yerlerden birisi programcılar arası interaksiyondur. Bunun örneklerini eşli programlama (pair programming), beraber kod inceleme (code review) ve beraber pratik yapma (code retreat) aktiviteleri teşkil eder. Bu aktiviteleri ve programcıya kattığı artı değeri yakından inceleyelim. Eşli Programlama (Pair Programming) Eşli programlama Extreme Programming (XP) çevik süreci ile popüer olmuş bir programlama aktivitesidir. İki programcı bir araya gelerek, bir müşteri gereksinimini test güdümlü kodlarlar. Eşli programlama oturumunda programcılar sıkça klayveyi kendi aralarında değişirler. Bu hem fikir alışverişini, hem programcıların birbirlerinden öğrenmelerini, hem de ekipte her programcının proje hakkında aynı bilgiye sahip olmasını teşvik eder. Eşli programlama oturumlarda benim en büyük kazancım, partnerimden onun kullandığı yazılım tekniklerini öğrenerek kendi günlük işlerimde adapte etmem olmuştur. Bu şekilde çok şey öğrendigimi itiraf etmem lazım. Bu yüzden eşli programlama çok severek dahil olduğum bir aktivitedir. Eşli programlama yapan programcılar birbirlerinden farkında olmadan çok şey öğrenmektedirler. Bu programcının şimdiye kadar tanımadığı bir kısa yol tuşundan, değişik tasarım prenbiplerinin nasıl uygulandığına kadar geniş bir yelpazeyi kapsamaktadır. Eşli programlama pratiği ekibe yeni katılmış ya da tecrübesiz programcıların hızlıca bilgilendirilip, takıma entegre edilme süreçlerini kısaltacaktır. Bu amaca doğru yola çıkılmak istendiğinde tecrübeli bir programcı ile tecrübesiz bir programcı bir araya getirilip, eşli programlama oturumunda bilginin serbestçe akışı sağlanabilir. Eşli programlama sadece bu durumda kullanılır diye bir kural yoktur. Mümkün mertebe her fırsatta uygulanması gereken bir aktivitedir. Eşli programlama metodu, iki programcının aynı işi yaptığı düşünüldüğü için zaman kaybı olarak algılanabilir. İlk etapta bu böyle olsa bile, bu yönde yapılmış olan yatırım projenin başarısına katkıda bulunacaktır. Eşli programlama oturumlarında iki çift göz kodu geliştirdiği için hata oranı daha düşük olacaktır. Bilgi ekip içinde eşit olarak dağıldığından, bir programcının projeden ayrılması proje gidişatını olumsuz yönde etkilemeyecektir. Kod İnceleme (Code Review) Eşli programlama oturumunda olduğu gibi birden fazla programcı bir araya gelerek bir kod parçasını beraberce incelerler (code review). Genelde bir müşteri gereksinimini kodlamış olan bir programcı çalışmasını tamamladığında, diğer bir çalışma arkadaşını beraberce kod incelemek üzere kendi çalışma masasına davet eder. Dört göz iki gözden daha fazla görür prensibinden yola çıkarak iki programcı kod parçasını beraberce incelerler. Geçenlerde yaptığımız bir toplantıda beraber kod inceleme konusunda konuşurken, bir çalışma arkadaşım bu tür aktivitelerden hoşlanmadığını, çünkü parmağıyla bir kod satırını gösterip, burası olmamış demenin, kodu yazan tarafından yanlış algılanabileceğini söyledi. Doğru, bu çogu zaman olan birşey, ama birbirimizden birşeyler ögrenmek istiyorsak, o zaman egomuzu artık bir kenara koymamız gerekiyor. Herşeyi bilmemiz, doğru çalışan kod yazmamız her zaman mümkün değil. Bunu böyle kabul etmemiz gerekiyor. Bir çalışma arkadaşımızın kod inceleme oturumunda yanlışlarımızı yüzümüze vurmasını hakaret olarak değil, bir şans olarak algılamalıyız. Bu gibi durumlarda kendisine hakaret edildiğini düşünen programcı adada yaşayan bir programcıdır. Kendimizi geliştirmek istiyorsak kritiğe açık olmamız gerekiyor. Beraber Pratik Yapma (Code Retreat) Code retreat Corey Haines tarafından başlatılmış, bir tam gün boyunca 15-25 arası programcının bir araya gelerek, beraber kod yazdıkları bir aktivitedir. Böyle bir çalışmaya katılmış olan Ryan Weald bir günde ögrendiklerinin okulda bir sene öğrendiklerinden daha fazla olduğunu söylemekte. Bu tür aktivitelerin programcılar için ne kadar önemli olduğu ortadadır. Diğer programcılarla interaksiyona girmeyen bir programcı, kendisini daha hızlı geliştirmek için sağlanan avantajlardan mahrum kalacaktır. Buradan çıkardığımız sonuç şudur: Job protection yapanlar aslında bindikleri dalı keseler. Oysaki bilgi paylaşımına açık olan programcılar diğer programcılarla olan ilişkilerinde devamlı yeni birşeyler öğrenerek, kendi piyasa değerlerine değer katarlar. Adada yaşayan programcılara allah kolaylik versin. İşleri kolay değil.

EOF (End Of Fun) Özcan Acar