2018'in başından bu yana, takımda lider/patron/lider geliştirici pozisyonunu tutuyorum - buna ne dersen de, ama mesele şu ki modüllerden birinden ve çalışan tüm geliştiricilerden tamamen sorumluyum. üstünde. Bu pozisyon, daha fazla projeye dahil olduğum ve karar alma süreçlerine daha aktif olarak katıldığım için bana geliştirme süreci hakkında yeni bir bakış açısı kazandırıyor. Son zamanlarda bu iki şey sayesinde birdenbire anlama ölçüsünün kodu ve uygulamayı ne kadar etkilediğini fark ettim.
Vurgulamak istediğim nokta, kodun (ve nihai ürünün) kalitesinin, kodu tasarlayan ve yazan kişilerin yaptıkları işin ne kadar farkında olduklarıyla yakından ilişkili olduğudur.
Şu anda şöyle düşünüyor olabilirsiniz: “Teşekkürler Kaptan. Elbette genel olarak ne yazdığınızı anlamak güzel olurdu. Aksi takdirde, keyfi tuşlara basmak için bir grup maymun kiralayıp işi bu şekilde bırakabilirsiniz." Ve kesinlikle haklısın. Buna göre, ne yaptığınıza dair genel bir fikre sahip olmanın gerekli olduğunu fark ettiğinizi varsayıyorum. Buna sıfır anlayış düzeyi denilebilir ve bunu ayrıntılı olarak analiz etmeyeceğiz. Tam olarak neyi anlamanız gerektiğine ve bunun her gün verdiğiniz kararları nasıl etkilediğine ayrıntılı olarak bakacağız. Bunları önceden bilseydim, bu beni çok fazla zaman kaybından ve şüpheli kodlardan kurtarırdı.
Aşağıda tek bir kod satırı görmeyecek olsanız da, burada söylenen her şeyin yüksek kaliteli, etkileyici kod yazmak için büyük önem taşıdığına inanıyorum.
Birinci düzey anlayış: Neden işe yaramıyor?
Geliştiriciler genellikle bu seviyeye kariyerlerinin çok erken dönemlerinde ulaşırlar, hatta bazen başkalarının yardımı olmadan da, en azından benim deneyimime göre. Bir hata raporu aldığınızı düşünün: uygulamadaki bazı işlevler çalışmıyor, düzeltilmesi gerekiyor. Nasıl ilerleyeceksin?
Standart şema şöyle görünür:
- Soruna neden olan kod parçasını bulun (bunun nasıl yapılacağı ayrı bir konudur, bunu eski kodlarla ilgili kitabımda ele alıyorum)
- Bu snippet'te değişiklik yapın
- Hatanın düzeltildiğinden ve herhangi bir gerileme hatasının oluşmadığından emin olun
Şimdi ikinci noktaya, yani kodda değişiklik yapmaya odaklanalım. Bu sürece iki yaklaşım vardır. Birincisi, mevcut kodda tam olarak ne olduğunu araştırmak, hatayı tanımlamak ve düzeltmektir. İkincisi: hissederek hareket edin - koşullu bir ifadeye veya döngüye örneğin +1 ekleyin, işlevin istenen senaryoda çalışıp çalışmadığına bakın, sonra başka bir şey deneyin ve bu şekilde sonsuza kadar devam edin.
İlk yaklaşım doğrudur. Steve McConnell'ın Code Complete adlı kitabında açıkladığı gibi (bu arada şiddetle tavsiye ediyorum), koddaki bir şeyi her değiştirdiğimizde, bunun uygulamayı nasıl etkileyeceğini güvenle tahmin edebilmeliyiz. Aklımdan alıntı yapıyorum ama eğer bir hata düzeltmesi beklediğiniz gibi çalışmazsa, çok paniğe kapılmalı ve tüm eylem planınızı sorgulamalısınız.
Söylenenleri özetlemek gerekirse, kodun kalitesini bozmayan iyi bir hata düzeltmesi gerçekleştirmek için hem kodun tüm yapısını hem de spesifik sorunun kaynağını anlamanız gerekir.
İkinci anlayış düzeyi: Neden işe yarıyor?
Bu seviye bir öncekine göre çok daha az sezgisel olarak anlaşılmaktadır. Hala acemi bir geliştiriciyken bunu patronum sayesinde öğrendim ve daha sonra konunun özünü yeni gelenlere defalarca anlattım.
Bu kez aynı anda iki hata raporu aldığınızı düşünelim: Birincisi A senaryosu, ikincisi ise B senaryosu. Her iki senaryoda da bir şeyler ters gidiyor. Buna göre ilk önce ilk hatayı giderirsiniz. Düzey 1'i anlamak için geliştirdiğimiz ilkeleri kullanarak, sorunla ilgili kodun derinliklerine iner, uygulamanın Senaryo A'daki gibi davranmasına neden olduğunu anlar ve beklediğiniz sonucu üreten makul ayarlamalar yaparsınız. . Her şey harika gidiyor.
Sonra senaryo B'ye geçersiniz. Bir hatayı kışkırtmak için senaryoyu tekrarlarsınız, ama sürpriz! – artık her şey olması gerektiği gibi çalışıyor. Tahmininizi doğrulamak için A hatası üzerinde çalışırken yaptığınız değişiklikleri geri alırsınız ve B hatası geri gelir. Hata düzeltmeniz her iki sorunu da çözdü. Şanslı!
Buna hiç güvenmedin. A senaryosundaki hatayı düzeltmenin bir yolunu buldunuz ve bunun B senaryosunda neden işe yaradığına dair hiçbir fikriniz yok. Bu aşamada her iki görevin de başarıyla tamamlandığını düşünmek çok cazip geliyor. Bu oldukça mantıklı: Amaç hataları ortadan kaldırmaktı, değil mi? Ancak iş henüz bitmedi: Eylemlerinizin neden B senaryosundaki hatayı düzelttiğini anlamanız gerekiyor. Neden? Çünkü yanlış prensiplerle çalışıyor olabilir ve o zaman başka bir çıkış yolu aramanız gerekebilir. İşte bu tür durumlara birkaç örnek:
- Çözüm, tüm faktörler dikkate alınarak B hatasına göre tasarlanmadığı için, farkında olmadan C fonksiyonunu bozmuş olabilirsiniz.
- Aynı işlevle ilgili olarak bir yerde gizlenen üçüncü bir hatanın da olması mümkündür ve B senaryosunda sistemin doğru çalışması için hata düzeltmeniz buna bağlıdır. Şimdilik her şey yolunda görünüyor ama bir gün bu üçüncü hata fark edilecek ve düzeltilecek. Daha sonra B senaryosunda hata tekrar meydana gelecektir ve sadece orada olması iyidir.
Bütün bunlar koda kaos katıyor ve bir gün başınıza düşecek - büyük ihtimalle en uygunsuz anda. Her şeyin neden işe yaradığını anlamak için zaman ayırmaya kendinizi zorlamak için iradenizi toplamanız gerekecek, ama buna değer.
Üçüncü anlayış düzeyi: Neden işe yarıyor?
Son zamanlardaki içgörüm tam olarak bu seviyeyle ilgilidir ve eğer bu fikre daha önce gelseydim muhtemelen bana en fazla faydayı sağlayacak olan da buydu.
Daha açık hale getirmek için bir örneğe bakalım: Modülünüzün X işleviyle uyumlu hale getirilmesi gerekiyor. X işlevine pek aşina değilsiniz, ancak onunla uyumlu olmak için F çerçevesini kullanmanız gerektiği söylendi. Diğer. X ile entegre olan modüller tam olarak onunla çalışıyor.
Kodunuzun ilk günden bu yana F framework ile teması olmadığı için onu hayata geçirmek pek kolay olmayacaktır. Bunun modülün bazı kısımları için ciddi sonuçları olacaktır. Ancak kendinizi geliştirmeye adarsınız: haftalarca kod yazmaya, test etmeye, pilot versiyonları kullanıma sunmaya, geri bildirim almaya, regresyon hatalarını düzeltmeye, öngörülemeyen komplikasyonları keşfetmeye, başlangıçta kararlaştırılan son teslim tarihlerine uymamaya, biraz daha kod yazmaya, test etmeye, geri bildirim iletişimi almaya, Regresyon hatalarının düzeltilmesi - tüm bunlar F çerçevesini uygulamak için.
Ve bir noktada aniden F çerçevesinin size X özelliğiyle uyumluluk sağlamayacağını fark edersiniz - veya belki birinden duyarsınız - Belki de tüm bu zaman ve çaba bunun için tamamen yanlış harcanmıştır.
Sorumlu olduğum bir proje üzerinde çalışırken benzer bir şey bir kez başıma geldi. Bu neden oldu? Çünkü X fonksiyonunun ne olduğu ve F çerçevesiyle nasıl bir ilişkisi olduğu konusunda çok az bilgim vardı. Ne yapmalıydım? Geliştirme görevini veren kişiden, diğer modüller için yapılanları tekrarlamak veya X'in yapması gereken özelliğin bu olduğuna dair sözlerine güvenmek yerine, amaçlanan eylem planının istenen sonuca nasıl yol açtığını açıkça açıklamasını isteyin.
Bu projenin deneyimi bana, bizden neden belirli şeylerin istendiğini net bir şekilde anlayana kadar geliştirme sürecine başlamayı reddetmeyi öğretti. Kesinlikle reddedin. Bir görev aldığınızda ilk dürtü, zaman kaybetmemek için hemen onu üstlenmektir. Ancak "tüm ayrıntılara girene kadar projeyi dondurun" politikası, boşa harcanan zamanı büyük ölçüde azaltabilir.
Üzerinizde baskı kurmaya, sizi işe başlamaya zorlamaya çalışsalar bile, bunun mantığını anlamasanız da direnin. Öncelikle size neden böyle bir görev verildiğini anlayın ve bunun hedefe giden doğru yol olup olmadığına karar verin. Tüm bunları zor yoldan öğrenmek zorunda kaldım - umarım örneğim bunu okuyanlar için hayatı kolaylaştırır.
Dördüncü anlayış düzeyi: ???
Programlamada her zaman öğrenilecek daha çok şey vardır ve anlama konusunun yalnızca yüzeyini çizdiğime inanıyorum. Yıllarca kodla çalıştığınızda başka hangi anlayış düzeylerini keşfettiniz? Kodun ve uygulamanın kalitesi üzerinde olumlu etkisi olan hangi kararları aldınız? Hangi kararların yanlış olduğu ortaya çıktı ve size değerli bir ders verdi? Deneyimlerinizi yorumlarda paylaşın.
Kaynak: habr.com