Acemi programcılar tarafından yapılan yaygın hataların analizi, pt. 1

Selam Dünya! Bilmeniz gereken her şeyi öğrendikten ve sonunda bir stajyer veya genç geliştirici olarak çalışmaya başladığınızda, muhtemelen rahatlayabilirsiniz, değil mi? Hayır. Sizin için her şey daha yeni başlıyor... Yeni ve anlaşılmaz bir sürü şeyle çevrilisiniz. Kapıdan çıkar çıkmaz nasıl mahvetmezsin? Bugün bunun hakkında konuşacağız. Bu makalede, yaygın çaylak hatalarını analiz etmek ve kendi deneyimlerime dayanarak bunlardan nasıl kaçınılacağına dair bazı tavsiyeler vermek istiyorum. O halde lafı daha fazla uzatmadan başlayalım:

1. Daha deneyimli meslektaşlarından yardım arama korkusu

Hepimiz insanız. Hepimiz, özellikle yeni, daha deneyimli meslektaşlarımızın gözünde aptal görünmekten korkarız. Geliştiriciler ilk işlerini aldıklarında, genellikle bu korku tarafından yönlendirilirler ve ağır bir şekilde kendi içlerine çekilirler ve her şeyi kendi başlarına çözmeye çalışırlar. Ek olarak, bir kişinin etrafı, daha fazla hatadan ve gereksiz "kafasına çarpmalardan" kaçınmaya yardımcı olarak onu en umut verici yöne yönlendirebilen daha deneyimli meslektaşları tarafından çevrelenebilir. Bu yüzden unutmayın: soru sormaktan korkmayın. Siz bir acemisiniz ve bunu herkes çok iyi anlıyor. Sorduğunuzda kimse sizi sopalarla dövmeyecek. Hatta belki tam tersi de gerçekleşecek: iş arkadaşlarınızla daha çabuk arkadaş olacak ve onlarla daha aktif bir iletişimin keyfini çıkarmaya başlayacaksınız. BEN' Daha da fazlasını söyleyeceğim: Çeşitli teknik sorunları ne kadar çok sorup tartışırsanız, o kadar hızlı yeşil acemi derinizi atabilir ve alanınızda bir uzman haline gelebilirsiniz. Ve bir tavsiye daha. yabancı olmaStackOverflow . Özellikle bu kaynak hakkında soru sormaktan bahsediyorum. Bir yandan, sorunuza yanıt almanız biraz zaman alıyor. Ancak öte yandan, sorununuzu çözmek için birden çok yaklaşımı hızla öğrenebilir ve soruna biraz farklı bir açıdan bakabilirsiniz. Ayrıca, diğer geliştiricilerin StackOverflow sorularına yorum/yanıt yazmanın ve açıklayıcı sorular yazmanın pratik faydaları olduğunu da belirtmek isterim: Karma artışı bir yana, sorunları tartışma ve derinlemesine inceleme şansınız olur.

2. Kendi başınıza bilgi aramaya çalışmamak

Bu hata bir öncekinin tersi olarak kabul edilebilir.Burada, karşılaştığınız her sorun veya hıçkırık için meslektaşlarınızı ve tanıdıklarınızı rahatsız etmeye başladığınızda kastediyorum. Sormak iyidir, ancak sorularla aşırıya kaçmayın. Aksi takdirde, insanlar sizi sinir bozucu bulabilir. Bir konuda kafanız karışırsa, yapılacak ilk şey, arama becerilerinizi en iyi arama motoru olan Google'da kullanmaktır. Bir başkası, anlaşılmaz hataların ve diğer sorunların ezici çoğunluğuyla zaten karşılaştı. Ve sorunuzu Google'da aratıp benzer bir soruna aşina olan ve kendi işinizde uygulayabileceğiniz ayrıntılı yanıtları zaten almış olan kişilerin sayısını görürseniz oldukça şaşıracaksınız. Bu nedenle iş arkadaşlarınızın "Google it" ile yanıt verdiğini sık sık duyacaksınız. Giymek' Bu cevaba gücenmeyin - meslektaşınız, çalışma alanınızın tüm inceliklerini iletmesi gereken kişisel öğretmeniniz değildir. İnternetin sonsuz genişlikleri akıl hocanız olacak. Bazen programcılar olarak da adlandırılırGoogle aramada siyah kuşak sahibi kişiler . Yani bir "hıçkırığımız" varsa, önce sorunu Google'da ararız. Bir çözüm bulunamazsa (bu nadirdir, ancak olur), ancak o zaman meslektaşlarımıza sormaya başlarız. Acil sorular, bir hız tümseğine veya anlaşılmaz bir hata mesajına çarptığınızda ne yapacağınızdan çok, bir sorunu çözmek için hangi yaklaşımı seçmeniz gerektiği konusunda tavsiye almak içindir. Ne de olsa, tercih ettiğiniz yaklaşımın ötesini görebilirler ve herhangi bir yaklaşımın uzun vadede nereye varacağını hemen tahmin edebilirler.

