İpimin sonunda [kapalı]


17

Ben büyük bir şirketin yüklenicisiyim. Şu anda, projede kendim dahil üç geliştirici var.

Sorun, diğer 2 geliştiricinin gerçekten anlamadığıdır. "It" ile aşağıdakileri kastediyorum:

  • Kullandığımız teknoloji için en iyi uygulamaları anlamıyorlar. 6 ay sonra ve onlara örnek verdikten sonra korkunç anti-kalıplar kullanılıyor.
  • Öncelikle spagetti kodu üreten "kopyala ve yapıştır" programcılarıdır.
  • Onlar sürekli değişikliklerin uygulanması ancak tüm iyi olup olmadığını görmek için bir temel duman testi yapmıyor, şeyleri kırmak
  • Kod değerlendirmeleri için sormayı reddediyorlar / nadiren.
  • Kod biçimlendirme gibi temel şeyleri reddeder / nadiren yaparlar.
  • Hiçbir sınıfta belge yok (jsdocs)
  • Hiçbir şey yapmayan kodu silmekten korkuyor
  • Sürüm kontrolümüz olmasına rağmen yorumlanmış kod bloklarını her yerde bırakın.

Kendimi başkalarının kodunu biçimlendirirken, hataları düzeltirken, bozuk işlevselliği keşfederken ve spagetti'yi kaldırmak için soyutlamalar oluştururken kendimi giderek daha fazla hayal kırıklığına uğratıyorum.

Gerçekten ne yapacağımı bilmiyorum. Sinirlenmemeye çalışıyorum, ama bu sadece bir karmaşa. Bu insanları insan olarak seviyorum, ancak kodlama durumunun o kadar kötü olduğunu hissediyorum ki, bütün gün internette dolaşırlarsa daha hızlı hareket edebilirim.

Bizim svn taahhüt erişim gözden geçirmek bizim yöneticiden sormak için çizgi dışında olurdu; taahhütler ancak ne yaptığımızı bilen biri tarafından gözden geçirildikten sonra yapılabilir mi? Bir müteahhit olarak, bunun en iyi hamle olup olmadığından emin değilim.

Kaç şeyi düzelttiğimi netleştirmenin ince / ince olmayan bir yolu var mı?


1
Bu soruya yanıt olarak ekibinizin yaşadığı gerçek sorunu genelleştirdiğini düşündüğüm bir soru açtım: programmers.stackexchange.com/questions/127117/… . Otomatik testler sunmaya gelince, Martin Blore'nin gönderisine kesinlikle katılıyorum: martinblore.wordpress.com/2010/06/02/… - iyi ilkeler ve temeller olmadan TDD'nin çabaları boşa gidecek. Merak ettiğim için yazıma da bu temeli sıfırlamaya çalıştım.
DXM

benim sorunum test sadece işlevselliği çalıştığını doğrulamak olmasıdır. Listelediğim diğer 7 maddeye hitap etmiyorlar.
hvgotcodes

1
Bu adamlarla ikili programlamayı denediniz mi? onlar sizin fikrinizi görür ve tek bir makinede oturup tek bir işlevsellik geliştirirseniz onlarınkini görürsünüz. Bir ay, haftada 3 gün, günde 3 saat yapın. Yardımcı olabilir. Ayrıca CI oluşturun ve kod kapsamı ve test senaryosu geçiş oranı metriklerini yayınlayın. Bunlardan herhangi biri ihlal edilirse yapı başarısız olsun.

Yanıtlar:


7

Ekibimde böyle bir şey var. İnsanların doğru şeyi yapmalarını sağlamaya çalıştım ve beklendiği gibi çalışmadı, bu yüzden farklı bir çözüme geçtim.

İlk olarak yöneticime gittim ve bir anlaşma yaptık, birim testlerin kapsamına girmediği sürece kaynak kontrolüne hiçbir kod girmez. Kod birim testleri olmadan girerse, taahhüdü hemen geri almak için veto gücüne sahibim ve sorumlu olan ping testlerde çalışabilir ve daha sonra kodu itebilir.

