Patronum benden küçük fonksiyonlar yazmamı ve her şeyi aynı döngüde yapmamı istedi.

Robert C. Martin tarafından Temiz Kod adlı bir kitap okudum . Bu kitapta, küçük işlevler yazmak, adları dikkatlice seçmek, vb. Gibi kodları temizlemek için birçok yöntem gördüm. Ancak bugün patronum bu kitabı okuduktan sonra kod yazmamı sevmedi.

Argümanları vardı

• Küçük fonksiyonlar yazmak acı vericidir, çünkü kodun ne yaptığını görmek için her küçük fonksiyona geçmeniz için sizi zorlar.
• Ana döngü 300 satırdan fazla olsa bile her şeyi ana büyük döngüye yerleştirin, okunması daha hızlıdır.
• Küçük kodları yalnızca kodu kopyalamanız gerekiyorsa yazın.
• Yorumun adını içeren bir işlev yazmayın, yukarıdaki kod içeren karmaşık kod satırınızı (3-4 satır) koyun; benzer şekilde, başarısız kodu doğrudan değiştirebilirsiniz

Bu okuduğum her şeye aykırı. Genellikle nasıl kod yazarsınız? Bir ana büyük döngü, küçük işlevler yok mu?

Kullandığım dil çoğunlukla Javascript. Açıkça adlandırılmış küçük işlevlerimin tümünü sildim ve her şeyi büyük bir döngüye soktuğum için şimdi okumakta gerçekten zorlanıyorum. Ancak, patronum bu şekilde seviyor.

Bir örnek:

// The way I would write it
if (isApplicationInProduction(headers)) {
  phoneNumber = headers.resourceId;
} else {
  phoneNumber = DEV_PHONE_NUMBER;
}

function isApplicationInProduction(headers) {
   return _.has(headers, 'resourceId');
}

// The way he would write it
// Take the right resourceId if application is in production
phoneNumber = headers.resourceId ? headers.resourceId : DEV_PHONE_NUMBER;

Kitapta okuduğum örnek yorumlar, temiz kod yazamamak olarak kabul edilir çünkü küçük işlevler yazarsanız ve çoğu zaman güncellenmemiş yorumlara yol açarsanız eskidirler (yorumunuzu değil kodunuzu değiştirirsiniz). Ancak yaptığım, yorumu silmek ve yorum adını içeren bir işlev yazmaktır.

Peki, temiz bir kod yazmak için hangi yöntem / uygulamanın daha iyi olduğu konusunda bir tavsiye istiyorum.

İlk önce kod örneklerini alarak. Siz favoriniz:

if (isApplicationInProduction(headers)) {
  phoneNumber = headers.resourceId;
} else {
  phoneNumber = DEV_PHONE_NUMBER;
}

function isApplicationInProduction(headers) {
   return _.has(headers, 'resourceId');
}

Ve patronun bunu şöyle yazardı:

// Take the right resourceId if application is in production
phoneNumber = headers.resourceId ? headers.resourceId : DEV_PHONE_NUMBER;

Kanımca her ikisinin de sorunları var. Kodunuzu okuduğumda, derhal benim düşüncem " ifüçlü ifadeyle değiştirebilirsin " idi. Sonra patronunun kodunu okudum ve "fonksiyonunu neden bir yorumla değiştirdi?" Diye düşündüm.

En uygun kodun ikisi arasında olduğunu söyleyebilirim:

phoneNumber = isApplicationInProduction(headers) ? headers.resourceId : DEV_PHONE_NUMBER;

function isApplicationInProduction(headers) {
   return _.has(headers, 'resourceId');
}

Bu size her iki dünyanın da en iyisini verir: basitleştirilmiş bir test ifadesi ve yorum test edilebilir kod ile değiştirilir.

Patronunuzun kod tasarımı konusundaki görüşlerine rağmen:

Küçük fonksiyonlar yazmak acı vericidir çünkü kodun ne yaptığını görmek için her küçük fonksiyona geçmeniz için sizi zorlar.

İşlev iyi adlandırılmışsa, durum bu değil. isApplicationInProductionaçıktır ve ne olduğunu görmek için kodu incelemeye gerek yoktur. Aslında tam tersi doğrudur: kodun incelenmesi, işlev adından daha az niyeti olduğunu gösterir (bu nedenle patronunuzun yorumlara başvurması gerekir).

Ana döngü 300 satırdan fazla olsa bile her şeyi ana büyük döngüye yerleştirin, okunması daha hızlıdır

Tarama yapmak daha hızlı olabilir, ancak kodu gerçekten "okumak" için, kafanızda etkili bir şekilde uygulayabilmeniz gerekir. Küçük işlevlerde bu kolay ve 100 satırlık yöntemlerle gerçekten çok zor.

Kod kopyalamanız gerekiyorsa, yalnızca küçük işlevler yazın

