Hiç yapmadığınız bir programlama görevi ile karşılaştığınızda ne yapmalısınız?

Kariyerime 3 ay önce .NET geliştiricisi olarak başladım ve çeşitli teknolojiler, kalıplar ve konseptler üzerine uzun bir eğitim planından sonra, beni denetleyen geliştiriciler şirketin yönettiği birçok projeden birine katılmaya hazır olduğuma karar verdim.

Sonunda kodlamaya başlayabilmem için çok heyecanlıyım. Katıldığım takım şu an için oldukça küçük çünkü yeni bir projeyle başlamıştı, çünkü harika çünkü projenin tüm yaşam döngüsüne dahil oluyorum. ASP.NET MVC / ASP.NET Web API'sını kullanan ve önünde Durandal çerçevesini ve ilgili kütüphaneleri destekleyen, web tabanlı bir SPA projesidir.

Benim sorunum, meslektaşlarımla bir toplantı yaptıktan ve gelecek ayki görev ve tahminleri belirledikten sonra, kendimi, herhangi bir görevi üstlenip üstlenemediğimi bilmediğim bir pozisyonda bulmam.

Oluşturulan görevlerin hiçbirini yapmadım ve nasıl devam etmem gerektiğini bilmiyorum.

Örneğin, oluşturulan görevlerden biri, tüm uygulama için genel bir hata işleme mekanizması oluşturmaktır.

İnsan hiç yapmadığı görevlerle karşılaştığında genellikle nasıl ilerler?

Görev için hazırlanmak için yapabileceğiniz ve yapmanız gereken birkaç şey var:

• Sorunu düşün ve bazı diyagramlar çiz. Sorunun ne olduğunu çözmeye çalıştığınızdan emin olun.
• Ne yapmaya çalıştığını araştır. İnternet değerli bir bilgi kaynağıdır. Yığın Taşması sorma demiyorum - Başkalarının sizinki gibi bir sorunu nasıl çözdüğü ya da ona nasıl yaklaştığı konusunda araştırma yapıyorum. Google'ın ortaya koyduğu şey şuydu: "İstisna, Sistem Çapında Endişe Olarak İşleme" . Şahsen ben her zaman başkalarından öğrenmeye çalışırım.
• Son olarak, ve bu en önemlisi olabilir, ne yapacağınız konusunda daha fazla netlik ve yön almak için ekibinizdeki diğer insanlarla konuşun. Her zaman yeni mühendislerin gelip projeler hakkında rehberlik istediklerini görmek istiyorum.

Bir şeyi nasıl yapacağını bilmemek asla bitmeyecek. Her gün daha önce hiç karşılaşmadığım problemlerle karşılaşıyorum. Yeni sorunların nasıl çözüleceğini çözme yeteneğine sahip olmak son derece önemlidir. Eski problemler bile asla eski değildir - programlamada, neredeyse her zaman yeni bir büküm veya çözümünüzün yeni veya farklı bir şekilde çalışması için bir istek vardır.

Bu yüzden ben mühendisim; Yeni şeyler çözmeye bayılırım.

Yeni şeyler öğrenmeyi asla bırakma. Öğrenme, seni daha iyi yapan şeydir.

Mükemmel bir çözüm yok, ancak yardımcı olabilecek bazı şeyler var:

• İşleri mümkün olan en küçük birimlere ayırın - yapabileceğiniz şeyleri alana kadar bunları bölün.

• Gerçekten anladığınızdan emin olmak için acil görev veya sorunu elinizde yeniden yazın. Sonra biraz analiz yapın ve tekrarlayın.

• İlk önce en basit işi seçin, sadece hız kazanamayacak kadar basit görünse de . Bazı insanlar en zor işi tercih eder, bu nedenle 'zor iş' ortadan kalkar. 'En basit görevin' genel olarak daha iyi çalıştığını keşfettim, çünkü sadece biraz ivme kazanmayı umuyorsunuz ve 'en zoru ilk' projenin gerçek bir ivme kazanmadan önce durma noktasına geldiğini gördüm.

• Başlamak için doğru görevi ve yaklaşımı seçme konusunda yardım isteyin.

