Search Results for: java

Başarı Üzerine: Dinleme ve Anlama

Kültür, Bilgi ve Düşünce

Şu anda lise 3 öğrencisi olan kızım, sahip olduğu sosyal sorumluluk bilinci vesilesiyle, haftasonları TEGV‘de (Türk Eğitim Gönüllüleri Vakfı) ilkokul çocuklarına eğitimler veriyor. Geçenlerde yine böyle bir eğitim gününde gittiği TEGV şubesinde, eğitim saatini ve öğrencilerini beklerken, Ekonomi dersi sınavına hazırlanmak amacıyla yanında taşıdığı ders kitabını okuyormuş. Benzer şekilde yine eğitim gönüllüsü olarak orada bulunan, üniversitede Ekonomi bölümü öğrencisi gençler de, kızımın, kendilerinin üniversitede gördüğü konuları çalıştığını farkedince arada bir sohbet başlamış. Kızımın ifadesine göre konu çok hızlı bir şekilde “başasının sırrı nedir”e gelmiş 🙂 Etrafta çocuklarını şubeye getiren veliler de varmış ve kızımla gençler arasındaki sohbet genişleyince, çocuklarının geleceği hakkında endişeli her ebeveyn gibi onlar da “sen nasıl böyle başarılısın” anlamında sorularla sohbete dahil olmuşlar.

Bu günlüğü takip edenler, benim başarıyla neyi kastettiğimi kabaca bilirler. Başarı anlayışımın en temelinde, ciddi ve sağlam bir bilgilenme yatar. Bilginin üzerine bina edilen tecrübe ve tefekkür, kişiyi fikir sahibi yapar. O yüzden bilgi sahibi olmadan fikir sahibi olduğunu düşünenlerden daima uzak dururum. Kızım da öyledir, çok yetenekli ve yaratıcıdır ama her şeyden önce doğru ve sağlıklı bilgilenmeye önem verir. Bana anlattığına göre bu olayda da “nasıl oldu bilmiyorum ama birden etrafım, ‘hayatın sırrı nedir üstad’ diye bakan anne-babalarla doldu” dedi bana 🙂 Peki, “senin başarının sırrı” konusundaki soruya sen ne cevap verdin diye sordum tabi ki. Böyle bir soruya herkes kendi tecrübesi açısından mümkün olan zilyon tane cevaptan birisini verebilir. Kimisi “annem” der mesela, kendi sahsi tecrübesi açısından çok farklı bir yerdedir annesi. Kimisi “ilköğretim 4. sınıf öğretmenim” der. Kimisi de kişinin sahip olduğu ve doğuştan tevarüs ettiği özelliklerinde arar başarıyı. Dolayısıyla bu soruya “zekam” diye cevap verir bazıları. Bütün bunlar böyle bir soruya cevap olarak verilebilir. Fakat bu sorunun cevabını, doğuştan gelmeyip, kişinin ve yakın çevresinin gayretiyle, o kişide zamanla gelişmiş bulunan davranışlar açısından ele alırsak, cevaplarımızı bayağı bir sınırlandırmış oluruz. Örneğin “çalışmak”, “kendine güven” ya da daha da özelde “çok soru çözmek” gibi davranışsal cevapları kastediyorum yani. Bu cinsten yani davranışsal cevapların, başarıyı açıklamada çok daha geçerli olduğunu düşünüyorum. Neyse, kızımın verdiği cevap ne biliyor musunuz? “Dersi derste öğrenmek”. Bu cevap sizleri etkilememiş ve hatta size göre şaşırtıcı derecede basit kalmış olabilir. Ben şaşırmadım kızımın bu cevabına ama. Çünkü hem bu ülkede hem yurt dışında eğitim almış, ister okul öncesi ve ilk seviye eğitim isterse üniversite eğitimi olsun, hem bu ülkede hem yurt dışında eğitim alan çocuklara sahip ve ötesinde eğitimin teorisi ve pratiği üzerine kendince kafa patlatan birisi olarak kızımın bu cevabı üzerine eskiden bu yana düşünür ve gözlemlerde bulunurdum zaten. Dahası onlarla ilişkilerimde “dersi derste öğrenmeyi” devamlı teşvik ederdim. Dolayısıyla bu cevap beni hiç şaşırtmadığı gibi sevindirdi de. Dahası, kızımın bunu farketmiş olması mükemmeldi.

Uzatmadan şunu söyleyeyim: İster ilköğretimde bir çocuk, ister lise çağında bir genç, ister üniversitede bir öğrenci, isterse, işe aldığım ve çalışma fırsatı bulduğum, iş görüşmesi yaptığım, eğitim ya da danışmanlık vesileleriyle karşılaşıp çalışma imkanı bulduğum kişiler olsun, onlarla ilgili yaptığım gözlemlerde elde ettiğim sonuçlardan birisi de şu: Başarılı insanların ezici çoğunluğu, dinlemeye ve anlamaya önem veren kişiler. Önemden öte, dinlemeyi ve anlamayı, her hareketiyle hayatının merkezinde tutan kişiler. Ders açısından ifade edilirse, başarılılar, çoğunlukla dersi derste anlayan kişiler. Yani, derse önem veren, derste anlatılanları anında anlamaya özen gösteren, anlatılanlara iyi odaklanan dolayısıyla da iyi bir dinleyici olan, hatta sonrasında güzel sorularla olan biteni çözümleyici bir anlayışla zihnine yerleştiren insanlar. Dahası, iyi sorularla, öğretmene bile o ana kadar farketmediği şeyleri farkettiren öğrenciler, iyi öğrenciler. İstediği kadar çalışkan olsun, dersi derste anlamayan, hatta derse devam etmeyip sonradan çalışarak arayı kapatan insanlardan başarılı insan çıkması çok zor. Biliyorum, hemen Steve Jobs gibi kişilerden örnek vererek bu söylediklerime karşı çıkanlar olacaktır. Ama şunu unutmayalım ki başarının, ezici çoğunluğu bizim elimizde olmayan pek çok etkeni var. Ayrıca ben başarıyla, ünlü olmayı ya da tonla para kazanmayı kastetmiyorum. Dolayısıyla bu yazıyı okuyan ya da bu günlüğü takip eden birisi, benim Steve Job’s yerine örneğin Dennis Ritchie‘yi başarılı olana örnek göstereceğimi de tahmin edebilir.

