Sürekli kod örnekleri mi arıyorsun, kötü bir geliştiricinin işareti mi? [kapalı]

C ve C ++ 'ta birkaç yıl deneyime sahip bir CS öğrencisiyim ve son birkaç yıldır sürekli olarak Java / Objective C ile uygulama geliştirmeye çalışıyorum ve şimdi web geliştirmeye geçtim ve temelde yakut üzerinde duruldum raylar ve ben (uygulama geliştirmede olduğu gibi) başka bir koda çok fazla başvuru yaptığımın farkına vardım. Sürekli olarak Google işlevini sıfırdan başarabilmem gerektiğini düşündüğüm birçok şey için yapıyorum ve bu kendime olan güvenimi biraz kırdı.

Temel temeller bir sorun değil, bunu örnek olarak kullanmaktan nefret ediyorum ama javabat'ı her iki java / python'da bir sprintte çalıştırabilirim - açıkçası bir başarı değil ve ama demek istediğim, temeller için güçlü bir temelim var Bence?

Genelde neye ihtiyacım olduğunu biliyorum, fakat sürekli referans sözdizimi. Derecemi bitiriyor olmama rağmen, bu alanda iş aramak konusunda beni oldukça katı tuttuğu için, bazı tavsiyelere ve girdilere bayılırım. Sormamın asıl sebebi aslında istihdam ile ilgili değil, fakat daha çok, sürekli kod çözmeyen, 20 tane Google / Github sekmesi olan ve orada oturan bir hackathondaki tek erkek olmak istemiyorum. hafif bir güven eksikliği yüzünden ...

Bir kişi sürekli olarak orta ila karmaşık işler için kod örnekleri arayarak kötü bir geliştirici mi?

Kör kopyala-yapıştır: kötü.

Daha iyi anlaşılması için belgelere bakın, kod örneklerini okuyun: iyi.

Her zaman her şeyi araştıran ve her şeyi bildiğini sanan, her şeyi bildiğini sanan ve kendisinin bilmediğini düşünen biri gibi çalışmasını tercih ederim. Ancak en kötüsü, işlerin nasıl yürüdüğünü anlama zahmetine girmeyen ve yalnızca web üzerinden kodunuzu eleştirmeden kopyalayan bir kişidir (ve daha sonra hata raporları yağmaya başladığında hiçbir şeyi düzgün bir şekilde çözemez).

Çözümlerinizi sürdürülebilir bir şekilde kodlarsanız ve gerçekte kopyaladığınız / yapıştırdığınız / değiştirdiğiniz şeyleri ANLAYIŞTIRSINIZ, sorun olmaz.

Ne zaman ve neden "Bilmiyorum, kodu yapıştırdım ve belirtilen zamanda çalıştı" yanıtı hakkında neden bir üst düzey geliştiriciye sorular sorduğumda ölüyorum.

Sadece beceri ile mi / çıkış API belgeleri ile programlamak , kod örnekleri arayan kötü bir programcı bir işareti olduğunu, ancak birinin kim yoksun akıcılık ...

... Burada akıcılıktan bahsediyorum. Sadece akıcı bir şey yapma yeteneğine sahip değil .

Akıcı olmanın ne olduğunu biliyor musun? Sana bakan birisi için yazdığın gibi kod yazıyormuşsun gibi ...

• ... Sanki doğru kod parmaklarınızdan ekrana akıyor. API belgelerini, dersleri ve kılavuzları kontrol etmiyormuşsunuz gibi. Aslında, bunu hepsini kontrol, ama kafanın içinde oldugu için görünmez. İhtiyacınız olan tüm bilgiyi beyninizde bulabilirsiniz - şarjlı, dolu ve kullanıma hazır.

... Bu akıcı bilgidir. Bir saatte acemi çekeni yapmak için bir dakikanızı alırken. Gerçekten çabaya değer. Zafer gibi kokuyor.

... ve uygulama bana akıcılık kazanmanın tek güvenilir yoludur.

Kolb döngüsü adı verilen bir öğrenme teorisi var (onu tanımlayandan sonra). Bu döngüdeki girişler:

Concrete experience -> Reflective observation
    ^                        |
    |                        v
Active experimentation <- Abstract conceptualisation

Farklı insanlar, döngünün farklı yerlerinden başlamak ister. Bu yüzden öğrenme edilecek tamamen mümkün tarafından daha sonra soyutlama yoluyla büyük resmi için bu örneklerden çalışma dışarı, örneklerin (yansıtıcı gözlem aşaması) arıyorum.

Diğer insanlar farklı şekillerde öğreneceklerdir: bazı insanlar deneyerek başlamakla (yani deneyle), sonra neyin doğru neyin yanlış gittiğini düşünmekten hoşlanırlar. Mesele şu ki, bunlar sadece şeyleri öğrenme problemine saldırmanın farklı yollarıdır: hiçbiri yanlış değildir.

