Meslektaşım önceden haber vermeksizin gereksiz iyileştirmeler yaptığında kodumun sorumluluğunu nasıl alabilirim?


71

Ekip arkadaşlarımdan biri, BT mağazamızdaki tüm işlemlerin bir jack'ı ve onun görüşüne saygı duyuyorum.

Ancak bazen kodumu gözden geçiriyor (ekip liderimize ikinci sırada geliyor, bu yüzden beklendiği gibi). Bazen, hedefimi tamamlamadan önce değişikliklerimi gözden geçirir ve değişiklikleri hemen yapar ... ve bir kere bile işimi bozdu.

Diğer zamanlarda, kodumu 3 + aylık olan bazılarında gereksiz iyileştirmeler yaptı.

Bu beni birkaç nedenden dolayı rahatsız ediyor:

  1. Hatalarımı düzeltmek için her zaman bir şans verilmez
  2. Bana karıştığında ne yapmaya çalıştığımı sormaya zaman ayırmadı, bu da testlerini veya değişikliklerini etkileyebilir.
  3. Her zaman kodunun okunabilir olduğunu düşünmüyorum.
  4. Son tarihler bir sorun değildir ve mevcut iş yükü, projelerimde kod değişikliklerimı incelemekten başka hiçbir iş gerektirmiyor.

Her neyse, geçmişte ona işimde değiştirmek istediği bir şey görürse, kodumun mülkiyetini alabilmem için (belki de "eksiklikler" demeliydim) ve cevap vermemesi için beni haberdar etmesini söyledim. .

Bana değişikliklerini açıklamasını istediğimde saldırgan olarak gelebileceğimden korkuyorum.

O sadece kendini tutan sessiz bir insan, ama eylemleri devam ediyor. Onu kod değişikliği yapmaktan çıkarmak istemiyorum (yapabildiğim gibi değil), çünkü biz bir takımız - ancak ekibimize yardım etmek için üzerime düşeni yapmak istiyorum.

Ek açıklamalar:

  • 1 geliştirme kolunu paylaşıyoruz. Tüm değişikliklerim tek bir görevi tamamlayana kadar beklemiyorum, çünkü önemli bir işimi kaybetme riskim var - bu yüzden değişikliklerimin bir şey yapıp bozmadığından emin oluyorum.
  • Endişem, takım arkadaşımın değişikliklerinin arkasındaki nedeni veya amacı açıklamadığıdır. Nimetime ihtiyacım olması gerektiğini düşünmüyorum, ancak bir yaklaşıma katılmıyorsak, hem artıları hem de eksileri tartışmanın ve ikimizin de neler olduğunu anladıktan sonra bir karar vermenin en iyi olacağını düşündüm.
  • Bunu, ekibimizin liderleriyle görüşmedim, ancak gerekli olmadıkça yönetime dahil olmadan kişisel anlaşmazlıkları çözmeyi tercih ederim. Endişem, işimize yönelik bir tehditten daha kişisel bir konu gibi göründüğü için takım liderini rahatsız etmemeyi seçtim. Kod inceleme süreci fikirleri üzerinde çalışıyorum - daha düzenli kod incelemelerinin faydalarını, evcil hayvanımın tümü hakkında yapmadan geliştirmeye yardımcı olmak için çalışıyorum.

20
Kod deponuz için git, CVS veya TFS kullanıyor musunuz? Sadece taahhütlerini geri al. Sonunda

6
Kuruluşumda, tüm kod değişikliklerinin bir tür gözden geçirmeden geçmesi gerekiyor ve gözden geçirenin kim olduğunu belirten açıklamada belirtmeden bir değişikliği kontrol etmek için kötü bir form olarak kabul ediliyor. Kuruluşunuzda bu prensibi tanıtmak, yazmadan önce yazdığınız kod değişikliklerini kontrol eden iş arkadaşlarınızın incelemesi olmadan uzun vadeli bir çözüm olabilir.
Carolyn

13
Paylaşılan bir dalda neden bitmemiş değişiklikleriniz var? Bu kötü bir fikir ve yalnızca karşılaştığınız nedenle değil.
hyde