Zeka, kendine güven, çalışma vs., hepsi başarıda bir yere sahip, eyvallah, ama normal zekalı bir çocuğun bence en temelde sahip olması gereken yetkinliklerden birisi “dersi derste anlamak”tır. Ve bu davranış bence örneğin “çok çalışmak”tan çok daha önemlidir. Ebeveynler, çocuklarına çalışma alışkanlığı kazandırmadan önce onlara, dinleyip anlamasını öğretmeliler. Okul çağına geldiğinde ise çocuğun, dersi derste anlaması teşvik edilmeli. Dersi derste anlamayan ama çok çalışan bir çocuk, dersi derste anlayan ve bunun üzerine az bir çalışma ekleyen bir çocuk kadar başarılı olamayacaktır.

Böyle bir günlükte böyle bir konuyu neden yazıyorum biliyor musunuz? Eğitim vesilesiyle ben de çok sık olarak ders veriyorum, derste öğreten öğretmen/hoca konumunda bulunuyorum ve sınıfta dikkatimi en çok çeken şey, katılımcıların yani öğrencilerin dersi derste öğrenme konusunda genel olarak sahip olduklarını gözlemlediğim zaafiyetleridir. Eğitim vermek, özellikle yetişkin eğitiminde ya da bir başka deyişle mesleki eğitimde hocalık yapmak kolay birşey değil, kendine göre zorlukları var. Yetişkin eğitiminin, bazen sizden bile yaşlı ama her zaman 20 yaşından büyük, ezici çoğunlukla bir üniversite bitirmiş olan katılımcılarının size saygı duymalarını sağlamak, gerektiğinde “bilmiyorum” diyebilmek vb., ilköğretim ya da lise öğretiminde pek de problem olmayan, tonla zorluğu var. Eğitmenin yarı Cem Yılmaz olması gerekir meslea eğitimde. İnsanların, yetişkin de olsalar dikkatlarinin devamını sağlamak, esprilerle dersi eğlenceli hale getirmek, en az derste anlatılan konuyu, teorisi ve pratiğiyle, ilgi çekici kılmak kadar önemli. Eğitimler sayesinde ben de yarı ya da hadi o kadar iddialı olmayayım, kendi çapımda ufak bir Cem Yılmaz oldum çıktım. Artık eskidi ama geçen yazki esprilerimden birisi, şike soruşturması sürecinden dolayı özellikle, benim Fenerli olup ve hayatımda ilk defa kombine almış olmamdı. Tonla espri çıktı buradan ve çok eğlenceli oldu. Malum, kişinin kendisini tiye alan sözler genelde en etkileyici ve hoş esprilerdendir.

Neyse, konuyu uzatmayalım, bütün bunlara rağmen, eğitimlerde, sınıftaki katılımcıların beni takip etmelerini sağlamakta çok zorlanıyorum. Basit bir ayarı ya da bir şeyi yapış şeklini, örneğin, Eclispe’deki bir projede, paketlerin hiyerarşik olarak görünmesini sağlama gibisinden sadece ve sadece 3 adımlık bir ufak detayı bile 5 günlük bir eğitimde 10 defa söylediğim oluyor. Zaten sınıfta 10 kişi ya var ya yok, düşünün gerisini.

Bazı eğitmen arkadaşların, katılımcıların saygısızlıklarından bahsettiği çok sık oluyor. Ben çok az böyle bir durum yaşadım. Sanırım yaşım, eğitimin ilk 15-20 dakikasında katılımcılara verdiğim izlenim, kendimle ilgili her türlü tiye almayı sınıfta bizzat kendimin başlatması ve çok rahat olarak “bilmiyorum” diyebilmem gibi faktörler, sınıfta bana karşı doğrudan saygısızlık yapılmasının yolunu en baştan kapatıyor, bunun farkındayım. Fakat, önüne geçmekte zorlandığım şey, katılımcıların dersi takip edip, derste olabildiğince başka şeylerle uğraşmadan, sadece benim anlattıklarıma odaklanmalarını sağlamak. Bu anlamda çok sık gördüğüm, dersi takip etmeme sebepleri ve yine çok sık karşılaştığım sonuçları şunlar:

  1. Zaten bildiğini düşünmek ve belki bundan dolayı ileriki konuları karıştırmak ve bunlarla ilgili soru sormak ya da kendi makinasında bunları denemek. Sonra da benim daha önce 9 defa gösterdiğim Eclipse ayarının nasıl olduğunu sormak. Dolayısıyla çok büyük bir ihtimalle, katılımcı bildiğini sanıyor ama en azından benim anladığım ve anlattığım şekliyle bilmiyor. Bu anlamda benim eğitimlerimin, pek çok aynı isimdeki eğitimden farklı olduğunu katılanlar bilirler.
  2. Teorik açıklamalardan sıkılıp hızlıca pratiğe dalmak istemek de çok sık karşılaştığım sebeplerden. Malum aksiyon sever bir milletiz ve teoriden hoşlanmayız. Her şeyi, tonla acı çekecek olsak bile, deneye yanıla öğrenmeyi tercih eden mazoşist bir yapımız var. İki dakika sonra pratik yaparken akla gelecek tonla “neden böyle”nin cevabını, sistematik olarak en baştan kavramsal bir yapıda açıklamak aslında çok daha sağlıklı bir durum ama SBS, ÖSS gibi sınavlar için soru çözerek büyümüş olan bizlerin, “nasıl”lıktan önce “neden”liğe önem vermemizi beklemek her zaman adil değil, bunun da farkındayım. O yüzden eğitimlerde çok sık, felsefi argümanlarla teori-pratik arasındaki ilişkiden bahsetmek zorunda hissediyorum kendimi.
  3. Soru sormamak en yaygın olanı belki de. Aklına takılanı bana sorarak, benim onu, bütün sınıf için halletmeme imkan sağlayacakken, arkadaşına fısır fısır sorup, onu kendi ekranına bakmaya davet edip, o sırada benim anlatıp yaptıklarımı kaçırmak, dahası sınıfta kendi başına iş yapar bir görüntü vermek ve gürültü yapmak. O kadar da, “ne kadar saçma olursa olsun sorun” gibi ciddi teşvikler ya da “yarın obür gün yöneticinizin karşısında rezil olacağınıza, buradan çıkıp gittikten sonra sizi hatırlamayacak ve sizi asla ve asla yargılamayacak olan benim karşımda rezil olun” gibi esprili uyarılarla soru sormayı teşvik etsem ya da çok sıklıkla sınıfa “neden”likle ilgili işin felsefi arka planına ait sorular sorsam da, çok kişinin soru sormama/soramama adetini yıkamıyorum. Kolay değil, taa ilkokuldan bu yana “soru sormamanın faziletiyle yetişmiş” ya da “saçma soru korkusuyla büyümüş” yetişkinleri üç beş günde soru sorar hale getirmek. Dolayısıyla ciddi bir soru sorma korkumuz var.

