Eğer takımımın yetenekleri düşükse, kodumun becerisini mi düşürmeliyim? [kapalı]

Örneğin, JS'de varsayılan bir değer elde etmek için yaygın bir snippet var:

function f(x) {
    x = x || 'default_value';
}

Bu tür bir snippet, ekibimin tüm üyeleri tarafından kolayca anlaşılmıyor, JS seviyeleri düşük.

O zaman bu numarayı kullanmamalı mıyım? Kodun eşler tarafından daha az okunabilir olmasını sağlar, ancak herhangi bir JS dev'ine göre aşağıdakilerden daha okunabilir olmasını sağlar:

function f(x) {
    if (!x) {
        x = 'default_value';
    }
}

Tabii, eğer bu numarayı kullanırsam ve bir meslektaşım görürse, bir şey öğrenebilirler. Ancak durum genellikle bunu “akıllı olmaya çalışmak” olarak görmeleridir.

Peki, eğer takım arkadaşlarım benden daha düşük bir seviyeye sahipse, kod seviyemi düşürmem gerekir mi?

Tamam, işte bu büyük ve karmaşık konuya benim adım atıyorum.

Kodlama stilinizi korumanın avantajları:

• Gibi şeyler x = x || 10JavaScript geliştirme deyimsel ve kodunuz ve kullandığınız harici kaynakların kodu arasında bir tutarlılık biçimi sunar.
• Yüksek kod düzeyi genellikle daha etkileyicidir, ne elde ettiğinizi bilirsiniz ve yüksek eğitimli profesyoneller arasında okunması kolaydır.
• İşinden daha çok zevk alacaksın. Kişisel olarak güzel kod oluşturmaya değer veriyorum. Bana işimden büyük memnuniyet getirdiğini düşünüyorum.
• Genellikle daha okunabilir bir stil yaratır. Dilin deyimlerine sadık kalmak çok değerli olabilir - genellikle bir sebep için deyimlerdir.

Kodlama stilinizi korumak için dezavantajları:

• Alt seviye programcıların yetişmesi daha zor olacak. Bunlar genellikle kodunuzu koruyan kişiler ve yazdıklarınızı gerçekten okuması gereken kişilerdir.
• Kod koruyucular, genellikle JavaScript kodu diğer dillerden gelir. Programlayıcılarınız Java veya C # konusunda yetkin olabilir, ancak JavaScript'in tam olarak ne zaman ve nasıl farklılaştığını anlayamaz. Bu noktalar genellikle deyimseldir - hemen çağrılan bir işlev ifadesi (IIFE) böyle bir yapının örneğidir.

Benim kişisel görüşüm

Kodunuzun becerisini düşürmemelisiniz. Anlamlı, açık ve özlü bir kod yazmayı hedeflemelisiniz. Takımınızın seviyesi hakkında herhangi bir şüpheniz varsa - eğitin . İnsanlar, düşündüğünüzden daha fazla öğrenmeye isteklidirler ve daha iyi olduklarına ikna olduklarında yeni yapıları uyarlamaya isteklidirler.

'Zeki olduğunuzu' düşünüyorlarsa, amacınızı tartışmaya çalışın. Bazen yanlış yaptığınızı kabul etmeye istekli olun ve ne olursa olsun, çalışma ortamınızdaki stilleri tutarlı tutmaya çalışın. Bunu yapmak düşmanlıktan kaçınmaya yardımcı olacaktır.

En önemli şey tutarlı kalmaktır.

Bir takımın kodu, sanki bir kişi kodlamış gibi yazılmalıdır. Kodlama kuralları üzerinde kesinlikle hemfikir olmalısınız . Bu kurallara uymalısınız. Kodlama yönergeleri isteğe bağlı parametrelerin okunmasının 'daha az akıllı' şekilde yapılması gerektiğini belirtirse, bu şekildedir.

Yorum iyi