• Bir ya da iki hafta boyunca size sürekli (ideal olarak günlük) geri bildirimde bulunabilecek bir mentor arayın.

• Çok fazla soru sorun, ancak takım arkadaşlarınıza kibar davranmaya odaklanın. Her zaman vakti olup olmadıklarını sorun ve normal sözlü ve sözsüz işaretlere o zaman vakti olmadığına dikkat edin.

• Karşılaştığınız sorunların bir listesini tutun ve sonra günlük olarak veya seçiminizin düzenli bir zamanında diğerleriyle birlikte gidin.

• En temel soruları sormaktan korkmayın. Başkaları tarafından yapılan varsayımlara itiraz etmek zor olabilir, ancak verilenlere devam edemiyorsanız tekrar sorgulamanız gerekir.

• Hedefi biliyorsanız, sıkışıp kalana kadar elinizden geleni yapın ve ardından Yığın Taşması ile ilgili ilerlemeyi ve soruyu gönderin.

Elbette "genel hata mekanizması" nasıl yazacağınızı bilmiyorsunuz. Bazı gereksinimler tanımlanana kadar hiç kimse bir "genel hata mekanizması" yazmayı bilmiyor. Sahip olduğun tek şey, birinin "genel bir hata mekanizması" nın bu projeyi başlatmak için gerekli olduğu düşüncesi olduğu gibi.

Şahsen ben bu fikre geri döneceğim. Gerçek kullanıcı gereksinimlerini uygulamadan önce "jenerik" bir şey yazmak neredeyse her zaman bir zaman kaybıdır. Ve genel olduğundan, tanım gereği şirketinize veya uygulamanıza özel değildir, bu nedenle muhtemelen ihtiyaçlarınızın yaklaşık% 95'ini karşılayabilecek bir şey vardır.

Fakat siz küçük üye olduğunuzdan geri çekilmek iyi bir fikir olmayabilir. Bu yüzden, "genel bir hata mekanizmasına" ihtiyaç duyduklarını düşünen insanlarla konuşmanız ve bu mekanizmanın ne gibi hizmetler beklediğini öğrenmeniz gerekir. Ardından, önceden yazılmış bir şeyin yeterli olup olmadığını görmek için net'i arayın. Bir şey bulursanız, basitçe kullanmayı teklif edin. Muhtemelen kabul etmiyorlar, çünkü "genel hata mekanizması" isteyen herkes burada icat edilmemiş kötü bir durumdan muzdariptir.

Bu başarısız olursa, bir sonraki adım hata mekanizması için bir arayüz tanımlamak ve paydaşlar tarafından onaylatmaktır. Bundan sonra, uygulama muhtemelen önemsiz olacaktır.

=================

Not: Herhangi bir projeye başlamanın yolunun, uygulama modüllerinin ihtiyaç duyacağı tüm ortak hizmetleri sağlayacak bir "platform" yazmak olduğunu düşünen bazı programcılar var. Bu genellikle zaten ücretsiz olan şeyleri yeniden icat eden aylarca önemsiz çalışmalara dönüşür. Mevcut çözümlerin performans sınırlarına ulaşana kadar, "platform" hizmetleri yazmak için hiçbir neden yoktur. Sarıcıları mevcut API'lerin etrafına yazmak için hiçbir neden yoktur. Sürekli refactor yaparsanız, uygulamanızın gerektirdiği tam sarıcı sihirli bir şekilde görünecektir.

Bence beceri eksikliğinden çok endişe çekiyorsun. Bir noktada, her şey yeni değil miydi? Size hiç bir görev verildi ve bir dereceye kadar çözemediniz mi? Bir şeyleri çözmek için para alıyorsun.

Takımınızı Kullanın - İyi bir takımdaysanız, yardım isteyebilmelisiniz. En yaşlıların bile bilmeyeceklerini bileceğin şeyler var. Yardım istemek, bir zayıflık işareti değildir (bazı soru sitelerine koşmaktan başka bir şey değildir).

Arama - Genel hata işlemeyle ilgili bir web araması hiçbir şeyle sonuçlanmadı mı? Çözümün tamamını bulamayabilirsiniz. Bunun üzerinde çalışmanız ve uygulamanıza zaten uydurmanız gerekecek.