Katılmıyorum. Kod örneğinizin gösterdiği gibi, küçük, iyi adlandırılmış işlevler, kodun okunabilirliğini artırır ve örneğin bir işlevsellik parçasının "nasıl", sadece "ne" ile ilgilenmediğiniz zaman kullanılmalıdır.

Yorumun adını içeren bir işlev yazmayın, karmaşık kod satırınızı (3-4 satır) yukarıdaki yorumu yazın. Bunun gibi başarısız kodu doğrudan değiştirebilirsiniz

Bunun gerçekten de ciddi olduğunu farz ederek, bunun arkasındaki nedeni gerçekten anlayamıyorum. Bu Uzman Acemi twitter hesabı tarafından parodi yazılmış görmek beklediğim bir şey . Yorumların temel bir kusuru vardır: derlenmemiş / yorumlanmamıştır ve bu nedenle birim test edilemez. Kod değiştirilir ve yorum tek başına bırakılır ve hangisinin doğru olduğunu bilmeden kalırsınız.

Kendini belgeleyen kod yazmak zordur ve bazen ek belgeler (yorum biçiminde bile) gerekir. Ancak "Bob Amca" nın yorumlamada bir kodlama hatası olduğu görüşü çok sık doğrudur.

Patronunuzun Temiz Kod kitabını okumasını sağlayın ve kodunuzu sadece onu tatmin etmek için daha az okunabilir hale getirmeye direnmeye çalışın. Sonuçta, onu değiştirmeye ikna edemezseniz, ya sıraya girmeli ya da daha iyi kodlayabilecek yeni bir patron bulmalısınız.

Başka sorunlar var

Her iki kod da iyidir, çünkü her ikisi de kodu temelde hata ayıklama testi durumuyla şişirir . Sebebi ne olursa olsun daha fazla test etmek istersen?

phoneNumber = DEV_PHONE_NUMBER_WHICH_CAUSED_PROBLEMS_FOR_CUSTOMERS;

veya

phoneNumber = DEV_PHONE_NUMBER_FROM_OTHER_COUNTRY;

Daha fazla dal eklemek ister misiniz?

Önemli sorun, kodunuzun bir bölümünü temelde çoğaltmanız ve bu nedenle gerçek kodu sınamamanızdır. Hata ayıklama kodunu test etmek için hata ayıklama kodu yazıyorsunuz, ancak üretim kodunu yazmıyorsunuz. Kısmen paralel bir kod temeli oluşturmak gibi bir şey.

Patronunuzla nasıl kötü kod yazmanın daha akıllıca olacağını tartışıyorsunuz. Bunun yerine, kodun kendine özgü sorunu düzeltmelisiniz.

Bağımlılık enjeksiyonu

Kodunuzun nasıl görünmesi gerektiği:

phoneNumber = headers.resourceId;

Dallanma yok, çünkü buradaki mantığın dallanma yok. Program telefon numarasını başlıktan çekmelidir. Dönemi.

DEV_PHONE_NUMBER_FROM_OTHER_COUNTRYSonuç olarak sahip olmak istiyorsanız , bunu içine almalısınız headers.resourceId. Bunu yapmanın bir yolu, sadece headerstest senaryoları için farklı bir nesne enjekte etmektir (eğer bu doğru kod değilse özür dilerim, JavaScript becerilerim biraz paslanmış):

function foo(headers){
    phoneNumber = headers.resourceId;
}

// Creating the test case
foo({resourceId: DEV_PHONE_NUMBER_FROM_OTHER_COUNTRY});

Bunun headersbir sunucudan aldığınız yanıtın bir parçası olduğunu varsayalım : İdeal olarak headers, test amacıyla çeşitli türler sunan eksiksiz bir test sunucunuz vardır . Bu şekilde, gerçek üretim kodunu olduğu gibi test edersiniz ve üretim kodu gibi çalışabilecek ya da çalışmayabilecek yarı çoğaltılmış kodları test edemezsiniz.

Buna "doğru" ya da "yanlış" cevap yok. Ancak 36 yıllık mesleki deneyime dayanarak yazılım sistemleri tasarlama ve geliştirme fikrini sunacağım ...

1. "Kendini belgeleyen kod" diye bir şey yoktur. Neden? Çünkü bu iddia tamamen özneldir.
2. Yorumlar asla başarısız olmaz. Bir başarısızlık nedir , hiç yorum yapmadan anlaşılamayan koddur .
3. Bir kod bloğundaki 300 kesintisiz kod satırı bir bakım kabusu ve yüksek oranda hatalara açık. Böyle bir blok, kötü tasarım ve planlamanın güçlü bir göstergesidir.