3. Körü körüne kopyalama ve yapıştırma

Ancak sorunları ve çözümlerini Google'da aramanın tuzakları vardır. Örneğin, körü körüne kopyalama ve yapıştırma .Bu genellikle StackOverflow'ta benzer bir sorun (ancak tam olarak aynı olmayabilir) ve ilişkili bir çözüm bulduğunuzda olur. Ayrıntılara girmeden bu çözümü alıp kopyalayıp yapıştırıyorsunuz. Ve sonra siz veya iş arkadaşlarınız kodunuzda bazı garip hatalar veya yanlış davranışlar keşfedersiniz. Ve kimse nereden geldiklerini hemen tahmin edemez. Sonunda elbette kopyalanan kodun olduğu yer bulunacak ve çözümünüz için kesinlikle övülmeyeceksiniz. Bu nedenle, StackOverflow'ta (veya başka bir yerde) hazır bir çözüm bulduğunuzda, önce neyi, nasıl ve neden olduğunu iyice anlamanız gerekir. Belki de ilgili işlevi google'da araştırın ve bununla ilgili belgeleri okuyun. Ve ancak bunu yaptıktan sonra onu projenize eklemelisiniz.

4. Yanlış çözüme takılıp kalmak

Bir çözüm yazarken, bazen bunun sürekli olarak daha karmaşık hale geldiğini ve sonunda bir çıkmaza girdiğini göreceksiniz. Ve sonra, daha uygun başka bir alternatif aramak yerine, bir şekilde çalışmasını sağlamak için çözümü daha da ayrıntılı hale getirmeye çalışırsınız. Belki de çok fazla zaman ve çaba harcadığınızı hissediyorsunuz ve bu nedenle ne olursa olsun pes etmeyeceğinize ve mevcut yaklaşımınızla sorunu çözeceğinize karar vermişsinizdir. Bu pek doğru bir tutum değil. En azından programlamada. Farklı bir yaklaşımı ne kadar erken denerseniz, sonunda o kadar çok zaman kazanırsınız. Bu nedenle, mevcut yaklaşımınıza ne kadar zaman ayırmış olursanız olun, diğer yaklaşımları denemekten ve denemekten korkmayın. Dahası, birden fazla yaklaşım deneyerek ve konuya daha derinlemesine dalarak,

5. Mevcut ödeviniz hakkında soru sorma korkusu

Bir yazılım geliştirme projesi üzerinde çalışmak genellikle belirli görevleri yerine getirmekle sonuçlanır. Örneğin, Jira'da. Bu görevler her zaman açık ve ayrıntılı olarak ana hatlarıyla belirtilmez. Görev açıklamaları genellikle aynı zamanda ölümlü olan ekip liderleri tarafından yazılır. Bir şey eklemeyi unutabilirler veya şu veya bu işlevselliğe aşina olmadığınızı hesaba katmayabilirler. Veya projeye herhangi bir erişiminiz olmayabilir (örneğin, veritabanına, günlük sunucusuna vb. erişim). Ve şimdi, görevi aldınız, birkaç saatten fazla çalıştınız, ancak hala orada oturmuş, şaşkınlıkla ekrana bakıyorsunuz. Başarısız bir şekilde bunu anlamaya çalışmak yerine, görevi oluşturan kişiden açıklama veya rehberlik istemeye başlamalısınız. Örneğin, ekibinizin iletişim için kullandığı uygulamada (örneğin Microsoft Teams), görevle ilgili sorular sorabilir veya doğrudan yorum yapabilirsiniz. Bir yandan, sorunuzu kişisel bir mesaja yazarsanız, kişi sorunuzu hemen göreceği için muhtemelen daha hızlı yanıt alırsınız. Öte yandan, Jira'da bir soru sorarak, bir şey yaptığınıza, yani sorunu analiz ettiğinize dair kanıt sağlamış olursunuz. Bu süreci hızlandırmanın bir yolu var: sorunuzu Jira'da bir yorumda sorun ve ardından bir DM'de, yorumunuzun bağlantısını bırakın ve bir göz atmasını isteyin.