Prototip - Üretimden prototipe kadar görev konusundaki bakış açınızı değiştirin. Sadece çalışmak ve oradan inşa etmek için bir şeyler olsun. Onu elde ettiğiniz noktaya ulaştığınızda, onu üretim olarak düşünmeye başlayın. Artık görevi nereden başlayacağınızı bile bilmediğiniz bir şey olarak görmeyeceksiniz.

Üstesinden gelin - Yalnızca yapmayı bildiğiniz şeyleri yapmak sıkıcı olacaktır. Ayrıca, aynı şeyleri tekrar tekrar tekrar ederek bazı çözümleri zorla bir kaba kaba tuzağa düşürür (Bir şeyi tekrarlamaktan hoşlanıyorsanız, bir montaj hattında çalışın.). Hata yapmaya hazır olun. Size her şeyi bildiklerini, asla yardım istemediğini veya arama yapmadığını söyleyenler sadece yalan söylüyor.

Doktorların hala ilaçları "pratiği" yapan eski şakası; Onlar da tüm cevaplara sahip değiller.

Daha önce yüzlerce kez yaptığınız bir şeyi yapmadığınız için sevinin. Yazılım geliştirme sevincini (benim için, her neyse, YMMV) buldunuz - otoyolda olağanüstü hızlarda ilerlerken nasıl sürüleceğini öğreniyorsunuz. Bu, büyük bir geliştiricinin yaşadığı ve yaşadığı türden bir şey.

Kişisel işlemim böyle bir şey:

• Araştırma. Bu sorunun veya benzer bir sorunun daha önce çözülüp çözülmediğini ve nasıl çözüldüğünü öğrenin. Yalnızca farklı diller veya platformlar için çözümler hakkında bilgi bulabilseniz bile, son derece bilgilendirici olabilir.
• Prototip. Bir şeyi doğru yapmanın en iyi yolu, önce yanlış yapmaktır. Araştırmanıza dayanarak, istediğiniz gibi her şeyi yaparak bir çözüm oluşturun. Yardımcı gereklilikleri dikkate alarak ana gereklilikleri yerine getirmeye çalışın. Güzel ya da mükemmel ya da genişletilebilir ya da esnek ya da performans göstererek zahmet etmeyin, sadece çalışmasını sağlayın. Alınan dersleri not alın - neyin işe yaradığını, neyin işe yaramadığını, olası barikatları vb. Çok uzun süren bir aptal aramaktan endişeleniyorsanız, bunu kendi zamanında yapın. Bilgi açısından kişisel olarak size fayda sağlar.
• Tasarlayın. Dış bilginizi (araştırma) kişisel bilgilerinizle birleştirin (prototip dersleri alındı) ve bunu yapmanın doğru yöntem olacağını düşündüğünüzün tasarımını formüle edin.
• İşbirliği yapın. Üst düzey bir ekip üyesi bulun, önerdiğiniz tasarımı gösterin, geri bildirim alın. Bir başkasına göster, geri bildirimlerini al. Tasarımınızı geliştirin.
• Uygulayın. Çözümünüzden hala emin değilseniz, meslektaş değerlendirmelerinin yineleme döngüsünün bir parçası olduğundan emin olun. Uygulamanızı geribildirim için düzenli olarak kıdemli bir ekip üyesine getirin.
• Mutlu olun - bilginizi ve kariyerinizi geliştirdiniz ve daha önce bin kez yaptığınız eski ve sıkıcı bir şey yerine yeni ve ilginç bir şey yapmalısınız. Bir sonraki projenizi daha da büyük bir sorun haline getirmeye çalışın.

Ve son olarak, görünüş hakkında fazla endişelenme. Dev bir ekip yöneticisi olarak, şu anda yapmaya çalıştığımız şeyi zaten bildiklerini ispatlayabilecek birini, ihtiyaç duyduklarında öğrenmeleri gereken her şeyi öğrenebileceklerini ispatlayabilen birini tercih ederim. Birincisi, yarın veya gelecek ay veya gelecek yıl ne yaparsak yapalım daha iyi olacak.