Forum
Aktif konular
Üyeler
Kurallar
Arama
Tahribat.com Forumları 
Yazılımlar / Diğer Programlar 
Uzman Junior İle Senior Arasındaki Farklar Ve Ne Yapmam Gerek? Uzman Junior İle Senior Arasındaki Farklar Ve Ne Yapmam Gerek?
-
Uzman Junior DeveloperSenior 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 görü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 yöntemleri ile ilerleme eğilimleri vardır.
- Karşılaştıkları sorunlarda otoriteler tarafından kabul görmüş 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" sözünü severler ve kendi çözümleri haricindeki çözümleri dışlama eğilimindedirler.
- "Her sorunun birden fazla doğru çözümü olabilir" sözü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 görmüş ve test edilmiş yöntemleri 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" sözünü sıkılmadan söyleyebilirler.
- 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 göremememden ö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 böyle 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 böyle 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 dökü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.
-
okuman lazım. başkalarının tecrübelerinden faydalanman lazım.
-
tagext bunu yazdı
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 dökümantasyon olarak neleri okumam gerekiyor? Birkaç başlıkta sıralayabilir misiniz?
-
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.
-
zeybekustasi bunu yazdı
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, dökümantasyon paylaşmaktan ziyade yardım almak için paylaştım. Henüz dökümantasyon hazırlayıp insanları yönlendirecek seviyede bir yazılımcı değilim.
-
Ö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 sözlerinden gelecek feyzi böylesine dikkatli bir şekilde dinlemek, juniorun en önemli görevidir. Böylece seniorun fazlından kendisine gelecek nasibi alır. -
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 görevimiz 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.
Kısayol
Şikayet
Özel Mesaj
Alıntı yap
Cevapla