Doğrudan verdiğiniz örneğe göre konuşma ... isApplicationInProduction()Kendi rutini içine yerleştirmek yapılacak en akıllı şeydir. Bugün bu test sadece "başlıkların" kontrolüdür ve bir ternary ( ?:) operatöründe kullanılabilir. Yarın, test çok daha karmaşık olabilir. Ayrıca, "headers.resourceId" uygulamasının "üretim durumundaki" ifadesiyle açık bir ilişkisi yoktur; Böyle bir durum için yapılan bir testin , temel verilerden ayrıştırılması gerektiğini ; Bir alt yordam bunu yapacak ve bir terner olmayacak. Ek olarak, faydalı bir yorum, resourceId'nin neden "üretimde" için bir test olduğu sonucuna varabilir.

"Açıkça adlandırılmış küçük işlevler" ile denize girmemek için dikkatli olun. Bir rutin bir fikri “sadece kod” dan daha fazla içermelidir. Amon'un önerisini destekliyorum ve "üretim durumu" testini yapması gerekenleri phoneNumber = getPhoneNumber(headers)ekliyorum.getPhoneNumber()isApplicationInProduction()

“Varlıklar gerekliliğin ötesinde çarpılmamalıdır”

- Occam Jilet

Kod mümkün olduğu kadar basit olmalıdır. Hatalar karmaşıklık arasında gizlenmeyi sever, çünkü orada fark etmeleri zor. Peki kodu basit yapan ne?

Küçük birimler (dosyalar, fonksiyonlar, sınıflar) iyi bir fikirdir . Küçük birimlerin anlaşılması kolaydır çünkü bir kerede anlamanız gereken daha az şey vardır. Normal insanlar bir seferde sadece ~ 7 kavramlarını oynatabilir. Ancak boyut yalnızca kod satırlarında ölçülmez . Kodu “golf ederek” (kısa değişken isimleri seçerek, “akıllı” kısayollar alarak, tek bir satıra mümkün olduğunca çok kod yazarak) mümkün olduğunca az kod yazabiliyorum, ancak sonuç basit değil. Bu tür kodları anlamaya çalışmak okumadan çok tersine mühendislik gibidir.

Bir fonksiyonu kısaltmanın bir yolu, çeşitli yardımcı fonksiyonları çıkarmaktır. Bağımsız bir karmaşıklık parçasını çıkardığında bu iyi bir fikir olabilir . İzolasyonda, bu karmaşıklık parçasının yönetilmesi (ve test edilmesi!) İlgisiz bir soruna gömüldüğünden çok daha kolaydır.