Yerine bu kural ile, düzenli (bu durumda, kod kapsamı araçlarını çalıştırmak jacoco bizim de sbt yapı) emin parçalar doğru kaplıdır ve ben de onlar tarafından itilen herhangi bir kodda sürekli refactorings ve kod değerlendirmeleri yapıyorum yapmak. Bu bir Java ve Scala projesi olduğundan, orada olmaması gereken veya düşündüğümüz şekilde çalışmayan, JavaScript ile aynı şeyi nasıl yapabileceğinizden emin olmayan şeyler yakalamama yardımcı olacak birçok aracım var. bir çözüm.

Buna ayak uydurmamda yardımcı olduğum ana şey, projeden ne beklediğime ve ana mimarisine ilişkin net bir görüşe sahip olduğum, bu yüzden bu görüşü yansıtmayan bir şey gördüğümde oraya gidebilirim düzelt. Aynı şeyi yapmalı, görüşünüzü, kullanılması gereken kalıpları, kodun yazılması ve kendinizi bunun üstünde tutmalı, daima (ve yönetiminizin) neler olduğunu ve projenin neyin devam etmesini engellediğini bilmelisiniz Daha hızlı.

Kesinlikle vazgeçtikleri ve doğru olanı yaptıkları ya da yönetimin mesajı aldığı ve projeden çıkardığı bir an olacaktır.


5
Buradaki sorun (ve bu sorunun çok yerel olup olmadığından emin değilim çünkü altta yatan neden çok yaygın olduğunu düşünüyorum) geliştiricilere "gerçek ve denenmiş" kopya uygulamalarına güvenmek yerine öğrenmeleri ve büyümeleri için nasıl ilham vereceğinizdir. yapıştırarak spagetti'leri işler. OP gözetmen / gözden geçiren / onaylayan rolüne geçerse, kendi zamanını önemli ölçüde azaltacaktır. Aynı zamanda, kötü kod yazan insanlar, daha kötü birim testleri yazıyorlar. Daha da yavaş gidecekler, sürdürülemeyen testler yazacaklar ve daha sonra birim testlerin işe yaramadığını ve önerdiğiniz için sizi suçladığını gösterecekler
DXM

dxm, evet bu bir sorun. Sorumun nedeni, bu sorunun yönetime nasıl getirileceğidir, ancak muhtemelen çok açık olmadığını itiraf ediyorum.
hvgotcodes

2
Yönetime bu almak için en iyi seçenek kodlarının ne kadar yeniden gerektirir ve bu ne kadar anlık israf olduğunu göstermek olduğunu düşünüyorum.
Maurício Linhares

7

Eminim şu anda yorumlarımı ve diğer yazımı gördünüz, bu yüzden cevabı gerçekten bildiğimi iddia etmeyeceğim. Sunabileceğim en iyi, başkalarından duyduğum / okuduğum şeyin bir özeti ve kendi deneyimlerimin bir kısmını karışıma eklemek.

İlk olarak, bir süre önce kendi Programcılar SE üyelerimizden biri olan Martin Blore ve IMO'ya ait bir blog ile karşılaştığımı söylemek istiyorum, TDD kendini gerçekleştirme ile ilgili bu özel yazı çok doğru. TDD, her şeyi birbirine bağlayan son, en yüksek seviyedir, ancak önceki seviyeler, özellikle de en büyüğü olmadan, açık ve okunabilir kod üretme ilke ve uygulamaları, TDD'nin çalışması imkansız değilse çok zor olacaktır.

Şirketimde, hem Agile hem de TDD bize yönetim tarafından empoze edildi ve ilk başta bunları basitçe yaptık çünkü söylendi (çevikliğin tersi). TDD'yi iki kez denedik ve otomatik testleri kullanmanın büyük bir savunucusuyken, ekibin son sürümde birlikte tokatladığı herkesi şahsen attım. Kırılgan, devasa, wazoo'yu kopyaladı / yapıştırdılar ve onları gerçekten yavaş ve öngörülemez bir şekilde çalıştıran uyku ifadeleriyle bilmiyorlardı. Ekibiniz için tavsiyem: TDD YAPMAYIN ... henüz.

Durumunuzun ne olduğunu bilmiyorum çünkü sadece 6 aydır şirkette olduğunuzu ve müteahhit olduğunuzu söylediniz. Bu şirkette kalmak için uzun vadeli hedefleriniz mi var, yoksa sözleşme bitecek mi? Soruyorum çünkü bir şey yapsanız bile, sonuçları görmek biraz zaman alabilir.

