Eksik Gereksinim Analizleri ve Neticeleri

Bir yazılım ürününün kontrollü ve istenilen nitelikte ortaya çıkabilmesi için gereksinim analizi yapılması gerekmektedir. Gereksinim analizi kısaca müşterinin piyasa koşullarından doğan gereksinimlerinin tespit edilmesidir. Bu analiz müşteri ne ister sorusunun cevabını vermelidir. Aksi taktirde müşterinin ihtiyacı olmayan bir ürün ortaya çıkma riski oluşabilir. Bu yazımda bu tür gereksinim analizlerinin doğru yapılmadığı durumlarda doğabilecek sıkıntılardan bahsetmek istiyorum.

Okumaya devam et

Sekiz Milyar Değişik İşletim Sistemi

Son zamanlarda alışkanlıkların oluşumu, etkileri ve yapıları hakkında bilgi edinme ve uygulama fırsatım oldu. Bir yazılımcı olarak insan vücudunu donanım, kişiliğini oluşturan tüm davranış biçimlerini ve diğer yetilerini yazılım olarak gördüğüm için alışkanlıkları da bu pencereden incelediğim bu yazıyı kaleme almaya çalıştım.

Okumaya devam et

Gitflow ve Verdiği Zararlar

Artık git ile çalışmayan kalmadı sanırım. Bilindiği üzere gitflow isminde bir çalışma modeli var. Bu modelde uzun ömürlü feature branchlar ve ihtiva ettikleri daha geniş kapsamlı commitler ile çalışılmakta. Bu yazımda sizlerle bu modelin dejavantajları ve sebep olduğu sorunlar ve zorunlulukklar hakkındaki fikirlerimi paylaşmak istiyorum.

Okumaya devam et

Çevik Süreçler Neden Dikiş Tutturamadı

Çevik süreçlerin tam olarak ne olduğunu kavramamış, çevik süreçler ile bir proje uygulamamış, scrum yaparak çevik olduğunu ve çevik süreçlerin bir işe yaramadığını zanneden şahısların “agile is dead” naralarını unutmadık. Ben de çevik süreçler öldü diyorum, lakin ekliyorum: “yaşasın çevik süreçler”. Çevik süreçlerin yıldızlarının bundan sonra nasıl parlayacaklarını ve tam anlamıyla yazılım geliştirme süreçlerine hakim olacaklarını kendi yazılımcı perspektifimden sizinle paylaşmaya çalışacağım.

Okumaya devam et

Bilginin Evrimi

Yazılımda bilginin yarı ömrü ne yazık ki altı ayın altına düşmüş durumda. Yazılımcılar eskiye nazaran daha çok bilgi edinmek zorundalar. Bunda yazılımda soyutlamanın hızlanmasının büyük bir rolü mevcut. Soyutlama ve geldiğimiz noktayı bu yazımda kaleme almaya çalışmıştım.

Soyutlama işlemi bilginin evrimi için gerekli bir süreç. Evrimin olmadığı yerde gelişme olmaz. Evrim süreci bilginin geçerliliğini ispat etmekle mükellefken, soyutlama süreci de bilginin kullanıldığı anlamına gelmekte. İnsanlık var olduğu sürece, bu ilişki bilginin bir balon gibi şişip, sonsuzluğa doğru büyüyeceği anlamına geliyor, çünkü insanoğlu doğası gereği soyutlamadan yapamaz. Bu yüzden soyutlama işlemini bilgisel evrimin akaryakıtı olarak görebiliriz. Okumaya devam et

Yazılım Dünyasının Hızlı Çözüm Üretmek İle Olan İmtihanı