Kodunuzun becerisini düşürmelisiniz? Zorunlu değil, ama kesinlikle yorumlarınızın becerisini arttırmalısınız . Kodunuza iyi yorumlar eklediğinizden emin olun, özellikle daha karmaşık olacağını düşündüğünüz bölümler etrafına. Kodun takip edilmesi zorlaşacak kadar fazla yorum kullanmayın, ancak her bölümün amacını açıkça belirttiğinizden emin olun.

Gerçek şu ki, yorumlarla biraz daha ayrıntılı olmak, daha az yetenekli ekip üyeleri için faydalı olabilir, ancak özellikle çok fazla kişi varsa, aşırıya kaçmayın.

Bir Stil Meselesi?

Sağladığınız örnek biraz basit, ama aynı zamanda oldukça stilist. Varsayılan her değişkenin etrafındaki bir yorum, okunması ve okunması oldukça sıkıcı olacaktır. Bunun yerine, stilistik veya tekrarlanan kısayollar veya kod desenleri muhtemelen standart olarak oluşturulmalıdır. Eğer böyle bir parametre varsayılanı türünün herkes tarafından anlaşılması ve her seferinde kullanılması gerektiğini düşünüyorsanız, bu fikirleri bir yere yazın ve onları takım liderinize götürün. Takım arkadaşlarınıza öğretmek için alacağınız her şey, teklif ettiğiniz standartları tartıştığınız basit bir toplantıdır.

Daha önce de belirtildiği gibi bir cevap daha tutarlı olsun .

Balıkçılığa Bir Adam Öğretin ...

Takım arkadaşlarına öğretmek muhtemelen katılan herkese yardım etmenin en iyi yoludur. Birisinin bir işlem kodu veya zaman damgası adında adınızla bir kod parçasına ilişkin bir sorusu varsa, size sormaktan çekinmeleri gerektiğini açıkça belirtin. Ekibinizde kod incelemeleri varsa, kafa karıştırıcı (ahem) iyi yorumlanmış herhangi bir kodu ekip arkadaşlarınıza açıklamak için bu harika bir fırsattır . Ekibinizde kod incelemeleri yoksa neden olmasın? Al hadi!

Yine de dikkatli olmalısın. İnsanlara öğretmek için her zaman buralarda olmayabilir ve hatta belirli bir kod bölümünde başlangıçta ne yapmaya çalıştığınızı unutabilirsiniz.

"Zeki" Püf Noktaları

Ekip arkadaşlarınızın yeteneklerinin akılda tutulması kesinlikle önemlidir, ancak korunabilir kod yazmak genellikle daha yaygın çözümlere sahip olabilecek sorunlara yaylı kısayollar kullanmamak anlamına gelir. Takım arkadaşlarınız zeki olsa bile bu önemlidir. Kodun kavranması ya da gözden kaçması gereken ince ancak önemli yan etkileri olması için çok uzun sürmesini istemezsiniz. Genel olarak, uygun alternatifler olduğunda "zeki" numaralardan kaçınmak en iyisidir. Kodun kimin altında kalması gerektiğini asla bilemezsiniz - çoğu zaman kendimizin eski sürümleri bu numaraların ayrıntılarını veya nedenlerini hatırlamayacaktır.

Zekice bir numara uygulamanız gerektiğini düşünüyorsanız, en azından bir sonraki tavsiyeye uyun ...

ÖPMEK

Şüpheniz olduğunda, basit tutun . Kodun basit olup olmamasının, sizin düşünebileceğiniz gibi programcı becerisine mutlaka uyması gerekmez. Aslında, bir problemin en mükemmel çözümlerinden bazıları en basitleridir ve daha karmaşık çözümlerden bazıları TheDailyWTF'e dayanır . Kodunuzu basit ve özlü tutmak, daha zeki fakat muhtemelen karşı sezgisel kararların bazılarının anlaşılmasını kolaylaştırabilir.

