İşyerimdeki yerleşik sözleşmeleri takip etmek için kötü bir kodlama stili izlemeli miyim?


102

Bir yıldır işimde çalışıyorum. Öncelikle bir C arka uçtan yöntemleri kullanan GUI arayüzümüzde çalışıyorum, ancak genellikle geri dönüş değerleri dışında bunlarla uğraşmak zorunda değilim. Bizim GUI, sınırlamalarımız göz önüne alındığında oldukça makul bir şekilde yapılandırılmıştır.

Programın komut satırı bölümüne bir işlev eklemekle görevlendirildim. Bu işlevlerin çoğu, 300 satır uzunluğunda ve kullanımı zor. Belirli alarm bilgilerini almak için parçalarını toplamaya çalışıyorum ve organize olma konusunda sorun yaşıyorum. Uzun bir fonksiyonla test ederek testlerimi daha karmaşık hale getirdiğimi biliyorum.

Var olan fonksiyonların tarzına göre her şeyi büyük bir fonksiyonda mı tutmalıyım yoksa alarmları kendi fonksiyonlarında mı sarmalıyım?

Geçerli kodlama kurallarına aykırı olup olmadığına ya da sadece mermiyi ısırmam ve kodu kendim için biraz daha kafa karıştırıcı yapmam gerektiğinden emin değilim.

Özetle, karşılaştırıyorum

showAlarms(){
    // tons of code
}

karşısında

showAlarms(){
   alarm1();
   alarm2();
   return;
}

alarm1(){
    ...
    printf(...);
    return;
}

EDIT: Herkese tavsiyem için teşekkürler, kodumu çarpanlara göre tasarlayacağım ve sonra ne istediklerini sormaya karar verdim ve hepsini bir arada isterlerse faktoring kodundan keserek tekrar 1'e döndürebilirim. büyük işlev Bu, tüm kodları tek bir tanımda istese bile, yazmama ve daha kolay sınamama izin vermelidir.

GÜNCELLEME: Faktörlü koddan memnun olduklarında sona erdiler ve birden fazla kişi bu emsali verdiğim için teşekkür etti.


117
Çalıştığınız şirketin işlevlerinizin 300 satır olması gerektiği şeklindeki pozisyonunu alması şüphelidir çünkü "biz her zaman böyle yaptık". Bu "kodlama stili kuralları" değildir; bu sadece kötü bir tarz.
Robert Harvey,

64
Bu, ekibinizin diğer üyeleriyle görüşmeniz gereken şeydir, gördüğünüz uygulamaların, herkesin izlemesi için önemli olduğunu düşündüğü sözleşmeler olduğunu ve birinin bir kez yaptığını ve yapmadığınız şeyleri anlamaya çalışmaktır. taklit etmek gerekiyor. Hiç şüphesiz her ikisinden de bir miktar olacaktır.
Saat

17
@beginnerBinx Bu sadece nasıl ifade ettiğinizi gösterir. "X gerçekten aptalca bir şey yapıyor, aynı zamanda o aptal şeyi de yapmalı mıyım" deme. "X'in bunu yaptığını fark ettim, bunun böyle yapmasının özel bir nedeni var mı? Y yazarken aynı şeyi yapmazsam sorun olur mu?" Daha sonra eski kodu basıp basmamaya ya da neden bu şekilde yapmak zorunda olduklarını açıklamaya karar veriyor (isteksizce mi yoksa coşkuyla mı).
Saat

11
İyi veya kötü tarz sıklıkla tartışılır ve nadiren üzerinde anlaşılır. Üniversite öğretimi, işlevlerin kısa olması gerektiği, ancak eğer bu anlamı engellerse, bunu yapmayın. Test, düşüncesizce bir dizi kurala uymak yerine açıklık olmalıdır.
hızla,

9
İnternetteki rastgele insanlar takım arkadaşlarınızı okumanın sakıncası yok, bu yüzden burada aldığınız tüm cevaplar sadece kişisel tercihler. Takımınla konuşmalısın. Uzun işlev kasıtlı bir tasarım ilkesi midir? Uzun fonksiyon stiline devam etmenizi mi istiyor yoksa en temiz olduğunu düşündüğünüzü yazmanızı mı istiyorlar?
JacquesB

Yanıtlar:


102