Tam açıklama - İş çağında mevcut farklı bir İnternet öncesi eğitim almış yaşlı bir insanım. Genç geliştiricilerin becerilerinin, çoğunlukla bilgileri ellerinde tutmadıkları veya İnternet'ten elde ettikleri çözümü anlamadıkları için sürekli olarak bozulmalarını izledim. Bir kişinin, 20 yıl önceki 1-2 yıllık deneyimden sonra sahip olduğu yetkinlik düzeyinin, şimdi birinin, 5-7 yıllık deneyimden sonra sahip olduğu yetkinlik düzeyi olduğunu gözlemledim. (Evet, bu kişisel bir gözlem ama ben çok işe aldım, konuyla ilgili istatistiki verilerim yok ve evet, bazen yaşlı ve huysuzum, bu ifadeyi bir tuz tuzu ile alıyorum. Ve bahçemden uzak durun. )

Her şeyi aramak zaman açısından verimsizdir. Aynı zamanda çok fazla bilgiye sahip olmayan birinin bir belirtisidir. Bilgi birikimi derinliği olan insanlar, bir sorunu çözmeden bilmeyenlere göre daha hızlı kod yazabilir. Bu yüzden sürekli bir şeyler aramak zorunda kalmadan daha fazla şeyle başa çıkmayı öğrenmeye değer.

Şimdi hiçbir şey aramamanız gerektiğini söylemiyorum, bilgiyi korumayı öğrenmeniz gerektiğini ve yalnızca nadiren kullandığınız şeyleri veya gerçekten yeni bir konu veya dil veya paradigma ile karşılaştığınızda bakmanız gerektiğini söylüyorum. Ve yeni çözümlere, araçlara ve dillere ayak uydurmak için okumamalısınız.

Çok fazla şey arayan geliştiricilere duyduğum asıl endişem, çoğu zaman (mutlaka siz değil) sahip oldukları sorunları ve ihtiyaç duydukları çözümleri anlamak için asla analitik beceriler geliştirmemeleridir. Kişinin, açıkça anlayamadığı, ancak profesyonel düzeyde çalışan herkes için açıkça anlaşılması gereken bir hata iletisine koyduğu kaç soru olduğunu okuyun. Veya kişinin söylediği "işe yaramıyor, neden?" hata mesajına veya nasıl çalışmadığına ve kodun sözdizimsel olarak doğru olup olmadığına bakmadan. Veya çalışması gereken bir kod parçası olanlara,

Eğer aradığınız şey, dil (ler) in temel işlevselliğinin bir parçası olan şeyler (BTW, altı aydan uzun bir süredir kullandığınız SQL veritabanını da içermeli, SQL olmalıdır) çok. Eğer aradığınız şey gelişmiş özellikler, özellikle de nadiren kullanabileceğiniz özelliklerse, o zaman para cezası alırsınız.

Fakat daha fazla bilgiyi korumayı nasıl öğrenirsiniz? İlk önce kodun neden kırıldığını anlayın. Biri size bir çalışma çözümü verse bile, bunun neden işe yaradığını ve sizinki çalışmadığını göremiyorsanız sorun. Hata mesajını anlamıyorsanız, ne anlama geldiğini sorun ve ardından kendiniz çözmeye çalışın.

Ve asla anlamadığınız bir çözümü kesip yapıştırın. Aslında, kesme ve yapıştırma. Bilgiyi saklamak istiyorsanız, yazarak yazmanız gerekir. Aslında kodu fiziksel olarak kendiniz yazmak, öğrenmenize yardımcı olur. Bu iyi bilinen bir öğrenme tekniğidir.

Kod anlayışınızı genelleştirme alıştırması yapın. İnsanların zaman zaman tekrar tekrar benzer sorular sorduklarını gördüm, çünkü bir ay önce ABC problemine çözdükleri çözüme DEF probleminin aynı çözümü olduğunu anlamıyorlar.

Bu yüzden, bir şeyi araştırdığınızda, ne tür problemleri çözmenin ve bunun hakkında kendinize not almanın iyi olacağını düşünmek için biraz zaman ayırın. O zaman çözülecek bir probleminiz olduğunda, önce olası bir tekniği not aldığınızı görmek için kendi notlarınızı kontrol edin. Bir sorunu çözmek için birden fazla yol değerlendirirseniz, sorunun türü, baktığınız olası çözümler ve her birinin avantaj ve dezavantajları hakkında not alın. Yine not almak beyninizdeki bilgiyi sağlamlaştırmanıza yardımcı olmaktır, zaten artıları ve eksileri konusunda kendi düşünce sürecinize sahipsiniz ve bunu bir daha yapmak zorunda kalmazsınız (veya en azından bu kadar derinlemesine değil). Bir sonraki benzer problem için hala daha olası teknikleri araştırın).