JS'de bir fonksiyon yaratma konusunda büyük bir isteksizlik var gibi görünüyor. Bu isteksizlik, insanların zeki olmaya çalışmasına ve sadece bir işlevin çağrıldığı gibi bir satırdaki şeyleri tutmak için saçma numaralar kullanmasına neden olur. Elbette bir çağrıdaki fonksiyon ismi de ekstra dokümantasyon görevi görür. Zor bir ifadeye yorum ekleyemeyiz, çünkü o zaman bunu yapma noktasını yitirir, böylece biz sadece "js deyimi" olarak adlandırırız ve aniden anlaşılabilir olur.

Javascript son derece erişilebilir, çoğu insan bizim gibi kahvaltı için teknik özellikleri yemiyor. Böylece hiçbir zaman bir deyimin saklı varsayımlarının ve son durumlarının ne olduğunu asla anlamayacaklar.

x = x || 'default_value';

Ortalama joe bunu anlamayacak veya varsayılan değer için deyim olduğunu ezberleyecektir. Her ikisi de zararlıdır, aslında ikincisi daha da zararlıdır. Buradaki varsayımları ve son durumları anlamıyor. Şartnameyi okumayı ve onu asla anlamayı umursamıyor.

Ben bu kodu baktığınızda bunu eğer" bölümüne bakın nullveya undefineddaha sonra bu varsayılan değere ayarlayın. O da örtülü olarak görür rağmen +0, -0, NaN, false, ve ""olarak uygun değildir değerlerini. Ben hatırlamak zorunda olacağı 3 ay zaman o ihtiyaçlar andan itibaren değiştirmek için. Ben muhtemelen unutacağım. "

Örtük varsayımın gelecekte bir hataya neden olması son derece muhtemeldir ve kod temanız bu tür püf noktalarla doluysa, bir değişikliğin ne etkileyeceğini düşündüğünüzde hepsini kafanızda tutma şansınız yoktur. Ve bu "JS yanlısı" için, ortalama bir joe, gereksinimler başlangıçta sahte bir değeri kabul etse bile, hatayı yazmış olurdu.

Yeni snippet'iniz daha tanıdık bir sözdizimine sahip, ancak yine de yukarıdaki sorun var.

İle gidebilirsiniz:

function f(x) {
    x = valueOrDefault(x, "default_value");
}

Artık son durumları ele almak için çok karmaşık bir mantığa sahip olabilirsiniz ve müşteri kodu hala güzel ve okunabilir görünüyor.

Şimdi, bir işlevi argüman olarak geçirme ya da akıllıca bir numara gibi ileri dil özellikleri arasında nasıl bir fark var || "default"?

Akıllı hileler, kod ilk olarak yaratıldığında göz ardı edilebilecek bazı gizli varsayımlar altında çalışır. Bir IIFE'yi asla başka bir şeyle değiştirmek zorunda kalmayacağım, çünkü bir ihtiyaç değişti, daima orada olacak. Belki 2020'de gerçek modülleri kullanabildiğimde ama evet.

| 0ya da ~~numdöşeme için kullanılan kargo kült versiyonu, pozitif ve 32-bit işaretli tam sayı sınırlarını varsayar.

|| "default" Tüm sahte değerlerin bir argümanı geçmemekle aynı olduğunu varsayar.

Ve bunun gibi.

Sen olmamalıdır düşürmek programlama beceri, ancak gerekebilir ayarlamak size kod yazmak nasıl. Neredeyse her şeyden önce amaç, kodunuzu, okuması ve bakımını yapması gereken kişilere açık yapmaktır.

Maalesef, belirli bir stilin "zeki" olup olmadığına ya da sadece ileri düzey bir kullanım olup olmadığına dair bir yargılama kararı olabilir. Söz konusu kod buna iyi bir örnektir - çözümünüz mutlaka diğerinden daha iyi değildir. Bazıları tartışacak, bazıları katılmayacak. Her iki çözüm de etkin bir şekilde çalışma zamanı performansına eşit olduğundan (okuma: kullanıcı hiçbir zaman farkı anlamaz), ekibin bir bütün olarak en rahat olduğu stili seçin.