Sanırım, derse devam etmeden, sonrasında, geçmiş senelerde sorulmuş sorulardan yola çıkarak, hızlıca ders geçmek şeklinde açıklanabilecek olan kötü bir adetimiz de bizi ders ortamından soğutuyor. Ben de İTÜ’de okurken 2-3 sene böyle takılmıştım nedenini bilmeden. Şimdilerde de gençlerle karşılaştığımda, çok zeki ve kapasiteli olanların bile, malesef, hocayı ya da dersi beğenmeyerek, ya da alışkanlıktan dolayı, böyle bir tutumda bulunduklarını gözlemliyorum. Ezberci, hantal, aşırı bilgi yükleyen eğitim sistemimiz olduğunun çok fena halde farkındayım ama malesef, iki yanlış bir doğru etmiyor. Bu sanırım biraz da bizim sahip olduğumuz, SBS, ÖSS vb. “problem çözme” kültürümüzün bir devamı. Öyle ya lise sonun ikinci döneminde pratik olarak hiç ders yapılmıyor, herkes paso dershaneye gidip soru çözüyor, akıllı atış/tahmin stratejisi öğreniyor. Diyecek hiç bir şey yok.

Bütün bunlar nihayetinde, daha ilk öğretime bile başlamadan anne ve babanın çocuğuna öğretmesi gereken ve bu hayatın en temel uğraşılarından birisi olan “anlama” konusundaki problemlerimizden kaynaklanıyor. Ve böyle bir problemle yetişmiş bireyin davranışını, değil 25 -30 yaşında, 15 yaşı bile düzeltmek zor ya da imkansız.

Eğitime zorla gönderilmiş olmanın ya da ne bileyim, Pazar günü, dışarıdaki bahar ya da yaz havasına rağmen eğitimde olmak gibi, benim yapabileceğim bir şey olmayan konulardan kaynaklanan ilgisizlik ve dersi bırakmışlıklardan bahsetmiyorum bile. Onlar bu kategoride ele alınan problemler değil.

Dersi iyi takip eden, aklına takılan birşey olduğunda yanındaki arkadaşına değil de bana soran, doğru ya da yanlış olsun çıkarımlarını tüm sınıfla paylaşan kişilerle ders yapmak kadar eğlenceli ve hoca olarak beni de eğiten bir durum az olur. Böyle eğitimlerde inanın en az öğrenciler kadar ben de öğreniyorum ya, mükemmel.

Anlamak ve anlama uğraşısı, her şeyi çok değerli kılıyor.

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

Programlama Nedir: Programlamanın Tabiatı ve Programcılık Üzerine – I

Bilgisayar Bilimleri, Programlama, Yazılım Mühendisliği ,

Hayatta en sevdiğim şeylerden birisi programlama yapmak. Ne zaman bir vesile ile böyle bir imkan bulsam, kendimi makinanın başında sabahlamış buluyorum. Başka hiçbir şey, bu günlükte yazı yazmak dahil, beni makina başında sabahlatmıyor. Bu duruma, 90’lı yılların başından bu yana alışkınım aslında. Benim gibi programcı olan kişilerin en temel tutkusu, programlama. Dolayısıyla programlamanın ve programcılığın en temel özelliği “tutku”. Acaip tutkulu insanlar programcılar, manyaklık derecesinde bir durum bu.

Neden acaba programcılar böylesine tutkulular? (Öyle ya bir kurumda, en anlaşılmaz, diğer çalışanlar, özellikle de İnsan Kaynakları tarafından en uç noktada görülen insanlardır genelde programcılar.) Sanırım yaptığımız iş, zihni melekelerimizi sonuna kadar kullanmamızı sağladığı için. Zaten, zihni açıdan böyle ağır bir iş, tutku olmadan, başka türlü yapılamaz. Zihni melekelerimizi sonuna kadar kullanmamızı sağlayan şey ise bence, programcının, programlama esnasında kendisiyle uğraştığı faktörlerin sayısının yüksek oluşudur. Faktör sayısının yüksekliği, faktörlerin durumlarının sayısı ve aralarındaki ilişkilerin karmaşıklığı, faktörlerin aralarındaki ilişkilerin sayısı ve karmaşıklığı, yapılan işin ne kadar karmaşık olduğunun en temel belirleyicisidir. Bunu şöyle ifade edebiliriz: Genel olarak bir programcının, üzerinde çalıştığı konunun, yani süreç, iş kuralı, algoritma, arayüz, iletişim protokolü, vs. her ne ise, faktör sayısı, yani değişken olsun sabite olsun, konunun matematiksel modelinde var olan soyutlamaların sayısı ile bu soyutlamaların aralarındaki ilişkilerin sayısı ve karmaşıklığı, normal bir insanın günlük hayatının herhangi bir kesitinde baş edebileceğinden çok daha fazla sayıdadır.