Daha sonra ne öğreneceğinize karar verirken, başka bir teknolojiye değer olan ilk 30 günü öğrenmeye başlamadan önce ana teknolojilerinizden birinde biraz derinliğe gidin (bu, eğer gerekliyse, işinizi gerçekten gerçekleştirmek için yeterli miktarda bilgiye sahip olduğunuzu varsayar) 6 teknolojiyi kullanın - derinliğe gitmeden önce ilk önce altıdaki bilgileri edinin). Sonra ileri geri gidin, temel düzeyde yeni şeyler öğrenmek, daha derinlemesine bir şey öğrenmek, daha sonra temel düzeyde daha yeni teknolojiler öğrenmek. Zamanla bunu yaparsanız, yeni bir teknolojiden ne istediğinizi temel seviyenizin daha derin olduğunu göreceksiniz çünkü bunun hakkında sorulacak daha gelişmiş soruları anlıyorsunuz.

Bilgiyi korumayı öğrenmenin bir başka yolu, onu başkalarına öğretmektir. Bu gibi yerlerde soruları yanıtlayın, ekibinize eğitim konuları sunun, yerel kullanıcı gruplarınızda sunumlar yapın, blog girişleri yazın ve şirketinizde diğer geliştiricilere yardımcı olmak için bir bilgi wiki'si tutmanıza yardımcı olun.

Kod örnekleri aramak kötü bir geliştiricinin işareti değildir. Kişi nadiren ihtiyaç duydukları tüm arayüzleri hatırlamak için çok az şeye ihtiyaç duyar, bu yüzden bazı şeyleri araştırmak doğaldır ve kod örnekleri genellikle kullanımı en kolay referanstır.

Yapmamanız gereken, örnekleri kopyalayıp yapıştırmak, çünkü orada çalışıyorlar, nasıl çalıştıklarını anlamadan da burada çalışmalılar. Bu, genellikle tesadüfen kopyalanacak birçok yararsız bit sonucuna yol açar, çünkü sonucu korumak zorlaşır, çünkü bunu yazarken nasıl çalıştığını bilmiyorsanız, altı ay sonra da bilmezsiniz ve yapamazsınız düzelt.

Ancak bir örnekten kopyaladığınız kodu anladığınız sürece, işi daha hızlı halletmek için geçerli bir yoldur ve bu genellikle iyi bir şeydir.

Bu cevaplar oldukça iyi. Ancak, kopyala / yapıştır veya "beceri" eksikliğinden çok daha derin bir probleminiz var.

Karşılaştırma öldürücüdür. Kendinizi diğer insanlarla karşılaştırdıkça ve yeteneklerinin kendinizi görme şeklinizi etkilemesine izin verdikçe, daha fazla buruşup içeride ölürsünüz. İnsanların ne kadar yeteneksiz olduğunu görecekleri korkusuyla hackathonlara gitmiyorsun . Ve yeteneksiz olduğunu düşünmenin tek nedeni, kendini sıfırdan daha fazla kod çıkarabilecek hacker'larla karşılaştırman, çünkü daha hızlı.

“Dakikadaki Kod Satırı” beceriyi ölçmek için iyi bir ölçü olsa bile, orada her zaman senden daha iyi geliştiriciler olacağı gerçeğini kabul etmen gerekir . Ve bu ok Eğer beceri eksikliği başkalarına göstermenin.

Başkası kadar iyi ya da daha iyi olmanıza gerek yok. Her zaman bir şekilde eksik kalacağınız ve sürekli öğrendiğinizden memnun olmanız gerekir. Düşük bir geliştirici olmaktan memnun olamazsanız, ASLA mutlu olamazsınız.

Bir şey daha: "üstün" olduğunu düşündüğünüz insanlar tarafından reddedilme korkunuz, sizi daha iyi geliştiricilerle omuzlarınızı ovuşturmaktan ve onlardan ders almaktan alıkoyan şeydir. Böylece korkunuz büyümenizi önler ve bu da korkunuzu korur. Bu senin büyümeni engelliyor. Döngüyü görüyor musun? Bir yerde bu döngüyü kırmalısın.

Bence çoğu, zihninizin nasıl çalıştığına bağlı. Hafızam kokuyor, bu yüzden istediğime en yakın olan kodu alıp, yeni işi yapabilmek için elden geçirmeyi tercih ederim. Yapmam gereken her şeyin bir örneği ve hatırlatıcısı olarak hizmet ediyor. Örneğin, 20 yıl boyunca basit SQL kullandım, ancak bir SELECT veya UPDATE deyiminin düzenini asla hatırlayamıyorum. (Birinin parantez içerdiğini düşünüyorum ama hangisini hatırlayamıyorum.) Öte yandan, hatırlayabildiğim birkaç şey var; Java Iterator uygulamasını gözüm kapalıyken bir araya getirebilirim.

Kopyaladığım kodların çoğu bana ait, ancak kesinlikle yeni bir şeyler öğrendiğimde diğerlerinin kopyalarını yapıyorum.

Hacktanlar hakkında bir şey bilmiyorum. Fotografik hafızası olan bir grup programcıdan faydalanabilirler. Bir deneyip göreceğim. Bir salak gibi görünmek seni rahatsız ediyorsa, programlama yapmamalısın.

Tamamen, kopyaladığınız ve değiştirdiğiniz tüm kodları anlamanızı tavsiye ederim, ancak diğer cevapların bazılarını okuyana kadar, birisinin anlamadan kopyalayabileceği bir başıma asla gelmedi. (Bu sitede her zaman yeni mengene öğreniyor gibiyim ...)

