Tüm bu kodlama kuralları ne olacak?

Bir şirketteki veya belirli bir projedeki geliştiriciler için kodlama kurallarına sahip olma fikrini her zaman destekledim. Özellikle şirket 10'dan büyükse, şirket büyüdükçe ihtiyaç da artar. Pek çok insanın aynı fikirde olmayacağını biliyorum, ama onlara sahip olmayan projeler gördüm ve kod tamamen felakete benziyor.

Bundan kaynaklanan asıl sorun, if ifadelerinde köşeli parantez kullanmayı veya kodun her yerinde ya da her neyse aynı bağlantı dizesini kullanmayı sevmeyen bu sert başlı olanların nasıl kodlama kurallarına karşı çıkmadan nasıl kullanılacağıdır. fikir?

Onları mücadele kurallarından ziyade bir sorunu çözmeye dahil edin. Ben şahsen diz kuralları "kurallar = kötü" reaksiyonu önlemek umuduyla, "stil kılavuzları", "kodlama standartları" ya da benzer bir fikrini tercih ederim.

Ama öyle olsa bile - kuralların bir sebepten dolayı yerinde olduğunu düşünmeye eğilimliyim ve sert başlı insanların dönmesini sağlamanın yolu, kuralları izleyerek kodu daha kolay hale getirmeye yardımcı olduklarını fark etmelerini sağlamaktır. herkes için okuyun.

Bazen akran baskısı bunun için en iyi çözümdür.

Çalışmamda aşağıdaki çözümlerin üçünü de kullanıyoruz:

1) Mükemmel Checkstyle (Java için) veya StyleCop gibi bir kod stili denetleyicisini benimseyin (C # için . Bunlar, kodlama stilini / kural sapmalarını otomatik olarak vurgulayabilen, kolayca yapılandırılmış araçlardır. Neyin kabul edilebilir ve neyin kabul edilemez olduğunu belirlemek için herkese tarafsız bir 3. taraf verir.

2) Otomatik kaydetme yeniden biçimlendirme kodu şablonunu (burada Eclipse kullanan bir örnek) kabul edin (ve Visual Studio için başka bir şablon ) otomatik olarak biçimlendirin. Bu, birinin nasıl istediklerini kodlamasına izin vermek için mükemmeldir, ancak kaydet / taahhütte tüm kodların aynı şekilde biçimlendirilmesini sağlar. Bunu gerçekten beğendim ve kodumuz hiç bu kadar tutarlı olmamıştı.

3) Kod incelemeleri. Umarım bunları zaten yapıyorsunuzdur, ancak bunların vurgulanması gereken bir şey, kodlama kurallarının / stillerinin konvansiyonu kırdığı yerdir.

Yukarıdakilere ek olarak, herkesin aynı teknede olması ve üzerinde çalıştığı stilleri / kuralları kabul etmesi önemlidir. Herkesten her şey üzerinde anlaşmayacağınızı açıkça belirtin, ancak takımın kararına sadık kalması için takımdan taahhüt isteyin. Bunları ve ekip dönüşünü kullanarak gerçek dünya deneyimini hesaba katmak için seçilen stilleri / kuralları zaman zaman gözden geçirdiğinizden emin olun.

Bundan kaynaklanan asıl sorun, if deyimlerinde köşeli parantez kullanmayı veya kodun her yerinde aynı bağlantı dizesini kullanmayı sevmeyen sabit başlı olanların nasıl yapılacağıdır.

Köşeli parantez kullanmadan "sert başlı" mılar yoksa bu "sert başlı" bir istek mi?

Savaşını seç. Bu çekmeye değer olanlardan biri olduğundan şüpheliyim. Ben "ilk check-in kodu" ayrıntı bu düzeyde yakınındaki herhangi bir yerde beklenen herhangi bir yerde çalışma zevk olmaz . Bu, ekibin yeniden düzenlemeyi anlamadığını gösteren kırmızı bayraklı bir göstergedir.

OO 101 : "Ürün yapması gerekeni yaptığında refactor". Önce değil.

Onlar parantez koymak emin olarak, büyük takımların her bir geliştiricinin omzuna oturup yapmak çok zordur sen gittikleri gerektiğini düşünüyorum - yani birinde güven bana).

Gerçekten gelişiminizi engellediğini düşündüğünüz bir şeyse, o zaman bir "kapı bekçisine" ihtiyacınız olacaktır. Örneğin, kod incelemesi olmadan kullanıcıların check-in yapmasına izin vermeyin. Teknik mimara veya ekip liderine kodu gözden geçirmelerini ve kod stilini "düzelten" olana kadar reddetmelerini sağlayın. Yakında bundan bıkacaklar ve muhtemelen sadece kontrol edildikleri sürece kurallara uyacaklar.

