İşyerinde Kodlama Standartlarını Kullanmak (Ben patron değilim)

Küçük bir ekiple çalışıyorum, yaklaşık 10 dev. Hiç kodlama standartlarımız yok. Norm haline gelen bazı şeyler var, ancak bazı şeyleri yapmanın tamamen farklı olduğu görülüyor. Büyük olanım girinti. Bazıları sekmeler, bazıları boşluklar, bazıları ise farklı problemler yaratan farklı boşluklar kullanır. Birleşmek istediğimde sık sık çatışmalarla karşılaşıyorum çünkü birileri IDE'leri otomatik formatlama için kullanıyorlar ve girintilerim için benden farklı bir karakter kullanıyorlar. Hangisini kullandığımız umrumda değil, sadece hepimizin aynı olanı kullanmasını istiyorum.

Yoksa bir dosyayı açacağım ve bazı satırlarda koşulu ile aynı satırda küme parantezleri varken diğerleri bir sonraki satırda. Yine, hepsinin aynı olduğu sürece hangisinin umrundayım.

Standartlar konusunu doğrudan yöneticime, birebir ve grup toplantılarında gündeme getirdim ve bu konuda fazla endişelenmiyor (kendimle aynı görüşü paylaşan birkaç kişi daha var). Girinti karakterleriyle ilgili özel endişelerimi ortaya çıkardım ve daha iyi bir çözüm olacağını düşündüm, "depodan ittiğimizde / çekersek her şeyi dönüştürebilecek bir tür komut dosyası oluşturmak". Değişmek istemediğinden şüpheleniyorum ve bu çözüm aşırı karmaşık görünüyor ve yolun aşağısındaki bakım sorunlarına yatkın görünüyor (ayrıca bu, daha büyük bir sorunun yalnızca bir tezahürünü ele alıyor).

Herhangi biriniz işyerinde benzer bir durumla karşılaştınız mı? Eğer öyleyse, nasıl başardınız? Patronumun standartlara satılmasına yardımcı olacak iyi noktalar neler olabilir? Bir çim kökleme hareketi, kodlama standartları oluşturmak için, bizim aramızda olanlarla aramızda olmak iyi bir fikir olur mu? Çok özel mi oluyorum, gitmesine izin mi vermeliyim?

Zaman ayırdığınız için teşekkür ederiz.

Not: Şimdiye kadarki harika geri bildirimleriniz için herkese teşekkürler! Açık olmak gerekirse, hepsini yönetmesi için bir stil dikte etmek istemiyorum. Tercih ettiğim bir şeyi yapmanın, herkese en çok yakışan şey lehine karar vermeye razıyım. Tutarlılık istiyorum ve bunun demokrasi olmasını istiyorum. Herkesin kabul edeceği bir grup kararı olmasını istiyorum. Doğru, herkes yoluna girmeyecek, ancak herkesin grubun iyileşmesi için uzlaşacak kadar olgun olacağını umuyorum.