6. Takım liderine gerçekçi olmayan yüksek beklentiler yüklemek

Yine, bu önceki noktanın diğer yüzü. Ekip lideri, bir geliştirme ekibinin başıdır. Kural olarak, ekip lideriniz zamanının çoğunu çeşitli iletişim türleri üzerinde geçirir. Ancak programlama ile ilgili her şeyi unutmamak için kod da yazar. Anlayacağınız üzere bir takım liderinin hayatı oldukça yoğundur. Her hapşırmanız gerektiğinde takım liderinizin kolunu çekiştirmek kesinlikle hoş olmayacaktır. Ekibin her üyesinin liderliği bir dizi soruyla bombardımana tuttuğunu hayal edin. Bu herkesi deli edebilir, değil mi? Ve bir sürü soru üst üste yığılırsanız, o zaman takım lideriniz size cevap vermek için çok zaman harcamak zorunda kalacaktır. Ekip liderine yöneltilen soru sayısını azaltmak için neler yapılabilir:

• Kör noktaların sayısını azaltmak için proje belgelerini daha derinlemesine keşfedin.
• Sorularınızı diğer ekip üyelerinize yönlendirin. Bu işlevselliğe müşteri adayı kadar veya muhtemelen daha fazla aşina olabilirler, çünkü işlevsellik büyük olasılıkla onlardan biri tarafından yazılmıştır.

Alternatif olarak, belirli bir satırdaki kodun en son kime ve ne zaman değiştirildiğine ilişkin IDE'deki ek açıklamalara bakabilirsiniz. Sorunuzu sormak için en uygun kişinin kim olduğunu tam olarak bu şekilde öğrenebilirsiniz. Muhtemelen zaten fark ettiğiniz gibi, ekip liderine sorular söz konusu olduğunda, tıpkı iş arkadaşlarınıza sorularda olduğu gibi, mutlu bir ortam bulmaya çalışmanız gerekir — soru sormaktan korkmayın, aynı zamanda çok fazla soru sormayın. onlardan.

7. Kod gözden geçirme korkusu

