Sektörde 10 yıl geçirdikten sonra fikrimin değiştiği yazılım geliştirme başlıkları

• 4 yıl önce de aynı konuda bir yazı yazmıştı; 10. yılda geriye bakma zamanı geldiği için bunu yeniden yazmış

Değişen düşünceler

• Sadelik kendiliğinden ortaya çıkmaz; sürekli çaba gerektiren bir unsurdur
• Karmaşıklığı yönetmek ya da anlamakla gurur duymak için bir neden olmadığını fark etti
• Farklı deneyim seviyelerinin bir arada olduğu ekiplerde typed diller vazgeçilmezdir
• Java sıkıcı olduğu için aslında harika bir dildir
• REPL, tasarım aracı olarak çok faydalı değildir ama keşif amaçlı kullanımda yararlıdır
• Gerçek programlama, kodu yazmadan önceki aşamada büyük ölçüde tamamlanmış olmalıdır
• Frontend geliştirme Kafkaesk bir kâbus alanına dönüştü ve artık keyif vermiyor
• Zarafet kavramı pratikte ölçülebilir bir metrik olamaz
• İyi yönetim çok değerlidir (uzun kariyeri boyunca düzgün yönetime çok nadir rastlamış)
• DynamoDB, belirli bir iş yüküne tam olarak uyuyorsa iyi bir veritabanıdır
• Nesne yönelimli yaklaşım, uygun olduğu alanlarda mükemmel bir yöntemdir. Yalnızca functional'a körü körüne inanmak akıllıca değildir

Sonradan edinilen görüşler

• Mühendisliğin özü iletişimdir
• Java'da Monad kavramını aşırıya kaçacak kadar uygulamamak gerekir
• Query Planner acımasız bir varlıktır
• Bir şeyin 'kolay' geldiği an, aslında onu tam anlamıyla kavramadığının işaretidir
• Yeni geliştiricilere araştırma yapma ve hata yapma payı tanınmalıdır
• Soft skill'ler aktif biçimde geliştirilmelidir. Yatırımın karşılığı hemen görülür
• Genel uygulama geliştirmede 'gerçekten genel amaçlı soyutlama' diye bir şey neredeyse yoktur. İhtiyaç duyulan kodu yazmak daha iyidir
• Buna karşılık, kütüphane geliştirme soyutlama tasarlama işidir. Doğru yapıyı (cebirsel biçimi) bulmaya zaman ayırmak gerekir
• ORM'ler tüm dillerde, tüm uygulamalarda sorunludur. SQL'i doğrudan yazmak daha iyidir
• Functional programlamanın sorunu çoğu zaman onun müritleridir
• Yeterince uzun zaman geçince, Serverless Functions üzerinde sistem kurmuş olmaktan ciddi biçimde pişman olunur
• Type'lar, dünyaya bakarken ortaya koyduğumuz iddialardır
• Dağıtık kilitler hâlâ son derece zor bir problemdir
• Biçimsel modelleme ve analiz yeteneği mutlaka sahip olunması gereken bir beceridir
• Entegrasyon test paketlerinde en önemli özellik yalıtımdır
• DynamoDB, genel uygulama geliştirme için olabilecek en kötü seçeneklerden biri de olabilir
• Çoğu insan kod 'zanaatkârlığıyla' pek ilgilenmez. İlgilenenlere değer verilmeli ama geri kalanlarla da bulundukları yerden iş birliği yapılmalıdır
• Geleceğin gradual, dependently typed dillerde olduğuna inanıyor
• Test kodunda ne kadar çok yorum olsa da asla fazla değildir

Değişmeyen görüşler

• Kod stili, lint kuralları gibi küçük meselelere takılıp kalan insanların hâlâ tuhaf bir grup olduğunu düşünüyor. Daha önemli şeylere odaklanmak gerekir
• Kod kapsamının kod kalitesiyle ilgisiz olduğu görüşünü koruyor (çoğu zaman ters orantılı bile olabiliyor)
• Monolith'in hâlâ gayet makul bir tercih olduğunu düşünüyor
• On yıllar boyunca birikmiş RDBMS araştırmasını ve iyileştirmelerini geçmenin zor olduğunu kabul ediyor
• Micro-service kullanmak için haklı bir gerekçe şart (bugünlerde bunun giderek doğal kabul edilmesi üzücü)
• Çoğu proje (AWS içindeki projeler de dahil) gerçekte 'ölçeklenmeye' ihtiyaç duymaz; hatta ölçeklenme varsayımıyla tasarlamak çoğu zaman zararlıdır
• Proje yöneticilerinin %93'ünün, hatta belki %95,2'sinin ortadan kalkmasının ya hiçbir etkisi olmayacağını ya da verimliliği artıracağını düşünüyor (4 yıl öncesine göre oran yükselmiş)