... farkına vardım ki ... başka bir kod wayyyy'e çok fazla atıfta bulunuyorum. Sıfırdan yapabilmem gerektiğini düşündüğüm birçok şey için sürekli olarak işlevselliği google'a götürüyorum ve bu kendime olan güvenimi biraz kırdı.

O zaman dur. Bir süre diğer yöne doğru gidin. Gereksinim duyduğunuz şeyi daha az zamanda bulabileceğinizi bilseniz bile, her şeyi kendiniz uygulayın .

Olan şu ki, problem çözme kasınızın (Latince adı gluteus mojo ) kullanımdan kurtulduğu ve şimdi onu kullanmaktan kaçındığınız için ne kadar zayıf olduğunu biliyorsunuz. Spor salonunda pazı üzerinde çalıştığınız gibi o kası kurmaya ve güçlendirmeye başlamanız gerekir. Yüksek tekrarlar ve düşük dirençle başlayın - çok kolay problem. Biraz güven oluştururken, daha uzun, daha zor sorunlara geçin.

Mojo dönüşünüzü yavaş yavaş hissedeceksiniz ve Google’a güvenmeniz gerekecek. Yine de o kası kullanmaya devam et ve eski yöntemlerine geri dönmediğinden emin ol. Önce bir sorunu çözmek için kendinize sorun , ancak daha sonra diğer çözümleri araştırın. Bazen başkalarının da aynı şeyi yapmanın daha iyi bir yolunu bulduğunu görürsünüz, bazen de kendi çözümünüzün daha iyi olduğuna karar verirsiniz.

Bir kişi sürekli olarak orta ila karmaşık işler için kod örnekleri arayarak kötü bir geliştirici mi?

Örnekleri bulmadan hiçbir şey yapamayan bir kişi kötü bir geliştiricidir. Mesele şu ki: deneyene kadar yapıp yapamayacağınızı bilemezsiniz.

Gençsin ve birçok programlama dili ile çalıştın. Tahmin ediyorum ki, muhtemelen yeni dilleri eski dillerden daha hızlı öğreneceksiniz. Akıcılık geliştirmek için yeterince büyük bir uygulama için tek bir dile hala yeterli zaman ayırmadınız.

Her zaman aşağıdaki gibi geniş çözümler mi arıyorsunuz: bir web ızgarasını bir veritabanı tablosuna bağlama sürecinin tamamı veya bağlantı dizesini biçimlendirme gibi daha küçük bir parça (her yıl yaklaşık dört kez yazdığımdan beri her zaman bu konuyu aramalıyım.) )?

Her zaman farklı kod veya işlev satırlarının sözdizimine referansları arayacaksınız. Programınız arttıkça, karşılaştığınız zorluklar, farklı ortamlar ve dil değişiklikleri de artar. Her zaman bir şey yaptığınızda tüm bir eğiticiye ihtiyacınız varsa, o zaman bir sorununuz olur.

Eskiden bir gece topladığınız birçok bilgiyi saklamaya dayanan testler yapmaktan nefret ettiğini söyleyen bir profesörüm vardı, çünkü yine de birçoğunu unutuyorsunuz. Kaynaklarınızı bilmek ve bilmediğiniz bilgileri bulmak için bunları doğru şekilde kullanmanız daha iyidir. İş dahil, yaptığım her şeye benzer bir prensip uygulamaktan hoşlanıyorum.

Bence doğru kullandığınız sürece sahip olduğunuz en önemli araçların sizin kaynaklarınız olduğunu düşünüyorum. Bu yüzden, kod yazarken, mevcut bilgileri bildiğim kadarıyla alıyorum ve uygun çözümü daha iyi anlayabilmek için diğer programcılara sorarak veya İnternet'te araştırma yaparak araştırma yapıyorum. Bilgi zamanla gelişecek ve bir süre sonra doğal olarak becerileri daha iyi bilecek ve anlayacaksınız. Bilgiye gerçekten ihtiyacım olup olmadığına bakmaya devam ediyorum ve dürüstçe söyleyebilirim ki her gün yeni bir şeyler öğrendiğimi söyleyebilirim.

Çözmeye çalıştığınız sorunu anlıyorsanız ve nasıl çözmek istediğinizi anlıyorsanız, doğru sözdizimini bulmak bence çok da önemli değil.

İki yıl önce mezun oldum ve işimi aldığımda kurtlara atıldım. Daha önce hiç dokunmadığım bir dilde yazılmış büyük bir uygulamayı öğrenmek, sürdürmek ve yükseltmek zorunda kaldım. Bir hata raporu alırdım, kodu gözden geçirir ve nasıl düzeltmek istediğimi bulurdum, sonra da bu dilde istediğim şeylerin nasıl yapılacağına ilişkin google örnekleri bulmam gerekirdi.

İşleri bitiriyorsanız ve gereksiz karmaşa üretmemek için yeterince anlıyorsanız, muhtemelen sorun yok demektir.