Bir kod incelemesikodunuzu ortak bir uygulamaya (örneğin, master veya dev gibi paylaşılan bir şubeye) göndermeden önce gerçekleşen bir aşamadır. Bu kontrol, göreve dahil olmayan, yeni gözleri kod stilinizde kodunuzu ilk yazdığınızda fark edilmeyen hataları, yanlışlıkları veya kusurları tespit edebilen bir geliştirici tarafından gerçekleştirilir. Eleştiriler varsa, kodun belirli bölümlerine yorum olarak bırakılır. Bu durumda, kodu yazan geliştiricinin incelemede belirlenen hataları düzeltmesi (veya kararlarını gözden geçirenle tartışması ve muhtemelen onu bunların doğru olduğuna ikna etmesi) gerekir. Ardından, gözden geçirenin başka yorumu kalmayana kadar kod tekrar tekrar incelenmek üzere gönderilir. Gözden geçiren kişi, kod işlenmeden önce bir "ağ geçidi" görevi görür. Buradaki zorluk, birçok acemi programcının kod incelemesini eleştiri ve kınama olarak algılamasıdır. Kod incelemelerini takdir etmezler ve onlardan korkarlar. Yapmamalılar. Kod incelemeleri, tam olarak kodumuzu geliştirmemize izin veren şeydir. Ne de olsa, neyi yanlış yaptığımız ve nelere dikkat etmeye değer olduğu hakkında önemli bilgiler alıyoruz. Her kod incelemesini, daha iyi olmanıza yardımcı olabilecek bir şey olan öğrenme eğrisinin bir parçası olarak düşünmelisiniz. Birisi kodunuz hakkında yorum yaptığında, deneyimlerini ve en iyi uygulamaları sizinle paylaşıyor demektir. Ben şahsen kod incelemesi almadan iyi bir programcı olabileceğine inanmıyorum. Çünkü kodunuzun kalitesinin ve deneyimli bir yabancının hatalara işaret edip etmeyeceğinin farkında bile değilsiniz. Kod incelemelerini takdir etmeyin ve onlardan korkmayın. Yapmamalılar. Kod incelemeleri, tam olarak kodumuzu geliştirmemize izin veren şeydir. Ne de olsa, neyi yanlış yaptığımız ve nelere dikkat etmeye değer olduğu hakkında önemli bilgiler alıyoruz. Her kod incelemesini, daha iyi olmanıza yardımcı olabilecek bir şey olan öğrenme eğrisinin bir parçası olarak düşünmelisiniz. Birisi kodunuz hakkında yorum yaptığında, deneyimlerini ve en iyi uygulamaları sizinle paylaşıyor demektir. Ben şahsen kod incelemesi almadan iyi bir programcı olabileceğine inanmıyorum. Çünkü kodunuzun kalitesinin ve deneyimli bir yabancının hatalara işaret edip etmeyeceğinin farkında bile değilsiniz. Kod incelemelerini takdir etmeyin ve onlardan korkmayın. Yapmamalılar. Kod incelemeleri, tam olarak kodumuzu geliştirmemize izin veren şeydir. Ne de olsa, neyi yanlış yaptığımız ve nelere dikkat etmeye değer olduğu hakkında önemli bilgiler alıyoruz. Her kod incelemesini, daha iyi olmanıza yardımcı olabilecek bir şey olan öğrenme eğrisinin bir parçası olarak düşünmelisiniz. Birisi kodunuz hakkında yorum yaptığında, deneyimlerini ve en iyi uygulamaları sizinle paylaşıyor demektir. Ben şahsen kod incelemesi almadan iyi bir programcı olabileceğine inanmıyorum. Çünkü kodunuzun kalitesinin ve deneyimli bir yabancının hatalara işaret edip etmeyeceğinin farkında bile değilsiniz. yanlış yapıyoruz ve nelere dikkat etmeye değer. Her kod incelemesini, daha iyi olmanıza yardımcı olabilecek bir şey olan öğrenme eğrisinin bir parçası olarak düşünmelisiniz. Birisi kodunuz hakkında yorum yaptığında, deneyimlerini ve en iyi uygulamaları sizinle paylaşıyor demektir. Ben şahsen kod incelemesi almadan iyi bir programcı olabileceğine inanmıyorum. Çünkü kodunuzun kalitesinin ve deneyimli bir yabancının hatalara işaret edip etmeyeceğinin farkında bile değilsiniz. yanlış yapıyoruz ve nelere dikkat etmeye değer. Her kod incelemesini, daha iyi olmanıza yardımcı olabilecek bir şey olan öğrenme eğrisinin bir parçası olarak düşünmelisiniz. Birisi kodunuz hakkında yorum yaptığında, deneyimlerini ve en iyi uygulamaları sizinle paylaşıyor demektir. Ben şahsen kod incelemesi almadan iyi bir programcı olabileceğine inanmıyorum. Çünkü kodunuzun kalitesinin ve deneyimli bir yabancının hatalara işaret edip etmeyeceğinin farkında bile değilsiniz.

8. Gizli kararlar verme eğilimi

