yanlış anlamada, Yazdıkları kodlara başkaları baktığında, "Vay be, adam neler yapmış, helal olsun" denilmesinden hoşlanırlar. bu ne saçma bir sıralama. bende teknik bir şeyler sanmıştım. şimdi bu listeye uyan adının yanına jinyır mı yazdırabiliyor. hocam çok gereksiz birşeye takılmışsın. Benim takıldığım nokta müşteri için çalışan bir proje yapıyorum, müşteri dışardan bakınca oo süper diyor. Ama geliştirebilirlik yok, readability yok, scalability yok. Bana senior ya da junior demelerinden ziyade ya da bu listeye uymaktan ziyade bu konuları nasıl düzeltebilirim, neleri okumam gerekiyor. Bunları merak ediyorum. Ben kodu müşteri için yazmayı ğrendim şimdiye kadar, çünkü hep bireysel projelerim oldu. Ama takım çalışmasında yazdığın kodu diğer yazılımcıların da anlaması için, bir ortak büyük şeyler ortaya çıkarırken takımda olabilmek için bunların nasıl yapılabileceğini ğrenmek gerekiyormuş, bunu farkettim. Yanlış anlama, dkümantasyon paylaşmaktan ziyade yardım almak için paylaştım. Henüz dkümantasyon hazırlayıp insanları ynlendirecek seviyede bir yazılımcı değilim. Hello, i am nothing. I come from Neverland.

yanlış anlamada, Yazdıkları kodlara başkaları baktığında, "Vay be, adam neler yapmış, helal olsun" denilmesinden hoşlanırlar. bu ne saçma bir sıralama. bende teknik bir şeyler sanmıştım. şimdi bu listeye uyan adının yanına jinyır mı yazdırabiliyor. https://www.youtube.com/watch?v=WC3-71NKwPw

okuman lazım. başkalarının tecrübelerinden faydalanman lazım. hocam yanında çalıştığım üst düzey bir insan var, proje sorumlum. İkimiz yürütüyoruz projeleri fakat dkümantasyon olarak neleri okumam gerekiyor? Birkaç başlıkta sıralayabilir misiniz? Hello, i am nothing. I come from Neverland.