Kritik olmayan kopyala ve kopyala yapıştır bu cevaplarda defalarca belirtildiği gibi. Ama herşeyi sıfırdan yazmak da öyle. İşletmenizin özü olan kritik bir bileşen değilse, önce bunu yapmak için bir kütüphane veya kod pasajı arayın. Bir pasajı bulmanın istisnası, sorunun çok basit olması, bunun nasıl yapılacağı konusunda çok net bir resme sahip olmanız ve bir kitaplık kullanmamanız durumunda: başka bir şey yapmanıza gerek kalmayacağınızdır.

Yaygın olarak bilinen bir şey yazarsam şahsen biliyorum, çok fazla test etmeden bazı ince böcekler ve belki de bir veya iki tane çok ince olmayanlar olabilir. Bu yüzden benzer bir çözüm ararım, üzerinde test ve geliştirme konusunda zaman kazanmak için bunu değiştirir ve test ederim. Çünkü sonunda, çalışan, genişletilebilir, bütçe dahilinde veya altında olan ve teslim tarihlerini karşılayan bir ürün sunmaktan sorumluyum. Kod ve kitaplıkları tekrar kullanmak bu amaca doğru atılmış iyi bir adımdır.

Kod örneklerini okumak ve diğer insanların genel olarak geliştirdiklerinin kaynak kodunu okumak, becerilerinizi geliştirmenin en iyi yoludur. Gerçekten beyninde başka türlü açılmayacak kapıları açtığını düşünüyorum.

Bir çözüm A düşünürseniz ve bir başkası B çözümünü düşünürse, her biriniz çözümlerinizi paylaştığınızda, A veya B'den bile daha iyi olabilecek C çözümünü gerçekleştirebilirsiniz.

Birçok yazılım geliştirme uzmanlığı seviyesi olduğunu düşünüyorum. Sadece öyle, çünkü birçok yazılım geliştirme belgelendirme yeterliliği de var. Açıkçası, bu günlerde, sistemler 1980'lerin ortalarında bilgisayar programlamaya başladığımdan daha karmaşık bir emirdir.

Daha sonra, bilgisayarın ne yapmasını istediğinizi bilmek zorundaydınız ve 6 inç kalınlığında belgeler yazıp bilgisayarın nasıl daha temel şeyler yaptığını anlatan bir yazı yazdınız. İstediğiniz şeyi bilgisayarın alabileceği bir forma sokmak, bu kitapların indekslerinin içeriğini ve bir programlama dilini bilmekle ilgili bir sorun (ya da iki. Gerçekten de, dört ya da beş dil öğrendikten sonra diğerleri sadece lehçelerdir).

Günümüzde, bu görev bir dil bilmek, bir sistem bilmek, bir paradigma bilmek, bir programlama modeli ve hepsi hareketli hedefler olan en az bir API seti gerektirir.