Bu gerçekten seninle takım arkadaşların arasında. Başka hiç kimse size doğru cevabı söyleyemez. Bununla birlikte, satırlar arasında okumaya cesaret edersem, bu stile "kötü" dediğiniz gerçeği, onu yavaşlatmanın daha iyi olduğunu gösteren bazı bilgiler verir. Çok az sayıda kodlama stili aslında "kötü". Kullanmayacağım şeyler var, kendim, ama onlar için her zaman bir kafiyeli ya da sebep var. Bu, bana göre, şu ana kadar gördüğünüzden daha fazla bir hikaye olduğunu gösteriyor. Etrafta sormak çok akıllıca bir çağrı olurdu. Birisi senin bilmediğin bir şey biliyor olabilir.

Kişisel olarak, gerçek zamanlı görev açısından kritik kodlamaya ilk başladığımda bununla karşılaştım. Böyle bir kod gördüm:

lockMutex(&mutex);
int rval;
if (...)
{
    ...
    rval = foo();
}
else
{
    ...
    rval = bar();
}
unlockMutex(&mutex);
return rval;

Ben parlak ve parlak OO C ++ geliştiricisi olarak, derhal RAII kullanmak yerine muteksleri manuel olarak kilitleyip kilidini açarak yaşadıkları böcek riskleri üzerine çağırdım . Bunun daha iyi olması için ısrar ettim:

MutexLocker lock(mutex);
if (...)
{
    ...
    return foo();
}
else
{
    ...
    return bar();
}

Çok daha basit ve daha güvenli, değil mi? Derleyicinin sizin için yapabileceği durumlarda geliştiricilerin tüm kontrol akış yollarındaki mutekslerini kilidini açmasını neden unutmayın?

Daha sonra öğrendiğim şey, bunun için usule ilişkin bir sebep olduğuydu. Evet, gerçekten de, yazılımın doğru çalıştığını ve kullanmamıza izin verilen sınırlı bir araç listesi olduğunu onaylamamız gerekiyordu. Yaklaşımım farklı bir ortamda daha iyi olabilirdi, ancak çalıştığım ortamda, yaklaşımım on kat algoritmayı doğrulamak için gereken iş miktarını kolayca çarpacaktı çünkü bir C ++ RAII kavramını bir kod bölümüne getirdim. bu, C tarzı düşünmeye gerçekten daha müsait standartlara uyuyordu.

Bu yüzden bana kötü, düpedüz tehlikeli, kodlama stilinin neye benzediği aslında iyi düşünülmüş ve "iyi" çözümüm aslında yolun aşağısında sorunlara yol açacak olan tehlikeydi.

Öyleyse etrafa sor. Elbette, neden böyle yaptıklarını anlamak için sizinle birlikte çalışabilecek kıdemli bir geliştirici var. Ya da, kodun bu bölümünde bir refaktörün maliyet ve faydalarını anlamanıza yardımcı olabilecek kıdemli bir geliştirici var. Her iki durumda da, etrafa sor!


60
Muhtemelen mutex örneğinin daha tehlikeli kısmı, neden RAII kullanamadığını açıklayan kod yorumları açıkça görülmemesidir. Bu açık kilitleme / kilit açmanın kod tabanının her tarafında olması durumunda, her örnek için bir yorum eklemek yanlış olabilir. Bu durumda, belki de yeni cihazların aşina olması gereken bir primer belge yazılmalıdır.
Kelvin,

10
Elbette, bir kıdemli ile konuşmak her zaman iyidir ve yeniden yapılanma işlemi dikkatle (ve testlerle) yapılmalıdır. Ve elbette, eşzamanlılık / muteksler kendi başlarına özel bir canavardır. Ancak> 300 satırlık fonksiyonlar görürken, bu fonksiyonların neden bu kadar büyük olduğu "gizli teknik bir sebep" aramak için fazla zaman harcamam. İşlevlerin çok uzamasının nedeni her zaman aynıdır ve teknik değildir.
Doktor Brown

8
@DocBrown Sadece teknik olmadıkları için sebep olmadıkları anlamına gelmez. Geliştiricilerin daha büyük bir makinenin bir parçası olduklarını hatırlamaları önemlidir. (Bu dersi almak için kaç kez okuduğumu sayamıyorum)
Cort Ammon

4
@DocBrown Her iki durumda da, birinin konuşması gereken üst düzey geliştiriciler. Yaptığım örneği seçtim çünkü aptal kodun neden aptal olduğu konusunda sayısız argüman bulmak kolay. Aptal görünen kodun neden aptal olmadığına dair argümanları bulmak zor.
Cort Ammon