Yazılım neden vardır sorusu sorulduğunda, benim aklıma gelen ve benim için en anlamlı cevap yazılımın müşterinin gereksinimlerini tatmin etmek için var olduğudur. Müşteri piyasa ihtiyaçlarından doğan gereksinimlerini tatmin etmek ya da piyasa rekabetinde avantaj sağlamak için yazılıma yönelir. Yazılım müşterinin piyasa şartlarında ayakta kalkmak için kullanacağı en kıymetli araç haline gelebilir. Sektörüne göre yazılım olmadan bir firmanın piyasa işlevini yerine getiremediğini, rakiplerine yenik düştüğünü ve yök olduğunu ya da yetersiz yazılım yüzünden yok olma riski ile karşılaştığına tanık olmak mümkündür.

Okumaya devam et

Alan Borcu (Domain Debt)

Buradaki yazımda teknik borcun ne olduğunu, nasıl oluştuğunu ve nasıl ödenebileceği konusuna değinmiştim. Teknik borç kodu doğrudan ilgilendiren ve projenin sürdürülebilirliğini etkileyen bir durumdur. Bu yazımda teknik borç kadar dikkat görmeyen, lakin yazılım projesinin kaderini teknik borçlanmaya nazaran daha belirleyici olan alan borçlanmasından bahsetmek istiyorum.

Okumaya devam et

Neden Debug Yapmak Yazılımın En Kötü Alışkanlıklarından Birisidir

Kodu debug yapma tekniği her yazılımcının hata bulmak ve kodu anlamak için kullandığı bir yöntemdir. Lakin bu tekniğin kullanımı yazılımın en kötü alışkanlıklarından birisidir. Bunun neden böyle olduğunu bu yazımda sizlerle paylaşmak istiyorum.

Yazıma başlamadan önce şunu belirtmek isterim. Bir yazılımcı olarak debug etme tekniğini gerekli gördüğümde kullanıyorum. Bu blog yazımın kesinlikle “debug etmek yanlıştır, kullanılmamalıdır” şeklinde algılanmasını istemem. Gerekli olduğu yerde debug etme tekniğinin kullanımı mübahtır. Yazımda debug yapma termini hata bulma ve kodu anlama süreci için eş anlamlı kullandım.

Bu konuda kısa bir zaman önce bir tweet yazdım:



Okumaya devam et

Java 9 ile Modül Bazlı Yazılım

Bir yazılım sisteminde karmaşaya, bağımlılıklara ve kodun bakım ve geliştirilmesi sürecine hakim olabilmenin bir yolu da komponent ya da modül bazlı yazılım yapmaktan geçmektedir. İdeal şartlarda bir modül tek bir görevi yerine getirir ve tek sorumluluk prensibi göz önünde bulundurularak implemente edilmiştir. Modül iç dünyasını gizli tutar ve kullanımını modül API (application programming interface) olarak isimlendirilen tanımlı giriş, çıkış kanalları ya da başka bir deyişle kullanım arayüzü aracılığı ile sağlar. Kullanım arayüzleri modülün hangi işlemleri gerçekleştirdiğini soyut olarak tanımlarken, bu işlemlerin nasıl gerçekleştirildikleri modül içinde yer alan implementasyonlarda yer almaktadırlar. Kısaca bir modül kullanıcısı için bir kara kutudur. Bu şekilde kullanıcısını etkilemeden, iç implementasyonu değiştirmek mümkündür, çünkü kullanıcı iç implementasyona değil, kullanıcı arayüzüne bağımlıdır. Kullanıcı arayüzleri sahip oldukları yapıyı koruyabildikleri sürece, modül üzerinde yapılan değişiklikler kullanıcıyı etkilemez. Bu şekilde tanımlı kullanıcı arayüzleri aracılığıyla esnek olarak birbirine bağlı olan uygulama parçaları geliştirmek ve bu parçalar üzerinde uygulamanın genelini etkilemeden gerekli değişiklikleri yapmak mümkündür.

Okumaya devam et

Yeni Teknolojileri Öğrenme Konusunda Nasıl Bir Yol Haritası Oluşturmalıyım?