Çeşitli görevler/sorunlar genellikle birkaç farklı çözüme sahip olabilir. Ve mevcut tüm çözümler arasından, yeni başlayanlar en karmaşık ve gizemli olanları kullanma eğilimindedir. Ve bu mantıklı: acemi programcılar daha dün birçok farklı algoritma, model ve veri yapısı öğrendiler, bu yüzden bazılarını uygulamak için elleri kaşınıyor. İnan bana, ben de öyleydim, bu yüzden neden bahsettiğimi biliyorum :) Uzun süredir bazı işlevleri uyguladığım bir durum yaşadım. Çok, çok karmaşık olduğu ortaya çıktı. Sonra kıdemli geliştirici kodumu yeniden yazdı. Tabii ki, neyi ve nasıl değiştirdiğini görmek çok ilgimi çekti. Uygulamasına baktım ve ne kadar basit olduğuna şaşırdım. Ve üç kat daha az kod vardı. Ayrıca şaşırtıcı bir şekilde, bu işlevsellik için otomatikleştirilmiş testler kaldırılmamış veya değiştirilmemiştir! Başka bir deyişle, genel mantık aynı kaldı. Buradan şu sonuca vardımen ustaca çözümler her zaman basittir . Bu farkındalıktan sonra kodlama çok daha kolaylaştı ve kod kalitem çok daha yüksek bir seviyeye çıktı. Öyleyse, tasarım modellerini ve süslü algoritmaları uygulamaya ne zaman değer olduğunu soruyorsunuz? Bunları uygularken en basit ve en kompakt çözüm olacaktır.

9. Tekerleği yeniden icat etmek

Tekerlek, uzun zaman önce icat edilmiş dayanıklı bir çözümdür. Bu anti-kalıpta, geliştirici zaten çözülmüş bir problem için kendi özel çözümünü uygular. Bazen bu mevcut çözümler, programcının bulduklarından daha iyidir. Kural olarak, tekerleği yeniden icat etmek zaman kaybına ve üretkenliğin azalmasına yol açacaktır, çünkü bulduğunuz çözüm en iyi olmaktan uzak olabilir veya hiç bulamayabilirsiniz. Bununla birlikte, kendi bağımsız çözümümüzü yaratma olasılığını göz ardı edemeyiz: eğer yaparsak, geriye kalan tek şey kopyala ve yapıştır programlama olacaktır. Programcı, hazır çözümler kullanarak veya özel çözümler yaratarak yetkin ve hızlı bir şekilde çözmek için ortaya çıkan belirli programlama görevleri tarafından uygun şekilde yönlendirilmelidir. Bir taraftan, üniversitelerde ve çevrimiçi kurslarda, tekerlekleri yeniden icat etmemize yardımcı olmak için tasarlanmış gibi görünen çeşitli görevlerle bombardımana tutuluyoruz. Ancak sadece ilk bakışta: Buradaki asıl amaç, algoritmik düşünmeyi geliştirmek ve dil sözdiziminde daha derin bir ustalıktır. Bu tür görevler aynı zamanda algoritmaları ve veri yapılarını daha iyi anlamanıza yardımcı olur ve gerekirse daha karmaşık benzerlerini uygulama becerileri kazandırır (bu bazen gereklidir, ancak son derece nadirdir). Gerçek hayatta, ihtiyaçlarınızı karşılayan tekerlekler uzun süredir ortalıkta olduğundan, çoğu durumda kendi tekerleğinizi icat etmenize gerek yoktur. Belki de deneyimsizliğiniz, ihtiyacınız olan işlevsellik uygulamalarının varlığından haberdar olmanızı engelliyor. Bu, bu makalenin ilk noktasında verilen tavsiyeyi almanız gereken yerdir, yani, daha deneyimli meslektaşlarınızdan yardım isteyin. Size rehberlik edebilecekler (örneğin, Google aramanızda sizi doğru yöne yönlendirebilecekler) veya belirli bir uygulama önerebilecekler (örneğin, bazı kitaplıklar).

10. Test yazamama

Tüm yeni başlayanlar test yazmaktan hoşlanmaz. Ama neden burada yeni başlayanları seçelim? Daha deneyimli geliştiriciler de test yazmaktan hoşlanmazlar, ancak testlerin neden gerekli olduğunu daha iyi anlarlar. Tamamen yeşil olduğunuzda, bunları neden yazmanız gerektiğini merak ediyorsunuz. Her şey çalışıyor, yani herhangi bir hata olamaz. Ancak, yaptığınız değişikliklerin sistemin herhangi bir yerindeki bir şeyi bozmayacağından nasıl emin olabilirsiniz? Yarardan çok zarara neden olan değişiklikleri uygulamaya koyarsanız iş arkadaşlarınız bunu takdir etmeyecektir. Testlerin imdadımıza yetiştiği yer burasıdır. Bir uygulamanın kodu testlerle ne kadar kapsanırsa o kadar iyidir (buna kod kapsamı veya test kapsamı denir). Uygulama iyi bir test kapsamına sahipse, kodunuz tarafından bozulacak yerleri bulmak için tüm testleri çalıştırabilirsiniz. Ve yukarıdaki örnekte söylediğim gibi, kıdemli geliştirici kodu yeniden düzenlediğinde testler başarısız olmadı. Bunun nedeni genel mantığın değişmemesiydi. Belirli işlevlerin mantığının değişip değişmediğini göstermek için testler kullanırız. Bu yüzden, test yazmaktan hoşlanmasanız bile, kesinlikle faydalıdırlar ve üzerlerine harcanan zamana değer.