15
Elbette bu, hangi VCS'yi kullandığınıza bağlıdır, ancak dalları daha çok kullanmaya başlamak için bakılması gereken bir şey olabilir. Kişisel şubeyle, endişelenmeden hissettiğinizde kendinize karar verdiğinizde (ve DVCS ile zorlayabiliyorsanız) birleştirin ve yalnızca bir parça ile bittiğinde birleştirin ya da sadece gerektiğinde kısmen birleştirin (iyi bir DVCS bunu oldukça kolaylaştırır) harikadır. Ayrıca kod incelemesiyle harika çalışıyor, doğal olarak yapabiliyor ve birleştirmeden önce sorunları çözebiliyorsunuz.
hyde

4
@Jesslyn - Takım arkadaşın takım arkadaşının eski kodda gereksiz iyileştirmeler yapmak için zaman harcadığından endişeleniyor mu? En azından, takım arkadaşınızın daha yüksek öncelikli işlerde çalışmak yerine gereksiz değişiklikler yapmak için zaman harcaması yetersiz görünüyor. Ek olarak, takım arkadaşınız sizi kendiniz yapmaya zorlamak yerine kodunuzu "düzeltmek" için zaman harcamayı tercih ederse, bu da oldukça verimsiz görünüyor. Bu endişelerden herhangi birini takım liderinizle konuştunuz mu?
Cliff

Yanıtlar:


81

Bence çoğu geliştirici bir noktada kendilerini bu pozisyonda buluyor ve mağdur olduğunu hisseden her geliştiricinin kendisinin kıdemli olduğu zaman ne kadar sinir bozucu olacağını fark edeceğini ve gençler tarafından yazılan kodu silmek zorunda kaldığını umuyorum.

Benim için bu durumda çatışmadan kaçınmak iki şeye iniyor:

  1. Nezaket . Biriyle onun kodu hakkında konuşmak, bir kişinin ilgilendiğinizi bilmesini ve bunu yetişkinler olarak tartışabileceğinizi bilmesini sağlar.

  2. "Kod sahipliğini" unut - ekip kodun sahibidir . Değişiklikleri yapmak isteyen diğer insanlar iyi bir şeydir. Üst düzey bir geliştirici, "okunamayan" veya daha kötü olan değişiklikler yaparsa, bunları geri alın. Agresif olmanıza gerek yok, sadece bir editöre değişikliklerinin işe yaramadığını bilmesini sağlayın ve dönüşünüzü tartışmaktan çok mutlu olursunuz.

Unutmayın, kodun ekip sahipliği harika ve her iki yolu da kesiyor. Başka birinin kodunda anlamlı olmayan bir şey görürseniz düzeltin. Aşırı derecede sahiplikçi ve yetersiz iletişimsel olmak, zehirli bir gelişme ortamı yaratmanın kesin yoludur.


4
Bence bu, Nokta 1'e iniyor - onunla bir tartışma yapalım. Orijinal geliştiriciye karşı kodun değiştiği gerçeğini saymak berbat bir yönetimdir (gerçekleşmeyeceğini söylemiyorum) ve daha iyi metrikler için dilekçe vermeniz gerektiğini savunuyorum. Gerektiğinde ve ne zaman olursa o köprüyü geç.
Michael,

2
Bence hepimiz odaklanmamız gereken şey budur - genel olarak, takım arkadaşlarınız sizi kötü görünmek için dışarı çıkmaz - analiz etmek için zaman harcamayın, sadece daha iyi olun ve ekibin daha değerli bir üyesi (bunun daha kolay olduğunu biliyorum) daha olsa bitti!)
Michael

7
Jessica, eğer sana yapıyorsa, herkese yapıyordur. Kimsenin bunu sana karşı saydığından şüpheliyim. (Herkese yapmıyorsa, farklı bir probleminiz olabilir)
user606723

3
@tgkprog: (1) Elbette, diğerlerinden geri bildirim almak çok önemlidir ve başkalarının koduna bakmaktan birkaç şey öğrendim ama (2) eğer birbirinizden öğrenmek istiyorsanız bir değişiklik öneriniz ve birlikte tartışmalısınız. . Sadece rastgele şeyleri değiştirmek, çünkü değişikliklerin doğru bir yaklaşım olmadığından sonra kodun daha iyi olduğunu düşünüyorsunuz. İnceleme araçlarını kullanarak kod incelemeleri gibi daha iyi yaklaşımlar vardır.
Giorgio