• 15. yılda bunun nasıl değişeceğini tekrar görmeyi planlıyor

[gongon]

Çoğunlukla katıldığım bir anlatı

[aer0700]

Çoğu projede ölçekleme gerektiren o an ya hiç gelmez ya da ihtiyaç haline gelmeden önce proje ortadan kaybolur...

[roxie]

Kademeli, bağımlı türlendirilmiş diller nedir..?

[botplaysdice]

Podcast’ten kulak misafiri olduğum kadarıyla, değerin tipi etkilediği türden bir tip sistemiymiş. Bu yazının yazarının fonksiyonel dillerden bahsetmesine bakılırsa, sanırım kastedilen de bu.

Bunun üzerine çalışan ve bunu geliştiren taraf daha çok fonksiyonel dil ekosistemi olduğu için...

Mesela List tipi, eğer değerlerin hepsi sıralıysa SortedList olabiliyor...

Böyle bir özellik varsa, derleme zamanında tip denetimiyle daha fazla şeyi kanıtlamak mümkün olurdu.

Bir fonksiyon SortedList alıp yine SortedList döndürüyor diyelim... Ama kodda bir bug varsa ve sıralı olma durumunu bozuyorsa, derleme sırasında type error çıkacak demektir.

Doğal olarak... tip denetiminin maliyeti de epey yüksek olur herhalde...

Pratikte ne kadar kullanılabilir hale geldiği konusunda ise hiç fikrim yok.

[roxie]

Aha, teşekkürler. Kulağa ilginç geliyor...

[xguru]

Statik ve dinamik tipler arasında esnek biçimde geçiş yapıp uygulanabilen bir dili ifade ettiği söyleniyor.

[extendednoob]

Java sıkıcı olduğu için aslında harika bir dil.
Bu ne anlama geliyor?

[botplaysdice]

Kim yazarsa yazsın benzer şeyler çıkıyor, bu yüzden bakımı daha kolaydır; galiba kastedilen bu, değil mi?

[vwjdalsgkv]

Sanırım bununla, özellikle daha fazla dikkat gerektiren ya da geliştiricileri şaşırtacak bir yönü olmadığı için, tam da bu haliyle bir güven duygusu verdiğini söylemek istemiş olabilir.

[dbs0829]

Kod stili veya linting ile ilgili konuların önemli bir kısmı araçlarla çözülebiliyor; buna karşılık bunları umursamayan insanlarla karşılaşınca birlikte çalışmak istemiyorum.

[beoks]

Katılıyorum. Ben de CI'a stil denetimi ekliyorum; böylece stile uyulmazsa merge edilmesini bile engelliyorum.

[edunga1]

> Kod stili, linting kuralları gibi ufak meselelere takılan insanların hâlâ tuhaf bir grup olduğunu düşünüyorum. Daha önemli şeylere odaklanmak gerek.

https://www.youtube.com/watch?v=JcY35HD77lg&t=828s
Ama bunun tamamen görmezden gelinmemesi gerektiğini, sonuçta bunların insanın odaklanmasını zorlaştıran unsurlar olduğu için çözüp devam etmenin daha iyi olabileceğini söyleyenler de var.

[yadameda]

> Çoğu insan kod "zanaatkârlığıyla" pek ilgilenmiyor. İlgilenenlere değer verin, ama geri kalanlarla da bulundukları yerde iş birliği yapmanız gerekir.

Katılıyorum..

[jjpark78]

Serverless üzerine sistem kurup pişman olanlardan biriyim.

Cold start hâlâ yavaş,
bir noktada trafik patlayınca on-demand ile neredeyse farkı kalmadı,
ve elden gelen her şeyi yapsak da deployment aşırı yavaş.

[jjpark78]

Kod kapsamı, şu iki durumda kod kalitesiyle ilgisiz olabilir diye düşünüyorum:

• Kapsam çok düşükse (benim ölçütüme göre yüzde 80) anlamı yoktur ya da
• Test senaryoları yalnızca normal akışta çalışan, sadece başarılı durum senaryoları olarak yazılmışsa

Sanırım bu iki durum söz konusu.

Bence test kodu ancak yüksek kapsamla ve hataya yol açan çeşitli senaryolarla, aynı bölümü farklı girdilerle birden çok kez test ettiğinde gerçekten anlam kazanır.

[annyeong]

İkinci anlamda yorumlamak bana daha anlamlı geliyor. Çünkü code coverage sayısının yüksek olması doğrudan kod kalitesiyle bağlantılı değil; önemli olan, bunu anlamlı test case'lerle doldurmak.

[carnoxen]

> Java sıkıcı olduğu için aslında harika bir dil.

Bir şekilde komik geliyor hahaha

[richardk]

Katılıyorum

Genel uygulama geliştirmede 'gerçekten genel amaçlı soyutlama' diye bir şey neredeyse yok. Gerekli olan kodu yazmak daha iyi.

[xguru]

Sektörde 6 yıl geçirdikten sonra fikrimin değiştiği yazılım geliştirme konuları

[GN⁺]

Hacker News görüşü

• Kod stili veya linting kurallarına takıntılı olanlara tuhaf bakan bir görüş var. Ancak ayrıntılara dikkat etmek, zanaatkârlığa değer vermektir
  • Kod yazmadan önce programlamanın büyük ölçüde tamamlanmış olması gerektiği görüşüne karşı çıkan geliştiriciler var. Kodlama ve tasarımı yinelemeli şekilde yürütmenin önemli olduğunu düşünüyorlar
  • Karmaşıklığı yönetmenin ve anlamanın önemli olduğu yönünde bir görüş var. Basit sistemler sadece karmaşıklığı başka bir yere taşır
  • Java'nın sıkıcı bir dil olduğu görüşüne karşı çıkanlar da var. Spring gibi Java kodlarının sıkıcı değil, eğlenceli de olmadığını düşünüyorlar
  • Kod yazmadan programlamanın tamamlanmış olması gerektiği görüşüne karşı çıkanlar da var. Kod yazılmazsa gerçeklikten kopmanın kolay olduğunu düşünüyorlar
  • Biçimsel modelleme ve analizin zorunlu olduğu görüşüne karşı çıkanlar da var. Deney yapmanın daha önemli olduğunu düşünüyorlar
  • Test koduna bolca yorum eklemenin iyi olduğu yönünde bir görüş var
  • Frontend geliştirmenin kâbus gibi olduğu yönünde bir görüş var. Ancak React + Typescript + MobX uygulamasını güncellerken büyük bir sorun yaşanmamış
  • Yazılım geliştirmenin organizasyonun aşamasına göre farklı değerlendirilmesi gerektiği yönünde bir görüş var. Startup'lar ile product-market fit'i oturmuş organizasyonlara farklı yaklaşmak gerekiyor
  • Java'daki Checked Exceptions'ın iyi bir fikir olduğu yönünde bir görüş var. Daha iyi hata yönetimi için biraz sözdizimsel iyileştirme gerekiyordu
  • Monolitik mimarinin hâlâ iyi olduğu yönünde bir görüş var. RDBMS üzerindeki araştırma ve iyileştirmeleri geride bırakmanın zor olduğu düşünülüyor
  • Deneyim seviyesi karışık ekiplerde tipli dillerin zorunlu olduğu yönünde bir görüş var. Programcıların bakış açısını hesaba katmak gerekiyor
  • Proje yöneticilerinin çoğu ortadan kalksa da büyük bir etkisi olmayacağı yönünde bir görüş var
  • Kod stiliyle ilgili stresin, proje stiline uyum sağlamanın önemli olduğuna işaret ettiği yönünde bir görüş var
  • Frontend geliştirmenin kâbus gibi olduğunu ama bazen keyif verdiğini söyleyenler de var
  • Zarafetin gerçek bir ölçüt olmadığı yönünde bir görüş var. Zarif çözümler her zaman pratik olmayabilir
  • DynamoDB'nin genel uygulama geliştirme için en kötü seçenek olduğu yönünde bir görüş var. Çoğu durumda SQL daha uygundur