Küçük bir geliştiriciden 'neredeyse iyi' kod ile nasıl baş edilir? [kapalı]

Takım yönetimi hakkında bir sorum var. Şu anda bir kodlama fabrikasından uzaktan çalışan küçük bir geliştiriciyle uğraşıyorum. Adam eleştiriye açık ve öğrenmeye istekli ama bazı şeyleri ne kadar zorlamalıyım diye bazı şüphelerim var.

Şu anda bir şey açık ve net olduğunda, iyi uygulamaların ihlali: SRP'nin ihlali, Tanrı'nın nesneleri, yöntemler veya değişkenler için anlamlı olmayan isimler; Neyi düzeltmesi gerektiğini ve neden yanlış olduğunu açıklamaya çalıştığını işaret ediyorum.

Sorum şu: ne zaman duracağım? Şu anda, yanlış dilde değişken isimleri gibi kodlama stilinde bazı küçük ihlaller varsa (önceki ekip İspanyolca ve İngilizceyi karıştırdı ve düzeltmeye çalışıyorum) ya da bazı küçük yapısal sorunlar gider ve giderdim Boş zamanım var veya sorunlu sınıfı değiştirmem gerekiyor. Bunun takım moralinin iyi olduğunu düşünüyorum, bu yüzden sürekli bir aceminin küçük detaylar gibi gözüktüğü kodları sürekli olarak zorlamıyorum, bu da oldukça sinir bozucu olabilir, ama aynı zamanda 'yumuşak' olmanın erkeği engelleyebileceğinden endişe ediyorum. bazı şeyler yapmayı öğrenmek.

Ona adama öğretmekle onu sürekli eleştirmemekle dışlamak arasındaki çizgiyi nasıl dengeleyebilirim? Bir küçük çocuk için, gözlerinin işe yaradığı şeyleri tekrar yapmasını söylerseniz sinir bozucu olabilir.

Birleşmeden önce kodun düzeltilmesi gerektiğini düşünüyorsanız, yorum yapın. Tercihen "neden" ile dev öğrenebilir.

Kodun yazıldığından çok daha sık okundığını unutmayın. Bu yüzden "küçük" görünen şeyler aslında çok önemli olabilir (örneğin değişken isimleri).

Ancak, kendinizi sıkıcı görünen yorumlar yaparken bulursanız, belki de şunları göz önünde bulundurun:

• CI süreciniz bunları yakalamalı mı?
• Başvurmak için açık bir "geliştirici kılavuzu" var mı (veya kafanızda her şey belgelenmiştir)?
• Bu yorumlar kod kalitesine katkıda bulunuyor mu?

Birçok insan, süreç veya mükemmellik sunağında üretkenliği feda eder. Bunu yapmamaya dikkat et.

Mümkünse meslektaşınızı şahsen ziyaret etmeye çalışın. Veya görüntülü aramaları kullanın. Bir ilişki kurmak, eleştiriyi (hatta kod incelemelerini bile) yönetmeyi kolaylaştırır.

Bir kod parçasının konularda çok fazla ileri / geri geldiğini tespit ederseniz, daha küçük kod parçaları için incelemeyi isteyin. Artımlı değişikliklerin bazı önemli tasarım problemlerinden kaçınması daha muhtemeldir, çünkü daha küçüktürler.

Ama kesinlikle do not şeyler birleştirme ve sonra geri dönüp bunu düzeltmek. Bu pasif bir agresif ve geliştirici sizi bunu yaparken bulursa, onların moralini öldürürsünüz.

Eleştiriyi yazardan çok kod üzerinde tutun.

Üretilen her iş, içsel duygusal bağlanma ile gelir. Kodu yazardan mümkün olduğunca ayırarak bunu kolaylaştırmayı düşünün. Kodun kalitesi, aranızdaki sürtünme noktasından ziyade, ikinizin birlikte karşılaştıkları ortak bir hedef olarak oluşturulmalıdır.

Bunu başarmanın bir yolu, kelimelerinizi akıllıca seçmektir. Her ne kadar STEM bireyleri kendilerini oldukça mantıklı görmeyi sevseler de, duygular insan doğasının bir parçasıdır. Kullanılan sözbilim, incinmiş veya korunmuş duygular arasındaki fark olabilir. "Bu işlev adı, İngilizce olsaydı sözleşmelerle daha tutarlı olurdu" demek, "Bu işlev adını yanlış yazdınız ve İngilizce olmalıdır." İkincisi hala uysal ve tek başına iyi görünmekle birlikte, eskiyle kıyaslandığında hataları açık bir şekilde ortaya çıkıyor - ne şahsen ya da bir e-postayla ne söyleyeceğinizi hazırlarken içeriğinizin, kelimelerin ve odaklanmanın değil , konuların olup olmadığını inceleyin. kişi .