Ayrıca bir ekibe katıldığınızda, ekibinizin (geliştiriciler ve yönetim) önerdiğiniz herhangi bir şeyi bile dikkate alacağı yeterli derecede güvenilirlik ve saygı duymanız genellikle zaman alır. Deneyimlerime göre, birkaç yangın çıkarır ve başkalarının güvenebileceği beceri ve bilgiye sahip olduğunuzu gösterirseniz yardımcı olur. 6 ayın yeterli olup olmadığından emin değilim. Sık sık yeni, hırslı bir kişi takıma katılıp, burada dünyayı nasıl değiştirebileceklerini soran bir yazı yapardı. Üzücü gerçek şu ki yapamazlar.

Yani ekibinizin saygısını ve ilgisini aldığını varsayarsak. Şimdi ne olacak?

İlk olarak, hem yönetim hem de geliştiricilerin bir sorun olduğunu bilmeleri gerekir. Yönetim sonuçları yapılan iş açısından ölçer. Mevcut özellik ve nicelikten memnunlarsa, üzücü gerçek, dinlemeyecekleridir. Diğerlerinin de belirttiği gibi, yönetimin desteği olmadan, her türlü değişikliği uygulamak son derece zor olacaktır.

Yönetim desteği aldıktan sonra, bir sonraki adım derinlemesine kazmak ve takımın neden olduğu gibi çalışmasının temel nedenlerini belirlemektir. Bu sonraki konu, kısa bir süredir benim kişisel arayışım olan bir şey. Şimdiye kadar bu benim yolculuğumdu:

  1. Bir kez yönetim desteğiniz var. Bunu merkezi diktatörlüğü uygulamalar / süreçlerin çok tanıtan başlayabilirsiniz MainMa cevaben önerdi sorumu . Birçoğunu yaptık (eşli programlama hariç) ve kesinlikle faydaları görüyorsunuz. Kod incelemeleri özellikle şekillendirme, dokümantasyon üzerinde standartlaşmaya yardımcı oldu ve aynı zamanda ekip arasında bilgi / teknikler paylaşmamızı sağladı. Kod incelemeleri dikte edilmiş olsa da, ekip onları gerçekten seviyor ve teslim edilen her işlevsellik parçasını gözden geçiriyoruz.
  2. Genel olarak yazılan kodun hala çok eşli olduğunu, tasarımın kötü veya tamamen eksik olduğunu fark ettiniz. Kod incelemeleri bazılarını yakalar, ancak yeniden yazabileceğiniz çok şey vardır. Tasarım ilk etapta neden kötü? - Pek çok geliştirici asla iyi uygulamalarla tanışmamış ve ilk etapta resmen OOD öğretilmemiştir. Bir çok insan hangi görevi yaparsa yapsın "basitçe kodladı".
  3. Yönetimin desteği ile herhangi bir kodlama yapılmadan önce tasarımın tartışılması gibi daha fazla süreç sunabilirsiniz. Ama sen sadece bir insansın ve dikkatini çekmez etmez takım her zaman yaptıkları şeye geri döner. Neden?
  4. Daha iyi uygulamalar veya alışkanlıklar tanıtılabilir ve öğretilebilir, böylece sürekli izlemeniz gerekmez mi? - Bu bölümün o kadar kolay olmadığı ortaya çıktı.
  5. Diğer takım üyeleri neden yeni uygulamalar öğrenmek ve almak konusunda isteksizdirler ve modern yazılım metodolojisi literatüründe bu kadar çok şey yazıldığı zaman neden SOLID veya DRY'ye karşı bu kadar dirençlidirler? Ekibimde yaptığımız tüm olumlu değişikliklerle, 2 hafta önce 15 satırlık özdeş koda sahip 2 işlevi yeniden düzenledim ve inceleme yapan kişi kahraman, gereksiz çaba dedi, çünkü sadece kopyala / yapıştır ile yanlış bir şey yok 15 satır. Bu tür görüşlere kesinlikle katılmıyorum ancak şimdilik katılmamaya karar verdik. - Peki şimdi ne olacak? Şimdi diğer yazımın konusuna ulaştık .
  6. As maple_shaft ve nikie onların cevapları (pardon, işaret MainMa , sen en çok oyu var, ama sen 5 adım gerisinde böylece vardır :)), bu forumunda bir sahne "süreç" artık yardımcın olsun ve kimse ulaşmış size "düzeltmenin" ne olduğunu söyleyebilir. Bir sonraki adım, bireylere, belki bire bir, belki bir takım olarak, muhtemelen hem bir seferde hem de diğerinde yaklaşmak ve onlarla konuşmaktır. Onlara, neyin işe yarayıp neyin yaramadığını sorun. Onları yönlendiren şeyin temel nedenini tanımlamanın tek yolu şimdi onlarla bireysel olarak konuşmak ve bunu bulmaktır. Bu adımın bir parçası olarak, son zamanlarda tamamen farklı bir takım problemiyle karşılaştım, ancak sanırım Joel'in cevabı buradaçok detaylı ve anlayışlı olan bu dava için de geçerlidir. Özetle, yönetimi "kısa tasma" olarak kullanmak hemen hemen her şeye olası bir yaklaşım olsa da, insanlarla uğraştığımızı hatırlamalıyız ki motivasyonları gerçekten anlamak için saf yönetim veya teknik liderlikten daha çok psikanalize geçmeliyiz.
  7. Şimdi takım arkadaşlarınızla mı konuşuyorsunuz? Onlara ne soruyorsun? Bir sonraki kısımdan emin değilim çünkü burada hiç bulunmadım. İşte olası bir senaryo: S: Nasıl SOLID gelmiyor? C: Buna ihtiyacım yok. S: Yardımcı olabilir. C: Olduğu gibi yaparım. - Her nasılsa, ağzınızı terk edecek ve dinleyicinin, bir şansı yakaladığınız her şeyi verirlerse, işlerin daha iyi olabileceğini fark etmesine neden olacak bir dizi ses oluşturmanız gerekir. Burada başarısız olursanız, "süreç" ne yaparsa yapsın aslında herhangi bir değere sahip olduğuna ikna olmazlar. Öte yandan, bu noktadan geçerseniz, muhtemelen artık "sürece" ihtiyacınız olmadığını göreceksiniz.
  8. IMO en temelde, takım arkadaşlarınız mevcut alışkanlıkları / uygulamaları ile ilgili yanlış bir şey görmediklerini öğrenmezler. Belki de bundan sonraki adım, açıklamak, sorunları açıklamak ve açıklığa kavuşturmak için bir yol bulmaktır. Sonuçta, bize sıcak ve bulanık bir his verdiği için okunabilir kod yazmıyoruz, SOLID / DRY ilkelerini kullanmıyoruz veya belgeleri koruyoruz. Bunu yapıyoruz çünkü daha kaliteli kod üretiyor ve açıkçası bizi daha hızlı kodlıyor. Bu ölçülebilir mi? Belki de bu noktada yazılım metrikleri devreye giriyor?
  9. İşte çılgın bir fikir ve gerçekten işe yarayıp yaramayacağı hakkında hiçbir fikrim yok (standart bir endüstri uygulaması olabilir ya da tamamen geçersiz olabilir. Son 24 saat içinde uydurdum), ama getirmek için çok cazipim gelecek yıl başlar başlamaz masaya:
    • Diğerlerinin görüşlerine karşı , tüm kaynak dosyalar için Yazar / Sahip fikrini tanıtın. Pragmatik Programcı'nın da belirttiği gibi , bunun bir kaynak koddan sorumlu olacak tek bir kişiye sahiplik ve sorumluluk duygusu vermesi. Bu, diğer kişilerin kodu değiştiremeyeceği anlamına gelmez, hepimiz bir ekip olarak çalışıyoruz, ancak günün sonunda, kodun sahibi olan kişi değişiklikleri incelemekten sorumludur.
    • Tüm check-in'leri izleyen ve özellikle hata düzeltmeleri arayanları arayan bir kaynak havuz tetikleyicisi oluşturun. Her hata düzeltmesinin check-in açıklamasının hemen önünde bir referans tanımlayıcıya sahip olması için bir işlem yapın. Şimdi, değiştirilen dosyaların listesini ayrıştıracak bir komut dosyası yazın ve "Yazar" ı dosya başlığı yorum bloğundan çıkarın. Dosya başına / proje başına / yazar başına teslim edilen kusurların sayısını izleyecek bir SQL veritabanı oluşturun.
    • Yeterli istatistiğiniz olduğunda, kodunuzun diğer kodlardan bazılarından daha az kusur / değişiklik içerdiğini umarsınız. Bu kullanabileceğiniz zor verilerdir. Tek bir projenin ortalama kusur oranının çok üstünde olması halinde, projeyi bir miktar teknik borcu geri ödemek için bir sonraki temizlik / yeniden düzenleme çabasına aday olarak getirin.
    • Bir proje veya dosyanın ortalama hata oranının çok üzerinde olması ve bir sahibi varsa, o kişiyle bire bir görüşün. Onlara, kibarca, çatışmasız bir şekilde, bunu ele almak için neler yapabileceklerini sorun. Onlar sahibi olduklarından, onlar değişiklik sürücü, ancak yanınızda herhangi bir ve tüm yardım sunuyoruz. Umarım, sahibi kendi spagetti kodunun birçok nedenini izler ve yardım istedikleri anda, eyleme geçtiğinizde ve bazı SOLID'leri koyduğunuzda.