2
evet 11:00 de ölü bir satırdan önce başkalarının kodunu düzelttiğim zamanları düşünüyordum, ancak o zaman bile takıma bir posta gönderecekti, böylece
QA'mız da

86

Siz ve cevap verenlerin çoğu, iki meslektaş arasında bu bir iletişim sorununa yaklaşıyor, ancak ben öyle olduğunu sanmıyorum. Tanımladığınız şey, her şeyden çok , korkunç derecede bozuk bir kod inceleme sürecine benziyor .

İlk önce, meslektaşınızın ikinci sırada olduğunu ve kodunuzu gözden geçirmesi beklenir. Bu açıkça yanlış. Tanım olarak, eş kod incelemeleri hiyerarşik değildir ve kesinlikle sadece kusurları bulmakla ilgili değildir. Ayrıca, öğrenme deneyimleri (katılan herkes için), sosyal etkileşim için bir fırsat sunabilir ve ortak kod sahipliği oluşturmak için değerli bir araç olduğunu kanıtlayabilirler. Ayrıca zaman zaman kodunu gözden geçirmeli, ondan bir şeyler öğrenmeli ve yanlış olduğu zaman onu düzeltmelisin ( her seferinde kimse onu doğru bulmaz ).

Ayrıca, meslektaşınızın derhal değişiklikler yaptığını söylersiniz. Bu da yanlış, ama elbette zaten biliyorsun; Gung ho yaklaşımının bir sorun olmadığını, bu soruyu sormazdın. Ancak yanlış yerde bir çözüm aradığınızı düşünüyorum. Dürüst olmak gerekirse, meslektaşınız bana biraz ... bana hatırlatıyor ve benzer durumlarda benim için çalışan iyi tanımlanmış ve sağlam bir inceleme süreci ve bir dizi harika araç oldu. İş arkadaşınızdan kodunuzu incelemesini durdurmak istemezsiniz ve her küçük değişiklik işe yaramayacaksa ondan önce sizinle konuşmasını isteyin. Bir süre olabilir, ancak yakında çok sinirleneceği bir noktaya ulaşacak ve başladığınız yere geri döneceksiniz ya da daha da kötüsü: sadece kodunuzu incelemeyi bırakacak.

Buradaki bir çözümün anahtarı, bir eş kod inceleme aracı olabilir. Genellikle ürün önerilerinden kaçınırım ancak kod incelemeleri için Atlassian's Cruciblegerçekten bir hayat kurtarıcı. Yaptıkları çok basit görünebilir ve öyle, ancak bu şaşırtıcı bir şekilde harika olmadığı anlamına gelmiyor. Deponuza bağlanır ve size tek tek değişiklik setlerini, dosyaları veya dosya gruplarını inceleme fırsatı sunar. Herhangi bir kodu değiştiremezsiniz, bunun yerine doğru hissetmeyen her şey hakkında yorum yaparsınız. Ve kesinlikle başka birinin kodunu değiştirmeniz gerekiyorsa, değişikliklerinizi açıklayan değişiklik setiyle ilgili bir yorum bırakabilirsiniz. Daha fazla ayrıntı istiyorsanız, Crucible'ın ürün sayfasındaki tanıtım videosu izlemeye değer. Potanın fiyatı herkes için değildir, ancak serbestçe temin edilebilecek çok sayıda akran değerlendirme aracı vardır. Çalıştığım ve keyif aldığım biri Review Board ve basit bir Google aramasıyla başkalarını bulacağınızdan eminim.