Vücut dili

Kelimeler önemli olsa da, çoğu iletişim sözsüzdür. Beden diline, oryantasyon matı gibi görünüşte önemsiz görünen inceliklere bile dikkat edin, örneğin birçok üst düzey genç etkileşimi yüz yüze gerçekleşir, ancak yan yana bir yaklaşım istediğiniz sonucu elde etmek için daha elverişli olacaktır.

Dürüst olumlu geribildirim verin

Çok sayıda çalışma, bilgiyi daha çabuk öğrendiğini ve kötü davranışları cezalandırmak yerine iyi davranışları ödüllendirdiğimizde daha iyi koruduğunu göstermektedir. Bazen sadece performansın basit bir "iyi iş" ya da daha spesifik bir şeyle geliştirildiğini belirtmek "Son zamanlarda stilinizin standartlarımızı bir tişörtle, harika işlerle eşleştirdiğini fark ettim!" Bu iyileştirmeyi tanımalarını sağlayarak bile, onlara, değiştirdikleri konularda başkasına tavsiyede bulunma, gençlerin ve çalışmalarının tüm farkını yaratabilir.

Adam eleştiriye açık ve öğrenmeye istekli ama bazı şeyleri ne kadar zorlamalıyım diye bazı şüphelerim var.

Elinden geleni yap. Eğer adam öğreniyorsa ve onun kodunu gözden geçirmek senin işinse, iyi bir iş çıkarsa ikisinin de kazanması gereken çok şey var.

Bu, gelecekte incelemesi için daha az kod anlamına gelir ve muhtemelen ekibinize işe alma hedefi verir.

Ayrıca, geri durursanız, yardımcı olmuyorsunuz, patronlaşma yapıyorsunuz.

Sorunuzu burada yayınladığınız gerçeğiyle, çok fazla bir şey yapıp yapmadığınızı sormak, bana bu özel tavsiyeye ihtiyacınız olmadığını zaten işaret ediyor, ama diğerleri için, işte bu geliyor: salak olmak.

Mentor olmak kolay bir iş değildir. Ayrıca bazı hatalar yapması ve kendi başlarına düzeltmesi için ona biraz yer vermeniz gerekecek, bunun gerçekten zarar vermeyecek bir yerde yapacağından emin olmalısınız.

Açıklamanıza dayanarak şunu bırakacağım: "Bu iyi. Farklı şekilde yapabileceğim birkaç şey var ama çok önemli değiller."

Kavradığınıza göre, eleştirinin bir bedeli var ve detaylara çok fazla zaman harcıyorsanız, moral sorunu olur. İdeal olarak, tüm kodlama standartları otomatik olarak kontrol edilir ve bunları izlemediğiniz sürece yapılamaz. Bu çok büyük bir zaman tasarrufu ve işe başlamanızı sağlar. Eleştirilerinizi 'önemli şeyler' için ayırırsanız, tavsiyeniz çok daha fazla etkiye sahip olacak ve değerli bir danışman olarak görüleceksiniz. İyi olmayan şeyleri ve tam olarak sizin yapma şekliniz olmayan şeyleri ayırt etmek gerçekten çok önemlidir.

Öğretilebilir anın konseptine inanıyorum . Eğer geliştirici yeterince zihinsel kapasiteye sahipse, farklı şekilde ne yapacağınızla ilgili detaylı bilgi isteyebilir. (S) olmayabilir ve sorun değil. İnsanlar tükenir ve bir kariyerin başlarında, daha sonra basit görünen şeyleri başarmak çok fazla zihinsel enerji alabilir.

Çalışmalarını kabul edilebilir olduğunda, mükemmel olmadığında kabul etmeyi düşünürdüm. Ve sonra bir sonraki görev, istediğiniz tüm küçük ama önemli değişiklikleri yaparak derhal yeniden yönlendirmek için yapılan bir tartışmadan sonra.

Bu yüzden iş ilk kez kabul edildiğinde mesajınız kötü değildi ve bazı yerler yeterince iyi kabul etmiş olacaktı - ama ticaretini doğru bir şekilde öğrenmek isteyen genç bir geliştirici olmak isteyebileceğiniz yerler değil.

Yani "İşini reddediyorum çünkü yeterince iyi değil" demiyorsun. (A) "Çalışmanızı kabul ediyorum çünkü bu yeterince iyi" ve ardından (b) "Ama daha iyisini istiyorum" diyorsunuz.

Oldukça geniş bir soru, ancak işte birkaç fikir.

