şükela:  tümü | bugün
  • yazilim sistemlerinin gereklerinin belirlenmesi, tasarlanmasi, kodlanmasi, test vb islemlerinin gerceklestirilmesinde uygulanan cesitli sureclerin tumu.
  • yeryüzünün en stresli işlerinden biri olduğunu düşünüyorum. ömür karartıyor. allahım sana geliyorum..
  • yatirim/getiri orani dusunuldugunde son derece verimli bir is kolu. ozellikle de gunumuz kosullarinda minimal yatirim ile cok verimli, yuksek gelir getiren projeler uretmek gecmise gore cok daha kolay.

    ornegin, aklinizda "lan soyle bir site olsa ne guzel olurdu, soyle soyle yapardim" gibi bir fikriniz var fakat bunun icin sunucu, o sunucuyu yonetecek isgucu, yazilimi gelistirecek is gucu gibi kaynaginiz yoksa isiniz eskiye nispeten cok daha kolay.

    yazilimi kendiniz gelistirebiliyorsaniz ne guzel, bir programlama dili biliyorsaniz ne ala, bir sonraki adima gecebilirsiniz. yok bilmiyorum diyorsaniz ve ogrenme yoluna gitmeyecekseniz -ki gitmenizi tavsiye ederim- campus london gibi co-working space'lerin orneklerinin turkiye'de de oldugunu duyuyorum, atlayin gidin bir tanesine bir sure takilin, insanlarla tanisin, gorusun. ben bunu bu tip bir kaynaga gereksinim olmamasina ragmen ve sinirli vaktimle yapiyor, "keske yirmili yaslarimdaki kadar bosa harcayacak zamanim olsa" diye hayiflaniyorsam, bosa harcadiginiz zamanlari dusunup "acaba onun yerine ne yapabilirim?" diyorsaniz, bence daha fazla vakit kaybetmeyin.

    diyelim ki bu isi hallettiniz, bir iki kisi bir araya geldiniz [bu asamada kabul goren gorus, ucten fazla kisinin uygun olmadigi yonundedir. yine de siz bilirsiniz] programlama dili biliyorsunuz, sunucu lazim. amazon web services ne gune duruyor ? adamlar ec2 uzerinde 1 sene sure ile, micro type sunucuyu ucretsiz veriyorlar. gelistirme ortami icin yeterli. ustelik sistem yonetimi derdiniz de yok. zaten dusundugunuz sey bir senede masrafini cikaracak kadar gelir getirmiyorsa, cok buyuk olasilikla o kadar da isabetli bir karar degildir demek. bakin %100 demiyorum ama cok buyuk olasilikla oyle.

    alin bir micro-type ubuntu linux, uzerine bir couchbase bir tomcat sunucusu atin, isinizi gorur. couchbase'i key-value store olarak kullanip, persistence store olarak da parse.com'u kullanin. adamlar gelistirme surecinde asla erisemeyeceginiz miktarda [1 milyon] api request'i ucretsiz veriyorlar zaten. para kazanmadan, sizden para almiyorlar yani. trafik icin istemediginiz kadarini facebook size sagliyor, facebook connect ile kullanici login sorununu da cozuyorsunuz, trafigi de sagliyorsunuz. oturup java ile istediginiz kodu yazarsiniz, sadece zamaninizi ayiracaksiniz.

    burada bahsettigim tool'lar alternatifsiz de degil, baska diller, baska tool'lar da kullanabilirsiniz. dil olarak php biliyorsaniz o da olur, ruby isterseniz o da olur. open source yazilim dunyasi size neredeyse sinirsiz cozumler sunuyor. login icin facebook olur, google olur, twitter olur bir suru cozum var.

    yazilim gelistirerek gelir elde etmek eskisinden cok daha kolay ve hizli. baska hic bir yerde olmadigi gibi turkiye'de de bir silikon vadisi olmayacak, bosa beklemeyin. ama silikon vadisi'ne ihtiyaciniz olmadigini da bilerek bosa vakit kaybetmeyin.
  • insanın sağlığını bozan ve yavaş yavaş vücudunun içine eden iş. yaklaşık iki buçuk senedir yazılım geliştiriyorum ve şimdiden boyun ağrıları çekiyorum. göz kuruluğu, göz alerjisi, bilek uyuşması, beyin eyyorlaması da cabası. işimi severek yapıyorum ama bazen dayanılmaz olabiliyor.
  • yazılım dediğimiz maliyeti düşük, getirdiği gelir başarıya oranla eksponansiyel olan bir sektör, buna karşın ülkemizde yazılım demek, büyük firmalardan iş kapabilecek networke sahip olup, ağabey ayağı ile yükselmek, kiniklik, envai çeşit ofis politikası demektir. bu işle uğraşan hiçbir insan, köpek balıklarına bağlanarak onların artıklarını yiyen remora balıkları gibi yaşayarak gerçek anlamda iyi bir yazılımcı olamaz ama şirkette yükselebilir, maaşı artabilir, saygı ve mevki, itibar edinebilir. (ne pahasına? yalamak pahasına)

    iyi bir yazılımcı olmak ne demek ben bu işin ustası falan değilim, ama neyin nasıl olacağı gizli saklı değil. bana göre teorik bilgi (ki yazılımda bu pratik bilgiden pek de uzak değil) oldukça önemlidir mesela, ben yazayım, yanlış da olabilirim, kendi çevremde pek doğru kabul edilmeyen, ciddiye alınmayan bir adam olduğum için belki de bataklığın ortasında don kişotluk yapıyorum. veri yapıları, bunların uygulamaları yani implementasyonları (list, stack, queue, hash, binary tree, avl tree, b-tree,...) , yazılım desenleri (design patterns), concurrency (multithreading) ve oop paradigmaları (design patterns'e ek olarak solid) bunların başında gelir, bunlardan anlamayan bir senior developer, elbet işe yarar ama oradan çıkacak olan kodun kalitesi, dünya ile yarışacak düzeye gelemez, yapılan işler, büyük çapta verinin işlenmesi için verimli olamaz (bkz: best practice)

    piyasada on sene çalışmış bir yazılımcıya "lütfen söyler misin, ne zaman bir işlemi bir stored procudure ile database'den halletmemiz gerekir, ne zaman ve neye göre stored procudurekullanmak yerine dataları dao classlarıyla databaseden çekip kod içinde idare ederiz?" sorusuna aldığım cevap tamamen bunun yazılımcıya bağlı ve keyfi olduğuydu. ben buna katılmıyorum, katılmadığım bir çok şey var ayrıca. mesela bir projenin neye göre tasarlanacağı, design'ın tasarım incelikleri, design şemalarının neye göre oluşturulduğu, nelerin göz önünde hangi önceliklere göre bulunacağı,... işte bunların ne denli detaylandırıldığı, hangi senaryoların (kötü senaryo) göz önünde bulundurulmasına göre şekillendirildiği, o yazılımın performas ve kalitesini belirleyen unsurlardır. performansı belirler çünkü işlem yükünü doğru yerde database'e, doğru yerde koda atmak performansı doğrudan etkileyen bir şeydir. örnek vereyim, bir öğrenci sınıfımız olsun, ve bunların not ortalamalarını almak isteyelim, iki seçeneğimiz var. ya öğrenci objelerinin hepsini database'den çekip puanları toplayacağız, ya da database'de bu işlemi yapan bir query yazıp bunu çağıran bir kodun geri döndüğü değeri business logic'in kurulu olduğu yere yollayacağız. ilk seçenekteki sorun, öğrenci datasında istemediğimiz değerlerle şişen model objesinin hafızayı şişirmesidir. bunlara karar veremeyen bir yazılımcı, kod hammalıdır, ya da tecrübesi hammaliyet üzerine kuruludur, bu durumda gelişim, kodun kalitesi nerededir?

    diğer bir mesele ise kodun yazımıyla ilgili (naming convention'dan bahsetmiyorum), mesela kodun ne kadar modüler olacağı, neye göre parçalanacağı, class'ların birbirleriyle ilişkisi, hiyerarşisi... (bkz: uml) (bkz: entity relationship diagram) yazdığınız her kodun parçasının sorumluluk alanı, ileride başınızı derde sokmayacağınız bir şekilde yazılmalıdır, ister oop olsun, ister procedural farketmeksizin böyle bu. birden fazla işlevi gerçekleştiren bir fonksiyon ya da method, kod değişikliği gerektiğinde ya da müşteri tarafından bir change request, ya da feature istendiğinde, olması gerektiğinden fazla bir maliyete, dolayısıyla daha fazla kaynağın harcanmasına sebep olacaktır.

    sonuç olarak kötü tasarlanmış bir yazılım, zamana göreceli olarak eksponansiyel artan bir yozlaşmaya (bkz: entropi)(bkz: spagetti kod) sahiptir, saç baş yolduracaktır, yerli yersiz istekleri olan müşteriye , müşterinin böyle davranmasına izin veren analiste, o analisti oraya koyan patrona, ve bozuk tasarımı yazan dezayn sahibine küfürler ettirecektir. her neyse çok dallandım.

    sonuç olarak teknik mevzuatttan bahsettim, fakat ülkemizde ezici olarak bu teknik mevzuatın bir önemi, değeri yok. mesaide şunu yazıyorsam, bazı şeylere olan inancımı tamamen yitirdiğim için bu eleştiriyi buraya aktarmaya çalışıyorum. bunlar önemli olmayınca, junior developer'ların bir şey öğrenmesi, daha doğrusu şirketten bir şey öğrenmesi, kendini geliştirmesi, doğru pratikleri uygulayabilecek ortam bulması mümkün olmuyor.

    bir de teknik olarak hakim olan kişinin şirkette işlevsel olarak zayıf olması kadar moral bozucu, umut kırıcı bir şey yok. yani allami cihan diyeceğiniz bir adamın bile bazı şeylerdeki işleyişe içten içe öf pöf dediğini hissedince, bir şeylerin gerçekten ters gittiğini düşünüyorsunuz peki çözüm ne? a firmasına b firmasına bağlı bir şey değil bu, tüm ülkeye yayılmış bir kanser söz konusu.

    bir yandan firmalar iş aldıkça büyüyor, bu da kaliteli yazılımla değil, doğru kişilerle kurulan bağlantıya bağlı oluyor. network, mesleki teknik mevzuatı sollayınca da yozlaşma vuku buluyor, o zaman da ağabey ayağı çekenlerin, çakalların, sırtlanların hükmettiği allahın belası bir organizasyon şeklinin firmalardan bağımsız, yazılıma zarar veren bir yapı olduğunu, en azından bu ülkede işlerin böyle yürüdüğü için kaliteli işlerin sadece bireysel ve istisnai çabalarla ortaya çıktığını anlıyorsunuz, geçmişler olsun.
  • grup halinde yapılırsa karışıklık olabilecek olay. türkiyenin sorunlarından biride bu zaten. grup halinde iş yapmak kolay değil burada.
  • akarı kokarı olmayan, internete bağlı olmadan yapılması zor olan iştir.
  • yazılım geliştirme sürecinde bilgisiz bir yöneticinin mantığa aykırı, imkansıza yakın isteklerini gerçekleştirdikçe bilgi seviyeniz artar. muhtemelen sizden en zor yöntemi ister. siz onu basitleştirmek için kafa yorarsınız.

    o muhtemelen ortaya çıkan sanat eserine de mantıksız berbat diyecektir. herkesin fikri kendine özeldir bir şey demek kimseye düşmez de sen kalkıp androidin native calendarı için mantıksız olmuş çok yorucu dersen yazılımcı da napacağını şaşırır.

    bu durumları web tarafında yaşamış biri olarak bildirmek istedim.