Yazılım Dünyası Ve Hala Tartışılan Meşhur Konular.

Yazılım en hızlı gelişen ve değişen sektörlerden birisi. Ayrıca programlama dilleri, metodolojileri, araçları ve kullanım şekilleri itibariyle en fazla çeşitlenmenin de olduğu alanlardan. Fikirler ve ürünler çok çeşitli olunca tartışmalar yaşanması kaçınılmaz oluyor. Çoğunlukla her iki tarafın da haksız olmadığı bu tartışmalar bazen uzun yıllar sürebiliyor ve hatta bir sonuca ulaşmıyor. Tab mı boşluk mu? Programcılıkta, kod parçalarının farklı girintiler yaparak yazılması önemlidir. Bir fonksiyonun içindeki kodları biraz içeriden, bir döngünün içinde kalan bölümü biraz daha içeriden vb. yazarak kodların kolay okunabilir ve anlaşılabilir olması sağlanır. Peki, bu girintileri verirken Tab (Sekme) karakteri mi kullanılmalıdır yoksa belirli sayıda boşluk mu verilmelidir? Bu sorunun cevabı çok eski yıllardan beri bir tartışma konusu olagelmiştir. Boşluk fikrini savunanlar, bir Tab karakterinin Unix'te 8 boşluk, Macintosh'ta 4 boşluk anlamına gelebileceğini ve ortak bir standart için belirli sayıda boşluk kullanılması gerektiğini söylerler. Tab fikrindekiler de herkesin boşluk verme şeklinin farklı olduğunu, asıl standardı Tab karakteri kullanmanın oluşturduğunu iddia ediyorlar. Modern programlama editörlerinin çoğunda Tab tuşunun kaç boşluk vereceği kullanıcıya bırakılmış durumda. Tab değil de boşluk vermeyi tercih edenler ise farklı alışkanlıklara bağlı olarak 2, 4, 8 karakter kullanabiliyorlar. Süslü parantez nereye konacak? C ve sonrasında çıkan benzeri programlama dillerinde bir programın, bir metodun ya da bir döngünün başlayıp bittiğini anlatmak için süslü parantezler { } kullanılır. Bu parantezlerin kullanım şekli de bir başka tartışma konusudur. Vikipedi'de anlatıldığı şekline göre; Klasik C dilinde çok kullanılan K&R (Kernighan and Ritchie) stilinde, Unix/Linux çekirdeğinin yazıldığı 1TBS (The One True Brace Style) ve BSD Unix kaynak kodunun yazıldığı şekil olan BSD KNF stilinde, açılan parantez metotlarda alt satıra, metot içindeki döngülerde ise aynı satıra konur. Kapatılan parantez metodun ya da döngünün başı ile aynı hizaya konur.

int metot() { while(şart) { işlemler... } if(şart){ işlemler... } else { işlemler... } }

ANSI C standardı olarak bilinen Allman stilinde ise, parantezler her zaman ayrı satırlarda bulunur. Bu yöntemde tek bir parantez bir satır olarak geçtiğinden yazılan kodun satır sayısı artar. Ama aynı zamanda okunabilirliği de artar.

int metot() { if(şart) { işlemler... } else { işlemler... } }