1
bu mükemmel, teşekkürler. Daha önce bu tekniklerin bazılarını denedim (Jen *, neden kod biçimlendiricinizi x, y, z, 2 dakika sürecek şekilde değiştirmiyorsunuz) ve her zaman dudak hizmeti alıyorum ve hiçbir şey olmuyor. Ayrıca, meslektaşlarımdan biri açıkça diğerinden daha güçlü; çok iyi olabileceği, ancak idam edemediği yerde. Kod kalitesi hakkında her zaman konuştuğunu duyuyorum, ama aynı zamanda harekete geçme zamanı geldiğinde bir kabuğa dönüşüyor: "serbest bırakmak için sadece 5 haftamız var, şimdi hiçbir şeyi yeniden düzenlemek istemiyorum". Ve ben facepalm. * isim değiştirildi
hvgotcodes

kod biçimlendiricisine (veya belirli bir şeye) odaklanmıyorsanız. Yerine sadece Jen konuşmak ve takım sorunları gibi konularda (örneğin "Ben bazılarını fark bazılarını getirmek bizim kod çok okunabilir değil, bunun neden olduğunu düşünüyorum bize önlenebileceği hata yapma"). Hiçbir şey önermeyin, ancak Jen'in olası çözümleri düşünmesine izin verin. Ayrıca önerilerinizi kaynaklarla yedeklediğinizde yardımcı olduğunu buldum. Demek yerine, derseniz, ne "Sanırım değişkenlerin daha iyi adlandırma üzerinde çalışmaya gerek" "Ben Temiz Kodu okudum ve yazar çok iyi bir noktaya vardı düşünüyorum en ... deneyelim" durmak ...
DXM