Bu yüzden, etrafta soran belli bir temel düzeyde bilgiye sahip bir insan iyi bir programcı değildir. O ise iyi bugünün ortamları göz önüne alındığında, programcı tür ve Microsoft gibi ilgisizliği firmalar aslında kendi temelleri belgelerine titizlik her türlü uygulamada var. Eşyalarının çoğu kendi kendine referans materyali ve bazı çok kötü örnek kodlar. (Karşılaştığım iki konu, "Windows Installer" ve WMV film dosyaları oluşturmak için kullanılan API'ler.)

Çünkü Microsoft, Google ve bir dereceye kadar Apple, hepsi bu gerçek eksikliği telafi etmek için “topluluğa” güveniyor, etrafta sormak sadece önemli değil, hayati öneme sahip. Ve sorulabilen ve bugünün ortamında sağlam cevaplar ve geribildirimler veren bir kişi olmak da çok önemlidir. Gibi siteler yüzden stackexchange.com siteleri onlar kadar faydalıdır.

Yani soru sormak, numuneler için (! Akıllıca sormak) ve cevapları tedarik insanlara saygı ve böylece isteğini yerine değil "kötü geliştirici" bir işareti olarak görülebilir.

Ve bir şey daha: Kötü örnekler vermek, kötü bir geliştiricinin işaretidir. Kötü geliştiricilerin fark edilmesini kolaylaştırır, ancak aynı zamanda google aramaları düzenler. Basit, anlaşılır, spesifik kod örneklerine güven duymuyorsanız, vermeyin.

Ve lütfen, soranlarla dalga geçme.

Bana göre sorun, sizin neye başvurduğunuzu anlamada daha az, tesis ve bellek konularında daha fazla. Kendine güvenini kaybediyorsa, evet, bu bir sorun - ama kesinlikle ele alınabilir!

Benim için bu tür zorluklar hayatımın birçok farklı yönüyle ortaya çıkıyor. Örneğin, bir müzik parçasında başarılı olmak için verdiğim notalardan bağımsızlığımı geliştirmem gerekiyor - burnunuz hala kitapçığınıza gömülmüşse, müziği gerçekten nasıl hissedebilirsiniz? Bazen, zamanım olursa, tüm müziği ezberlerim - konserim için gerekli olmasa bile. Neden? Notalar bittiğinde, doğru yapmak için ihtiyacım olan müziğin daha zorlu ve kapsamlı yönlerine odaklanmak benim için çok daha kolay ve bu inanılmaz saf müzik yapımı alanına girmem çok daha kolay. Bu yüzden sık sık ekstra belaya değeceğini düşünüyorum.

Programlama ile ilgili deneyimim benzerdi. Anahtarların şöyle olduğunu düşünüyorum:

1. dili pratik yap - yaz, çalıştır, yardım ederse konuş; bunu tekrar tekrar yapın.
2. tesisinizi inşa edin - farklı durumlarda aynı özelliği veya modeli kullanın; özellikleri bir araya getirmek; programlar yapmak
3. işlerin gerçekten uzun süreli hafızanıza girmesini sağlamak için tekrarlar arasında yeterli zaman verin .

Bu ilkeler aslında herhangi bir dil öğrenirken de geçerli görünmektedir! Örneğin, Yeni Kelimelerin Nasıl Hatırlandığına bakınız . Pimsleur yöntemi de bu gibi çalışır.

Düzenli olarak kullandığım dilin ve teknolojilerin tüm ilkelerinin, sözdiziminin ve ortak kütüphanelerinin bu anahtarları kullanarak tamamen ezberlenebileceğini buldum. Yine de İnternet'i sürekli olarak örnekler ve bilgelik için araştırıyorum! Ancak bu nokta, çözmeye çalıştığım sorun, doğrulanmış çeşitli yaklaşımlar, yardımcı olabilecek araçlar ve daha az kullanılan kütüphaneler için danışma konusunda doğrulama arıyorum. İlk defa bir dil öğrendiğimde ve dersler ve el kitaplarında başa çıkarken kullandığımdan çok farklı bir tür arama.

Hikayenden, işte içine girebileceğini düşündüğüm bazı engeller var.

1. Sözdizimi ile mücadele ediyorsanız, yeterli pratik alamayabilirsiniz. Bu özellikle, tekrarlamayı geliştirmek yerine doğrudan kodunuza kopyalayıp yapıştırıyorsanız geçerlidir - şunu söyleyebilir miyim? - Gerçekten iyi olmanıza yardımcı olacak kas hafızası . Buna karşı koymak için, istediğiniz alanlarda tesisinizi geliştirecek, tekrar ve zamana odaklanarak, sadece alıştırmalar ve disiplin geliştirin. Öneriler:
   • Her gün, günde bir kez aynı dilde basit bir program yazın.
   • Bunları kopyalayıp yapıştırmak yerine örnekler yazın.
2. Orta büyüklükteki sorunlara çözüm üretme konusunda zorlanıyorsanız, bina ile ilgili yeterli deneyim alamayabilirsiniz. Bunları dene:
   • İyi olmak istediğiniz bir teknoloji veya dilde orta ölçekli bir proje başlatın. Ya da, ilginizi çeken açık kaynak kodlu bir projede bir chunkier özelliğinde deneyin. Her gün biraz zorlayın. (Unutmayın, bu büyük projelerin peşinden giderken: onlara tuğladan tuğlaya gidin. Her şeyi bir kerede yapmayı deneyin!)
   • Aynı yeni özelliği arka arkaya dört günde, dört farklı bağlamda kullanın.
   • Web tarayıcısı kapalıyken bir şeyi kodlamak için kendinize sorun!
   • Aslında öğrendiğin şeyler hakkında not al. Öğrendiklerinizi sentezleyin ve gözlemlerinizi yazın. (Aslında bir şeyler yazmak ve kendimi bir şeyleri kendi kelimelerimle ifade etmeye zorlamak bana çok yardımcı olur.)
   • Absorbe ettiğiniz teknolojiyle ilgili StackOverflow soruları için yanıtlar yazın ve bunları doğrulayın. (Bu genellikle öğrenirken size biraz itibar kazanma avantajını da beraberinde getirir. :-))
3. Uygulamanızı çok ince yayıyor olabilirsiniz. Pek çok farklı dilde çalışıyor görünüyorsun. Bunun bir çok avantajı var, ancak deneyiminizi sulandırmanın dezavantajı var. Beş farklı dilde çalışarak zaman harcıyorsanız, aynı zamanda bir dilde geçirdiğinizden daha az ezberleyeceksiniz. Daha da kötüsü, farklı diller arasında pek benzer olmayan konyaklar vardır (eğer başka biriyse, elsif veya elif ??). Buna karşı koymak için odağınızı netleştirin. Soğuk öğrenmek ve öğrenmek için bir şey seçin. Ardından bir sonraki şeye geçin.

Kendinize ılımlı kod getirmeye odaklanırsanız verimliliğinizi ve verimliliğinizi artıracağını düşünüyorum. Muhtemelen kod aramak, okumak / anlamak, kaynağınızı kopyalamak, buna göre değiştirmek, vb. İçin daha fazla zaman alır.

Kendin bulursan, kendine özgü duruma daha büyük olasılıkla adapte olur ve bir süre sonra bu çözümler sana bakmaktan daha hızlı gelir.