Yine, bu iki metottan hangisini tercih edeceğiniz size kalıyor. Eşittirden sonra boşluk olmalı mı? Bir diğer tartışma konusu, değişken atamalarında ya da şart ifadelerinde = (eşittir) karakterinin etrafında boşluk bırakılıp bırakılmayacağı. Örneğin, değişken=değer mi olmalı yoksa değişken = değer mi? Bu sorunun cevabı değişken; çünkü bir çok programlama ve script dilinde boşluk kullanmanın anlamı değişebiliyor. GNU/Linux mu, Linux mu? Açık kaynaklı yazılım dünyasının tartışmalarından birisi, Linux işletim sisteminin adının GNU/Linux mu yoksa Linux olarak mı kullanılması gerektiği. GNU (GNU's Not Unix -yinelemeli bir kısaltma) Unix'e alternatif ve sadece özgür yazılımlardan oluşan bir işletim sistemi oluşturmak için Richard Stallman tarafından 1984 yılında başlatılmış bir proje. 1991'de, Linus Torvalds Linux çekirdeğini yazınca bazı GNU programları Linux üzerinde çalışmak üzere aktarılmış ve daha sonra GNU'nun diğer kısımları da Linux üzerine taşınmış. Böylece tam bir işletim sistemi ortaya çıkmış. Ancak, sonraki yıllarda Linux çekirdeğinden ve GNU programlarından oluşan bu işletim sistemine ne ad verileceği tartışma konusu olmuş. GNU/Linux ismini savunanlar, tam bir adı ortaya koyduğu için bir kimlik olarak kabul edilmesini isterken; Linux ismini savunanlar daha kolay ve yaygın bir kullanım oluştuğu için işletim sisteminin adının Linux olarak kalması gerektiğini iddia ediyorlar. Richard Stallman, işletim sisteminden bahsederken GNU/Linux; çekirdekten bahsederken ise Linux denmesini istiyor. Linus Torvalds ise, eğer Debian Linux, Redhat Linux gibi bir GNU dağıtımı hazırlanacaksa o zaman böyle denebileceğini, ama Linux'a GNU/Linux denmesinin komik olduğunu söylüyor. Kaynak kodu açık mı olmalı yoksa kapalı mı? Geliştirilen yazılımların kaynak kodunun açık ve ulaşılır olmasını isteyen açık kaynak felsefesi ile kaynak kodlarının gizli olmasının gerekliliğini savunan şirketlerin tartışması yıllardır devam ediyor. Açık kaynak felsefesi; açık kaynak kodlu uygulamaların güvenilirlik sağladığını, sanılanın aksine güvenlik açığı oluşturmadığını hatta bir çok kişi tarafından görülebildiği için hatalarının kısa zamanda düzeltilebileceğini belirtiyor. Ayrıca herkes tarafından geliştirilebilmesi sayesinde daha sağlam ve yüksek kalitede olacağını iddia ediyor. Microsoft'un başını çektiği, kapalı kodu savunan şirketler ise; kapalı kaynak kodlu uygulamaların daha güvenli olduğunu, daha çok kişinin kodu görmesinin hataları kapatmaya yetmeyeceğini, farklı kişilerin koda müdahale etmesinin daha yanlış olduğunu savunuyor. Ayrıca, yazılımlardan alınan lisans bedellerinin ar-ge faaliyetlerinde kullanıldığını, açık kaynak kodlu bir çok yazılımın ise ar-ge faaliyeti yapmadan kendilerinin fikirlerini kullandığını iddia ediyorlar. Yazılım geliştirme mi sanat mıdır, mühendislik mi? Yazılım ürünleri hem yapılış süreçleri itibarıyla bir sanat eseri hem de içerdikleri mantık ve sorunlara yaklaşımı sebebiyle bir bilim ya da mühendislik yapısı özelliği gösterirler. Tartışılan nokta ise daha çok yazılım geliştirme işinin hangisine daha çok uyduğu. Mühendislik fikrini savunanlar, yazılım geliştirmenin kendine özgü dinamikleri, çalışma prensipleri ve kuralları olan bir meslek olduğu, süreçlerin bilimsel olarak ele alınması gerektiği, ihtiyaçlara analitik ve sistematik bir yapıda çözümler üretilmesi gerektiği yaklaşımlarını ortaya koyuyor. Sanat olduğunu iddia edenler ise, geliştiricilerin el emeği olduğunu, yetenek gerektirdiğini, arayüz tasarımları, raporlamalar vb. sebebiyle birer sanat eseri olduğunu, yazılımcıların bir disiplinle çalışamayacaklarını ancak özgür bırakıldıklarında nitelikli bir üretim yapabileceklerini düşünüyorlar.

Yazıdan görseller

Sıkça Sorulan Sorular

Yazılım dünyasındaki tartışmalar neden bu kadar uzun süre çözümsüz kalıyor?

Yazılım geliştirmede doğru tek bir yol olmadığı için tartışmalar genellikle bağlama, projeye ve ekip tercihlerine göre değişir. Her iki tarafın da geçerli argümanları bulunduğundan konsensüs sağlamak güçleşir ve tartışmalar yıllarca sürebilir.

Programlama dili tartışmalarında hangi tarafı seçmek daha doğru bir yaklaşım?

Programlama dili seçimi projenin ihtiyaçlarına, ekibin deneyimine ve hedef platforma göre yapılmalıdır. Belirli bir dili körü körüne savunmak yerine hangi dilin hangi sorunu daha iyi çözdüğünü değerlendirmek çok daha verimli bir yaklaşımdır.

Yazılım metodolojileri arasındaki tartışmalar pratikte projeleri nasıl etkiliyor?

Agile, Scrum veya Waterfall gibi metodolojiler arasındaki tartışmalar ekiplerin süreç seçimini doğrudan etkiler. Yanlış metodoloji seçimi proje gecikmelerine, iletişim kopukluklarına ve verimsizliklere yol açabilir; bu nedenle tartışmalar teorik olmaktan çok pratik sonuçlar doğurur.