1. Hakem değerlendirmesi (genç geliştirici tarafından)

   Birisinin "doğru" yolu öğrenmesinin en iyi yolu, diğerlerinin de yaptığını görmektir. Geliştiricilerinizin tümü kod incelemeleri yapıyor mu? Küçük geliştiricinizin de bunları gerçekleştirmesine izin vermek kötü bir fikir olmayabilir (bununla birlikte üst düzey bir geliştiriciden en az bir inceleme yapmanız da gerekir). Bu şekilde iyi kodlayıcıları çalışırken görecek, ayrıca kendisinin dışındaki mühendislere yönelik yorumların olduğunu ve bunun kişisel olmadığı anlamına geldiğini görecektir.

2. Erken geribildirim / Görev yorumları

   Geliştiricinin kendi görev dağılımına katılmasına izin verin. Amaçlanan tasarımını görev notlarına kaydetmesini ve değişiklik yapmadan ve sadece görevi yerine getirmeden bir "kod incelemesi" göndermesini sağlayın. Bu şekilde tek bir kod satırı yazmadan önce planını gözden geçirebilirsiniz. Görevi gözden geçirildikten sonra kodlamaya başlayabilir (daha sonra başka bir kod incelemesi gönderir). Bu, geliştiricinin bir sürü şey yazdığı ve onu yeniden yazmasını söylemeniz gereken moral bozucu durumdan kaçınır.

Eğer kod nesnel olarak yazılı ve net bir standardı ihlal ediyorsa, o zaman her mesele çözülene kadar geri itmeye devam etmeniz gerektiğini düşünüyorum. Elbette, ilk birkaç müteahhit için geliştirici için biraz can sıkıcı olabilir, ancak daha sonrakilerden daha erken puanlayıcıları da öğrenebilirler.

Ayrıca, burada ve orada birkaç standart ihlaline izin verirseniz, kötü bir emsal oluşturacaktır - kırık pencere teorisine bakınız . Ayrıca, daha önce tutarlı bir şekilde kod tabanına uygulanmışsa, standartlara uymayı hatırlamak çok daha kolaydır. Gerçekten, söz konusu genç geliştiriciler dahil herkes kazanıyor.

Kodlama standardı yazılı olduğu sürece moralin büyük bir sorun olduğunu düşünmüyorum. O içine alır Sadece eğer daha sübjektif "de, ben geliştiriciler yaklaşım gibi geçerli olabilir çünkü o zaman, ilgili olmalıdır, -territory o farklı yapardı".

Geliştiricilerin teklif ettikleri taahhütleri Github Pull Requests veya Phabricator Diffusion gibi bir araca gönderdikleri ve değişikliklerini paylaşılan ana şubeye koymadan önce eş oturumunu imzaladıkları bir kod inceleme iş akışı benimseyin.

Bu şekilde, geçmişe dönük olarak eleştirmek veya birinden daha önce yapılanları tekrar etmesini istemek yerine, meslektaş incelemesini geçinceye kadar çalışma henüz yapılmamıştır . Akranlarla yapılan ileri-geri alma, derleyici ile yapılan ileri-geri yazılım mühendisliği sürecinin bir parçasıdır.

Endişelerinizi belirli satırlarda yorum olarak gönderebilir ve onlar hakkında tartışmalar yapabilirsiniz. Aynısını koduna da yapabilir. Tartışma, önerilen özel kod değişikliklerine odaklanmaya devam ediyor ve genel olarak birinin performansına veya yetkinliğine değil.

Şirketimdeki mükemmel kıdemli mühendisler bile, kod incelemeleri yazım hatası yaptığında veya onları daha net hale getirmeye zorladığında minnettarlar. Yeni işe alımlarda daha fazla tekrarlama gerektirmesi tamamen normaldir. Zamanla, farklı bir gönderme yapmadan önce yorumları çekeceğini bildiğiniz problemleri refleks olarak düzeltmeye başlarsınız . İlk denemede kabul ettiğiniz farkların daha yüksek bir yüzdesini almak, nasıl geliştiğinizi bildiğinizdir.

Bir aceminin küçük detaylar gibi göründüğü kodunu sürekli olarak zorlamıyorum, bu oldukça sinir bozucu olabilir, ama aynı zamanda 'yumuşak' olmanın adamın bazı şeyleri nasıl yapacağını öğrenmesini engelleyebileceği konusunda endişeliyim.

Bunlar hem gerçek olasılıklar hem de geçerli endişeler. Geliştiriciye bu konuda ne düşündüklerini sorun.

Bazı çekme isteğinizin veya kod inceleme iş akışınız olduğunu varsayarsanız ve yaptığınız anlaşılıyor ki, "kritik olmayan" veya "tercih edilen" şeyleri bildirmenizi tavsiye ederim.