Bakmamın yolu, belli bir çözüm hakkında ikinci bir görüş istemeniz gibi, başkalarının da (İnternet üzerinden) nasıl yaptıklarına bakıyorsunuz. Kendinizi bu kadar çok yapmakta / istemekte bulursanız, bir meslektaşınıza bir çözüm hakkında ne düşündüğünü sormak olarak düşünün. Meslektaşınıza her 15 dakikada bir soru sorarsanız, muhtemelen sinirlenir. Bu nedenle daha az soru soracak ve kendiniz bulmaya çalışacaksınız.

İnternette bir şeyler aramak istediğinizde bunu görselleştirin.

Ne bilmediğinizi öğrenmenin en iyi yolu: google! Çoğu geliştiriciyle eşit olduğunuzu düşünüyorum. Aşağılık kompleksi sırt çantanıza koyun ve açık bir zihinle gidin.

Soru sormaktan korkmayın, Google'da araştırma yapın, deneyin ve başarısız olun. Hepsi bunun bir parçası.

Kurumsal ortamlarda yazılım geliştirme, adil miktarda kod yeniden kullanımı gerektirir. Bir API zaten varsa ve yaygın olarak kullanılıyorsa, neden bir işlevi / yöntemi yeniden yazın ? Muhtemelen yazdığınız ve daha az zaman harcadığınız her şey kadar verimli olacaktır.

Elbette, yazılım geliştirmede başarılı olmak için klavyeden bir mola vermeniz gerekir, böylece gerçekte neler olup bittiğini okuyabilir ve anlayabilirsiniz. Herhangi bir web çerçevesini alın. Altında neler olup bittiğini bilmelisin, böylece yazdığın kodu anlarsın, ama muhtemelen sıfırdan bir web çerçevesi yazmak zorunda kalmazsın.

Sadece çerçeve türünden faydalanan (bileşen tabanlı bir çerçevenin belirli bir stil gerektirdiğini söyleyen) kod yazmanız gerekir ve bu daha büyük resmi anlamaktan gelir. Büyük resmi öğren ve iyi olacaksın.

Kör olarak kodlamak yerine, sorununuzu araştırmakta yanlış bir şey olmadığı verilen cevaplardan açıkça anlaşılır. Ancak doğrudan sorulmamış olduğu için sorulmamış olan soru, neden bu kadar güvensiz hissediyorsunuz - ve bu konuda ne yapabilirsiniz? Ne de olsa, birçok insan problemlerden geçiyor ve çok güven duyuyor (yapmamalı olanlar bile ...)

Peki ne yapmalı? Belki de arka tarafta birkaç yüz pat'a ihtiyacın vardı, şimdi aldım ve şimdi güvenle kodlayabilirsin. Ancak bu işe yaramadıysa, otomatik sınama ve Test Odaklı Geliştirme konusuna bakmanızı öneriyorum. Hiçbir şey test odasındaki "Tüm testler geçti" gibi "iyi iş" demez: Oraya gittiğinde, doğru yaptığını biliyorsun .

Kendine biraz da meydan okumayı denemelisin: Her zaman zaten bildiğin sözdizimini aradığını söylersin; öyleyse kendinize sözdizimi aramadan bazı kodlar yazmaya zorlayın; sonuçta derhal iyi yaptığınızı anlayın.

Geliştiriciler “büyük” olarak doğmazlar, ancak büyüklük otomatik olarak deneyimle gelmez. Tersine, deneyim eksikliği bir geliştiriciyi “kötü” yapmaz. Büyük bir geliştirici ile kötü bir geliştirici arasındaki fark etki alanı bilgisinde değil, metodolojisindedir. Büyük bir geliştiricinin ayırt edici özelliği, bilinçli olarak kodlamasıdır. Başka bir deyişle, iyi bir geliştirici neden bir şey yaptığını her zaman bilir. Kişisel etik açısından bakıldığında, entelektüel cesaret ve bütünlük gerektirir.

Biraz zaman ayırmak ve temellerini, daha da üzerine inşa edilen karmaşık şeyleri anlamak için çok önemlidir. Dili anlamada ve sahnelerin arkasında ne olup bittiğine dair bir temel yoksa kodlama basit bir şekilde kesilecektir.

Dolayısıyla örneklerle kitap okumak ve bunlara atıfta bulunmak kötü bir programlama olup sorunuzun bağlamıdır. Pek az kişinin API'sini belgelediğini görmek bizim elimizde bir kitap bıraktı.

Bu soruyu sormak için nedenlerinizin ne olduğunu bilmiyorum belki de durumumu okuduktan sonra birçok kod örneğine başvurduğum için kendinize cevap verebilirsiniz.