Bir örnekle ne demek istediğimi anlatayım: Programcının yaptığı programlama işi, karmaşıklık açısından, açık kalp ameliyatı yapan bir doktorunkinden farklı değil. Açık kalp ameliyatı yapan doktor da, kan basıncı, kanama riski, beyin fonksiyonları vb. tonla faktörü aynı anda yöneterek, bir ameliyat gerçekleştirir. Muhtemelen, böyle bir operasyon sırasında göz önünde bulundurması gereken faktörlerin sayısı, bu faktörlerin durumlarının sayısı ve aralarındaki ilişkiler ile bizzat faktörlerin aralarındaki ilişkilerin sayısı, normal hayatın herhangi kesitinde karşılaşacağınızdan çok daha yukarıdadır ve açık kalp ameliyatında durumun bir de kritikliği söz konusudur. Ben kritiklik tarafını çıkarırsak, bir programcının yaptığı iş olan programlama ile bir kalp cerrahının yaptığı iş olan açık kalp ameliyatını, karmaşıklık açısından benzer buluyorum ve bu konuda değerli doktorlarımızın hoş görüsüne sığınıyorum :). Fakat kalp cerrahımızın bir kaç avantajı var: İlki, bir programcıdan çok daha fazla eğitim ve pratik tecrübe kazandıktan sonra böyle bir işe girişiyor. Bereket ki bu durum böyle, yoksa sanırım açık kalp ameliyatlarının başarı oranı, bizim yazılımlarımınız başarı oranına düşerdi 🙂 Bir programcı, kesinlikle ve kesinlikle, bir kalp cerrahının içinden geçtiği eğitim ve çıraklığa (kadavra üzerinde uygulamadan başlayarak tonla ameliyatı seyretme vb. iş başı eğitimi kastediyorum) sahip olmadan açık kalp ameliyatına girişen bir gariban bence. Dahası, kalp cerrahımız, operasyon sırasında pek çok yardımcıya sahip: Mesela hemşirelerden birinin görevleri arasında doktorumuzun alnından akan teri silmek bile var. Gördünüz mü hiç kıvranan, depresyona girmeğe ramak kalmış bir programcının, değil terini silmeyi, durumunu farkedip, anında onu o ortamdan uzaklaştırıp, ona yardımcı olan bir kişi, görevli, rol vs? 🙂 Ben yöneticilik yaptığım zamanlarda, bunu farkettiğimde kendisine terapi uyguladığım, ortamdan uzaklaştırıp, çay-yemek vesilesi ile gerilmiş psikolojisini rahatlatmaya çalıştığım çok programcı arkadaşım oldu. Üstüne üstlük, cerrahın, faktörlerini kontrol eden pek çok cihazı var ve özenle tasarlanıp geliştirilmiş bu cihazlar, faktörlerin durumlarını görsel olarak sunuyorlar ve herhangi bir ciddi durum değişmesinde ses vb. yollarla, doktoru ve etrafındaki “n” tane yardımcısını uyarıyorlar. Gördünüz mü hiç, programcı program yazarken, “yazdığınız program şu noktada performans problemi verir”, ya da yanıp sönen “deadlock riski”, “deadlock riski”, ya da ne bileyim “unscalable code”, “unscalable code” diye uyarıda bulunan cihazlar etraflarında? Çok komik değil mi? Ama kalp cerrahları işlerini yaparken böyle yardımları devamlı alıyorlar, onlarsız iş yapmıyorlar. Çok tipik durumdur, Java ile geliştirilip, bol ve umarsızca nesne oluşturulup sonrasında, canlı ortamda çok hızla, bellek (memory) problemleri yaşayan dolayısıyla ölçeklenemeyen (unscalable) yazılımlar. Tipik bir programcının, teknik olan 1000 kelimelik bir konuşmasının içinde geçen bir kavram değildir “ölçeklenirlik” ya da “scalability”, ama çok önemlidir. Neden durum böyledir? Ölçeklenirlik bir faktördür ama yeterli eğitim ve tecrübeye sahip olmayan bir programcı, bu faktörü fena halde ıskalar. Çünkü o, program yazarken, en görünen ve fonksiyonel doğruluk ve tamlık açısından en bariz faktörlere odaklanır da ondan. Zaten programcının zihni, bu faktörler ve karmaşıklıklarıyla iğdiş olurken, ölçeklenirlik gibi bir faktörü düşünmesi imkansızdır ve tam da bu yüzden aslında “yazılım geliştirme, bir programcıya bırakılmayacak kadar önemlidir”. Tam da bu yüzden bu faktörler, gerek mimari gerek ise fonksiyonel tasarım çalışmalarıyla öncesinde ele alınmalıdır ki programcıya, kaldıramayacağı kadar, iş düşmesin. Yani, bir açık kalp cerrahının, ameliyat öncesinde “n” tane farklı daldaki doktordan “konsültasyon” alması, “m” tane tahlil vs. yapmasına benzer bu durum. Bunları yapmadan girilen bir ameliyatta, cerrahın faktörleri kontrol etmesi ne kadar zor ya da imkansız ise gariban ve sefil 🙂 programcıdan beklenen şey de bu kadar zor hatta imkansızdır.

Yukarıda örnekle anlattığımı daha sistematik olarak ifade edersek, bu şekilde programlama yapmada iki problem var: İlki, konunun zaten matematiksel modelinin kurulmamış olmasının getirdiği bir zorluk. Normal şartlarda, iyi bir analiz ve tasarımdan geçmiş ve bundan sonra programcının önüne gelmiş programlama işlerinde programcı, konudaki açık ve seçik olarak belirlenmiş yani, soyutlanmış faktörler ve aralarındaki ilişkileri rahatça anlar ve bunları bir programlama diliyle en iyi şekilde ifade etmeye odaklanır. Bir programcının en temelde iş tanımı budur ve bundan ne az ne de fazla bir şey yapar. Fakat, düzgün bir analiz ve tasarımdan geçmemiş programlama işlerinde ki neredeyse her zaman durum budur, programcının, önceden başka zihinlerin üzerinde düşünüp, değişik soyutlamalarla, konu içindeki faktörleri ve aralarındaki ilişkileri ortaya çıkarmış olması gibi lüksü olmadığından, konunun faktörlerini ve aralarındaki ilişkileri de bizzat kendisinin soyutlaması gereklidir. Dolayısıyla karmaşıklık bir kat daha artar. Bütün bu soyutlamaları bir seferde kavramak için bence 200’lerin üzerinde bir IQ seviyesine sahip olmak gerektiğinden ve böyle bir IQ seviyesine sahip olan programcı bulmak zor olduğundan, bulsanız bile bir programcının kazancına razı olmayacağından vs. vs. :), ve programcıların faktörleri soyutlamak için, UML gibi formal olsun ya da bir beyaz kağıt ya da tahta üzerinde, formal olmayan herhangi bir notasyon kullanarak bile çalışmadıklarından, çünkü programcıların formal notasyonu, bizzat programlama dilinin kendisi olduğundan, yazıkları program-kod parçası, hem soyutlama aracı hem de bu soyutlamaların programlandığı, gerçekleştirildiği ortam haline gelir. Karışık oldu değil mi? Demek istediğim şu: Programlama dili ile program yazmak, hem konunun anlaşılması için gerekli bir eskiz ortamı hem de sanki eskizi yapılmış ve anlaşılmış konunun, bir yazılım olarak ifade edildiği ortam haline gelmesidir bu durum. Bu da çok berbat bir haldir: Neden berbat? Bir, böyle bir çalışma şekli, programcının zihnini acaip yorar. Programcının tutkusu olmazsa bunu şu dünyada “hiçbir Allah’ın kulu” yapmaz. İki, programlarımızı yaz boz tahtasına döndürür bu şekilde çalışma. Programlarda bırakın kaliteyi, bir iç bütülük, bir insicam kalmaz, ortaya çıkan programı “şiir gibi oldu be abi” şeklinde ifade etmek kesinlikle mümkün değildir. Böyle durumlarda programcı, sonradan geri bakıp bu kodla yüzyüze gelmek istemez, yaptığı bu işle kesinlikle övünmez, utanır ondan çünkü. Peki bu durum yazılım kullanıcılarına nasıl yansır? Elbette hata, kullanılamayan, çok sık problem çıkaran sistemler olarak yansır, eğer yukarıda anlattığım sürecin bir yerlerinde kaliteyi arttırıcı gözden geçirmeler, sıkı fonksiyonel ya da fonksiyonel olmayan testler yoksa.