Hangi aracı seçerseniz seçin, sürecinizi tamamen değiştirecektir. Durmanıza, sandalyenizden çıkmanıza, diğer kişiyi rahatsız etmenize ve değişiklikleri tartışmanıza gerek yok; Yapmanız gereken tek şey, her hafta biraz zaman ayırıp yorumları incelemektir (haftada bir öneridir. Programınızı ve günlük rutini benden daha iyi bilirsiniz). Daha da önemlisi çekirdek incelemeler bir yerde bir veritabanında saklanır ve istediğiniz zaman geri alabilirsiniz. Su soğutucusu etrafında geçici tartışmalar yapmıyorlar. Eski incelemelerde en sevdiğim kullanım durumu, kod tabanımıza yeni bir ekip üyesi tanıtırken. Tam olarak nerede sıkışıp kaldığımızı, farklı fikirlerin olduğunu vb. Belirten kod tabanında yeni birisine yürüyebildiğim zaman her zaman güzeldir.

Devam edersek, bu meslektaşın kodunu her zaman okunabilir bulmadığınızı söylersiniz. Bu, ortak bir kodlama standardı dizinizin olmadığını ve bu kötü bir şey olduğunun haberini veriyor. Yine buna bir halk sorunu olarak yaklaşabilir ya da buna bir süreç sorunu olarak yaklaşabilirsiniz ve yine ikincisini şiddetle tavsiye ederim. Takımınızı bir araya getirin ve en kısa sürede ortak bir kodlama stili ve standartlar dizisi benimseyin. Gelişim ekosisteminizde ortak olan bir dizi standart seçmeniz ya da kendinizle gelmeniz önemli değil. Asıl mesele, standartlarınızın tutarlı olması ve onlara bağlı kalmanızdır. Çok sayıda araç var ve size yardımcı olabilir, ama bu tamamen farklı bir tartışma. Sadece başlaman için Yapılması gereken çok basit bir şey, kodunuzda bir çeşit stil formatlayıcıyı işleyen bir kancaya sahip olmaktır. İstediğiniz halde kodunuzu yazmaya devam edebilirsiniz ve aracın başkaları görmeden önce otomatik olarak "düzeltmesine" izin verin.

Son olarak , yorumda , yönetimin kişisel gelişim dallarının gerekli olduğuna inanmadığını belirtiyorsunuz. Onlara "dev dalları" dememizin bir nedeni var, "yönetim dalları" değil. Kafamda oluşan rantun dışarı çıkması için bir neden olmadığı için burada duracağım.

Bütün bunlar, meslektaşınızın burada hatalı olduğunu düşündüğümden emin değilim. Bu benim amacım değil, benim açımdan tüm gelişim sürecinizin de hatalı olduğu ve düzeltilmesi daha kolay olan bir şey olduğu. Kendinizi uygun araçlarla donatın, sayısız resmi ve gayrı resmi süreci keşfedin ve ekibinize uygun olanları seçin. Yakında “insan problemlerinin” artık varolmadığının farkına varacağınız bir noktaya varacaksınız. Ve lütfen "kendimiz dahil) kimseyi dinlemeyin" biz küçük bir ekibiz, tüm bunlara ihtiyacımız yok "mazereti. Yetkili geliştiricilerden oluşan bir ekip, gerekli araçları bir haftadan daha az bir sürede hazırlayabilir, otomatikleştirilebilecek her şeyi otomatikleştirebilir ve bir daha asla geriye dönüp bakmaz.

PS. "Kod sahipliği", sürekli tartışılan, terimsiz bir terimdir ve farklı insanlar için farklı anlamlara gelir. C2 hakkındaki farklı (ve bazen de antitetik) görüşlerin çoğunun mükemmel bir koleksiyonunu bulabilirsiniz .


7
Yapabilseydim +1 ve daha fazlası. Böyle bir süreci iyileştirmenin en iyi yollarını gösteren harika cevap.
Waldfee

2
Evet, OP bir kod inceleme aracına ihtiyaç duyar, bu şekilde kodu birlikte inceleyebilirsiniz, kod değiştiren sadece biri değildir, çünkü hoşuna gider. Smartbear.com/products/software-development/code-review adlı kullanıcıyı işte kullanmaya başladık
Juan Mendes

19

“Kodunuz” için sorumluluk almanızı isteyen süreçle ilgili nedir ? Bazı özelliklerin çalışmaya devam etmesinin tek sorumluluğu var mı? Lider "Michael, senin sorumluluğunu almanı istiyorum ..." dedi mi? Yoksa sorumluluğunuz açık mı, bazı özellikler her açıldığında liderin ve ekibin geri kalanının size bakması?