3
@DocBrown Yorumlarınız ve cevaplarınızdan, fikirlerimizin farkının, vermiş olduğum kanıtlara dayanarak, kodun zaten "kötü" olduğu varsayımından başladığınızı söyleyebilirim. ilk önce kodun "kötü" olup olmadığını keşfeden yolları kullanın.
Cort Ammon

84

Açıkçası, 300 satır ile kullanımı zor olan işlevlere sahip olmanın sadece bir stil meselesi olduğuna inanıyor musunuz? Yani kötü bir örnek izleyerek tutarlılık nedeniyle genel programı daha iyi bir durumda tutabilir? Sanırım buna inanmıyorsun, aksi takdirde bu soruyu burada sormazdın.

Benim tahminimce bu işlevler çok uzun, çünkü bizim işimizde okunaklılık, kod kalitesi, uygun adlandırma, ünite testleri, yeniden düzenleme işlemlerine dikkat etmeden ve doğru soyutlamalar oluşturmayı hiç öğrenmemiş olan, özellikleri sadece özelliklerin üzerinde kullanan birçok vasat programcı var. . Sürüyü takip etmek veya daha iyi bir programcı olmak istiyorsanız kendiniz için karar vermelisiniz.

Zeyilname, yorumlarından dolayı: "300 satır" ve "kullanımı zor" IMHO'nun kötü kod için güçlü göstergeleridir. Tecrübelerime göre, bu kodun neden Cort Ammon'un cevabı örneğiyle karşılaştırılabilir şekilde daha okunaklı bir şekilde uygulanamayacağına ilişkin bazı "gizli teknik sebep" bulunmuyor. Bununla birlikte, Cort ile bu konuyu takımdaki sorumluluklarla görüşmelisiniz - kodun veya bu "tarzın" neden değiştirilemediğinin belirsiz nedenlerini bulmak için değil, kodun bir şeyleri bozmadan nasıl güvenli bir şekilde yeniden yapılandırılabileceğini bulmak için .


127
Yetkili programcılar bile bu suçları sıkı teslim tarihleri ​​altında işliyorlar.
gardenhead,

13
@gardenhead, zaman kazanmak için 300 satırlık bir işlevi yeniden düzenlemeyi anlayamıyorum, ancak 300 satırlık bir işlevi yazmanın zaman kazandıracağının bir yolu yoktur.
Dangph

39
@ gardenhead: Bir cerraha gittiğimde, acil yardıma ihtiyacım var çünkü benimle ilgilenmeye başlamadan önce ellerini yıkamak için zaman harcamasını bekliyorum. Bu, gerçek yeterliliği elde etmek için birçok insanın işimizde öğrenmesi gereken bir şeydir : kodu daima öncekinden daha iyi bir durumda bırakın ve bunun da son teslim tarihlerini tutma yeteneğini artıracağını unutmayın. 300 satır işlevi genellikle umursamayan insanlar tarafından günden güne büyür ve "son tarihi" her zaman bahane olarak kullanırlar.
Doktor Brown,

17
@Dangph, yeniden düzenleme yerine işleve yalnızca 5 satır eklediğinizde zaman kazandırır. Bunlar genellikle başlangıç ​​işlevi uzun olduğunda (30+ satır) büyür ve bir sonraki programcı “bu benim kodum değil, onu kırmamaya çalışmayacağım, sadece buraya ve buraya birkaç satır ekler” diye düşünür.
Džuris,

7
@Juris, anladığım kadarıyla soru, var olanları yeniden düzenlememek yerine yeni bir işlev oluşturmakla ilgilidir. Yeni bir işlev yazıyorsanız, tek bir canavar işlevi haline getirerek zaman kazanmazsınız.
Dangph

42

Hayır.

Pragmatik Programcı kitabında yazar Kırık Pencere Teorisi hakkında konuşuyor .

Bu teori durumu:

Birkaç kırık pencereli bir bina düşünün. Camlar tamir edilmezse, vandalların birkaç pencereyi daha kırma eğilimi vardır. Sonunda, binaya bile girebilirler ve eğer kullanılmazlarsa, içlerinde çömelme veya hafif alevler olabilir.

Veya kaldırımı düşünün. Bazı çöpler birikir. Yakında daha fazla çöp birikir. Sonunda, insanlar oradaki paket servis restoranlarından çöp torbaları bırakmaya başlayabilir hatta arabalara bile girebilirler.

