Daha deneyimli geliştiricilerin yokluğunda, gerçek projeler üzerinde çalışırken becerilerimi nasıl geliştirebilirim? [kapalı]

C # ve ASP.Net ile çalışan küçük bir şirketin baş geliştiricisiyim. Ekibimiz küçük, 2-3 kişi, geliştirme ve tasarım konusunda fazla deneyime sahip değil. Daha üst düzey geliştiricilerden öğrenme fırsatım yok, ekibimde bana rehberlik edecek ve en iyi yaklaşımları seçmeme yardımcı olacak kimse yok, çünkü projelerin çoğuna kendim bakıyorum.

Daha deneyimli geliştiricilerin yokluğunda, gerçek projeler üzerinde çalışırken yazılım geliştirme becerilerimi nasıl geliştirebilirim?

Daha deneyimli meslektaşları bir araya getirecek birçok kaynak vardır: kitaplar, yetenekli geliştiricilerin blogları, Stack Exchange, konferanslar / konferanslar, vb. Kod incelemeleri de çok önemlidir ve CodeReview.SE değerli bir kaynaktır.

Bir örnek üzerinde nasıl çalışabileceğini görelim.

Misal

"ETL" teriminden bahseden bir blog yazısı okuyorsunuz . Bunun anlamını bilmiyorsunuz, ancak bu makaleden, bazı veri desteğinden diğerine veri taşıyan bir tür işlem veya iş akışı olduğunu belirsiz bir şekilde anlıyorsunuz.

Wikipedia'ya ve diğer kaynaklara gidersiniz ve daha net bir vizyon elde edersiniz . Ne zaman bir ETL kullanmanın yararlı olacağı henüz belli değil. Sonuçta, gerçek bir ETL oluşturmak için çok fazla zaman harcamak yerine, tüm işi yapacak bir SQL sorgusu yazmak çok daha kolay görünüyor.

Bu soruları cevaplamak için yerel kütüphanenizden ETL'ler hakkında bir kitap ödünç alıyorsunuz . Bazı özü-dönüştürme-yükleme işlemlerinin basit bir SQL sorgusu ile kolayca gerçekleştirilemediğini açıklar: sadece özütleme aşaması, sadece ilişkisel bir veritabanı değil, çeşitli, çeşitli veri destekleriyle de başa çıkamaz, aynı zamanda dönüşüm adımı için çok karmaşık olabilir. hem verileri doğrulamak / normalleştirmek hem de eşlemek.

Artık bir ETL'nin ne olduğu, nasıl kullanılacağı ve özellikle bir ETL'ye ihtiyacınız olduğunda ve uygun bir araç olmadığında net bir vizyonunuz var. Bu arada, kişisel bir proje olarak küçük bir ETL uyguladınız. Bu proje, sizin için yeterince açık olmayan ve bir kitap tarafından kapsanmayan bazı noktaları keşfetmenizi sağlar. Bu noktalar oldukça soyut ve kaynak koduyla ilgili değil, Programcılar'a bir soru gönderirsiniz .

Şirketinizde bir tane oluşturma fırsatınız olduğunda, onu yaratmaya başlarsınız. Birkaç sorununuz var. Bazıları kodla ilgilidir; Stack Overflow üzerine soru gönderirsiniz . Diğerleri veritabanı ile ilgilidir; DBA.SE ile ilgili soruları sorarsınız .

Son olarak, son derece yetenekli bir geliştirici tarafından ETL'lerin nasıl optimize edileceği hakkında bir konferans var . Bu konferansa katılıyorsunuz ve projeniz için yapabileceğiniz geliştirmeler hakkında size değerli ipuçları veriyor.

Yıllardır farklı ETL'ler üzerinde çalışan bir geliştiricinin blogunu da takip etmeye başlıyorsunuz . Farklı yaklaşımları görmek ilginç ve bu blog aracılığıyla ECCD hakkında bilgi ediniyorsunuz; ilgilendiğiniz için, "Çıkar, temizle, uydur ve teslim et" süreci hakkında ayrıntılı olarak konuşan kitap olan Ralph Kimball'ın Veri Ambarı ETL Araç Seti'ni ödünç alırsınız . Aynı blog, programlama becerileri olmadan ETL'ler oluşturmayı amaçlayan birçok uygulamadan da bahsediyor. Bu, özellikle şirketiniz için yaptığınız ETL için yararlıdır, çünkü patron olmayan, teknik olmayan bir kişi sürekli olarak yaptığınız şeyde küçük değişiklikler yapmanızı ister.