Sıkı durun, yukarıdaki anlattıklarıma bir katman zorluk daha geliyor: Ya programcının zihninde kod yazarken yaptığı bu soyutlamalar çok sık bir şekilde, konunun yani işin sahibi olan kişi tarafından değiştiriliyorsa? Yani aslında yukarıda bahsettiğim, iş süreçi, kuralı vs.nin sahibi olan kişinin kafası henüz net değilse ve arada analiz ve tasarım katmanları da olmadığından, iş sahibi ile programcı devamlı karşı karşıya kalıp, konuşuyorlarsa? Bakın işte bu “hiçbir şekilde yapılacak iş” değildir. Böyle bir ortamda, normal şartlarda kimse çalışmak istemez. Benim sık sık, “insan yapmaz bunu” dediğim haldir bu. Bunu ülkemizdeki pek çok programcı yapar ama, neden biliyor musunuz? Bir, hoşuna gider, çünkü zorluk büyüdükçe ve kendisi başardıkça ya da en azından başardığını düşündükçe (problem de bu ya zaten, başardığını düşünmesi 🙂 ), egosu kabarır ve bu durumun çok fena farkındadır programcı. İki, programcının gücü artar, kendisine bağımlılık artar, her şeyi kontrol edebiliyor olmak müthiş bir şeydir çünkü. Üç, belki de en kötüsü, yazılım endüstrisi açısından, programcı, bu sıkıntılı durumun aslında nasıl olması gerektiğini bile bilmez, çünkü okulda ve sonrasında çalıştığı ortamlarda ona “yazılım=program” yanılsaması, gerçek olarak sunulmuştur çoğu zaman. (Komiktir, bir programlama diliyle doğru düzgün bir program bile yazamayacak durumda olan kişiler, kendilerini “Yazılım Mühendisi” olarak tanıtıyorlar mesela 🙂 Halbuki, bir derleyici (compiler) yazacak kadar yetkin bir programcı olmak bile o insanı “Yazılım Mühendisi” yapmaz, çünkü “yazılım” farklı bir şeydir. Farktan ne kastettiğimi anlamak için, “böyle bir derleyiciyi kullanmak ister misiniz” diye kendinize sorun ve neden “hayır” diye cevap verdiğiniz üzerine düşünün mesela.) Aslında durum, “programcısın, programcı kal”dır sadece 🙂 (Neyse, bu konu da bir yazı gerektirir, o yüzden dalmayalım oraya.)

Dolayısıyla, programcının karşılaştığı üç katmanlı zorluklar şunlardır: Soyutlamaların yapılması, soyutlamaların gerçeklenmesi ve bu gerçeklenmenin, soyutlamalardaki değişimi göz önüne alacak şekilde yapılması. Sabahtan akşama değil de değişen iş ihtiyaçlarına göre makul miktarda değişen iş süreçlerini ve muhtemel değişim noktalarını göz önüne alarak program yazmak, zaman verildiğinde bir programcıdan bekleyeceğiniz şeylerdendir. Ama gerek iş süreçlerindeki gerek ise ölçeklenirlik gibi yazılım mimarisindeki soyutlamaların gerek ise bu iki konudaki muhtemel değişim noktalarının belirlenmediği bir süreçte, programcıdan hem bunları hem de bunlar sonucunda ortaya çıkan yapının bir programlama diliyle gerçekleştirilmesini beklemek hayalciliktir, programcıya da eziyettir.

Bütün bunlardan sonra, bir programcının sahip olması gereken en temel karakter özelliklerini sıralayabiliriz:

  1. Yüksek soyutlama gücü. Yani çözümlemeci/analitik düşünebilme yetkinliği. Daha açık bir ifade ile, olguları sistematik bir şekilde bileşenlerine ayırabilme, bu bileşenlerin durumlarını ve aralarındaki ilişkileri ortaya çıkarabilme, bileşenler arasındaki bağımlılıkları ortaya çıkarabilme, bunları sistematik bir şekilde yapabilme ve aktarabilme  yetkinliğidir çözümlemeci olmak. Bu yetkinliklerin ciddi bir kısmı Allah vergisidir ama iyi bir Matematik, Fizik vb. eğitimle güçlendirilmiş olmalıdır.
  2. Odaklanma: Hiç bir zihin, ilk maddedeki noktada ne kadar yetkin olursa olsun, eğer odaklanma sorunu yaşıyorsa, içinde bulunduğu kişiyi iyi bir programcı yapamaz. Odaklanmadan bu kadar karmaşıklık yönetilemez.
  3. Sabır: Programcı, iğneyle kuyu kazar gibi iş yapar, aynı konuya bazen sil baştan yaklaşır bir kaç defa ve en son denemesinde başarır örneğin. Dolayısıyla azim ve sabır son derece önemlidir.
  4. Denemeci yaklaşım: Programcı, doğruyu bulana kadar çok dener, çok test yapar ve çoğu zaman ancak bir kaç denemeden sonra doğruyu bulur. Bir kere yapıp, oraya takılan kişiler, aynı olaya farklı açıdan bakamayanlar hiç bir zaman iyi bir programcı olamazlar. Bir noktaya takılıp ilerleyemeyenler zaten 1. maddeden de geçememişlerdir çoğu zaman.

Bunlar dışında, formal algortima, veri yapıları, programlama dili, gerekli araçlar vs.nin bilgisi de gereklidir ama ben bu yazıda daha çok karakter özelliklerine dikkat çekmek istedim.

“Abbas Güçlü” vari bir bitiriş yapalım, özetin özeti şudur: Ey programcılar ve programcı olmaya talip gençler: Bu yazıda anlatılanlar size çekici geliyorsa ancak, iyi bir programcı olabilirsiniz. Ey yazılım evleri, BT yöneticileri, programcılarınıza acıyın ve insan içine çıkacak yazılımlar geliştirmek istiyorsanız, yazılım geliştirme işinizi, “programcıların programlaması” olarak değil de bir süreç olarak ele alıp,  programcılarınızdan önce ve sonra konumlandırdığınız kişiler ve çalışmalarla, programcılarınızın işini kolaylaştırın, yazılımlarınızın kalitesini arttırın.