Kitapta yazar bu teori ve kod arasında bir paralellik yazar. Böyle bir kod bulduktan sonra durup kendinize de aynı soruyu sorabilirsiniz.

Ve cevap hayır.

Bu kırık pencereyi terk ettiğinizde - bizim durumumuzda, kötü kod - bu, herkesin kırık pencereleri geride bırakacağı etkisini yaratacaktır.

Ve bir gün kod çökecek.

Herkese Temiz Kod ve Temiz Kodlayıcı'nın bir kopyasını verin .

Siz konuyla ilgilenirken , TDD'nin bir kopyası da iyi.


6
Kod temeli kırık pencereler dışında hiçbir şey içermeyen bir sera ise?
Alan Shutko

8
@AlanShutko O zaman özgeçmişinizin güncel olduğundan emin olun? Şimdi farklı bir işveren bulun .
David Montgomery,

12
Kod nadiren "çöküyor". Yeni özellikler eklemek daha da zorlaşıyor, gittikçe daha fazla zaman alıyor ve kodu temizleme tahminleri artacak - bu da gerekli temizlik için herhangi bir zaman bütçesi elde etmenin zorlaştığı anlamına geliyor.
Doktor Brown,

8
Vay canına, ne kadar keyfi bir benzetme "kırık pencere" teorisi gibi görünüyor.
Samthere,

4
TDD'nin bununla hiçbir ilgisi yok. Gidip gitmeyeceğinize dair İş / Etki Alanı / Test / Hiçlik sürücü tasarımında hiçbir şey değiştirmeyen temiz kod temellerini takip edin. Üzgünüz ama 'TDD'yi' her yerde alıntı yapılmadığında görmek çok yorucu.
Walfrat

25

Evet, bunun için gidin. Yapı! = Stil

Yapı hakkında konuşuyorsun, stilden değil. Stil yönergeleri yapıyı (genellikle) yapmaz, çünkü yapı genellikle bir kuruluşa uygun olmayan belirli bir soruna uygunluğu için seçilir.

Dikkatli ol

Diğer alanlarda, sizin başınıza gelmemiş olabilecek olumsuz sonuçlara neden olmadığınızdan emin olun. Örneğin,

  • Var olan koda herhangi bir benzerliği ortadan kaldırdığınızdan, farkları veya kod birleştirmelerini karmaşıklaştırmadığınızdan emin olun.
  • İstisna akışlarının doğru şekilde kabardığından ve yığın izlerinin büyük miktarda okunaksız saçmalıkla kirlenmediğinden emin olun.
  • Doğrudan çağrılırsa sorun yaratabilecek genel giriş noktalarını yanlışlıkla göstermediğinizden emin olun (haritaya koymayın ve / veya dışa aktarmayın).
  • Global ad alanını karıştırmayın, örneğin daha küçük fonksiyonlarınızın tümü daha önce yerel fonksiyon kapsamında ilan edilmiş bir tür genel içerik gerektiriyorsa.
  • Günlüklere baktığınızdan emin olun ve destek ekibinde olup olmadığınızı kendinize sorun, kodunuz tarafından oluşturulan günlüklerin, dokunmadığınız herhangi bir koddaki günlüklerle iç içe göründüğünde kafa karıştırıcı olup olmayacağını sorun.
  • Emin olun do onlar eski okul kullanıyor olsalar bile, örneğin mevcut stili, uygun Macar notasyonu ve gözlerin, kanamaya genel kod tabanı ile tutarlı kalmak yapar. Macarca notasyonu okumaktan daha acı veren tek şey, kimin ne yazdığına bağlı olarak bir düzine farklı tipte notasyon kullanan kod okumaktır.

Nazik olmak

Bir takımın bir parçası olduğunuzu ve iyi kodların önemli olmasına rağmen, tatildeyken yazdığınız şeyleri takım üyelerinizin sürdürmesi de çok önemlidir. Eski stile alışkın olan insanlara mantıklı olacak bir akışa bağlı kalmaya çalışın. Sırf odadaki en zeki adam sensin, herkesin kafalarının üstünde konuşmalısın!


"Eski stile alışkın olan insanlara mantıklı olacak bir akışa bağlı kalmaya çalışın." - yani, daha önce ne kadar beceriksiz bir palyaçonun yaptığını aynı şekilde programlamak için tavsiyeniz var mı? 300 satır işlevi eklemek kolaylaştıracak değil.
BЈовић