Her iki durumda da, eğer sorumluluğunuz varsa, o zaman kod üzerinde yetkiye ihtiyacınız vardır. Diğer adam bir dahaki sefere tek taraflı değişiklikler yaptığında ve lider onları düzeltmek için size geri döndüğünde, ipucu ile birlikte oturmalı ve yetki ve sorumluluğunuzun uyumlu olmasını istemeniz gerekir.


5
+1 Önemli bir gerçeği belirtmek için: Ya takım sahipliği var (1) herkes sorumlu (2) herkes kodu değiştirebilir ya da bireysel sahiplik vardır ve (1) modül sahibi sorumludur (2) her değişiklik modül sahibi tarafından onaylanmalıdır. Genellikle bir karmaşa bir ekip üyesinin bir modülden sorumlu olması beklendiğinde ortaya çıkar, ancak kıdemli bir üye kodda rasgele değişiklikler yapma hakkına sahip olduğunu düşünür. Başka bir deyişle, "otorite olmadan sorumluluk" durumundan kaçınmak gerekir.
Giorgio

4

Bunun durumu çözemeyeceği kesin değil, ancak kaynak kodunuza daha fazla yorum eklemeyi deneyebilirsiniz.

  1. Kod eksiksiz değilse, bu şekilde işaretlenebilir.
  2. Bir kod bloğunun amacı kendiliğinden belgelenmiyorsa, bunu belgelemeniz gerekir.

Sonuçta, limonata yapmaya çalışın, bunun yerine limon emerek zaman harcayın. Michael'ın dediği gibi, genel olarak, takım arkadaşları sizi kötü görünmek için dışarı değil. Hatalarınızdan öğrenmeye çalışın ve bunları gelecekteki revizyonlara uygulayın.

Değişikliklerinin olumsuz bir etkisi olduğuna inanıyorsanız, lütfen bunu (diplomatik olarak) söyleyin. Ben olsaydım, neden belirli değişikliklerin yapıldığını sorardım ve orijinal değişikliklerinizi savunup savunamayacağınıza bakın. Üst düzey iş arkadaşlarınız da insandır. Bir şeyi kaçırması ve / veya sağladığı olumsuz etkilerin farkında olmaması oldukça muhtemel.


3
Kafa karıştırıcı olabilecek bir çocuk. Hayal edin - "Bu kod tamamlanmadı" diyen bir yorum ekleyin ve sonra kodu tamamladığınızda kaldırmayı unutun.
riwalk,

1
@ Stargazer712, Branşta eksik kod sahibi olmaktan daha mı kafa karıştırıcı?
user606723

Raflar bunun için var. Eksik kodu kontrol etmeyin.
riwalk,

2
Hayır. Böyle bir şekilde etiketlemek için bir yorum gerektiren tamamlanmamış kodu kontrol ederseniz, zaten cehennemdesiniz demektir. Yorumlar sadece seni cehennemin farklı bir köşesine götürür.
riwalk,

1
Onlar TODO'lar olarak adlandırılır, her zaman çalışma kodunda kalırlar
Juan Mendes

4

Politikaya, yasallığa veya ekonomiye bakılmaksızın, herkesin kendi koduna sahip olduğu kesin olarak 'kendi koduna sahiptir'.

İş arkadaşınız, sizin bir baş sorarken tanımladığınız ve yanıt vermeyen davranışlarda bulunuyorsa , bu meslektaşınız nezaketsizdir, en azını söylemeye ve sizi incitmeye çalışıyor olabilir (en kötüsünü söylemek için .. .) - yok dEĞİL bir takım oyuncusu gibi konuşuyorsun.

İyi bir iş arkadaşınız sizinle temasa geçecek ve kodunuzla ilgili sorunu size gösterecektir - düzeltmenize / değiştirmenize veya uygun şekilde yanıt vermenize izin verecektir. Ben newbee olduğum zaman bile benim rehberlere hep, yanlış ne yaptığını bana işaret ve izin (ya da neden olduğunu açıkladı çok minnettarım yapılan bana bunu düzeltmek). Bu beni daha iyi bir programcı yaptı ve herkes yararlandı. Ve diğerleri tarafından yapılan çalışmaları incelerken hep yaptığım şey buydu. Öyleyse siz (veya her kim) aslında 'bütün işlemlerden' bahsinizden bir şeyler öğrenirsiniz ve öğretmeniniz de dahil olmak üzere kod ve ekip daha iyi olur: Öğretmek anlayışı anlamaya yardımcı olur.