Ve siz de bugün bir programcı bulup ona sarılın 🙂

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

Yazılım Projelerinde İhtiyaç Analizi – I

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

Bir yazılım projesinin en kritik safhası hangisi diye sorsalar, bu yaşta hasta bir Javacı 🙂 olarak her zaman ve kesinlikle “analiz” derim. Çünkü, Brooks babanın da çok isabetli bir şekilde belirttiği gibi bir projenin en zor sorusu “neye ihtiyacımız var?”dır Yani “projemizin çıktısı olacak yazılım sisteminden ne bekliyoruz?”a cevap vermek en kritik ve en zor olandır. En kritik olandır çünkü bu sorunun cevabı, kendinden sonra gelecek her türlü yazılım geliştirme faaliyetinin içeriğini belirler. Dolayısıyla, bu soruya cevap verirken yapılacak bir hatanın, eskiklik ya da yanlışlığın örneğin, büyüyerek, ortaya çıkan yazılım sisteminde nasıl bir fonksiyonel probleme dönüşeceğini tahmin edebilirsiniz. Yazılım Mühendisliği kitapları, analiz safhasında yapılan hatanın aynı safhada düzeltilmesinin maliyetini bir birim alarak yaptıkları kıyaslamalarda, ortaya çıkan hatayı son sistemde düzletmenin maliyetinin yüzlerce kat olabileceğini vurgularlar. Bu soru aynı zamanda en zor olandır çünkü, geliştirilecek yazılım sisteminin bütün iş süreçlerini, iş kurallarını, entegre olacağı diğer sistemlerle olan iletişim detaylarını, bütün kullanıcı arayüzlerini ve diğer tüm standart, kısıntı vb. cinsten ihtiyaçlarını belirlemek çok zordur. Hatta en zordur çünkü, bir yazılım projesindeki bütün diğer faaliyetler, genel olarak üzerine bina edildiği ve önce gelen diğer çalışmalardan faydalanırlar ama işin analizinin ise çoğu zaman böyle bir lüksü yoktur. Eğer projeniniz, zaten var olan ama farklı sebeplerle yeniden yazmayı planladığınız, dolayısıyla da kullanımda olan bir yazılımın yeni versiyonu olacaksa ancak, durum çok daha farklı ve kolay olabilir. Çünkü sadece ve sadece zihinde olan bir ihtiyacı, yukarıda bahsettiğim farklı tipte ihtiyaçlar toplamı olarak ifade etmek aşırı zordur. Hatta Brooks, bunu ilk seferde yapmanın teorik olarak imkansız olduğunu söyler. Ona göre bu detayda bir betimleme, geliştirilen sistemin ancak ilkel de olsa bir versiyonunun çalışır halde görülmesinden sonra yapılabilir.

Analiz safhasının kritikliğini ve zorluğunu hallettikten sonra bir başka soruya geçelim. Yazılım projelerinde en fazla ihmal edilen, en fazla yok sayılan safha hangisidir sizce? Nereye gelmeye çalıştığımı farkettiniz değil mi? Bu sorunun cevabı ile yukarıdaki sorunun cevabı aynı malesef 🙁 Bu durum dünyada da böyle ama ülkemizde bence sanki biraz daha böyle. “Analizin ihmal” edilmesi üzerine biraz daha düşündüğümüzde, aslında bu ihmal kavramının açılması gerektiği aşikar hale gelir. Problem aslında şudur: Bir kurumun işleriyle ilgili olarak bir yazılım sistemine ihtiyacı vardır. Bu sistem ile işinin tamamını ya da bir kısmını daha hızlı ve etkin olarak yapabilecektir, en azından o kurum böyle düşünmektedir. Bu amaçla bir yazılım geliştirecek/geliştirtecek/satın alacaktır. Hangi çözümden yana giderse gitsin, ihtiyacının ne olduğunu çok ciddi bir detay ve kesinlikte belirlemek ve betimlemek zorundadır. Aksi taktirde hayal kırıklığı yaşaması çok büyük bir ihtimaldir. Yani o kurumun o an itibariyle yaptığı işler açısından, var olan iş süreçlerini, bu süreçlerdeki iş kurallarını, varsa form ve doküman gibi girdi ve çıktıları, kullanılan malzemeleri, iş sürecine dahil olan çalışan/insan rollerini ve özelliklerini, süreçlerin birbirleriyle ve diğer sistemlerle olan ilişkilerini vb. daha pek çok detayı, bir yazılım sistemi kullanmıyor olsa bile, iyi biliyor ve bu bilgiyi de formal bir şekilde örneğin bir dokümanda betimlemiş olmalıdır. Yani bir kurum, bütün işlerini tamamen klasik olarak elle, ya da en fazla Word ve Excell gibi yazılım araçlarını kullanarak işletiyor ve bir otomasyon sistemi kullanmıyor olsa bile durum budur. Bunu gerçekleştirdiğinde o kurum, “işini” biliyor ve bunu insandan bağımsız olarak detaylarıyla tarif edebiliyor demektir. Bu durumda o kurum kesinlikle daha etkin çalışır, çünkü en önemlisi kurumsal bir hafızayı çok daha sağlıklı olarak oluşturmuş olur. Bu şekilde, çalışanlarını uzmanlaştırarak, onları daha yanlışsız ve verimli bir çalışmaya sevkeder ki bu durum, çalışan motivasyonunu olumlu yönde etkiler. Böylece aynı pozisyona gelen farklı kişilerin farklı çalışma şekillerinin yarattığı iç ve dış, uyumsuzluk ve memnuniyetsizliklerin sebep olduğu verimsizlikleri ve kayıpları ortadan kaldırır. Bu şekilde oturmuş olan süreçlerin sürekli gözden geçirilmesi ve değişen şartlara uyarlanmasıyla, müthiş bir enerji ortaya çıkar. Dolayısıyla, sisteme yeni girenlerin de üretken hale gelmeleri çok hızlı olur, hatalar kemikleşmez, herkes tekerleği baştan keşfetmez.