Ancak her işlev çağrısı bir sahiptir bilişsel yükü : Sadece kod anlamak gerekmez içinde kod benim şimdiki parça, ben de o kod ile nasıl etkileşime girdiğini anlamak zorunda dışarıdan . Çıkardığın işlevin, işleve, işlediğinden daha fazla karmaşıklık getirdiğini söylemek doğru olur . Patronunuzun kastettiği “ küçük işlevler [bir acıdır” çünkü kodun ne yaptığını görmek için her bir küçük işleve geçmeye zorlar. ”

Bazen, uzun sıkıcı fonksiyonlar , yüzlerce satır uzunluğunda olsalar bile, anlaşılması inanılmaz derecede basit olabilir . Bu, başlatma ve yapılandırma kodunda, örneğin bir sürükle ve bırak editörü olmadan elle bir GUI oluştururken ortaya çıkma eğilimindedir. Makul bir şekilde çıkartabileceğiniz kendine yeten bir karmaşıklık yoktur. Ancak, biçimlendirme okunabilir ve bazı yorumlar varsa, olanları takip etmek gerçekten zor değil.

Başka birçok karmaşıklık ölçütü var: Bir kapsamdaki değişkenlerin sayısı mümkün olduğunca az olmalıdır. Bu değişkenlerden kaçınmamız gerektiği anlamına gelmez . Bu, her değişkeni gerektiği yerde mümkün olan en küçük kapsamla sınırlamamız gerektiği anlamına gelir. Değişkenler, içerdikleri değeri asla değiştirmezsek daha da basitleşir.

Çok önemli bir ölçüm, siklomatik karmaşıklıktır (McCabe karmaşıklığı). Bir parça kod aracılığıyla bağımsız yol sayısını ölçer. Bu sayı her koşullu katlanarak artmaktadır . Her koşullu veya döngü, yol sayısını iki katına çıkarır. 10 puandan fazla bir puanın çok karmaşık olduğunu gösteren kanıtlar var. Bu, 5 puan alan çok uzun bir fonksiyonun, 25 puan alan çok kısa ve yoğun bir fonksiyondan belki de daha iyi olduğu anlamına gelir.

Şartlı, tamamen çıkarılabilecek bir karmaşıklık örneğidir:

function bigFatFunction(...) {
  ...
  phoneNumber = getPhoneNumber(headers);
  ...
}

...

function getPhoneNumber(headers) {
  return headers.resourceId ? headers.resourceId : DEV_PHONE_NUMBER;
}

Bu hala kullanışlı olmanın sınırında. Bu şartın karmaşıklığı önemli ölçüde azaltıp azaltmadığından emin değilim, çünkü bu şart çok şartlı değil . Üretimde her zaman aynı yolu izleyecektir.

Karmaşıklık asla kaybolamaz. Sadece etrafa karıştırılabilir. Birçok küçük şey birkaç büyük şeyden daha mı basittir? Bu, duruma çok bağlı. Genellikle, doğru hisseden bazı kombinasyonlar vardır. Farklı karmaşıklık faktörleri arasındaki bu uzlaşmayı bulmak sezgiyi ve tecrübeyi ve biraz da şans gerektirir.

Çok küçük fonksiyonların ve çok basit fonksiyonların nasıl yazılacağını bilmek yararlı bir beceridir, çünkü alternatifleri bilmeden bir seçim yapamazsınız. Mevcut duruma nasıl uygulanacaklarını düşünmeden kurallara veya en iyi uygulamalara kör bir şekilde uymak , en iyi ihtimalle ortalama sonuçlara, en kötü ihtimalle kargo-kült programlamasına yol açar .

Patronunla aynı fikirde değilim. Argümanları geçersiz değil, ancak Temiz Kod kitabının da yanlış olması. Patronunuzun kurallarına uymak muhtemelen daha iyidir, ancak bu sorunları düşündüğünüz, daha iyi bir yol bulmaya çalıştığınız gerçeği çok umut vericidir. Deneyim kazandıkça, kodunuz için iyi bir faktoring bulmayı daha kolay bulacaksınız.

(Not: bu cevap, kodu ne basitleştirdiği konusunda üst düzey bir görünüm sağlayan Beyaz Tahta'dan The Whiteboard tarafından yazılan Makul Kod blog yazısının düşüncelerine dayanmaktadır .)

Robert Martin'in programlama stili kutuplaştırıcıdır. “Bu kadar” ayrılmanın neden bu kadar fazla olduğu ve işlevlerini biraz daha büyük tutmanın neden “daha ​​iyi” olduğu konusunda birçok mazeret bulmuş birçok programcı, hatta deneyimli olanlar bulacaksınız. Bununla birlikte, bu "argümanların" çoğu zaman eski alışkanlıklarını değiştirme ve yeni bir şeyler öğrenme isteksizliğinin bir ifadesidir.

Onları dinleme!

Ne zaman bir kod parçasını etkileyici bir adla ayrı bir işleve yeniden aktararak bir yorum kaydedebiliyorsanız, bunu yapın - büyük olasılıkla kodunuzu geliştirir. Bob Martin'in temiz kod kitabında yaptığı kadar ileri gitmediniz, ancak geçmişte gördüğüm kodun büyük çoğunluğu çok küçük işlevler içermeyen çok büyük işlevler içeriyordu. Dolayısıyla, kendi kendine tanımlayan isimlerle daha küçük fonksiyonlar yazmaya çalışmak ne denemeniz gerektiğidir.

Otomatik yeniden düzenleme araçları, yöntemleri çıkarmayı kolay, basit ve güvenli hale getirir. Ve lütfen,> 300 satırlık yazı yazma işlevini öneren kişileri ciddiye almayın - bu tür insanlar kesinlikle nasıl kodlamanız gerektiğini söylemeye yetkili değildir.

Senin durumunda: Bir telefon numarası istiyorsun. Bir telefon numarasını nasıl alacağınız çok açık, sonra da açık kodu yazıyorsunuz. Veya nasıl bir telefon numarası alacağınız belli değil, o zaman bunun için bir yöntem yazıyorsunuz.

Senin durumunda, telefon numarasının nasıl alınacağı belli değil, bu yüzden bunun için bir yöntem yaz. Uygulama açık değil, ancak bu yüzden ayrı bir yönteme koyuyorsunuz, bu yüzden sadece bir kez başa çıkmanız gerekiyor. Bir yorum faydalı olacaktır çünkü uygulama açık değildir.

"İsApplicationInProduction" yöntemi oldukça anlamsız. Bunu getPhonenumber yönteminden çağırmak, uygulamanın daha belirgin olmasını sağlamaz ve neler olup bittiğini öğrenmeyi zorlaştırır.

Küçük fonksiyonlar yazmayın. İyi tanımlanmış bir amacı olan işlevleri yazın ve bu iyi tanımlanmış amacı yerine getirin.

PS. Uygulamayı hiç sevmiyorum. Telefon numarasının yokluğunun bunun dev bir sürüm olduğu anlamına gelir. Yani, telefon numarası üretimde yoksa, yalnızca işlemez değil aynı zamanda rasgele bir telefon numarası kullanabilirsiniz. 10.000 müşteriniz olduğunu ve 17'sinin bir telefon numarasının olmadığını ve üretimde sorun yaşadığını hayal edin. Üretimde veya geliştirmede olup olmadığınız, doğrudan kontrol edilmeli, başka bir şeyden türetilmemelidir.

Her iki uygulamanın da bu kadar iyi olmadığı gerçeğini görmezden gelse bile, bunun temelde en azından tek kullanımlık önemsiz işlevleri çıkarma düzeyinde bir tat meselesi olduğunu not edeceğim.

Satır sayısı çoğu durumda kullanışlı bir ölçüm değildir.

Son derece önemsiz saf sıralı kodun (Kurulum ya da buna benzer bir şey) 300 (ya da 3000) satırında nadiren bir sorun vardır (Ancak daha iyi otomatik olarak ya da bir veri tablosu ya da başka bir şey olabilir), çok sayıda karmaşıkla iç içe geçmiş 100 satır Gauss Elimination veya matrix inversiyonunda bulabileceğiniz çıkış koşulları ve matematiği kolayca takip etmek için çok fazla olabilir.

Benim için, bir şeyi bildirmek için gereken kod miktarı, uygulamayı oluşturan kodun miktarından çok daha küçük olmadıkça, tek bir kullanım işlevi yazmazdım (Kolayca hata enjeksiyonunu yapabilmek istemek gibi bir nedenim olmadığı sürece). Tek bir şartlı nadiren bu faturaya uyuyor.

Şimdi, yığın derinliği ve çağrı / geri dönüş ek yükleri gibi şeyleri de göz önünde bulundurmamız gereken küçük bir çekirdek yerleşik dünyadan geliyorum (Bu, yine de burada savunulmuş gibi görünen küçük işlev türlerine karşı savunuyor) ve bu, tasarımımı önyargılı bırakıyor olabilir. Kararlar, ancak bu orijinal işlevi bir kod incelemesinde görürsem, cevap olarak eski bir tarza sahip olan alev alacaktır.

Tat, tasarımın öğretilmesi zordur ve yalnızca deneyimle gelir, işlev uzunlukları hakkındaki kurallara indirgenebileceğinden emin değilim ve hatta döngüsel karmaşıklığın bile bir ölçüt olarak sınırlarını taşıdığı konusunda emin değilim (Bazen onlarla başa çıkmak için işler biraz karmaşıktır).
Bu, temiz kodun bazı iyi şeyleri tartışmadığı, konuştuğu ve bu şeyler hakkında düşünülmesi gerektiği, yerel gelenekler ve mevcut kod tabanına ne olduğu konusunda da ağırlık verilmesi gerektiği anlamına gelmez.

Bu özel örnek bana önemsiz ayrıntılarla yaklaşıyor gibi görünüyor, bir sistemi kolayca anlama ve hata ayıklama konusunda çok daha önemli olduğu için çok daha yüksek seviyeli konulardan daha çok endişe duyarım.

Her şeyi büyük bir döngüye koymayın, ancak bunu da çok sık yapmayın:

function isApplicationInProduction(headers) {
   return _.has(headers, 'resourceId');
}

Büyük döngüdeki sorun, birçok ekranı kapladığında genel yapısını görmek gerçekten zor. Bu nedenle, büyük bir parçayı çıkarmaya çalışın, ideal olarak tek bir sorumluluğu olan ve yeniden kullanılabilir olan parçalar.

Yukarıdaki küçük işlevle ilgili sorun, atomiklik ve modülerlik genel olarak iyi olsa da, çok ileri götürülebilmesidir. Yukarıdaki işlevi tekrar kullanmayacaksanız, kodun okunabilirliğinden ve korunabilirliğinden sapar. Ayrıntılara inmek için, ayrıntı satırsonunu okumak yerine işleve atlamanız gerekir ve işlev çağrısı, ayrıntının kendisinden daha az yer kaplar.

Açıkçası, çok fazla şey yapan yöntemler ile çok az şey yapan yöntemler arasında bulunabilecek bir denge var . Birden fazla yerden çağrılacak gidiyordu sürece yukarıdaki gibi küçük bir işlevi patlak asla ve işlev sırf o zaman bile, bu konuda iki kez düşünürdüm o önemli değil yeni mantık tanıtılması ve terimlerde Bu zorlukla kendi varlığına sahip olduğunu garanti eder.

Aslında istediğin bu gibi görünüyor:

phoneNumber = headers.resourceId || DEV_PHONE_NUMBER

Ayarlayın: Bu kendini açıklayıcı okur herkese olmalıdır phoneNumberiçin resourceIdiçin kullanılabilir, ya da varsayılan eğer DEV_PHONE_NUMBERo değilse.

Bu değişkeni yalnızca üretimde gerçekten ayarlamak istiyorsanız, nereden çalıştığınızı belirlemek için başka, daha genel uygulama içi yardımcı program yöntemine (parametre gerektirmeyen) sahip olmalısınız. Bu bilgilerin başlıklarını okumak bir anlam ifade etmiyor.

Künt olalım: Bana göre ortamınız (dil / çerçeve / sınıf tasarımı vb.) "Temiz" kod için uygun değil. Olası her türlü şeyi, birbirine çok yakın olmaması gereken birkaç kod satırında karıştırıyorsunuz. Tek bir fonksiyonun, resourceId==undefüretimde olmadığınızı, üretim dışı sistemlerde varsayılan bir telefon numarası kullandığınızı, resourceId'nin bazı "başlıklara" kaydedildiğini ve ne anlama geldiğini bilmesiyle ne gibi bir iş vardır? Sanırım headersHTTP üstbilgileri, bu nedenle hangi ortamda bulunduğunuzu son kullanıcıya bırakmaya karar verdiniz mi?

Bunun tek parçalarını işlevlere ayırmak, bu temel problemde size pek yardımcı olmaz.

Aranacak bazı anahtar kelimeler:

• ayrışma
• birleşme
• bağımlılık enjeksiyonu

İstediğiniz şeyi (diğer bağlamlarda) sıfır kod satırıyla, kodun sorumluluklarını değiştirerek ve modern çerçeveler (ortamınız / programlama diliniz için var olabilecek veya olmayabilir) kullanarak elde edebilirsiniz.

Açıklamanızdan ("ana" işlevinde "300 satır kod"), "işlev" kelimesi bile (yöntem yerine), elde etmeye çalıştığınız şeyin hiçbir anlamı olmadığını varsayıyor. Bu eski okul programlama ortamında (yani, küçük bir yapıya sahip temel zorunlu programlama, kesinlikle anlamlı sınıflar, MVC veya somesuch gibi bir sınıf çerçeve modeli yok), hiçbir şey yapmanın pek bir anlamı yoktur . Temel değişiklikler olmadan hazneden asla çıkamayacaksınız. En azından patronunuz kod çoğaltılmasını önlemek için işlevler oluşturmanıza izin veriyor gibi görünüyor, bu iyi bir ilk adım!

Hem kod tipini hem de oldukça iyi tarif ettiğiniz programcı tipini biliyorum. Açıkçası, bir meslektaş olsaydı, tavsiyem farklı olurdu. Ama patronun olduğu gibi, bunun için savaşmaya gitmen de işe yaramaz. Sadece patronunuz sizi engelleyemez, ancak kod eklemeleriniz, kısmen yalnızca “işinizi” yaparsanız ve patronunuz (ve muhtemelen diğer insanlar) daha önce olduğu gibi devam ederse, gerçekten daha kötü kodlara yol açacaktır. Programlama stillerine uyarlanırsanız (elbette bu özel kod tabanında çalışırsanız) ve bu bağlamda en iyi sonucu almaya çalışın, sonuçta daha iyi olabilir.

"Temiz" kod yazmanın bir amacıdır. Tek amaç bu değil. Bir başka değerli hedef ise kollokalitedir . Gayrı resmi olarak söyleyin, colocality, kodunuzu anlamaya çalışan insanların ne yaptığınızı görmek için her yere sıçramaya gerek kalmaması anlamına gelir. Üçlü bir ifade yerine iyi adlandırılmış bir işlev kullanmak iyi bir şey gibi görünebilir, ancak bu tür işlevlerin kaç tane bulunduğuna ve nerede bulunduklarına bağlı olarak, bu uygulama sıkıntıya dönüşebilir. Size, bu çizgiyi geçip geçmediğinizi söyleyemem, insanlar şikayet ederse, özellikle bu kişilerin iş durumunuz hakkında bir sözleri varsa, dinlemeniz gerektiğini söylemek dışında.

Küçük fonksiyonları kullanmak, genel olarak iyi bir uygulamadır. Ancak ideal olarak, bir fonksiyonun tanıtılmasının ya büyük mantıksal parçaları ayırması ya da DRYing yaparak kodun genel boyutunu azaltması gerektiğine inanıyorum. Her ikisine de verdiğiniz örnek kodu daha uzun hale getirir ve geliştiricinin okuması için daha fazla zaman gerektirirken, kısa alternatif "resourceId"değerin yalnızca üretimde bulunduğunu açıklamaz. Bunun gibi basit bir şey, özellikle kod temeli için hala yeniyseniz, onunla çalışmaya çalışırken hem unutması hem de şaşırtması kolaydır.

Kesinlikle bir üçlü kullanmanız gerektiğini söylemeyeceğim, birlikte çalıştığım bazı insanlar biraz daha uzun süre tercih ediyor, if () {...} else {...}çoğunlukla kişisel bir seçim. "Bir satır bir şeye yaklaşıyor" tercih etme eğilimindeyim, fakat temelde kod temeli normalde ne kullanırsa yapsın.

Mantıksal kontrol satırı çok uzun veya karmaşık hale getirirse, üçlü kullanırken, değeri tutmak için iyi adlandırılmış bir değişken / s oluşturmayı düşünün.

// NOTE "resourceId" not present in dev build, use test data
let isProduction = 'resourceId' in headers;
let phoneNumber = isProduction ? headers.resourceId : DEV_PHONE_NUMBER;

Eğer kod temeli 300 satır fonksiyonuna doğru uzanıyorsa, o zaman bazı alt bölümlere ihtiyaç duyduğunu söylemek isterim. Ancak biraz daha geniş vuruşların kullanılmasını öneririm.

Verdiğin kod örneği, patronun DOĞRU. Bu durumda tek bir net çizgi daha iyidir.

Genel olarak, karmaşık mantığın daha küçük parçalara bölünmesi okunabilirlik, kod bakımı ve alt sınıfların farklı davranışa sahip olma olasılığı (sadece çok az olsa bile) için daha iyidir.

Dezavantajları göz ardı etmeyin: genel gider işlevi, belirsizlik (işlev, yorum ve işlev adının ima ettiği şeyi yapmaz), karmaşık spagetti mantığı, ölü işlevler potansiyeli (bir zamanlar artık adlandırılmayan bir amaç için yaratıldı).

Uzun fonksiyonlar lehine en az iki argüman düşünebilirim:

• Her satırın etrafında çok fazla içeriğin olduğu anlamına gelir. Bunu resmileştirmenin bir yolu: Kodunuzun kontrol akış grafiğini çizin. İşlev girişi ve işlev çıkışı arasındaki bir tepe noktasında (~ = satır) gelen tüm kenarları bilirsiniz . İşlev ne kadar uzun olursa, o kadar çok köşe var.

• Birçok küçük fonksiyon, daha büyük ve daha karmaşık bir çağrı grafiği olduğu anlamına gelir. Rastgele bir fonksiyondan rastgele bir satır seçin ve "bu satır hangi bağlamda yürütülür?" Sorusuna cevap verin. Bu zorlaşır, arama grafiği ne kadar büyük ve karmaşık olursa o grafikte daha çok köşeye bakmak zorundasınız.

Uzun fonksiyonlara karşı da argümanlar var - birim test edilebilirliği akla yaylanıyor. Biri ile diğeri arasında seçim yaparken, deneyiminizi t̶h̶e̶ ̶f̶o̶r̶c̶e̶ kullanın.

Not: Patronunun haklı olduğunu söylemiyorum, sadece bakış açısı tamamen değeri olmayan olabilir.

Benim görüşüme göre, en iyi optimizasyon parametresinin fonksiyon uzunluğu olmadığını düşünüyorum. Bence düşünmek daha yararlı bir Desiderata'nın şu olduğunu düşünüyorum: her şey eşit olduğunda, hem iş mantığının hem de uygulamanın üst düzey bir tanımını koddan okuyabilmek tercih edilir. (İlgili kod parçasını bulabilirseniz düşük seviye uygulama ayrıntıları her zaman okunabilir.)

David Arno'nun cevabını yorumlayarak :

Küçük fonksiyonlar yazmak acı vericidir çünkü kodun ne yaptığını görmek için her küçük fonksiyona geçmeniz için sizi zorlar.

İşlev iyi adlandırılmışsa, durum bu değil. isUygulamaÜreti açıktır ve ne olduğunu görmek için kodu incelemek gerekli olmamalıdır. Aslında tam tersi doğrudur: kodun incelenmesi, işlev adından daha az niyeti olduğunu gösterir (bu nedenle patronunuzun yorumlara başvurması gerekir).

Ad, dönüş değerinin ne anlama geldiğini açıkça gösterir , ancak kod çalıştırmanın etkileri hakkında hiçbir şey söylemez (= kodun yaptığı ). İsimler (sadece) niyetle ilgili bilgi iletir, kod davranışla ilgili bilgiyi iletir (niyetin hangi kısımlarından bazen çıkarılabileceği).

Bazen birini, bazen diğerini istersiniz, bu nedenle bu gözlem tek taraflı evrensel olarak geçerli bir karar kuralı oluşturmaz.

Ana döngü 300 satırdan fazla olsa bile her şeyi ana büyük döngüye yerleştirin, okunması daha hızlıdır

Tarama yapmak daha hızlı olabilir, ancak kodu gerçekten "okumak" için, kafanızda etkili bir şekilde uygulayabilmeniz gerekir. Küçük işlevlerde bu kolay ve 100 satırlık yöntemlerle gerçekten çok zor.

Kafanda yürütmek zorunda olduğuna katılıyorum. Büyük bir fonksiyonda, birçok küçük fonksiyonda, 500 fonksiyon hattınız varsa, bunun neden kolaylaştığı açık değildir.

500 satırlık düz çizgi son derece yan etkili kodun son halini varsayalım ve etki A'nın etki B'den önce mi sonra mı olduğunu bilmek istediğinizi varsayalım. Satır numaraları. Çok-küçük işlevli durumda, çağrı ağacında etkilerin nerede olduğunu hatırlamalısınız ve unutursanız, bu ağacın yapısını yeniden keşfetmek için önemsiz miktarda zaman harcamak zorunda kalırsınız.

Destek fonksiyonlarının çağrı ağacını geçerken, aynı zamanda iş mantığından uygulama ayrıntılarına ne zaman girdiğinizi belirleme zorluğuyla da karşılaşıyorsunuz. Kanıt olmadan * çağrı grafiğinin ne kadar basit, bu ayrım yapmanın o kadar kolay olduğunu iddia ediyorum.

(*) En azından bu konuda dürüstüm ;-)

Bir kez daha, her iki yaklaşımın da güçlü ve zayıf yönlerinin olduğunu düşünüyorum.

Kod kopyalamanız gerekiyorsa, yalnızca küçük işlevler yazın

Katılmıyorum. Kod örneğinizin gösterdiği gibi, küçük, iyi adlandırılmış işlevler, kodun okunabilirliğini artırır ve [örneğin] bir işlevsellik parçasının "nasıl", sadece "ne" si ile ilgilenmediğiniz zaman kullanılmalıdır.

“Nasıl” ya da “ne” ile ilgilenip ilgilenmediğiniz, kodu okuduğunuz amacın bir işlevidir (örneğin, genel bir fikir edinmek veya bir hatayı izlemek gibi). Kodu okuduğunuz amaç programı yazarken kullanılamaz ve büyük olasılıkla kodu farklı amaçlar için okuyacaksınız; farklı kararlar farklı amaçlar için optimize edecektir.

Bu, patronun muhtemelen en fazla katılmıyorum görüşünün bir parçası olduğunu söyledi.

Yorumun adını içeren bir işlev yazmayın, karmaşık kod satırınızı (3-4 satır) yukarıdaki yorumu yazın. Bunun gibi başarısız kodu doğrudan değiştirebilirsiniz

Bunun gerçekten de ciddi olduğunu farz ederek, bunun arkasındaki nedeni gerçekten anlayamıyorum. [...] Yorumların temel bir kusuru var: derlenmemiş / yorumlanmamıştır ve bu nedenle birim test edilemez. Kod değiştirilir ve yorum tek başına bırakılır ve hangisinin doğru olduğunu bilmeden kalırsınız.

Derleyiciler sadece eşitlik isimlerini karşılaştırırlar, asla yanıltıcı bir isim vermezler. Ayrıca, birkaç çağrı sitesi belirli bir işlevi isme göre çağırabildiğinden, bazen bir ismi değiştirmek daha zor ve hataya açıktır. Yorumların bu sorunu yok. Ancak, bu biraz spekülatiftir; Bunu gerçekten halletmek için, muhtemelen programcıların yanıltıcı yorumları ve yanıltıcı isimleri güncelleme ihtimalinin daha yüksek olup olmadığı hakkında verilere ihtiyaç duyulur ve buna sahip değilim.

Bence, istediğiniz işlevsellik için doğru kod şudur:

phoneNumber = headers.resourceId || DEV_PHONE_NUMBER;

Ya da bir işleve bölmek istiyorsanız, muhtemelen şöyle bir şey:

phoneNumber = getPhoneNumber(headers);

function getPhoneNumber(headers) {
  return headers.resourceId || DEV_PHONE_NUMBER
}

Fakat bence “üretimde” kavramıyla ilgili daha temel bir probleminiz var. İşlevinizle ilgili sorun isApplicationInProduction, bunun “üretim” konusunda önemli olan sistemdeki tek yer olması ve size söylemek için resourceId başlığının varlığına veya yokluğuna güvenebileceğinizden garip görünüyor. Çevreyi doğrudan kontrol eden genel bir isApplicationInProductionyöntem veya getEnvironmentyöntem olmalıdır . Kod şöyle görünmeli:

function isApplicationInProduction() {
  process.env.NODE_ENV === 'production';
}

Ardından telefon numarasını aşağıdaki şekilde alabilirsiniz:

phoneNumber = isApplicationInProduction() ? headers.resourceId : DEV_PHONE_NUMBER;

Mermi noktalarının ikisi hakkında sadece bir yorum

• Küçük fonksiyonlar yazmak acı vericidir, çünkü kodun ne yaptığını görmek için her küçük fonksiyona geçmeniz için sizi zorlar.
• Ana döngü 300 satırdan fazla olsa bile her şeyi ana büyük döngüye yerleştirin, okunması daha hızlıdır.

Çoğu editör (örneğin IntelliJ), sadece kullanımı Ctrl-Clicking ile bir fonksiyona / sınıfa atlamanıza izin verir. Ek olarak, kodu okumak için bir işlevin uygulama ayrıntılarını bilmeniz gerekmez, böylece kod okumayı daha hızlı hale getirirsiniz.

Patronuna söylemeni tavsiye ederim; savunuculuğunu beğenecek ve liderlik olarak görecek. Sadece kibar ol.