11
Benzer bir akıma sadık demedim. Anlayabilecekleri bir akışa bağlı kal dedim.
John Wu

2
İyi tavsiye. I tekrar elden zaman , tek bir komut içinde 5 işlevlerini Bu yanıt, bir ustaca başlangıçta sadece şartlı hesaplanmıştır mantıksal ifade içinde ön-işlem değerleri ile semantik değiştirildi. Hakemler olsa yakaladı ;-). Ciddi tavsiye, iyice incelemek ve test etmektir. Her değişiklik hataları doğurabilir ve bu kimsenin yapmamasının ana nedeni olabilir.
Peter A. Schneider,

6

Bunu bir kod sözleşmesi olarak görmüyorum. Bunu, anlaşılması kolay, bakımı kolay bir kod yazmayı anlamayan biri olarak görüyorum. 300 satırlık fonksiyonların neden kabul edilebilir olduğunu düşündüklerini anlamaya çalışırken, ekibinizi önerdiğiniz gibi ve takımın bunu yapmanın yararları konusunda eğiterek kodunuzu farklı fonksiyonlara bölerim. Sebeplerini duymakla çok ilgilenirim.


1
Sebep yok, sadece politikamız var.

5

Cevap kod incelemesinde.

Asıl soru, iyi faktoring kodunu açarsanız, onunla çalışmak isteyen tek kişi siz misiniz?

Ben, buradaki çoğu insan gibi, 300 satır fonksiyonunun bir uyuşukluk olduğuna inanıyorum. Bununla birlikte, Windex'i bir çöp sahasına götürmek pek iyi sonuç vermeyecek. Sorun kod değil, kodlayıcılar.

Sadece haklı olmak yeterli değil. İnsanları bu stilde satmalısın. En azından okumaya. Sonunda bu zavallı adam gibi davranmazsan: kovuldun çünkü yeteneklerin iş arkadaşlarının çok üstünde

Küçük başla. Etrafına sor ve başkalarının daha küçük işlevleri tercih edip etmediğini öğren. Daha iyisi, kod tabanının etrafında dolaşın ve en küçükleri kimin yazdığını bulup bulamayacağınızı görün (en çirkin kodun en eski kod olduğunu ve mevcut kodlayıcıların daha iyi kod yazdığını görebilirsiniz). Bu konuda onlarla konuşun ve bir müttefiki olup olmadığına bakın. Aynı şekilde hisseden başka birini tanıyıp tanımadıklarını sorun. Küçük işlevlerden nefret eden birini tanıyorlar mı diye sorun.

Bu küçük grubu bir araya toplayın ve değişiklik yapma hakkında konuşun. Onlara yazmak istediğiniz kod türünü gösterin. Okuyabildiklerinden emin ol. İtirazları ciddiye alın. Değişiklikleri yap. Kodunuzu onaylayın. Artık arkanda bir toplantı yapma gücüne sahipsiniz. Bunlardan birkaçı daha varsa, tanıttığınız yeni stili açıkça kabul eden bir sayfalık bir belge hazırlayabilirsiniz.

Toplantılar şaşırtıcı derecede güçlü şeylerdir. Pelerin üretebilirler. Clout, bu harekete karşı çıkanlarla savaşmak için kullanacağınız şeydir. Ve bu noktada budur. Bir hareket. Statükoyu iyileştirme hakkı için savaşıyorsun. İnsanlar değişimden korkuyor. Tatlı konuşmaya, cajole ve eşyaya ihtiyacın olacak. Ancak küçük bir şansla hemen kabul edilmeye başlayacaksınız.


5
Geliştiricileri 300 satırlık bir yöntemin çok uzun olduğuna ikna etmek bu kadar sosyalleşme ve çoklu toplantılar gerektiriyorsa, konuşmanın yardımcı olacağını sanmıyorum. Yukarıdaki yaklaşımla ilgili sorun, iyi kod yazmak için izin istemeniz durumunda, savunmada olmanızdır. Ancak sadece iyi kod yazarsanız ve mevcut kodu yeniden düzenlemek için zaman ayırırsanız, o zaman itiraz eden herkes 300 hatlı bir yöntemin neden iyi olduğunu açıklamak ve zamanını geri koyarak zamanını haklı göstermek için savunmadadır.
Brandon,