Bazı durumlarda, onlara kodlama için daha iyi yollar öğretmeniz gerekir, ancak diğer zamanlarda açıklık için ödün vermeniz gerekir.

Bu zaten başka bir cevapta söylenmiş olabilir, ancak bu soruya kendi emirlerimle cevap vermek istiyorum.

Genel Rehber

Bir ekip üzerinde çalışırken, bir kod parçasının hedef kitlesi değilsiniz. Kitleniz, ekibinizin geliştiricileridir. İyi sebep olmadan anlayamadıkları kodları yazmayın.

1. Belirli bir dezavantajı olmadığı sürece, kodun tümü, bakımını yapacak geliştiriciler tarafından kolay bakım yapılmasını sağlayacak belirli bir desen veya kılavuzun ardından yazılmalıdır. (Bir ihtar: Sadece şu an kod tabanında bulundukları için kötü kalıpları takip etmek korkunç bir uygulamadır.)
2. Dile özgü bir deyimi, hedef kitle tarafından kolayca okunamayan bir deyim kullanmak için iyi bir neden bulabilirseniz, bir yorum ekleyin. Diğer her satıra bir yorum eklemeniz gerektiğinin farkına varırsanız, hedef kitleniz tarafından daha okunaklı olmak için kodunuzu yeniden yazmak isteyebilirsiniz. Aptal olmak adına aptalca olmanın değerli olduğunu düşünmüyorum.

Belirli bir örnek

Kod tabanımızda çok sayıda perl betiği var. Genelde sadece basit işlemler için perl kullanıyoruz ve kodun büyük çoğunluğu java geliştiricileri tarafından yazılıyor, bu yüzden java'ya çok benziyor. Bir dizi perl senaryosu ve o zamandan beri firmamızdan ayrılan bir 'perl gurusu' tarafından yazılmış bir çerçeveye sahibiz. Bu kod, daha belirsiz olan perl deyimlerinin çoğunu içerir ve kendim de dahil olmak üzere geliştiricilerin hiçbiri bu perl kodunu fazla çaba göstermeden okuyamaz. Bunun için onu sık sık lanetliyoruz. :)

İyi bir kod yazarsanız, ancak şimdiki veya gelecekteki meslektaşlarınızın bunu takip etmekte zorlanabileceğini düşünüyorsanız, açıklamak için kısa bir yorum eklemelisiniz.

Bu şekilde, onlara kendi kişisel zekasına hakaret etmeden veya grup tartışmalarında kimseyi utandırmadan bir şeyler öğretebilirsiniz.

Örneğinize bir numara demem ama sadece aptalca. Kullanmanız gerekiyorsa, IMHO'ya ekibinizin şu anki seviyesine o kadar bağlı değildir, ancak (en azından bazıları) takım arkadaşlarınız yeni deyimler öğrenmeye istekliyse. Elbette, bu konuyu onlarla tartışmalı ve bu tarzı üzerlerinde uygulamamalısınız. Ve sizden her gün 5 yeni şey veya "püf noktası" öğrenmelerini istememelisiniz. Ama dürüst olmak gerekirse, eğer sadece takım arkadaşlarınız varsa, yeni bir şeyler öğrenmeye istekli olmazlarsa, bu deyimden çok basit ve küçük olsa bile, farklı bir takıma geçmeyi düşünmelisiniz.

Bu soruyu okumak ve ardından gelen cevap ve tartışmalar iki nokta gibi görünüyor. İlk: Gelişmiş dil özelliklerini kullanmak uygun mudur? İkincisi: Bunu 'gösteriş yapıyor' gibi görünmeden nasıl yapabilirim?

İlk durumda, iyileştirmeler ve gelişmiş özellikler kullanmak mantıklıdır. Örneğin: C # 'da Linq veya Lambda ifadelerini kullanmak zorunda değilsiniz ama çoğu insan bunu yapıyor çünkü kodun daha düzenli ve anlaşılması kolay, çünkü ne yaptığını gerçekten öğrendikten sonra. İlk başta sadece garip görünüyor.