16 yaşındayken sokakta olduğum için üniversiteye gitme şansım olmadı. Her nasılsa 24 yaşındayken bir yazışma kolejinde eğitim alma ve SCJP, SCJD, SCBCD ve SCWCD gibi satıcı sertifikaları yapma pozisyonundaydım. Bazen mücadele ettiğimi ve örnekler için çevrimiçi olmak zorunda kaldıklarını itiraf etmeliyim. Bilmeden, şu anda kafamda büyüyen bir beyin tümörü vardı (2010 yılına kadar bir portakal büyüklüğündeydi). 5 beyin ameliyatımdan sonra, 6 hafta kemo / radyoterapiyi ve 10 aylık kemoyu birleştiriyor, hala profilimden görülebilen elle yazılmış kodlu siteler ile programlıyorum.

Evet şimdi beyin hasarı ile ilgili birçok kod örneğine ihtiyacım var, bu beni kötü bir programcı mı yapıyor?

Anladığım kadarıyla, senin bir hackona gideceğinden bahsetmiştin. Geçen yıl epeyce oldum (15'ten fazla) ve onların öğrenme için harika olduklarını farkettim. Ve öğrenme için harika bir şey, bir daha asla böyle kodlama yapmamayı öğrenmek demek. Çoğunlukla gittiğim her hackathonda yeni bir şeyler yapmaya çalışıyorum, böylece yeni şeyler öğrenebiliyorum. Çok büyük bir zaman kısıtlaması olduğu için, bulabileceğiniz tüm kodu yapıştırarak kopyalamaya güveniyorsunuz ve bu test ederken sizi kıçınızdan ısırmaya geliyor.

Bununla birlikte, iyi şeyler ortaya çıkar, siz: A) Hata testi sırasında çok fazla bilgi edinin (ayrıca çok ağlar) B) Bir daha asla böyle kod yazmamayı ve daha iyi kodlama uygulamalarını öğrenmeyi öğrenin. Ayrıca, hackan'larda size asla tanımadığınız birçok yeni şeyi öğretebilecek insanlarla tanışacaksınız ve okulda asla yapamayacağınız şeyler yapacaksınız.

Demek istediğim kopya yapıştırmak kötü, ve hiçbir şey öğrenmeyeceksiniz ve kopya yapıştırmayla kaydettiğiniz zaman sizi daha sonra hata testi sırasında ısırır ve yazdıklarınız hakkında hiçbir fikriniz olmaz, saat 8:00, ve tüm kafeinlerle beslenir. Ancak, kodunuzu sınamadığınız sürece, daha önce kopyaladığınız her şeyi öğrenmek zorunda kalacağınızı düşünüyorum.

Ben kendime iyi bir programcı demiyorum. Ama yaptığım şey basit. Bir şeyi nasıl yapacağımı bilmiyorsam, aslında İnternet'teki bazı koda / örneklere bakarım. Sonra okuduktan sonra yeniden yazmaya, optimize etmeye ve istediğim kod için en uygun olanı kullanmaya çalışıyorum.

Not: İnternetten kod okumak sizi kötü bir geliştirici yapmaz . Başkalarının nasıl yaptığını görmek her zaman iyidir ve her zaman bir şeyler öğreneceksiniz. Ama sonra, kör olarak kopyalamak iyi değil.

Bir geliştirici / öğrenci söylemeye devam ederse .. Wikipedia .. kodunu kendi projesine kopyalamak / yapıştırmak, daha sonra "işe almak" için çalışır, daha sonra bu kişinin geliştirdiği tek yetenek 'Google'a nasıl girilir'. Orada bir miktar osmoz süreci olabilir, fakat bir bütün olarak olmayabilir. (Bunu kolej derslerinde kaç kişinin yaptığına inanmazsınız)

Gerçekten diğer halklar kodunu analiz ve varsa ANCAK gelmez sonra kod kendisi de ne olup bittiğini düşünmek değil bir kişinin kötü bir geliştirici olun. Onları kararlı bir geliştirici yapar ve muhtemelen daha dokunsal veya görsel olan bir öğrenme stilini gösterir. Örnek olarak çok iyi öğreniyorum. Biri bana bir şey söylerse veya bana anlatmaya çalışırsa, genellikle onlardan bahsettiğini bana göstermelerini isterim.

Koddan bakmak, analiz etmek ve öğrenmek, zaman içinde onları iyi bir geliştirici yapar , çünkü kullandıkları dilde okuyor ve öğreniyorlar.

Bilgisayar dillerinin giriş ve çıkışlarını anadili İngilizce yaptığımdan daha çok tanıdığım için şaka yapıyorum. Hangi soruya yalvarır; “Bunu bana Java plz'de açıklar mısınız?”

Bence biraz satranç oynamak gibi bir şey. Parçaları ayrı ayrı kontrol ediyoruz ve kurallara göre hareket edebilecekleri yerleri takip ediyoruz ve bilinçaltı bir araya gelinceye kadar kalıpları ve ilham veren dizileri ortaya çıkana kadar bir süre bu bilinçli kontrolden geçmeliyiz.

Programlama ile daha fazla parça ve kural olabilir, genellikle sözdizimi ile tökezlerim ve 'kuralları' geçirerek sonsuza dek bulmakta zorlanan hatalara saplanırım, ancak sonunda bilinçaltı tekmeleyecektir. Yeterince uzun kaldığında, okuyabilirim bazen geri döner ve yapabileceklerine şaşırabilirsin.