Uzman Junior Developer Senior Developer "Open Closed" bunlar için aç-kapa anlamına gelir. Yeni bir Change Request geldiğinde, yazdıkları eski kodu açıp, değişiklik yapıp, kapatırlar. "Open Closed" bunlar için, yazılan kod bir daha değiştirilmemek üzere kapanması anlamına gelir. Yeni bir Change Request geldiğinde, yazdıkları eski kodu dışarıdan Extend ederler. if-else yapıları ile araları çok iyidir. Hatta bunu programcılığın doğal bir parçası olarak grürler. if-else yapılarını sevmezler. Çok fazla if-else kullanımının hatalı tasarımın bir sonucu olduğuna inanırlar. Karşılaştıkları sorunlarda sürekli Amerika'yı yeniden keşfetme ve kendi yntemleri ile ilerleme eğilimleri vardır. Karşılaştıkları sorunlarda otoriteler tarafından kabul grmüş Best Practice'leri araştırma ve bunları kullanma eğilimleri vardır. Zamanlarının büyük çoğunluklarını, kendi geliştirdikleri çzümlerin sorunlarıyla ilgilenmekle geçirirler. Zamanlarının büyük çoğunluklarını, ünlü mimarların makalelerini okumak ve yeni çıkan mimari tasarımları incelemekle geçirirler. "En kısa yol en iyi bildiğin yoldur" szünü severler ve kendi çzümleri haricindeki çzümleri dışlama eğilimindedirler. "Her sorunun birden fazla doğru çzümü olabilir" szünü severler ve başkalarının getirdiği çzümlere sıcak yaklaşırlar. Yeni ğrendikleri bir tekniği, yazdıkları hemen her kodda uygulamaya çalışırlar. "Prensip" kelimesi ile "Kanun" kelimesi arasındaki farkı bilirler ve KISS prensibini, gerekmedikçe diğer prensiplerle değiştirmezler. Yazdıkları kodlara başkaları baktığında, "Vay be, adam neler yapmış, helal olsun" denilmesinden hoşlanırlar. Yazdıkları kodlara başkaları baktığında, "İş çok basitmiş, aktarıma bile gerek yok, ben devam ederim" denilmesinden hoşlanırlar. Kendi çzümlerindeki eksikleri bildikleri için, proje sürelerinin arkasında çok sağlam duramazlar ve genellikle başkalarının verdikleri sürelerde projeleri yetiştirmeye çalışırlar. Otoriteler tarafından kabul grmüş ve test edilmiş yntemleri kullandıkları için işin ne kadar süreceğini ve yolda ne gibi aksilikler çıkarak bunların nasıl çzüleceğini bilirler. Bu yüzden "Bu işin ederi budur, daha kısa sürede düzgün yapacak varsa gelsin" szünü sıkılmadan syleyebilirler. Dünyadaki diğer programcılar ile kendilerini kıyasladıklarında, bilgi ve başarı olarak %10'luk bir dilimde olduklarına inanırlar. Dünyadaki diğer programcılar ile kendilerini kıyasladıklarında, bilgi ve başarı olarak %40'lık bir dilimde olduklarına inanırlar. Alıntı : http://www.jskoleji.com/ Kendimi soldaki sınıfa koydum, hoş bazı noktaları biliyorum fakat bir türlü nasıl bu noktaları aşacağımı bilmiyorum. Mesela if-else yapısı aşırı kullanmamak gerektiğini ve yazdığım kodları ne kadar düzenli yazmaya çalışsam da bir noktadan sonra değişken isimlerinden tutunda fonksiyonlara kadar hepsinin isimlerinin birbirine girmesinin nüne geçemiyorum. Her ne kadar dikkat etsem de adamakıllı bir yapı kuramıyorum, proje başında yeterince planlama yapıyorum ama adeta satranç gibi nümdeki 5-6 sonraki hamleyi gremememden türü oluşturduğum yapı birbirine giriyor. Ve artık birşeye ihtiyaç duyduğumda yamalaya yamalaya yapmak zorunda kalıyorum. Sonra bir bakıyorum, bir tane değişken adı bile değiştirince program çalışmaz hale geliyor. Hal byle olunca; şimdi de sürekli o an daha iyisini düşünüp karala-sil yapa yapa, artık projede ilerleyemez duruma geliyorum. Bir metot yazıyorum, sonra aa bunu da eklesem daha düzgün olur diyorum, sonra bir başkası geliyor ve byle devam ediyor. Sonunda vardığım nokta başladığım nokta oluyor. Bu durumu aşmak için, neler yapabiliriz? Forumda bu işe yıllarını vermiş üstadlar var, onlar bir projeye başlarken ne gibi adımlar oluşturuyorlar kendilerine? Çalışma prensipleri neler? Mesela işe, Interface' leri abstract class' ları yazarak mı başlıyorlar? Teoride çoğu şeyi biliyorum, oop yapısını terimleri kullanıldıkları yerleri ama iş pratiğe gelince çuvallıyorum. Çünkü insanlar interface' yi mesela araç araba kamyon veya hayvanlar memeliler diye anlatıyor dkümanlar... Ama işin aslını bilmiyorum. Bu konuda yardımcı olabilecek üstadlar, biliyorum zamanınız çok değerli ama birkaç birşey yazarsanız en azından bir yol izlesem? Not: Yazdığım kodlar çalışıyor bir şekilde ama aşırı derecede mükemmelliyetçi bir insanım, bu da artık başımı ağrıtır oldu. Sürekli yazdığım her satırı defalarca düşünür hale geldim. Not 2 : Kullandığım yazılım dili DELPHI. Hello, i am nothing. I come from Neverland.

Bunları bu kadar kafanıza takmayın. Bir yazılımcı olarak dünyanın en nemli işini yaptığımızı düşünmüyorum. Diğer disiplinler gibi ortalama bir mühendis olmaktan daha fazla bir grevimiz yok. İşin edebiyatıyla bırakın başkaları uğraşsın biz de sessiz sedasız çzümler üretelim. Yazılım desenleri konusuna gelince: Bunlar aslında çok yeni şeyler değiller, sadece bize yeniler. Çzmeniz gereken sorunu doğru çzdüğünüze inanıyorsanız, bırakın yle kalsın. Mimari, makale, paratigma fetişisti olmamak lazım. Olaylara karışmayın!

okuman lazım. başkalarının tecrübelerinden faydalanman lazım. ftw

ncelikle uzman junior diye bir mevki yoktur. sadece junior vardır. Junior, bir seniorun huzurundayken, deniz kenarında durup, kendisi için takdir edilen rızkın sahile vurmasını bekleyen kişi gibi olmalıdır. Seniorun szlerinden gelecek feyzi bylesine dikkatli bir şekilde dinlemek, juniorun en nemli grevidir. Bylece seniorun fazlından kendisine gelecek nasibi alır. Nush ile uslanmayanı etmeli tekdir, Tekdir ile uslanmayanın hakkı ktektir!