11. Aşırı yorumlar

Birçok geliştirici mükemmeliyetçilikten muzdariptir ve yeni başlayanlar da bir istisna değildir. Bazen herkes ve her şey hakkında yorum yapmaya başladıklarında bu eğilimin sadece bir yüzünü gösterirler. Kod çok açık olduğu için gereksiz yorumlar yapmak bile:

Cat cat = new Cat(); // Cat object

Acemi programcıların tümü, yorum kodunun her zaman iyi olmadığını hemen anlamaz, çünkü gereksiz yorumlar kodu karıştırır ve okumayı zorlaştırır. Ya kod değişirse, ancak eski yorumlar güncellenmezse? O zaman sadece bizi yanıltırlar ve kafamızı karıştırırlar. O zaman neden böyle bir yorum yapıyorsun? Genellikle, iyi yazılmış kodun yorumlanmasına gerek yoktur , çünkü içindeki her şey zaten açık ve okunabilirdir. Bir yorum yazmanız gerekiyorsa, kodun okunabilirliğini zaten bozmuşsunuzdur ve bir şekilde durumu düzeltmeye çalışıyorsunuzdur. En iyi yaklaşım, en baştan okunabilir kod yani yorum gerektirmeyen kod yazmaktır. Yöntemler, değişkenler ve sınıflar için doğru adlandırma kurallarına uyma gereğini de belirtmeden edemeyeceğim. İşte benim kuralım: En iyi yorum, yorum olmaması veya uygulamanızdaki işlevselliği açıkça tanımlayan doğru adlandırmadır.

12. Kötü adlandırma

Acemiler, sınıfları, değişkenleri, yöntemleri vb. adlandırmada hızlı ve gevşek davranırlar. Örneğin, adı amacını hiçbir şekilde açıklamayan bir sınıf oluşturarak. Ya da x gibi kısa isimli bir değişken bildirirler . n ve y adlı iki değişken daha olduğundaoluşturulduğunda, x'in neden sorumlu olduğunu hatırlamak çok zorlaşır. Bu durumla karşı karşıya kaldığınızda, kod hakkında dikkatlice düşünmeniz, onu bir mikroskop altında analiz etmeniz (belki bir hata ayıklayıcı kullanarak), neler olduğunu basitçe anlamak için işlevselliği incelemeniz gerekir. Yukarıda bahsettiğim doğru adlandırma kurallarının imdadımıza yetiştiği yer burasıdır. Doğru adlar kodun okunabilirliğini artırır, böylece kodu tanımak için gereken süreyi azaltır, çünkü adı yaklaşık olarak işlevselliğini tanımladığında bir yöntemi kullanmak çok daha kolaydır. Koddaki her şey isimlerden (değişkenler, yöntemler, sınıflar, nesneler, dosyalar vb.) oluşur, bu nedenle doğru, temiz kod oluştururken bu nokta çok önemli hale gelir. Adın, örneğin değişkenin neden var olduğu, ne yaptığı gibi anlamlar taşıması gerektiğini unutmamalısınız. ve nasıl kullanılır. Bir değişken için en iyi yorumun ona iyi bir isim vermek olduğunu defalarca not edeceğim. Yorumları daha derinlemesine incelemek ve doğru adlandırma için zamansız klasikleri okumanızı tavsiye ederim:"Temiz Kod: Çevik Yazılım İşçiliği El Kitabı", Robert Martin . Bu notta, bu makalenin ilk bölümü (düşüncelerim) sona erdi. Devam edecek...