Bir şeyleri keşfetmek

IMHO, zor kısmı, bir akıl hocanız veya daha deneyimli bir meslektaşınız olmadığında, bir şeyler keşfetmek ve keşfetmekle, demek istediğim devletten “bu şeyi hiç duymadım” dan duydum ama ne olduğunu çok iyi bilmiyorum ".

Birisi kodumu inceler ve gerçekten bazı stil kurallarını kullanmaya başlamam gerektiğini söylüyorsa, biraz merakla programlamada farklı kod yazma stilleri olduğunu, belirli bir dil ve kod tabanı için bir stille yapışması gerektiğini, ve birçok dilde bir stili uygulamak için araçlar vardır (C # için StyleCop gibi).

Kimse bana stilden bahsetmezse, böyle bir şeyin var olduğunu nasıl bilebilirim?

Bloglar veya Stack Exchange gibi kaynaklar kullanışlı. Wikipedia yardımcı olmaz (günlerce programlama hakkında rastgele sayfalara çarpmadığınız sürece) ve kitaplar nadiren bu şeyler hakkında konuşur.

Aynısı, kodla daha az ilgili kalıplar ve uygulamalar veya şeyler için de geçerlidir. Örneğin, sabah erken uyanan bazı geliştiricilerin, ITIL hakkında daha önce hiç ITIL hakkında bilgi sahibi olmadığı halde ITIL hakkında bir şeyler öğrenmesi gerektiğini söylediğini hayal bile edemiyorum.

Yeni bir terim keşfettikten sonra , bunu öğrenmek oldukça kolaydır. Yeni bir terim "kod sözleşmeleri" verdiyseniz ve bir C # geliştiricisiyseniz, MSDN'de (veya daha iyisi Jon Skeet'in kitabında) kendiniz yeterli bilgiyi kolayca bulabilirsiniz.

Merak yardımcı olur

Stajyerlerle çalıştığımda her zaman en iyilerinin derslerinin dışında merak edenler olduğunu fark ettim. Öğretmenlerinden hiç bahsetmemiş olsa bile fonksiyonel programlama adı verilen bir şey olduğunu bilebilirler ve herhangi bir fonksiyonel dili bilmeseler de, genel anlamda FP'nin ne olduğunu ve diğerlerinden nasıl farklı olduğunu açıklayabilirler. paradigmalar. Agile veya Unicode veya kısmi güven / sandbox modeli hakkında bilgi sahibi olabilirler, çünkü sadece bloglara okuyorlar ve Stack Exchange'i kullanıyorlar, sadece derslerine katılıyorlar.

Bir akıl hocası olmasa bile, hala üniversitede söylenmeyen şeyleri öğrenirler.

Benzer bir durumdayım: küçük bir ekibiz ve temel geliştirme ürün çalışmalarımız çoğunlukla birkaç yıllık bir kod tabanındaki artımlı değişikliklerdir.

Güncel kalmak ve becerilerimi geliştirmek için kullandığım birkaç teknik.

İşte:

• Okuyun: kitaplar, bloglar, halkla ilişkiler materyalleri. Birkaç RSS beslemesini takip ediyorum. Günün O'Reilly anlaşması duymadığım bir teknolojiyle ilgiliyken kitabın açıklamasını okudum. Teknolojinin üzerinde çalıştığım herhangi bir şeyle çok fazla ilişkisi varsa, MainMa'nın cevabına benzer şekilde, beş veya on dakika biraz daha derinlemesine araştırıyorum. Bunu birkaç farklı RSS beslemesi ile tekrarlıyorum.
• Yönetiminizle şirket kaynaklarıyla (zaman ve / veya para) desteklenebilecek bir eğitim planı oluşturun
• Çoğu programcının eğilimlerinin aksine, değişimi ve yeni tasarım seçeneklerini benimsemeye çalışın. Değişim uğruna değişiklik iyi değil , ancak geliştiricilerin değişiklik nedeniyle yeni bir tasarım veya çerçeve kullanmaktan kaçındıklarına inanıyorum. Bu, yürümek için ince bir çizgidir ve bağlayıcı kararlara acele etmeyin, ancak yeni şeyler yapmanın yeni yollarına dikkat edin. Bazı değişikliklerin beklenmedik faydaları olabilir: DVCS'ye geçmek, kod tabanımızı daha kolay denememe ve yeni teknolojileri denememe olanak tanır.
• Bazı insanlar konferansları sever; Yatırılan süre için getirinin küçük olduğunu gördüm.

İş dışında:

Günlük işler dışında becerilerim üzerinde çalışmanın çok önemli olduğunu gördüm. Deneme, hata yapma ve çıkarları takip etme özgürlüğü beni BT ile meşgul ediyor. Sadece iş başında projelerim varsa ve öğrenmemi hemen faydalı olanlarla sınırlamam gerekirse, çabucak tükenirdim.

• İş dışı bir projeye katılın. Benim için bu kişisel ilgi ile ilgili işlevsel bir web sitesi geliştiriyor. Özgürce yeniden düşünürüm ve aktif olarak farklı teknolojileri denemeye çalışırım. Açık Kaynak'a katkıda bulunmak, başkalarının kodlarına da maruz kalmanızı sağlar. Bu ayrıca, daha deneyimli geliştiricilere sahip olacak şirketle görüşmeler için paylaşmanız için iyi bir malzeme sağlayacaktır.
• Kod Kampı: Bir varsa kod kamp sizin de alan görevlisi katıldı. Bunlar çalışma saatleri içinde olmadığı ve ücretsiz olduğu için sizi ilgilendiren konularla ilgili oturumlara katılma özgürlüğünü hissedersiniz. Tipik konferanslara kıyasla, bunlar genellikle yereldir ve teknolojinin geniş alanlarını kapsar, bu yüzden daha konsantre bir değer olduğuna inanıyorum.

SO ya da Programcıları da ziyaret etmeyi unutmayın.

Buradaki cevaplar büyük bir yardımcı olacaktır, ancak bir şeyi vurgulamak istiyorum: hiçbir şey, sizden daha iyi biriyle (keyfi ve kişisel, daha iyi tanımları için) haftanın 5 günü, günde 8 saat çalışmanın yerini tutamaz. Bu çok kesin.

Her zaman daha iyi olmak isteyen, her zaman öğrenmek isteyen bir geliştiriciyseniz, sonunda farklı bir şirkete gitmeniz gerekecektir. Bu kadarı kaçınılmazdır ve planlanması gerekir.

Sizin için doğru olan şirketi bulduğunuzda, şirket içinde büyümekten çok büyümeye devam edebileceğinizi göreceksiniz.

Yazılım geliştirme bir takım spordur. Bir spor gibi, çok yüksek bir seviyede oynamak için, aynı şeyi yapan başkalarıyla birlikte olmanız ve rekabet etmeniz gerekir. Hareket etme fırsatlarını arayın.

Uygulamanın kalıcı hale geldiğini unutmayın, bu yüzden sürekli olarak daha iyi teknik ve bilgiye doğru çalışmıyorsanız, eleştirmen veya rol modeli olmadan tek başına çalışıyorsanız, yeteneklerinizin büyümediğini görebilirsiniz.

Dünya çapında, işler daha rekabetçi hale geliyor, bu nedenle nişinizin geçici olmasını bekleyin ve işinizi tatmin etmek için kriterlerinizi karşılayan bir fırsat için hazırlanın, aynı zamanda sizi üstün bir ekiple çalışmak için konfor bölgenizin dışına götürün.

Herhangi bir öneriye gelmeden önce, bir yıl kadar önce çok benzer bir pozisyonda olduğumu söylemeliyim.

Projeleri tamamlıyorsanız, ancak iyileştirilecek çok yer olduğunu düşünüyorsanız, bu iyi bir şey.

Bir keresinde projeyi tamamlamak için teknik bir yeteneğim ve güvenim yoktu. Genellikle bir kitap satın alırdım, oldukça teknik bir blog okurdum ve kendimi "derinliğimden uzak bulurum". Benim için en büyük sorun, herhangi bir büyük kurumsal uygulamaya maruz kalmamamdı. Sıklıkla iyi bir şey yapardım, ama yaptığım şeyi doğrulamak için yanımda kimse olmazdı.

Bu motive edici ve zorlayıcıydı, bu yüzden nereden geldiğini görüyorum. Bu sorunu nasıl ele aldım? Bir şirketten ayrıldım ve iyi kurulmuş bir yazılım geliştirme evine katıldım, bu da geçen yıl çok fazla deneyim kazanmamı sağladı.

Şirketten ayrılmak istemediğiniz sürece, sektörümüzün öncüleri tarafından yazılmış kitaplar öneririm. Andrew Hunt'ın Pragmatik Programcısı ile başlardım. Kitap, hatırlanması çok kolay olan tonlarca faydalı analoji içeriyor. Bu kitabın ilk birkaç bölümü beni işyerinde kullandığımız dilden çok farklı bir programlama dili seçmeye teşvik etti. Teknik olmayan literatürü okumaya başladım - şimdi roman ve bilim kurgu okumak beni daha iyi bir programcı yapacağına inanıyorum. Deneme yazmak temiz kod yazmaktan uzak değildir. Bazı yazarlar iyi, bazıları kötü. Bu kitap bana yazdıklarımı önemsedi. Analojilerden birine "Bozuk Pencereler" denir. Günlerce sokakta terk edilmiş bir araba bırakıyorsunuz ve hiçbir şey olmuyor. Tek bir pencereyi kırdığınızda, araba muhtemelen ertesi gün imha edilecek. Kod farklı değil. Bozuk veya kötü yazılmış bir kod görürseniz, hemen düzeltin, sadece orada bırakmayın çünkü er ya da geç size "uğrak" olarak geri dönecektir. Bu kitapta çalışmaya başladığınızda, kod hakkında farklı bir şekilde düşünmenizi sağlayacak onlarca benzer analoji alacaksınız.

Daha sonra Robert C. Martin tarafından Temiz Kod'a geçmenizi öneririm. Bu kitap, sizi kötü ve iyi (temiz) kodu okumaya zorladığı için daha pratiktir. Yazar, açık kaynak projelerinden birinden kod örnekleri kullanır. Size rehberlik edecek kimse olmadığını söylüyorsunuz. Başka birinin koduna bakmak, kendi kodunuzla karşılaştırmak ve onu nasıl geliştirebileceğinizi görmek için mükemmel bir fırsat var. Bana göre bu kitabı okumak, bir proje üzerinde çalışan birini gölgelemek gibiydi. Kitap aynı zamanda en kolay şey olan endişelerin ayrılması üzerine de güçlü bir vurgu yapıyor. Yazar, sektörümüzün öncülerine ne “temiz” bir kod olduğunu düşündüklerini sordu. Yanıtlarını okuduktan sonra, bunları temiz kodun ne hakkında olduğu konusunda kendi görüşünüzle karşılaştırabilirsiniz.

Son olarak, açık kaynak projeleri üzerinde çalışmayı düşündünüz mü? Kodunuzu inceleyip sizi doğru yönde gösterebilecek, muhtemelen daha deneyimli diğer geliştiricilerle işbirliği yapacaksınız.

Orijinal cevabımda söylediğim gibi, gece boyunca olmayacak. Bunu birkaç yıldır yapıyorum ve neredeyse her gün yanlış yaptığımı öğreniyorum.

İyi şanslar!

Problem çözme alıştırmaları. Başkalarının kodunu anlamak için okuyun ve çalışın (github bunun için harika bir kaynaktır) ve geliştirmeler gönderin. Danışmanlık işi yapmak beceri setinizi genişletmenize gerçekten yardımcı olabilir.