Yukarıda bahsettiğim şekilde çalışan şirketler uzmanlaşırlar ve piyasada avantajlı duruma gelirler çünkü, öğrenmenin maliyeti en aza iner ve nihayetinde şirketlerin varlık sebebi olan, sahiplerine kar sağlamak çok daha yüksek oranlarda gerçekleşir. Çalışan seviyesinde yani micro seviyede böyle bir uzmanlaşmanın ve nihayetinde işleri, uzmanların elbirliği ile yaptığı bir akış, bir süreç olarak ele almanın, makro seviyede daha üretken, daha karlı ve verimli bir ortam oluşturduğu da açıktır. Bir şirketin çalışan başına düşen toplam üretim değerinin ya da karlılığının tamamen aynı şartlarda ve aynı sektördeki diğer bir şirketten yukarıda olmasının sebebi, karlı olan şirketin uzmanlaşmış olmasıdır. İster beğenelim ister beğenmeyelim, daha çok üretime ve dolayısıyla da tüketime odaklanmış bir dünyada, daha çok üretmenin en temel yolu, işini iyi bilmektir (ve Adam Smith tarafından kitabı “Wealth of Nations”da çok güzel bir şekilde açıklanmıştır). “İş”in, gittikçe fiziksel olmaktan çıkıp, daha zihni bir hale gelmesi ise “insan sermayesi” (human capital) kavramını daha da öne çıkarıyor tabi olarak.

Neyse, çok fazla dağıtmadan konuya dönersek, eğer bir kurum, yukarıda anlattığım şekilde kendi işini iyi bilmiyorsa, bu işi otomatize etmek amacıyla bir yazılıma sahip olması ne anlama gelir? Tabi ki bu yanlışı betonlaştırmak ya da yanlışı daha “pahalı” bir yanlış haline getirmek demektir. Zaten hantal, bürokratik, verimsiz, insana bağlı olan bir sistemin, daha da kemikleşmesi, pahalı ve değişemez hale gelmesinden başka birşey değildir bu durum. Benim gerek kamu gerek ise özel sektör kurumlarında gördüğüm pek çok “otomasyon” sistemi bu duruma örnektir. Bir devlet dairesinde bulunduğum üç-beş dakikada bile o kadar farkedilebilir bir durum ki bu, inananılmaz…

Peki şimdi bu durumu “yazılım ihtiyaçları” açısından ele alalım. Yani yukarıdaki gibi, işlerini düzgün bir süreç olarak ifade etmemiş bir kurumda yazılım geliştirmek amaçlı olarak yazılım ihtiyaçlarının analizini yapmak ne anlama gelir? Kısaca “yapamamak” anlamına gelir 🙂 Ne yaptığını bilmeyen, neye ihtiyacı olduğunu da bilemez, bu kadar basit. İşte bu yüzden bir yazılım projesinde en kritik ve en zor soru “neye ihtiyacınızın olduğu”dur.

Buraya kadar bahsettiğimiz aslında işin analizidir yani İngilizce’de “business analysis” terimiyle ifade edilen çalışmadır. Yazılım ihtiyaçlarının analizi ise, yani İngilizce’de “software requirements analysis” ile ifade edilen ise, iş analizi yapılmış bir işin otomasyonunun yazılım ile sağlanması amacıyla, geliştirilecek yazılım sisteminin ihtiyaçlarının belirlenmesidir. Bu durumda iş analizinin üzerine, bir yazılıma konu olabilecek seviyede detay girmesi gerekiyor ki “iş” bir yazılımla yerine getirilebilsin. Burada yazılım ihtiyaçları analizinin ya da daha kısaca ihtiyaç analizinin, iş analizinde olmayan bir takım yeni detaylar isteyeceği çok açıktır. Böyle bir ihtiyaç analizi çalışmasının, grafik kullanıcı arayüzü (GUI) gibi, yazılımın yarattığı yeni yapıların belirlenmesi ya da “otomasyon” kavramının getirdiği ve önceki, elle çalışan yapılarda hiçbir şekilde söz konusu olmayan performans, ölçeklenirlik, güvenlik gibi yeni ihtiyaçların ortaya çıkarılması ve detaylandırılması gibi farklı boyutları olacaktır.

Buraya kadar, ister iş amaçlı ister yazılım yazılım amaçlı olsun, ihtiyaçların tarif edilmesinden bahsettik ve burada ikili bir ayrımı kurguladık. Biz yazılımcılar, eğer sağlıklı bir yazılım geliştirmek istiyorsak, bunun için sağlıklı bir yazılım ihtiyaç analizi yapmalıyız. Sağlıklı bir yazılım ihtiyaç analizi ise sağlıklı bir iş analizi üzerine bina edilebilir. İşinin analizini yapmamış ama bir şekilde işini otomatize etmek isteyen kurumun önünde iki seçenek vardır: Ya iş analizini de, geliştirilecek olan yazılım vesilesiyle yazılım projesinde, projenin başında yapmak, ya da hiç yapmayıp, doğrudan yazılıma girişmek. Ülkemizde ikisi de çok sık olarak uygulanan yöntemler ama sanki ikincisi daha fazla oranda yapılıyor gibi geliyor bana. Dolayısıyla bir analiz yapılacaksa bile tamamen yazılım geliştirme amaçlı olarak düşünülüyor çünkü zihnimizde iş analizi ile yazılım ihtiyaç analizi ayırımı yok malesef. Bu durumda da ortaya çıkan yazılım da ezici çoğunlukla, var olan hantal ve verimsiz süreçleri kemikleştirmekten öteye hizmet etmiyor. Hatta daha da temelde, işini bilmeyen ama bir şekilde halleden 🙂 kişilerle, işini ve ihtiyacını tarif etmek amacıyla ihtiyaç analizi çalışması yapmak çok sorunlu hatta şunu da diyeyim, hastalıklı bir hal alıyor. Bu şekilde ortaya çıkan yazılım da tatmin edici olmuyor, aşırı miktarda değişiyor ve bu yazılımı ayakta tutmanın maliyeti aşırı artıyor.

Bu yazıda, iş analizi ile sonrasındaki yazılım ihtiyaçları analizinden ve aralarındaki ilişkiden bahsettik. Bir sonraki yazıda yazılım ihtiyaçlarının analizini daha detaylı olarak ele alacağız.

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

Eşleştirme mi Haritalama mı? Not mu Dip Not mu? Bir “Chicken Translation” Hikayesi Daha

Java, Kültür, Bilgi ve Düşünce , , , , , , ,