3
İşlev sınırları başına kod satırlarını tartışmak üzere bir dizi toplantıya davet edilirsem, bu tür toplantılardan kaçmanın bir yolunu bulacağımı söyleyebilirim. Doğru numara yok ve hiçbir zaman insanların aynı fikirde olmasını istemezsiniz. Bazen insanların daha iyi bir şekilde gösterilmesi gerekir .
Brandon

Bazen, çok büyük bir işlevi bölmek (ve işleri daha iyi adlandırmak ve düşündüğüm gibi yorum ve belgeler eklemek , bir değişikliği açıkça gözlemlemeden önce gerekli ilk adımdır.
JDługosz

@Brandon Muhtemelen bu şekilde ses çıkarmayı kastetmiyorsunuzdur ama duyduğum şey haklı olduğunuz ve herkesin başa çıkabileceği. Kodunuz çalıştığı sürece, ekibin geri kalanının anlamadığı önemli değil. Onlara hiçbir şey öğretmek için canınızı sıkmaya kesinlikle değmez. Kendi kodunuzu yazarken, 300 satır işlevi oluşturmaya devam etmelerini izlemekten tamamen mutlusunuz.
candied_orange

1
@CandiedOrange Kesinlikle takıma karşı olmak istemedim. Demek istediğim, bazı konuların en iyi şekilde onları eylem halindeyken öğrenmeleriydi, ancak stil konusunda demokratik bir karar vermeleri için bir ekip kurmaya çalışmak verimli olmayacaktı. Okunamayan kod yazmak için bahane olarak kullanılan tutarlılığı gördüm. Sonuç? Daha fazla okunamayan kod. Bunun hakkında konuşmak için bir dizi toplantı ayarlayabilirim ya da düzeltebilirim ve insanlara sonuçları gösterebilirim .
Brandon

3

Bazen akışla gitmek zorundasın.

Söylediğiniz gibi, mevcut bir çalışma kod tabanında bir işlev uygulamak için görevlendirilmişsiniz.

Dağınıklıktan bağımsız olarak, ve onu temizlemenin cazip olduğunu anlıyorum. Ancak iş dünyasında, her zaman refactor kodunu yazma şansınız yoktur.

Sadece yapman istendiğinde yap ve devam et.

Yeniden düzenlemeye veya yeniden yazmaya değer olduğunu düşünüyorsanız, ekiple görüşmek üzere ortaya çıkarmanız gerekir.


2
Her küçük refaktörlükten izin alırsanız, sonsuza dek bir işletme için tehlikeli olan sınırsız bir kodunuz olacaktır. Yöneticiler sadece bir değişiklik pahasına bakmak, ama nadiren pahasına bakmak değil değişen.
Brandon,

5
OP kod satırlarını yüzlerce değiştirerek değil bir işlevi yazmak istendi
meda'ait

2
@meda tam olarak! Ben de aynı durumdayım. Şirket intraneti için yeni modüller geliştiriyorum ve sunucu yazılımı ve kitaplıkların 2006'dan beri hiç güncellenmemesiyle "tamir edilemeyecek yılların ihmal edilmesi" olarak nitelendirilebilecek olanı buluyorum. , ancak kısıtlamalar nedeniyle kodlamam daha uzun sürüyor. (MySQl 5.2, MySQL 5.0'ı hayal edin). Hiçbir şeyi güncelleyemem çünkü muhtemelen mevcut kod kullanımdan kaldırılmış kod nedeniyle daha yeni sürümlerde çalışmayacak.
roetnig

3
"Bozulmadıysa, düzeltmeyin." Biraz yağ sızan 20 yaşında bir arabam var. Para harcamaya değer mi? Hayır. Güvenilir? Evet.

3

Uygulamaların kötü olduğunu söylemeye başlamadan önce, ilk olarak büyük yöntemlerin ve diğer kötü uygulamaların sebebini anlama yolunda bir adım atardım.

Ardından, test kapsamının oldukça yüksek veya gerçekten yüksek olduğundan emin olmanız gerekir (büyük refactoring olmadan alabileceğiniz kadarıyla). Olmazsa, kodu yazmasanız bile kapsamı gerçekten yüksek tutmaya çalışırım. Bu, ilişki kurmanıza yardımcı olur ve yeni ekibiniz sizi daha ciddiye alır.

Bu üsleri kapattığınızda, aklı başında hiç kimse size meydan okumaz. Bir bonus maddesi olarak, bazı mikro kıyaslamalar yapın ve bu gerçekten de sizin durumunuza eklenecektir.