İnsanlar kalıplara alışırlar ve çoğu durumda insanlar, sadece işi yapmak için işleri yapma yolunu kullanırlar. Bundan sonraki adam kadar suçluyum. Hepimizin son tarihleri ​​var. Bazı açılardan, yeni fikirler ve yeni düşünme biçimleri getirmekten suçlusunuz! Bu ikinci noktaya geliyor ve muhtemelen en çok dirençle karşılaşabileceğiniz yer burasıdır.

Web sitesini kullanan kişi için hangi tarzın kullanıldığını umursamıyorlarsa, işe yarıyor mu? Hızlı mı Öyleyse, yolunuzda performans avantajı yoksa, verdiğiniz örnekte doğru ya da yanlış yol yoktur. Yolunuz kodu daha okunabilir kılıyor mu? Meslektaşların buna alıştıktan sonra yapabilir.

Peki, bu değişiklikleri nasıl tanıtıyorsunuz? Bu satırlar boyunca meslektaşlarınızla görüşmeye çalışın: Bu fonksiyonun bu şekilde yazılabileceğini biliyor muydunuz? Kod incelemeleri ve çift programlama, fikirlerin 'çapraz tozlaşmasına' izin vermek için iyi zamanlar olabilir. Ne yapacağımı söylemek benim için zor, çünkü çalıştığın ortamı bilmiyorum. Bazı programcıların değişime karşı çok savunmacı ve dirençli olabileceğini düşünüyorum. Yine bundan suçlu oldum. Bu tür programcılar ile çalışmanın en iyi yolu, biraz zaman geçirmelerini, öğrenmelerini, arka planlarını öğrenmelerini ve stillerinizi ve deneyimlerinizi onlarınkilerle karşılaştırıp karşılaştırmasını öğrenmektir. Zaman alır ama iyi harcanan zamandır. Mümkünse onları deneyin ve teşvik edin.

O zaman Royal McBee Computer Corp için çalışmayın, çünkü deneyimsiz bir programcı olmadığınızı söyleyenler.

emin, kısa ve kısa kod yazmak harika ve bir javascript ortamında faydalı olabilir (birileri tarayıcılara indirmek için bir js derleyicisi üretene kadar, ama bu başka bir hikaye).

Yine de önemli olan, kodunuzu yazmanızın birkaç dakikasını geçmeden yaşayabilme yeteneği. Tabii, çabuk ve kolay ve onu parçalayıp devam ettirebilirsiniz, ancak yıllar sonra tekrar gelmek zorunda kalırsanız, o zaman "hangi muppet'in bunu yazdığını" düşünebilir ve bunun siz olduğunu anlayabilirsiniz! (Bunu yaptım, çoğu insanın da var olduğundan eminim .. Aşırı agresif süreleri suçluyorum, dürüst).

Akılda tutulması gereken tek önemli şey budur, bu yüzden evet diyorum - eğer çalışırsa ve açıksa o belirli operatöre gidin ve 'deneyimsiz' devleriniz (yine de onlar için aşağılayıcı olmakla birlikte, çok şey biliyorum) Çeşitli web sayfası derslerini ve referanslarını ezberledikleri için tüm operatörleri ve püf noktaları bilen deneyimsiz devlerin listesi, her küçük numarayı bilmelerine rağmen en kötü kodu yazarlar ... bunun için tesadüften daha fazlası olabilir)

Her neyse, eğer Mel'in hikayesini okuyabilseydin , Mel'in ilk sıralamanın gerçek bir programcısı olmasına rağmen, numaraların herhangi bir koda koyacak en iyi şey olmadığını anlardın. Bu, birisinin iyi kod yazabileceğini söylediği ve diğerlerinin yetişmek için daha fazla şey öğrenmesi gerektiğini söylediği herhangi bir argümana para kazandırır.