... bununla Jen'in isimlendirmenin önemli olmadığını gösteren bir kitap bulması gerekecekti. Ve geri dönen insanlar hakkında ne demek istediğini biliyorum, bu doğal ve bunun nedeni, baskı altındayken, "önemli" şeylere yönelik çabalarınızı serbest bırakmak için konfor bölgenize geri dönmenizdir. Ekibinizi kaliteyi ve öğrenmeyi geliştirmekle bir araya getirseniz bile, iyi alışkanlıklara dönmeye başlamadan önce birkaç sürüm alacaktır. Sadece sabırlı ol, savaşlarını seç ve bazı şeylerin kaymasına izin ver
DXM

2

Sorun hakkında yöneticinizle konuşmanızı öneririm, ancak neredeyse her check-in'i gözden geçirmek istemeyecek.

Bunun yerine, SVN'ye bağlanmak ve her check-in için çalıştırmak için bir birim / regresyon testleri paketi önermenizi öneririm. Bu en azından kırık yapılardan kaçınmanıza yardımcı olacaktır. Yavaş yavaş diğer en iyi uygulamaları önerebilirsiniz.

Tamamen aldatıcı olduğu ortaya çıkarsa, belki de başının üzerinden geçmelisin. Bunu yapmaya karar verirseniz, en iyi oyununuzu getirmeniz gerekir. Bunu yaparsanız, temel olarak daha yüksek bir seviyede işe alınacak yönetime adım atacaksınız.


1
Bu müşteri tarafı çalışması olduğunu belirtmedim. otomatik fonksiyonel testler boru hattıdır, ancak birim testler değildir, bu nedenle geri bildirim günlük değil, günlük olacaktır.
hvgotcodes

2
@hvgotcodes: Bunun neden her checkin'de ünite testleri oluşturmanızı engellediğini anlamıyorum.
Marcin
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.