Tabii ki, bazı şirketler check-in ayrıcalıklarını tamamen genç programcılardan alır. Sonunda kuralları kodlayan şirketleri öğrendiklerinde ayrıcalığı elde ederler.

Bence çok farklı seviyelerdeki problemlerden bahsediyorsunuz:

if ifadelerinde köşeli parantez kullanmak istemeyen bu sert başlılar nasıl yapılır,

Açık bir operatör öncelik sorunu olmadığı sürece, bu çoğunlukla bir stil / okunabilirlik sorunudur. İkincisi çok yaygın olmamalıdır ve yine de birim test edilebilir, böylece düzeltilmesi kolaydır. Birincisi kolayca kazanmak için çok az bir şeyle, ancak moralin ciddi olumsuz sonuçlarıyla bir Kutsal Savaş'a dönüşebilir. Bu yüzden dikkatli olun - yalnızca en azından bazı ekipler / topluluklar tarafından kabul edilen ve çalıştığı kanıtlanmış denenmiş ve test edilmiş kuralları itin.

veya kodun her yerinde aynı bağlantı dizesini kullanın,

Sihirli Sabitleri kastediyorsanız, bu aslında bir bakım (artı potansiyel güvenlik) problemidir ve IMHO gibi deneyimli herhangi bir geliştirici bunun Kötü Bir Şey olduğunu anlayacak ve kabul edecektir.

ya da her neyse, kodlama kurallarını bu fikre karşı çıkmadan kullanmak için mi?

İnsanları herhangi bir kodlama kuralına katılmaya zorlayamazsınız - tek şansınız tartışma ve (bazen şiddetli) tartışmalarla ekip üyelerinden ortak bir anlayış ve katılım sağlamaktır . Buna gerek mantıklı ve inandırıcı argümanlar kullanmak her kural arkasında değerini gösteren ve bu kökleşmiş alışkanlıkları ayarlama rahatsızlıktan dolayı ödeme gidiyor aşağıdaki açıklayan. Diğer taraftan, kabul edilen kurallara göre, örneğin check-in sırasında otomatik kod biçimlendirmesi ekleyerek geçişi mümkün olduğunca kolaylaştırmaya çalışın.

Yine de, bazen insanların farklı fikirlere sahip olduğunu kabul etmeniz gerekir , bu nedenle herkesin kabul edebileceği kodlama kuralları belirli açılardan yumuşak olacaktır. Bunu kabul edin ve işleri daha az çabayla geliştirebileceğiniz alanlara odaklanın.

Kural oluşturma konusunda onları dahil edin. Bu genellikle insanları onları takip etmeye teşvik eder.

Kod incelemesi bunun içindir. Kod denetleyicileri, standartları karşılamayan kod geçişine izin vermemelidir. Acil düzeltmeler için kuralları gevşemediğinizden emin olun. Bunu yapmak için baskı altında birkaç kez tekrarlamak zorunda kalmak, işlerini ilk kez düzgün yapma konusunda isteksiz olanları düzeltir.

Her yerde aynı bağlantı dizesi? Bunun çözümü, tüm çoğaltmayı kaldırana kadar yeniden düzenleme yapmaktır. Kopyala-yapıştır kodlayıcıları programcı hapishanesine gitmelidir. (Gülme! Steve Ballmer bekçidir.)

Ama buradaki asıl sorun sizin “yapmak” fiiliniz . Programcıların hiçbir şey yapmasını sağlayamazsınız ve eğer yaparsanız, en değerli özelliklerini boşa harcarsınız: önemsediğiniz bir şey üzerinde çalışmaktan kaynaklanan derin entelektüel katılım.

Çözdüğüm yol:

1. Ekibin ortak bir kodlama standardına sahip olması konusunda ısrar edin. 5 satır uzunluğunda olabilir, ancak hepsinin aynı fikirde olması gerekir.
2. Ne zaman bir argüman fark ederseniz, onu bir araya getirip kodlama standardına koyarlar. İnsanların bir şeyi ileri geri yeniden biçimlendirdiklerini fark ederseniz, bunu bir argüman olarak ele alın.
3. Standart bir öğe üzerinde anlaşmaya varıldığında, kod tabanının tamamını bir kerede temizleyecek bir araç olup olmadığına bakın.
4. Her iki ayda bir, kodlama standardını gözden geçirin ve hangilerinin hala doğru ve alakalı olduğunu görün. Standart sadece insanların ne yaptığını belgeliyor. Ayrıca, standartta belirgin hale gelen öğeleri korumanın bir anlamı yok.

Programlama bir takım sporu ya da kolektif bir sanatsal çalışmadır. İnsanların üzerinde hemfikir olduğu şey, hemfikir oldukları kadar önemli değildir ve gerektiğinde yeni anlaşmalara varmada iyidir.