Sağlıklı düşünmenin göstergesi dili sağlıklı kulanmaktır. Kafası karışık insanların dili kullanma şekilleri, kelimeleri olgulara karşı getirmeleri, bunlar üzerine argüman bina etmeleri problemlidir. Bu tür kafa karışıklıklarının bir kısmı da, teknolojiyi ve ilgili terimleri ve ifadeleri, yabancı dilden, özellikle de İngilizce’den devşirirken takındığımız tutumla ilgili. Bu günlükte olgunun ya da sürecin ruhuna uymayan ve bu yüzden iğreti duran çevirilerden daha önce de bahsetmiştim. (Örneğin “object-oriented” kavramının “nesne-yönelimli” ya da daha da yanlış olarak “nesne-tabanlı” olarak çevrilmesi ile ilgili bu yazıya bakılabilir.)

Bu yazıda bu tip çevirilerden ikisine dikkat çekmek istiyorum: İlki “annotation” kelimesinin “dip not” olarak çevrilmesi. “Annotation” Java’ya 5 versiyonuyla gelen özelliklerden birisi ve “annotation”ları, bazen kod üretme, bazen de konfigürasyon amaçlı olarak uzun süredir kullanmaktayız. Pek çok Javacı, popüler bir Java bileşeni olan JPA ayarlarını, genelde XML yerine annotation denen elemanlarla yapmayı tercih eder. Bu annotationlar başlarında “@” işaretiyle kullanılır ve değişkenler gibi, nitelenen diğer dil elemanlarının hemen öncesine, ya da geleneksel olarak bir üst satırına yerleştirilir. Yani

 

@Entity(name="Person")
@Table(name="Persons")
public class Person{

   @Id
   private String tckn;
   ...
}

örneğinde olduğu gibi. Çok sıklıkla, “annotation” kelimesinin dilimize, özellikle JPA ile ilgili yazılarda “dip not” diye çevrildiğini görüyorum. İki problem var burada: İlki “annotation”, bir yazıya yapılan herhangi bir nottur. Bir yazıda bazı yerleri sarı kalemle işaretlemek ya da çizmek bile “annotation”dur İngilizce’de, yani not alma, notlandırma, işaretleme vb. kelimelerle dilimize çevrilecek bir harekettir. Her not bu anlamda bir dipnot değildir, olması da gerekmez. İkincisi ve ironik olanı, JPA’da olup da “dip not” olarak çevrilen bu “annotation”lar, yukarıdaki örnekten de görüleceği üzere “dip”te değil, aksine nitelediği dil elemanının öncesinde/üstünde yazılır :). Bu Java’nın bir kuralıdır.

Çeviri konusunda esas “chicken translation” örneği bu değil. Esas bomba, yine JPA ile ilgili olarak, uygulamadaki nesnelerin ilişkisel veri tabanındaki tablolar, nesnelerin değişkenlerinin ise tablolardaki kolonlar ile “eşleştirilmesi”nin dilimize “haritalama” olarak çevrilmesi. Sebebi, bu kavramın İngilizcesi olan “object-relational mapping” tamlamasında “map” kelimesinin geçiyor olması. Eeee, tabi taa İngilizce öğrendiğimiz ilk yıldan bu yana biliyoruz, “map” “harita” demek. Dolayısıyla bu tamlama da “nesne-ilişkisel haritalama” olarak çevrilmelidir. Halbuki işin ruhu, yapılan işin mahiyeti ele alındığında ki bunu ayrıntılı olarak bu yazıda açıkladım, olan biten şey, iki farklı ortamdaki yazılım elemanının birbiriyle eşleştirimesi ya da birbirlerine karşı getirilmesidir. Bu durum bir maçta, savunan takımın oyuncularının, hücum eden takımın oyuncularını, savunma amacıyla “alması” ya da onlarla “eşleşmesi”nden başka birşey değildir. JPA’daki bu “eşleştirme” işlemi o kadar da işin merkezindedir ki, anlamak için öyle çok da uzman olmaya gerek yoktur. Örneğin, 5 günlük bir JPA ya da Hibernate eğitiminin ilk bir ya da iki saatinde bu eşleştirmeyi katılımcılara anlatmış ve basit de olsa bir örneğini vermiş oluyorum ben. Ondan sonra eğitim yoğun olarak bu eşleştirmeyle geçiyor. Yani buradaki durum, zamanında, kendilerine saygım sonsuz olmakla birlikte, “object-oriented” terimini dilimize, bu kavramın neyi ifade ettiğini, pratikte dillerde nasıl kullanıldığını tamamen bilmeden, iyi niyetle bir sözlük çevirisi yapanların halinden daha berbat. JPA ya da bunun en yaygın ürünü olan Hibernate’i, üniversitede bir Bilgisayar Mühendisliği 2. yıl öğrencisi biliyor, eşleştirme işini pratik olarak da bizzat yapıyor. Dolayısıyla aklım, yapılanın tabiatının “bir karşı getirme” ya da “eşleştirme” olduğunu bilmemize rağmen, neden sözlükte “map” kelimesinin ilk anlamını alıp, “haritalama” diyerek yeni bir “chicken translation” komedisi yaratıyoruza takılmadan edemiyor. Halbuki, biraz İngilizce bilen, “map” kelimesinin farklı bağlamlarda kullanıldığını ve bilmem kaç yüzyıl önce etimolojik olarak harita kavramından çıksa bile artık genel olarak İngilizce’de bir karşı getirme, bir eşleştirme anlamına geldiğini bilir. Örneğin, matematik’teki fonksiyonlar bir “mapping” yani karşı getirme ya da eşleştirmedir.

Gün geçmiyor ki yenilerde Facebook vb. yerlerde, eskilerde forum vb. paylaşım ortamlarında, “eğitimsiz” olduğunu düşündüğümüz özellikle esnaf kesiminden olan insanların yanlış ya da komik İngilizce tercümeleri yayınlanmasın. Peki biz “eğitimli”ler niye aynı şeyi yapıyoruz? “Batı’dan kopyalamak” acaba eğitimle falan ilgisi olmayan, tamamen kültürel bir öğe olarak taa zihnimizin derinliklerine işlemiş bir hastalık mı yoksa?

Merak ediyorum, “map” kelimesini “harita” diye çevirenler Windows’daki “Map Network Drive”ı nasıl çeviriyorlar? Ya da “Director or his/her proxy must be present in the meeting” kelimesindeki “proxy”i de bir ağ (network) elemanı olarak mı düşünüyorlar?

Her çeviri bir yorumdur. Her yorum da kaçınılmaz olarak %100 nesnel olamaz, bunun farkındayım. Ama yukarıdaki örneklerin bununla yakından uzaktan alakası yok malesef.

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

«< 56 57 58 59 60 >»