Not 2: Bazı insanlar yukarıda verdiğim iki örnekte yakalanıyor. Ben meselenin özünden sonra daha çok varım. Pek çok örnekle kendini gösterir: adlandırma kuralları, parçalanması gereken büyük işlevler, bir kullanım veya hizmette bir şey olursa, bir şey sabit mi yoksa enjekte edilmeli mi, hepimiz bir bağımlılığın farklı versiyonlarını kullanmalı mıyız, yoksa Bu durumda arabirim kullanılmalı, ünite testleri nasıl yapılmalı, ünite testi yapılmalı, (Java'ya özel) ek açıklamalar ya da harici yapılandırma kullanmalı mıyız. Devam edebilirim.

Bir meslektaşım ve ben ilk katıldığımızda ekibimizde de benzer bir sorun vardı (önce ekibe katıldım, yaklaşık bir yıl sonra katıldı). Gerçek bir kod standardı yoktu. Biz bir MS dükkanıyız ve hatta MS kodlama standartları kullanılmadı. Örnek olarak yol göstermeye karar verdik. Birlikte oturduk ve tüm standartlarımıza sahip bir belge hazırladık: IDE standartları, adlandırma standartları, düşünebildiğimiz her şey. Sonra o ve ben standardı açıkça takip etmeyi kabul ettik. Ekibe bir e-posta gönderdim (ikimizden de), onlara bir eksiklik bulduğumuzu ve eksikliğimizi belgemizle çözeceğimizi bildirdim. Eleştiri, fikirler, yorumlar ve görüşler davet ettik. Geri bildirim biçiminde çok az şey aldık ve yalnızca biraz geri adım attık. O ve ben hemen standartları kullanmaya başladık. Genç geliştiricileri projelerimize getirdiğimizde, onları standarda getirdik ve kullanmaya başladılar. İlk başta isteksiz olan ancak standardı çok fazla şey için kullanmaya başlayan birkaç müşterimiz var.

Genç geliştiricilerin birçoğunun aynı sorunu tanıdığını, ancak başka birinin adım atıp karar vermesini beklediğini gördük. Bir zamanlar izlenecek bir plan vardı, çoğu bunu kabul etmeye istekliydi. Kırılması zor olan somunlar, başka bir yöntemle kodlamayı reddedenler ve genellikle uzun vadede kendilerini resimden çıkarırlar.

Standartlar istiyorsanız yolu açın. Ekibinize fayda sağlayacağını düşündüğünüz bir standartlar listesi ile gelin. Akranlarına ve geri bildirim için yol açar. Ekibinizdeki diğer insanların da benzer fikirleri olduğuna eminim, ama muhtemelen bu konuda bir şeyler yapacak kadar titizler. Gandi'nin dediği gibi, "Dünyada görmek istediğiniz değişiklik siz olmalısınız."

Standartlar bir yönetici tarafından tanımlanan ve uygulanan bir şey olmamalıdır. Bir bütün olarak takımın standartlara uyması gerekir. Ortak bir standartlar dizisi üzerinde anlaşamazlarsa, standartlar üzerinde yürürlüğe koymak için bir menajer almak başarısız olur.

Siz ve sizinle aynı fikirde olan diğerlerinin örnek olması gerekir. Aynı kodlama standartlarını kullanmaya başlayın, yayınlayın ve onları ekibin geri kalanına tanıtın ve nasıl geliştirilebileceklerine dair geri bildirimde bulunun.

Standartları yükseltmeye çalışırken önemli olan şey şu: Odağın işleri yapmanın en iyi yolunu bulmaya değil, daha tutarlı bir şeyler yapmaya odaklandığından emin olun . Bazı insanlar aynı fikirde olmadıkça, gerçek bir küme ayracı stili, gerçek yorum üslubu vb. Yoktur. Kodun okunmasını kolaylaştıran (ve böylece bakımı daha kolay olan) tutarlı bir stildir, ne olursa olsun.

Bunun neden olduğu sorunlardan dolayı boşa zaman harcadığınıza dair bir kanıt gösterebilir misiniz?

Bu sorunların giderilmesi için önemli miktarda zaman harcıyorsanız veya düzeltilmesi zaman alan hatalara neden oluyorsa, bu kodlama standartlarını benimseyerek ciddi ölçüde azaltabileceğiniz bir maliyettir.

Bu nedenle, hem sizin hem de (onların farkında olduğunuz yerde) meslektaşlarınızla karşılaştığınız sorunların ve bunların çözülmesi için gereken zamanın bir kaydını tutun.

O zaman makul miktarda veri elde ettiğinizde bunu iş arkadaşlarınıza sunun. Bir standardın benimsenmesinin yararını görmelidirler. Verileri patronunuza ve onun patronuna göstermiyorsanız. Kodlama standartlarına sahip olarak şirketinizin parasını koruyabileceğinizi ve benimsemelerini sağlama konusunda size destek vermeleri gerektiğini gösterin.

Senin özel durumunda, patronunun çözümünün iyi olduğunu düşünüyorum. Kimse tüm kariyeri boyunca yaptıklarını değiştirmek zorunda değildir ve bu tamamdır, çünkü derleyicinin görmezden geldiği kod stili bitleri, kodun okunabildiği sürece önemli değildir. Herkes check-out sırasında kendi stiline otomatik format ve check-in sırasında standart bir stil otomatik format yaptıysa, her şey yoluna girecek. (Ne yazık ki, çalıştığım yerin ve kodlayıcının artık sürekli entegrasyon sunucusunun gördüğü ile aynı kodu yazmayacağı gerekçesiyle karşı çıktığını önerdim.)

Kodlama standartlarının kod kalitesinde gerçek bir fark yarattığı yerlere uygulandığında iyi olduğunu düşünüyorum: örneğin, ufacık yöntemler, açıkça belirtilmiş bir sorumluluğu olan sınıflar, daha zor bitler için yararlı ve doğru yorumlamalar, vb. otomatik olarak kontrol etmek daha zordur, ancak bu yazılım geliştirmede temeldir. Gerçekten yapabileceğiniz tek şey, başkalarına iyi uygulamaları öğretmek ve yanlış satırdaki destekle kod okumayı kendinize öğretmektir.

Kodlama standartlarına gelince: Kodlama standartlarının “iyi bir şey” olduğunu söyleyerek (standartlara karşı değil) söyleyerek hemen hemen herkesle birlikte uçurum.

Ancak, başka yere gitme. Belirli bir girinti stilini dikten bazı karakterlerde çalıştım, karakter sayısının sonuna kadar (ve projeler o kadar ileri gittiğinde, kaçınılmaz olarak 8 boşluk girintisi gibi aptalca bir şey seçerler). Küçük şeyleri terleme.

Basit bir çözüm: Geliştiricilere küme ve girinti için sınırlı sayıda seçenek verin, ancak küme stilinin ve girintinin bir modülde tutarlı olması gerektiğini belirtin. (Foo.h ve foo.cpp'in aynı stile uymasını istersiniz, öyle değil mi?) Bakıcılar mevcut stile uyum sağlamalı; tuhaf tarzlarına uyacak bir modülü yeniden yazamazlar. Bir modül içindeki çoklu stiller sadece kafa karıştırıcıdır ve bir dikkatsizlik işaretidir. Bu saçmalığı gördüğümde, başka neyin yanlış olduğunu merak ediyor.

Ayrıca , bir dosyanın kayıtlı içeriğindeki girintileri sekmeleri yasaklama hakkında düşünmek isteyebilirsiniz . Çoğu IDE / editör, kullanıcı girişi sekmelerini boşluklara çeviren makul bir iş çıkarır ve çoğunun bu çeviriyi otomatik yapmak için seçenekleri vardır. Birçoğu dosya zaten sekmeler, özellikle karışık bir sekme ve boşluk torbası içerdiğinde berbat bir iş çıkarır.

Bütün bunlar, projenizde daha derin bir sorun olabileceğini düşünüyorum. Birleşmeyle ilgili sorunlardan bahsettiniz. Kendinizi çok fazla bir araya getirme ihtiyacı duyuyorsanız, bu projenin kötü bir şekilde bölümlendiğinin bir işareti olabilir. Tıpkı çok fazla aşçının suyu berbat ettiği gibi, aynı dosya üzerinde çalışan çok sayıda programcı da projeyi bozuyor. Neden her biri Joe, Susie ve foo.cpp'e dokunuyorsunuz?

Bu, bazı araştırmaların yapıldığı alanlardan biridir. Temel olarak ana soru, kod incelemeleri yapıp yapmadığınızdır. Kod incelemeleri şüphesiz kod kalitesini yükseltmek için en etkili yoldur. (Kaynak: Yazılım Mühendisliği Enstitüsü, CMU). Kesinlikle ekstra bir test cihazından daha verimli.

Şimdi, kod incelemeleri ortak bir kodlama standardından yararlanıyor, çünkü diğer insanların kodlarını okumayı kolaylaştırıyor. Bu size kodlama standartlarını tanıtmak için iki adımlı bir argüman sunar: Sonunda, iyi kod üretmeyi daha ucuz hale getirir.

Bu konuda sizinle birlikte olan “birkaç kişi” olduğu için, doğaçlama bir toplantı öneriyoruz. Tüm geliştiricileri davet et, kısa bir süre ayır ve her gün kendini ve meslektaşlarını rahatsız eden şeyleri çöz. İlk başta özel çözümler bulmaya çalışmayın, sadece şu anda kod yazma şeklinizde neyin değişmesi gerektiğini anlayın.

Sonra, bazı temel kavramlar üzerinde hemfikir olabilir misiniz bakalım. @David Hammen'in getirdiği her modülde aynı stili kullanma önerisi iyi bir başlangıç ​​ve çoğu geliştiricinin kolayca kabul edebileceğini düşünüyorum.

Eğer bir kez aşağı pat varsa, yeni kod yazarken bazı temel stil üzerinde hemfikir olabilirsiniz, bu iyi bir ek. Sürdürülebilirliği gerçekten etkileyen şeylere odaklanın; isimlendirme sorunları kişisel listemde yüksek olurdu çünkü herhangi bir önemli karmaşıklığa sahip tek bir üründe yarım düzine farklı adlandırma stiliniz varsa, çok hızlı bir şekilde başınızı ağrıtır, ama yine, sizin ve ekibinizin önemli olduğunu düşündüğünüze odaklanır . Herkesin en azından takip etmeyi kabul edebileceği (farklı bir evcil hayvan stiline sahip olsalar bile) kısa bir belge hazırlayın ve ekipteki herkese postalayın. "Yaşayan" bir belge haline getirin, zaman içinde güncellediğinizden emin olun, ancak çok katı ve belirli olmadığından emin olun .

Patronunuz kod yazmaya dahil olmadığı sürece, hangi stilin benimsendiğiyle ilgili çok fazla endişe etmemelidir (okunabilirlik ve bakımın üzerinde durması şartıyla), ancak ortak bir stili izleyen ekipteki herkesin yararlarını görebilmelidir. Kod yazarken

Acı veren bazı şeyler var. En acı verici olanı, IDE'lerini farklı şekillerde ayarlayan geliştiricilerle birlikte kodu otomatik olarak yeniden düzenleyen bir IDE'dir. Kodları her karşılaştırışınızda, kodu farklı ayarlara sahip birisinin değiştirmesinden sonra yüz değişiklik yapılır. Bu kabul edilemez. Burada herkesin kafalarını birbirine vurmanız, bir dizi ayar üzerinde anlaşmanız ve farklı ayarları kullanan herkes tarafından herhangi bir geri dönüşü reddetmeniz gerekir. Tek bir kod satırını değiştirirsem, farkların yüzlerce değil, tek bir kod satırının değiştiğini göstermesi gerekir.

Diğer her şey zararsızdır veya başkalarının ikna edebileceği şeyler yapmanın daha iyi yolları vardır. İşte kural şöyle olmalı: Gerçekten iyileştirmediğiniz sürece başkalarının koduyla uğraşmayın. Ve stil A ile stil B'nin karışımı her zaman hem stil A hem de stil B'den daha kötüdür.

En iyi uygulamayı takip ettiğinizden emin olun. Dil başına farklı olan. Fakat orada standartlara ihtiyacınız yok (ki bu iyi niyetli bir kişi tarafından yazılmış olabilir ama aslında bu bilgili değil), ama herkes iyi örnekler vermeye çalışmalı.

Kesinlikle güç mücadelelerinden kaçının. Ekibindeki bazı Hitler’den herkesi isteğine zorlamaya çalışan daha kötü bir şey yok. Ve ne yazık ki kodlama standartlarınızı yazmak için gönüllü olacak adam :-(

Verdiğiniz tüm örnekler temel olarak boşluk ve biçimlendirme ile ilgilidir. En büyük sorun buysa, yöneticinizle aynı fikirdeyim: o kadar da önemli değil.

Standartların gerçekten çok yararlı olduğu yerler, şeyleri adlandırmak ve karmaşıklığı azaltmaktır. Tanımlayıcıları, sınıfları, nereye koyacaklarını vb. Karmaşıklığın azaltılmasıyla ilgili kurallar, işlevleri belirli sayıda satırın altında tutmak (daha küçük fonksiyonlara bölmek) veya parametre listelerini belirli sayıda argümanın altında tutmak (belki de onları bir nesneye yerleştirmeniz ve etrafından dolaştırmanız gerekir).

Ekibinizdeki belirli bir geliştirici, tek harfli değişken adlarına sahip çok sayıda kod parçası içerdiğinden anlaşılması / hata ayıklaması zor olan bir kod yazarsa, bu, bazı standartların benimsenmesi için iyi bir nedendir; Bir komut dosyası. Bu, standartların geliştirebileceği bir şey olarak (dikkatle) belirtmek için iyi bir şey.

Yöneticinizin bunu bir sorun olarak görmemesinin bir başka nedeni de aslında birbirlerinin kodunu çok sık okumamanızdır. Bu, herkes kendi kod alanına sahip olduğunda ve onun dışına fazla çıkmadığında olabilir. Bu, birisi kuruluştan ayrılıncaya kadar oldukça iyi çalışır; bu, çeşitli iyi veya kötü nedenlerden dolayı olabilir. Okunabilirliğe yardımcı olan standartlar, yeni bir geliştiricinin bir kod parçasının bakımını üstlenmesini kolaylaştıracaktır.

birileri IDE'leri otomatik biçimlendirmek için kullandığından ve girintilemek için farklı bir karakter kullandığından birleştirdiğimde çakışıyor

Bunun gibi bir problem var, formatlama değil, yeniden formatlama sizin probleminiz. Bu, SCM'ler için büyük bir sorundur ve tavsiye basittir: Yapmayın. Bir dahaki sefere birileri tüm boşlukları sekmelere yeniden biçimlendirdiğinde ya da kıvrık parantezleri tercih ettikleri stile dönüştürdüğünde, onları tokatlamanız gerekir. Bunun yerine birleştirme yapmalarını sağlayın; onların düşüncesizliklerinin yol açtığı zaman israfını onaylamamaları üzerine durun.

Alternatif olarak, check-in işleminden önce tüm kodları her zaman standart stile yeniden formatlayan bir ön işleme formatlayıcı koymaktır. Elbette yeniden biçimlendiren bir dev ekibiniz varsa, o zaman bu iyi bir seçenektir - SCM her zaman aynı formatı görecektir, böylece deltalar küçük ve birleştirmek güzel olacaktır.

Birisi çalıştığım yerde yeni bir kodlama standardı önerdiğinde ona oy veriyoruz. Çoğunluk oyu alırsa, aksi takdirde reddedilir. Bunu yapmazsanız, standartlarınızdan satın almayacaksınız ve belgelenmiş olsalar bile kullanılmayacak.

Özel sayınıza göre, en iyi seçeneğiniz muhtemelen Joel'in önerisiyle başlıyor ve örnek olarak lider olacak. Bunu önemseyen 1 veya 2 programcı toplayın, bir anlaşmaya varın ve tembel olanları dayatmaya zorlayacaksınız.

Şimdi, genel sayı için, basitçe modüle etmenin en iyisini buluyorum . Her biri farklı bir dosya alır, bir dosyaya özen göstermek zorunda kalırsanız, kodlama standartlarını diğerlerinden farklı olsa bile sağlam tutarsınız. Aynı dosyaya yazmanız mı gerekiyor? Bir altküme dosyası oluşturun ve bunun yerine ekleyin.

Bunu deneme!

Sayaç örneğiyle kurşun. Kod biçiminizi olabildiğince korkunç hale getirmeye çalışın ve diğer insanların hoş kodunda korkunç biçimde biçimlendirilmiş değişiklikleri kontrol edin. (Kaçınılmaz) reaksiyon oluştuğunda, yaptığınız şeyin iyi olduğunu söyleyin, çünkü kodlama standardı yoktur.

İş arkadaşlarınız (!) Tarafından linç edilmezseniz, bir kodlama standardına sahip olabilirsiniz.

Açıkçası, bu yüksek riskli bir strateji ... :-)