Birçok okurumdan bu ve buna benzer sorular aldığım için bu konuyu aydınlatmak adına bu yazıyı kaleme almak istedim.

Bilindiği üzere yazılım sektörü çok hızlı teknolojik gelişmelere sahne olmakta. Kullanıma sunulan yeni programlama dilleri, çatı ve yöntemlerin sayısı çok yüksek. Doğal olarak yazılımcılar işin neresinden tutmalıyım ya da başlamalıyım, hangi konulara ağırlık vermeliyim, neleri öğrenmeliyim gibi sorularla karşılaşmaktalar. Bu yazımda bu tür sorulara kendim için nasıl cevap bulduğumu aktarmak istiyorum. Vermek istediğim örnek bir nevi öğrenim ve kişisel gelişim konusundaki benim yol haritam.

Okumaya devam et

Neden Programcılık Harici İşlerle Uğraşmak Daha İyi Bir Programcı Olmayı Sağlar

Programcılığın çok büyük bir bölümünü basmakalıp işler oluşturur. Bu zamanla programcının belli kalıpların dışına çıkmasını zor hale getiren bir durumdur. Belli kalıplar çerçevesinde düşünmeye başlamak, yaratıcı ve çözüm üretici olmanın önündeki en büyük engeldir. Bu kalıpları yıkmanın ya da en azından onların görüşü engellemeyecek şekilde aşılabilmelerinin tek yolu programcılık harici iş ve projelere zaman ayırmaktan geçmektedir.

Okumaya devam et

Zaman Eksenindeki Teknolojik Fay Hatlarının Programcılar Üzerindeki Etkileri

Programcılık gibi bilgi güdümlü mesleklerin bir dejavantajı bulunmakta. Bu tür meslekler sadece bilgiyi taşıyanı yanlarında geleceğe taşırlar. Bilgi de öyle bir kitap karıştırma ile edinilecek bir şey değildir. Çoğu bilgi daha önce edinilmiş bilgiyi temel alır. Yani bilgilenme süreci yıllarca süren ve sağlam bilgisel temellere ihtiyaç duyan bir yapıdır.

Okumaya devam et

Geri Dönüşü Olmayan Ünvanlar

İkibinli yılların başlarında bir konferansda eski başbakanlarımızdan Tansu Çiller’e etrafındaki korumalarının ve çalışma arkadaşlarının sayın başbakanım diye hitap ettiklerine şahit olmuştum. Başbakanlık görevi on sene geride kalmış bir şahıs için neden başbakan ünvanı kullanılmaktaydı? Nedenini tam olarak hala bilmemekle birlikte, bunun nezaket kuralları çercevesinde, ünvan sahibi şahsı onure etmek ve onu eski ünvanı ile bir zamanlar sahip olduğu mertebede görme amaçlı kullanıldığını düşünüyorum. Tenzili rütbe görmenin hoş görülmediginden de anlaşıldığı gibi bir şahsa sahip olduğu en yüksek ünvanın altında bir ünvanla hitap etmek ayıp kaçıyor olabilir.

Okumaya devam et

JVM Nasıl Çalışır Yazı Serisi – Java Just In Time Compiler (JIT) Nasıl Çalışır?

Java’yı çoğu programcı yorumlanan (interpreted) dil olarak bilir. Java’nın yavaş olduğu efsanesi de başlangıcını da burada bulur. Bytekod olarak derlenen Java sınıfları Java sanal makinesi (Java Virtual Machine – JVM) bünyesinde yorumlanır. Tek derleme işlemi Java sınıflarının bytekoda dönüştürülmesi esnasında yapılmaz. JVM bünyesinde de bytekodun makine koduna dönüştürüldüğü bir derleme gerçekleştirilir. Bu işleme Just in time (JIT) compilation ismi verilmektedir. Bu yazımda JVM bünyesinde kodun nasıl derlendiğini örnekler üzerinden aktarmak istiyorum.

Okumaya devam et