Bir PR'ı tanımladığınıza benzer bir durumda görürseniz, bazı küçük üslupsal konularla ya da kritik olmayan yeniden yapılanmaya ihtiyaç duyuyorsa, bir yorum bırakın, ancak onaylamaktan çekinmeyin. "Gelecekte, bunun gibi yöntem adlarından, tanımlayıcıMethodName gibi bir şey lehine kaçınmaya çalışın" gibi bir şey söyleyerek fikrini değiştirmeye veya gelişimlerini engellemeye zorlamadan belgeler.

Şimdi tercihinizi biliyorlar ve gelişmeye çalışıyorlarsa, gelecekte böyle bir durum olduğunu umuyorum. Aynı zamanda, o zaman sizin için hemfikir olduklarında ve yeterince eleştirel gördükleri takdirde, aslında o anda değiştirmeleri için kapıyı açık bırakırlar.

Kodlama fabrikasından uzaktan çalışan küçük bir geliştiriciyle uğraşıyorum.

Bu ne yazık ki ideal bir durum değil: acemi bir programcının sorumlusu ve coğrafi olarak ayrılan bir ileri programcı. Bir miktar gerginlik olması şaşırtıcı değildir, ancak eşitsizlik hafifletilebilir.

Merak ediyorum, "kodlama fabrikası" ile ne demek istiyorsun? Bu terminoloji bana göre, bahsettiğiniz yönetim sorunlarının bazılarını kötüleştiren rahatsız edici bir tavrı gösteriyor.

… SRP'nin ihlali, Tanrı'nın nesneleri, metotlar veya değişkenler için anlamlı olmayan isimler; Neyi düzeltmesi gerektiğini ve neden yanlış olduğunu açıklamaya çalıştığını işaret ediyorum.

Sanırım sorun, küçük geliştiricinizin uygun bir tasarım sürecinden geçmeden kod yaymasıdır. Bu, yönetici ve kıdemli geliştirici olarak, size rehberlik sağlama ve iyi yazılım geliştirme alışkanlıkları öğretme konusundaki başarısızlığınızdır. Önce bir taslak çizmek için birlikte çalışırsanız, hatalı kodun ilk başta yazılmasını engelleyebilirsiniz. Verimlilik ve moral açısından kod üretildikten sonra eleştirilmesi ve yeniden yazılması tercih edilir.

Muhtemelen iş akışınızı yeniden ayarlamanız gerekecektir. Size şu anda size ürünler sunmasını bekliyor gibisiniz. İhtiyacınız olan şey daha yakın işbirliği yapmaktır, böylece gelişimin her aşamasında rehberlik sağlayabilirsiniz. Kodlama başlamadan önce tasarım ve arayüz hakkında konuşun. Kodlama devam ederken, sorunları daha önce yakalamak için daha sık kontrol noktaları uygulayın. Mümkünse, bir ses kanalıyla ekran paylaşarak çift programlamayı deneyin.

Bunların hepsi sizin için daha fazla çaba gerektirecek, ancak şu anda sahip olduğunuz problemli ilişki göz önüne alındığında, muhtemelen faydalı olacaktır.

Kodlama standartlarına aykırıysa, nerede olduğunu bildiği şekilde gösterin. Ona aynı hatayı göstermeye devam etmek zorunda kalırsan, o zaman kurallara uymayan ya da reddedecek biriyle bir sorunun olabilir. Hataları düzeltmek için boş zamanını kullanmayın. Bu kişi kendi hatalarını düzeltmeli, böylece bir daha yapamazlar.

Onlara her zaman doğru yaptıklarını ve bir dahaki sefere nasıl iyileşebileceklerini söyleyin. Bazı bölgelerde her zaman daha iyi olabiliriz. Her şeyde daha iyi olmak için geri bildirim önemlidir.

"Çok fazla eleştiriyle" başa çıkmanın bir başka fikri zaman zaman kendiniz için bir görev yapmak ve küçük geliştiricinin sizin için bir kod incelemesi yapmasına izin vermek. Bunun en az iki avantajı var:

• işlerin nasıl yapılması gerektiğini öğrenebilirler.
• Birden fazla iyi çözüm veya değişken ismi olduğunda, farklı fakat (neredeyse?) eşit derecede iyi yaklaşımların önerilerini kabul ediyorum. Birinin yorumu nedeniyle kodumu düzelttiğimde, insanlara saygı duyulduğunu ve eleştirinin her zaman yalnızca kod ile ilgili olduğunu - yazarın kim olduğuna bakılmaksızın gösteriyorum.