Sıklıkla, sizin söylediğiniz biçim, kod kültürünü değiştirmek için uzun bir yol gider. Örnek olarak kurşun. Ya da daha iyisi, yazabildiğiniz bir kod parçasını bekleyin - refactor ve birim cehennemi test eder ve ihlal eder - duyulacaksınız.


Şu anki kodu yeniden düzenlemem, sadece yeni bir fonksiyon yazıyorum, sadece 'konvansiyonu' takip etmeli ve 300'den fazla çizgi canavarlıkta kodlamalı mıyım yoksa normalde yaptığım gibi mantıklı parçalara ayırmalı mıyım? kod tabanının bu bölümünde yapılmamıştır.
Justin,

1
300'den fazla satıra yeni yöntemler yazmanızı sağlayacak kuralları var mı? olmasa doğru yolu yazardım. ancak şubeleri de dahil olmak üzere onları test etmek için kesinlikle yolumdan çekilirim. Ben de benzer deneyimler yaşadım ve genellikle onları yenersin. İşin püf noktası zamanla yapmak ve ilişki kurmaktır.
16'da

3

Bu tür bir soru temel olarak " lütfen takım arkadaşlarımı okuyunuz ." İnternetteki rastgele insanlar bunu yapamaz, bu yüzden alacağınız tüm cevaplar sadece insanların kodlama tarzı hakkındaki kişisel görüşleridir. Mutabakat daha kısa yöntemlerdir, ancak siz zaten kendiniz düşünüyor gibi görünüyorsunuz, bu yüzden bunu yeniden düzenlemeye gerek yok.

Dolayısıyla, geçerli kod tabanı, tercih ettiğinizden farklı bir kodlama stili kullanıyor gibi görünüyor. Ne yapmalısın? İlk önce çözmelisin:

  1. Bu, mevcut ekibiniz tarafından desteklenen kasıtlı bir tasarım kararı mı?
  2. Bu tarzı izlemeni istiyorlar mı?

Bulmanın tek yolu var. Sor .

Uzun fonksiyonlara sahip olmanın birçok nedeni olabilir. Takımın uzun fonksiyonların çoklu kısa fonksiyonlardan daha iyi olduğuna inanması olabilir. Ayrıca, eski kod olduğu için olabilir ve ekip yeni kodun daha temiz bir tasarım izlemesini tercih eder. Bu yüzden, her iki seçenek de bir geliştirici olarak başınızı belaya sokabilir, eğer takımla konuşmaz ve nedenlerini anlamazsanız.


1
İyice katılıyorum ve ekliyoruz: "Başkalarının yaptıklarını takip etmediğiniz için kovulabilir veya başınızı belaya sokabilir misiniz?" O zaman cevap evet! Her kötü şeyi takiben şirket yapmanı ve onunla uğraşmanı istiyor.
Rob,

1

Farklı "stil" seviyeleri vardır.

Bir seviyede, genellikle kodlama sözleşmelerinin bir parçası, bu, beyaz boşlukların, boş satırların, köşeli parantezlerin ve eşyaların nasıl adlandırılacağı (karma harf, alt çizgi vb.) Anlamına gelir.

Başka bir düzeyde, programlama modeli, bazen statikten kaçınma veya soyut sınıflar üzerinde arabirimleri kullanma, bağımlılıkları nasıl gösterme, hatta bazı ezoterik dil özelliklerinden kaçınma gibi şeyler olabilir.

Sonra proje tarafından kullanılan kütüphaneler ve çerçeveler var.

Bazen fonksiyon boyutunda maksimum bir sınır olabilir. Ancak nadiren asgari bir sınır yoktur! Öyleyse, bunlardan hangisinin önemli olduğunu düşündüğünüz güçleri bulmalı ve buna saygı göstermeye çalışmalısınız.

Takımın mevcut kodu tekrar gözden geçirme konusunda olumsuz olup olmadığını, mümkünse yeni kod eklemekten bağımsız olarak yapılması gerektiğini öğrenmeniz gerekir.

Bununla birlikte, mevcut kodu yeniden düzenlemek istemeseler bile, eklediğiniz yeni kod için soyutlamalar yapabileceğiniz bazı katmanlar sunabilirsiniz; bu, zaman içinde daha iyi bir kod tabanı geliştirebilir ve belki eski kodu bunun için bakım gerektirir.

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.