Bana basit JS gibi görünen başlangıçlar için.

Ancak genel olarak - "hatayı ayıklamak programlamadan iki kat daha zordur." Yapabildiğiniz kadar zekice yazıyorsanız, tanımı gereği hata ayıklayamazsınız "ifadesini kullanmak için akıllıca kesmek zorunda değilsiniz.

Bu, başkalarının anlamadığı için koddan kaçınmanız gerektiği anlamına gelmez - kodu olabildiğince açık ve tutarlı bir şekilde yazmalısınız. Ancak net kriterleriniz "bunu bir yıldaki ilk okumada anlayacağım mı" olmalı, "kimse anlayamaz" değil.

Net bir şekilde yazın, anlamada zorluk çekmeyin ve başkalarının becerilerini arttırmaya çalışmasına izin verin - başkalarına bazı varsayımsal sorunlardan kurtulmak için kendinizi engellemeyin.

Ekip arkadaşlarımla ne tür kodlama standartlarına sahip olmak istediğimizi tartışacağım, bunun nedeni çoğunlukla kod tabanımız için düzinelerce yolla yapılabilecek bir şeyin nasıl yapılması gerektiğidir. Eğer bir cevaba ilk girişimi olacak bir fikir birliği varsa.

Olmazsa, o zaman ne tür bir önerilen standardın mantıklı olduğunu düşünürüm ve onu yönetimle ve bazı ekiple temizledikten sonra uygulamaya koymaya başlarım. Buradaki fikir, yönetimin bu fikir için uygun olduğundan ve yalnızca kendi işimi yapıp başkalarını almaya zorlamadığımdan emin olmaktır.

Buna, kodunuzu değerlendirmenin birçok yolu olduğu için, ekibinizin beceri seviyesinden ziyade ne tür standart ve uygulamalara sahip olduğu sorusuna benziyordum. Başkaları ne kadar iyi koruyabilirlerse bu kriterlerden biridir.

Sorun, kaynağın iyi okunabilirliğini istemenizdir, ancak okunabilirlik, sahibinin gözündedir.

Bu sorunu çözmek için daha iyi araçlara ihtiyacımız olduğunu öneriyorum. Karmaşık bir şey yok, sakıncası yoksa, bunu 50 yıldan fazla bir süredir yapacak teknolojimiz var. Editöre bir ayrıştırıcı ekleyin ve editörün kaynağı sexps biçiminde kaydetmesini sağlayın (evet, tıpkı lisp gibi). Ardından kaynak okunur, editör sözdizimsel ve tipografik olarak ayrıştırır (bilirsiniz, boşluklar, sekmeler, virgüller), kullanıcının tercih ettiği şekli oluşturur.

Bu şekilde yazabilir ve okuyabilirsiniz; x = x || 10diğer programcılar da okuyacaktır.

if (0 == x) { x = 10;}

emacs bunu kolayca yapabilen tüm parçalara sahip.

Kodu yazmak yerine, neden takımın kalitesini yükseltmiyorsun? Eğitim, koçluk, eğitim ve iyileştirilmiş işe alım uygulamaları sürekli iyileştirmeyi sağlamak için çok şey yapabilir.
Devletçilik, kod çürümesi, iyileştirmeyi ve yenilik yapmayı reddettiği için, çünkü birileri kendini iyileştirme üzerinde çalışmak istemiyor, çünkü sadece çizgide ve daha sonra değil, sıkıntıya neden oluyor.

Tabii ki gösterdiğiniz özel durumda, zekice ve kasıtlı olarak gizlenmiş bir kod yazmaya çalışıyorsunuz, ki bu asla iyi bir fikir değildir. İlk önce ve her şeyden önce okunabilir, kolayca anlaşılabilir olmalı, mümkün olan en az ifadeyle ne kadar akıllıca bir şey oluşturduğunuzu göstermek için yazılmamış olmalıdır (özel durumlar hariç için).