Mümkünse, konuyu özel olarak Takım Lideri ile tartışırım . Durumla ilgili açıklamana göre, iyi bir takım lideri senin tarafını tutacaktır - kötü biri olmaz .... Açıkçası bu dikkatli olmak ister - bunu kendin için yargılamak zorunda kalacaksın.


1
İlk ifadeden ayrı olarak (takım sahipliğini benimseyen ekipler ve bireysel mülkiyeti benimseyen diğer ekipler var), bu cevabdaki gözlemleri buluyorum. Üyenin takım içindeki pozisyonunu kendi isteğiyle değiştirerek kodunu değiştirir. Bu yüzden aşağı tarafları anlamıyorum. Seçmenlerin açıklamaya özen göstermesi iyi olurdu.
Giorgio

1
Mikey'nin cevabını takım oyuncusu olarak nasıl kalacağım konusunda iyi bir açıklama olduğunu düşünüyorum. Belki de bu insanlara odaklanmış mı? Yannis'in önerdiği gibi, ekibimin gelişim süreci asıl sorun gibi gözüküyor. Ne olursa olsun, bunun neden reddedildiğini merak ediyorum.
Jesslyn

1
@Jesslyn - "Herkesin kasten" kendi kodlarının sahibi "" ifadesi nedeniyle reddedildiğimi tahmin ediyorum. Bu bir felsefi soru, politika sorusu değil. :-)
Vektör

1
@Mikey: "Herkes dolaylı olarak" kendi koduna sahip "" Bu bir tartışma konusu olabilir elbette. Serbest meslek sahibi olmayan programcılar normalde kaynak koduna sahip olmadıklarını söyleyen bir sözleşme imzalar. Bunun dışında, kodun yazarının kodu en iyi anlayan kişi olduğunu düşünüyorum ve eğer bir başkası kodu değiştirirse, o zaman ne yazar ne de ikinci geliştirici kodu% 100 gerçekten anlamaz.
Giorgio

1
@Mikey: Paylaşılan kod sahipliği, yeterince ekip üyesinin kodu yeterince iyi anlamasını sağlamaya çalışır (kimse gerçekten iyi bir şekilde anlamıyor olsa da). Bu, her bir modülün (en azından prensipte) bir programlayıcı tarafından tam olarak anlaşıldığı bireysel kod sahipliği için tercih edilir, ancak bu programcıdan ayrılırsa bu bilginin kaybolma riski vardır.
Giorgio,

1

Kod yazarsanız, gözden geçirmeliyim.

İnceleme sırasında kodunuzu değiştirirsem, kod artık incelediğim kod değil, değiştirdiğim koddur. Bu nedenle gözden geçirilmesi gerekiyor. Muhtemelen senin tarafından.

Yeni kodunuzu, değişikliklerimi gözden geçiren bir kişi olmadan değişikliklerimde kabul edersem, o zaman (1) gözden geçirilmemiş bir değişiklik ve (2) kod incelemeleri ciddiye alınırsa mümkün olan en kötü günah işledim.


0

Şimdilik doğru şekilde kullandığınızı düşünüyorum - ama yakında bu şekilde kodlamadan mutlu olamayacağınız ölçüde sizi rahatsız eden bir devrilme noktası olacaktır.

Yerinde olsam, bu kişiyle birebir görüşmek isterdim ve benim POV'umu sakince ve kesin bir şekilde açıklardım. Kod vb. Takımın mülkiyeti gayet iyi ancak her geliştiriciye çalışmasını yapması, hata yapması ve iyileştirmesi için yeterli alan vermezseniz, asla iyi kodlar oluşturmazsınız. Bu, daha sonra değil, bir sürtünme alanı olabilir.

(Bu iş yerindeyse tamamen farklı bir cevap var.

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.