şükela:  tümü | bugün
  • programlama paradigmalarından habersiz, kimi zaman gördüğü her koda makarna diyen bir wepçi, kimi zaman 2 satır kod düzeltip 3 kuruş almak yerine projeyi baştan yazıp gözünü 5 haneli yeşillere dikmiş yokuşçu bir freelancer, kimi zaman çalıştığı şirkete yeni girmiş ve ondan öncekilerin üzerine basarak sıçrayabileceğini düşünen bir çömez olabilir. çalıştığı projelerde tek hedefi ay sonunu bir an önce getirmek olduğundan, ooprogramming in sadece class ve object lerden oluşmadığını öğrenecek kadar deneyim kazanmamışta olabilir. yazdığı projelerde, sınıf dışında kullandığı her if her else için de kendisine kafam girsindir.

    (bkz: kendi yazmadığı her koda spagetti diyen yazılımcı)
    (bkz: spagetti koda oop un tersi diyen yazılımcı)
  • böyle bir şey var sanırım.

    amatör dönemlerimde bana da her oop olmayan dizilim spagetti gelirdi. bir de takıntılıyım malesef, kendi yazmadığım şeyin üzerine yama yapmaktan da nefret ederdim. zamanla, işin mükemmelliği değil paramı kazanıp ne bok yerlerse yesinler noktasına geliniyor.

    gene de kendi işinizse "size göre" en anlaşılır dili edinmeye çalışın. taviz vermeyin.
  • programlama paradigmasının gelişimine baktığımızda aslında tikellerden soyutlamalara, kavramlara ulaşmaya çalıştığını görürüz.

    bir şeyi sadece bir kere yapmak değil sürekli yapmak istediğimiz için fonksiyonlar yazarız. sonra bu fonksiyonların arasında yapılar çıkmaya başlar. o zaman objeler, sınıflar üretmeye başlarız ki tekrar tekrar kullanabilelim.

    değişkenleri de sürekli dışarı çıkartmaya, parametreleri keyfi olmayan sistemler üretmeye çalışırız. yani benim objem veya sınıfım "teker" içinse, parametreleri değiştirerek her türlü "teker" için kullanabilmeliyim.

    olayın özeti bu. lakin olay bu değil. spesifik bir problemi çözerken mühendisin ilgili alanın fiziğini, kimyasını, geometrisini, cebirini vs bilmesi gerekiyor ancak 4 yıl boyunca öğrencilere neredeyse sadece kod yazmayı (ve matematik olarak da calculus) öğrettiğimiz için mühendis problemi çözemiyor.

    bugün bilgisayar mühendislerinin en büyük sorunu problemi çözmek. aradaki modellemeyi, matematiği yapmak. bu konuda yetersiz ve yeteneksiz olduğumuz için de genelde basit işlere kaçıyoruz. türkçe dil işlemeye bakın mesela. bir sürü bilgisayar mühendisi çalışır ama dilbilime kafa yoramayacak kadar meşgul oldukları için yabancı makalelerdeki şeyleri türkçeye uygulamanın ötesine geçemezler. görüntü işleme keza öyledir. hazır kütüphanelerle uygulama geliştirmektedir bugün en büyük firmalar bile.

    işin matematiğini, optiğini, dilbilimini, fiziğini, kimyasını bilmeden olmaz. bilgisayar sadece araçtır. kod yazmak sadece araçtır. ve lisans eğitimi size genelde en üstte açıkladığım yaklaşımı, pratiği kazandırmaya çalışır.

    hal böyle olunca da mecburen kodlar spagetti oluyor. çünkü derin bir kavrayışla değil anlık aydınlanmalarla veya geçici çözümlerle üretiliyor.

    not: çok güzel kod yazanlar da gördüm. ortak özellikleri şuydu. toplam 10 saat harcıyorlarsa bunun belki 7-8 saati kağıt kalemle oluyordu. metodu bir kez oturttuktan sonra zaten adam bu zanaatin ustası, kolayca yazıyor 500 satır kodu word'de yazar gibi.

    kağıt kalemle geçirdiği o süre boyunca problemin nereleri esas nereleri tali, bunu görüyor. sınıfları nesneleri metotları değişkenleri buna göre tanımlıyor. gerekli yerde açıklayabiliyor çünkü neyin açıklanmaya ihtiyacı olduğunu biliyor.

    böyle güzel kodlara bazı kütüphanelerin bazı sınıflarında da rastlarsınız. adam oturmuş mesela 1000 satır "optik perspektif düzeltme" kodu yazmış ama okutur kendini şerefsiz. çünkü orada bilimini, ilimini de anlatır. der mesela şu ikisi ters orantılı olduğu için burada böyle bir numara çekmemiz gerekti falan.
  • oop ne? spagetti ne ? kod ne ? bu başlıkta, bilgi nerede? algoritma bu kadar seçici olmayı nasıl başardı..
  • (bkz: dediğini anlıyor ve yapısal olarak parçalanıyorum)

    hep bunu yapmak istemiştim. holey!
  • bir trading botu yazdın, her ay %20 kar getiriyor. o saatten sonra class'tı, object'ti declaration'du kimsenin umrunda olmaz. kod çalışıyor mu tamam, gerisi hikaye.

    istersen fonksiyonun ne olduğunu bilme. 3 senede paran 500 katına çıkıyor.
  • bir yerde haklı olan yazılımcıdır. oop nin getirdiği solid dizayn biçimi yazılan projenin anlaşılabilir olmasını esas almaktadır. gerekli classları gerekli yerlere ayırıp farklı packagelarda toplarsanız bir başkası baktığında bu dizayn biçimiyle yazıldığını anlayıp, hemen üretime devam edebilir.

    fakat bunu functional programming için söyleyemeyiz, tabii kendi dizayn biçimleri olsa da oop nin gücü zaten abstraction olduğu için diğer diller bu kadar açık olamıyor.

    son olarak da ayıp eden yazılımcıdır, her dilin kendi standartları vardır, diğer dillerle karşılaştırıp spagetti demek saçmadır. beğenmiyorsa kendi dilinden devam edebilir.