it-swarm.dev

Hangi popüler "en iyi uygulamalar" her zaman en iyisi değildir ve neden?

"En iyi uygulamalar" sektörümüzün her yerinde. A "kodlama en iyi uygulamaları" ile ilgili Google araması yaklaşık 1,5 milyon sonuç verir. Fikir birçok kişiye rahatlık getiriyor gibi görünüyor; sadece talimatları izleyin, her şey yoluna girecek.

Örneğin bir en iyi uygulama hakkında okuduğumda, Temiz Kod yakın zamanda birkaç kez okudum - gerginleşiyorum. Bu her zaman bu uygulamayı kullanmam gerektiği anlamına mı geliyor? Eklenmiş koşullar var mı? değil iyi bir uygulama olabileceği durumlar var mı? Sorun hakkında daha fazla bilgi edinene kadar nasıl emin olabilirim?

Temiz Kod 'da belirtilen uygulamaların birçoğu benimle doğru oturmadı, ancak bunun potansiyel olarak kötü olmalarından mı yoksa sadece kişisel önyargılarımdan mı kaynaklandığından emin değilim. Teknoloji endüstrisinde önde gelen birçok insanın en iyi uygulama yok olduğunu düşündüğünü biliyorum, bu yüzden en azından rahatsız edici şüphelerim beni iyi bir şirkete yerleştiriyor.

Hakkında okuduğum en iyi uygulamaların sayısı burada listelenmek veya bireysel sorular sormak için çok fazla, bu yüzden bunu genel bir soru olarak ifade etmek istiyorum:

Popüler olarak "en iyi uygulamalar" olarak etiketlenen hangi kodlama uygulamaları belirli koşullar altında en uygun olmayan hatta zararlı olabilir? Bu koşullar nelerdir ve uygulamayı neden fakir yaparlar?

Belirli örnekleri ve deneyimleri duymayı tercih ederim.

100
Steven Evers

Bence bu ifadeyle kafasına çiviyi vurdun

Şeyleri makul değerlere almaktan ve eleştirel düşünmekten nefret ederdim

Niçin var olduğuna dair bir açıklama ile gelmediğinde neredeyse tüm En İyi Uygulamaları görmezden gelirim

Raymond Chen en iyisi bu makale derken

İyi tavsiye bir gerekçe ile gelir, böylece ne zaman kötü tavsiye haline geldiğini anlayabilirsiniz. Bir şeyin neden yapılması gerektiğini anlamıyorsanız, kargo kült programlama tuzağına düştünüz ve artık gerekli olmadığında veya hatta zararlı olduğunda bile yapmaya devam edeceksiniz.

125
Conrad Frix

Bunu ringe de atabilir:

Premature optimization is the root of all evil.

Hayır, değil.

Tam teklif:

"Zamanın yaklaşık% 97'sini küçük verimlilikleri unutmalıyız: erken optimizasyon tüm kötülüklerin köküdür. Yine de bu kritik% 3'teki fırsatlarımızı kaçırmamalıyız."

Bu, tasarım süreciniz boyunca belirli, stratejik performans geliştirmelerinden yararlandığınız anlamına gelir. Performans hedefleriyle tutarlı veri yapıları ve algoritmalar kullandığınız anlamına gelir. Bu, performansı etkileyen tasarım unsurlarının farkında olduğunuz anlamına gelir. Ama aynı zamanda anlamsız bir şekilde optimizasyon yapmamanız gerektiği anlamına gelir, bu da size bakım pahasına küçük kazançlar sağlayacaktır.

Uygulamaların iyi tasarlanmış olması gerekir, böylece üzerine biraz yük uyguladığınızda sonunda düşmezler ve daha sonra bunları yeniden yazarsınız. Kısaltılmış alıntı ile tehlike, çoğu zaman, geliştiricilerin bunu, bir şey yapmak için çok geç olabileceği zamana kadar performansı hiç düşünmemek için bir bahane olarak kullanmasıdır. Minutiae'ye odaklanmamanız koşuluyla, başlangıçtan itibaren iyi bir performans oluşturmak daha iyidir.

Diyelim ki gömülü bir sistem üzerinde gerçek zamanlı bir uygulama oluşturuyorsunuz. Programlama dili olarak Python 'ı seçersiniz, çünkü “Erken optimizasyon tüm kötülüklerin köküdür.” Şimdi Python'a karşı hiçbir şeyim yok, ama is yorumlanmış bir dil. İşlem gücü sınırlıysa ve gerçek zamanlı olarak veya gerçek zamanlıya yakın bir miktar işin yapılması gerekiyorsa ve iş için sahip olduğunuzdan daha fazla işlem gücü gerektiren bir dil seçerseniz, kraliyetten mahsur kalırsınız, çünkü şimdi yetenekli bir dille başlamalısınız.

95
Robert Harvey

İşlev/yöntem başına bir dönüş.

94
iMacUwhAK

Tekerleği yeniden icat etmeyin yaygın olarak yanlış kullanılan bir dogmadır. Onun fikri, uygun bir çözüm varsa, kendi çözümünüzü oluşturmak yerine onu kullanmanızdır; tasarruf çabalarına ek olarak, mevcut çözüm muhtemelen başlangıçta elde edeceğinizden daha iyi uygulanır (hatasız, verimli, test edilmiş). Çok uzak çok iyi.

Sorun, nadiren% 100 uygun bir çözüm bulunmasıdır. % 80 uygun bir çözüm mevcut olabilir ve bunu kullanmak muhtemelen iyidir. Peki ya% 60 kadar uygun? % 40? Çizgiyi nerede çiziyorsun? Çizgiyi çizmezseniz, özelliklerinin% 10'unu kullandığınız için projenize şişirilmiş bir kütüphane dahil edebilirsiniz - çünkü "tekerleği yeniden icat etmekten" kaçınmak istersiniz.

Tekerleği yeniden icat ederseniz, tam olarak istediğinizi elde edersiniz. Ayrıca tekerleklerin nasıl yapıldığını da öğreneceksiniz. Yaparak öğrenme küçümsenmemelidir. Ve sonunda, özel bir tekerlek hazır genel tekerleğe göre daha iyi olabilir.

87
Joonas Pulakka

"Birim Her Şeyi Test Et."

Sık sık tüm kodların, katılmıyorum bir nokta, birim testleri olması gerektiğini söyledi duydum. Bir yöntem için bir testiniz olduğunda, bu yöntemin çıktısında veya yapısında herhangi bir değişiklik iki kez yapılmalıdır (kodda bir kez, testte bir kez).

Bu nedenle, birim testler, bence, kodun yapısal kararlılığı ile orantılı olmalıdır. Aşağıdan yukarıya katmanlı bir sistem yazıyorsam, veri erişim katmanım wazoo'yu test edecek; iş mantığı katmanım oldukça iyi test edilecek, sunum katmanımın bazı testleri olacak ve görüşlerimin çok az testi olacak ya da hiç testi olmayacak.

78
Fishtoaster

Her zaman arayüzlere program.

Bazen sadece bir uygulama olur. Bir arayüz çıkarma işlemini, ihtiyacını gördüğümüz zamana kadar ertelersek, genellikle gerekli olmadığını görürüz.

57
Eric Wilson

Açık kaynak kodlu hiçbir şey kullanmayın (veya .NET geliştiricileri için Microsoft dışı)

Microsoft bunu geliştirmediyse, burada kullanmayız. ORM - EF kullanmak istiyorum, IOC - Birlik, giriş yapmak istiyorum - kurumsal günlük uygulama bloğu. Çok daha iyi kütüphane var - ama her zaman dolar menüsünden sipariş takılıp kaldım Yemin ederim ki Microsoft Best Practices her duyduğumda "McDonald's Beslenme Yönergeleri" ni düşünüyorum. Onları takip ederseniz muhtemelen yaşayacaksınız, ama aynı zamanda yetersiz ve aşırı kilolu olacaksınız.

  • Bunun sizin en iyi uygulama olmayabileceğini unutmayın, ancak çalıştığım hemen hemen her yerde takip edilen yaygın bir uygulamadır.
46
Watson

Nesne yönü

Varsayım var, sadece kod "nesne yönelimli" olduğu için sihirli olarak iyi. Böylece insanlar sadece nesne yönelimli olmak için işlevselliği sınıflara ve yöntemlere sıkıştırmaya devam ediyorlar.

40
LennyProgrammers

Tüm kodlar yorumlanmalıdır.

Hayır, olmamalı. Belli bir kodunuz olduğunda, örneğin ayarlayıcılar özel bir şey yapana kadar yorumlanmamalıdır. Ayrıca, neden bunu yorumlayayım:

/** hey you, if didn't get, it's logger. */
private static Logger logger = LoggerFactory.getLogger(MyClass.class);
35
Vladimir Ivanov

Metodolojiler, özellikle scrum. Yetişkinlerin "Scrum Master" ifadesini kullandıklarını duyunca düz bir yüz tutamıyorum. Geliştiricileri protesto etmekten o kadar yoruldum ki, Methodology X'in bazı yönleri şirketleri için çalışmıyor, sadece Guru tarafından söyleniyor. Metodoloji X. "Scrum daha sert, sen yapmalısın, Padawan öğrenicim!"

Çevik metodolojilerde bilgelik külçeleri vardır - birçoğu --- ama çoğu zaman gag refleksimle savaşamayacağım kadar gübre içinde yatmaktadırlar. Bu biti Wikipedia'nın scrum sayfası adresinden alın:

Scrum'da bir dizi rol tanımlanmıştır. Tüm roller, gelişim sürecine katılımlarının doğasına bağlı olarak iki farklı gruba (domuz ve tavuk) ayrılır.

Gerçekten mi? Domuzlar ve tavuklar, öyle mi? Büyüleyici! Bunu patronuma fırlatmak için sabırsızlanıyorum ...

32
evadeflow

Nesne İlişkisel Eşleme ... http://en.wikipedia.org/wiki/Object-relational_mapping

Verilerimden hiçbir zaman soyutlanmak istemiyorum ve bu hassas kontrol ve optimizasyonu da kaybetmek istemiyorum. Bu sistemlerle ilgili deneyimim son derece zayıftı ... Bu soyutlama katmanları tarafından oluşturulan sorgular, sıra dışı durumlardan gördüğümden bile daha kötü.

25
Fosco

İşlev adlarını İngilizce cümlelermiş gibi yazmak:

Draw_Foo()
Write_Foo()
Create_Foo()

bu harika görünebilir, ancak bir API öğrenirken acı çeker. "Foo ile başlayan her şey" için bir dizin aramak ne kadar kolay?

Foo_Draw()
Foo_Write()
Foo_Create()

vb.

22
Colen

YAGNI

( İhtiyacınız olmayacak )

Bu yaklaşım, dikkatli bir planlamanın bu özellikleri önceden içereceği mevcut bir kod tabanına özellikler uygulamak zorunda kaldığım saat ve saatlere mal oldu.

YAGNI ve çoğu zaman birinin bu karar için daha sonra ödemek zorunda kalması nedeniyle fikirlerim çoğu zaman reddedildi.

(Tabii ki, iyi tasarlanmış bir kod tabanının daha sonra özelliklerin eklenmesine izin vereceğini iddia edebilir, ancak gerçeklik farklıdır)

22

MVC - i çoğu zaman MVC yaklaşım içine birçok web tasarım problemleri ayakkabı atlaması bir çerçeve (Raylar vb) sadelik veya yapı hakkında daha mutlu yapmak hakkında olduğunu bulmak. MVC sadelik üzerinde aşırı iskele değer gibi görünüyor "mimari astronotlar" bir favori. YMMV.

sınıf tabanlı OO - Bence değişebilir devletin karmaşık yapılarını teşvik ediyor.Sınıf tabanlı OO yıllar içinde bulduğum tek zorlayıcı durumlar herhangi bir OO kitap) bölüm 1 oluşturan corny "şekil-> dikdörtgen-> kare" örnekleri

22
Brad Clawsie

SQL için

  1. Tetikleyicileri kullanma
  2. Tabloları her zaman görünümlerin arkasına gizle

Sırayla:

  1. Onlar yeri olan bir özellik. Bir tablo için birden fazla güncelleme yolunuz var mı, yoksa% 100 denetim mi gerekiyor?

  2. Sadece neden? Bir sözleşmeyi sürdürmek için yeniden düzenleme yapsaydım, ama o halkın herhangi bir tablo değişikliğiyle eşleşmesi için görünümü değiştirdiğini okumadığımda

Düzenle:

3 Numara: EXISTS ile * kaçınma. 1/0 deneyin. İşe yarıyor. Sütun listesi SQL standardına göre değerlendirilmez. Sayfa 191

20
gbn

Çoğunlukla Tasarım Desenleri. Fazla kullanılır ve az kullanılırlar.

20
Geek

Tek Sorumluluk İlkesi

("her sınıfın tek bir sorumluluğu olmalı; diğer bir deyişle, her sınıfın bir ve sadece bir tane değişme nedeni olmalıdır")

Katılmıyorum. Ben bir yöntem değiştirmek için sadece bir nedeni olmalı ve bir sınıftaki tüm yöntemler bir bir diğerine mantıklı bir ilişki olmalıdır, ama sınıfın kendisi aslında olabilir do birkaç (ilgili) şey.

Deneyimlerime göre, bu ilke çok fazla gayretle uygulanır ve birçok küçük tek yöntemli sınıfla sonuçlanırsınız. Çalıştığım çevik dükkanların ikisi de bunu yaptı.

.Net API'sinin yaratıcılarının bu tür bir zihniyete sahip olup olmadığını düşünün: List.Sort (), List.Reverse (), List.Find () vb. Yerine ListSorter, ListReverser, ve ListSearcher sınıfları!

Artık SRP'ye karşı tartışmak yerine (kendisi teoride korkunç değildir), uzun soluklu anekdot deneyimlerimi paylaşacağım:


Çalıştığım bir yerde, beş sınıftan oluşan çok basit bir maksimum akış çözücü yazdım: bir düğüm, bir grafik, bir grafik yaratıcısı, bir grafik çözücü ve grafiği kullanmak için bir sınıf -creator/çözücüler gerçek dünya sorunu çözmek için. Hiçbiri özellikle karmaşık ya da uzun değildi (çözücü ~ 150 satırda en uzundu). Ancak, sınıfların çok fazla "sorumluluğu" olduğuna karar verildi, bu yüzden iş arkadaşlarım kodu yeniden düzenlemeye başladılar. Yapıldıklarında, 5 sınıfım toplam kod satırı orijinalinde üç kattan fazla olan 25 sınıfa genişletildi. Kodun akışı artık açık değildi ve yeni birim testlerin amacı da yoktu; Şimdi kendi kodumun ne yaptığını anlamakta zorlandım.


Aynı yerde, hemen hemen her sınıfın tek bir yöntemi vardı (tek "sorumluluğu"). Program içindeki akışı takip etmek neredeyse imkansızdı ve birim testlerin çoğu bu sınıf kodunun başka bir sınıf olarak adlandırılan testlerden oluşuyordu. benim için eşit derecede gizem. Kelimenin tam anlamıyla yüzlerce sınıf vardı (IMO) sadece onlarca olmalı. Her sınıf sadece bir "şey", ancak "AdminUserCreationAttemptorFactory" gibi adlandırma kurallarında bile, sınıflar arasındaki ilişkiyi söylemek zordu.


Başka bir yerde (aynı zamanda sınıflar-bir-tek-yöntem-olmalı zihniyet), belirli bir işlem sırasında% 95 zaman alan bir yöntemi optimize etmeye çalışıyorduk. (Oldukça aptalca) biraz optimize ettikten sonra, dikkatimi neden bir bajillion kez deniyordu. Bir sınıftaki bir döngüde çağrılıyordu ... yöntemi başka bir sınıftaki bir döngüde çağrılıyordu .. bu da bir döngüde çağrılıyordu ..

Hepsi, 13 sınıfa yayılan beş seviyeli döngüler olduğunu söyledi (ciddi olarak). Herhangi bir sınıfın gerçekte ne yaptığını sadece ona bakarak belirlemek imkansızdı - buna hangi yöntemlerin isimlendirildiğini ve bu yöntemlerin hangi yöntemleri çağırdığını vb. Her şey tek bir yönteme sokulmuş olsaydı, sorun yöntemimiz hemen açık olan beş döngü içine yerleştirilmiş olsa bile, yaklaşık 70 satır uzunluğunda olurdu.

Bu 13 sınıfı bir sınıfa tekrar gönderme isteğim reddedildi.

Temiz Kod'dan bahsettiğinize göre, bazı iyi fikirler içeriyor olsa da, tüm yöntemleri alt yöntemlere ve alt yöntemlere vb. Birkaç on satır yöntemi yerine, yirmi (sözde iyi adlandırılmış) tek astarı tercih etmelisiniz. Açıkçası birisi temiz olduğunu düşünüyor, ama bana göre orijinal versiyondan çok daha kötü görünüyor.

Ayrıca, basit temel öğelerin yerine

0 == memberArray.length

sınıfın kendi yöntemini içeren bir sınıf içinde

isEmpty()

tartışmalı bir "iyileştirme" IMHO'sudur. Ek: Fark, ilk kontrolün tam olarak söylediği şeyi yapmasıdır: dizi uzunluğunun 0 olup olmadığını kontrol eder. Tamam, isEmpty() dizi uzunluğunu da kontrol edebilir. Ancak şu şekilde de uygulanabilir:

return null != memberArray ? 0 == memberArray.length : true;

Yani, örtük bir boş kontrol içerir! Bu, genel bir yöntem için iyi bir davranış olabilir - dizi null ise, o zaman bir şey kesinlikle boştur - ancak sınıf içlerinden bahsederken, bu çok iyi değil. Kapsülleme dışa doğru bir zorunluluk olsa da, class internals sınıf içinde neler olup bittiğini tam olarak bilmelidir. Sınıfı kendisinden kuşatamazsınız . Açık, örtük olmaktan iyidir.


Bu, uzun yöntemleri veya mantıksal karşılaştırmaları bozmanın iyi olmadığı anlamına gelmez; tabii ki, ama hangi dereceye kadar yapacağını - tatlı nokta nerede - açıkçası bir tat meselesi. Uzun bir yöntemi kırmak daha fazla yöntemle sonuçlanır ve bu ücretsiz değildir. Gerçekte neler olduğunu görmek için kaynak kodun etrafından atlamak zorundasınız, tüm bu şeyler tek bir yöntemdeyse bir bakışta görebiliyordunuz.

Hatta bazı durumlarda 1 satırlık bir yöntem bir yöntem olmayı hak çok kısa olduğunu söyleyebilirim.

14
Joonas Pulakka

"Yorumlarla liberal olun"

Yorumlar kesinlikle iyi bir şey, ama çok fazla yeterli değilse bile daha kötü değil. Neden? İnsanlar, çok fazla gereksiz yorum görürlerse yorumları ayarlama eğilimindedirler. Ben mükemmel kendi kendini belgeleyen kodu olabilir demiyorum, ama açıklama için yorum gerektiren kod tercih edilir.

13
Jason Baker

Zarar Gördüğü Zararına Git

Bir durum makinesi uyguluyorsanız, GOTO ifadesi "yapılandırılmış programlama" yaklaşımından daha mantıklı olabilir (okunabilirlik ve verimli kod). Yeni bir işte yazdığım ilk kod parçası sadece bir değil birkaç ifade içeriyorsa, bazı çalışma arkadaşlarından endişe duyuyorlardı. Neyse ki, bu özel durumda aslında en iyi çözüm olduğunu anlayacak kadar zekilerdi.

Kurallarında mantıklı ve belgelenmiş istisnalara izin vermeyen herhangi bir "en iyi uygulama" sadece korkutucu.

12
MZB

Kodu test edilebilir kılmak için yaptığımız fedakarlıklar

Kodumu test edilebilir yapmak için birçok çembere atladım, ancak seçim verilirse yapmazmışım gibi davranmıyorum. Ancak, çoğu zaman insanların bunların "en iyi uygulamalar" olduğu fikrini ittiğini duyuyorum. Bu uygulamalar (.Net dilinde yazılmıştır, ancak diğer diller için de geçerlidir):

  • every class için bir arayüz oluşturma. Bu iki katına çıkar sınıf sayısı ( dosyaları) ele alır ve kodu kopyalar. Evet, arayüz programlama iyidir, ancak genel/özel belirteçlerin amacı budur.
  • Başlangıçta somutlaştırılmayan her sınıfın bir fabrikaya ihtiyacı vardır. Açıkçası, new MyClass() bir fabrika yazmaktan çok daha basit, ama şimdi yöntem tek başına test edilemez. Bu gerçek olmasaydı, şimdi yaptığım fabrika sınıfı sayısının sadece 1/20'sini yapardım.
  • Her sınıfı herkese açık hale getirin . Bununla birlikte, halka açık olmayan sınıflara diğer projelerden erişilemez (ve böylece test edilemez), bu yüzden diğer tek seçenek tüm test kodunu aynı projeye taşımak (ve böylece nihai ürünle serbest bırakmak).
  • Bağımlılık Enjeksiyonu. every diğer sınıfı bir alan kullanıyorum ve yapıcı parametresi önemli ölçüde daha fazla iş onları ihtiyacım olduğunda yaratmaktan çok; ama sonra artık bu sınıfı tek başına test edemiyorum.
  • Tek Sorumluluk İlkesi, bu kadar çok baş ağrımıza neden oldu kendi cevabınız .

Peki bunu düzeltmek için ne yapabiliriz? Dil mimarisinde köklü bir değişikliğe ihtiyacımız var:

  • Sınıflarla alay etme yeteneğine ihtiyacımız var
  • İç sınıfların özel yöntemlerini başka bir projeden test etme yeteneğine ihtiyacımız var (bu bir güvenlik açığı gibi görünebilir, ancak test eden kişi testçi sınıflarını adlandırmaya zorlanırsa bir sorun görmüyorum) .
  • Bağımlılık enjeksiyonu (veya servis konumu) ve mevcut fabrika modelimize eşdeğer bir şey, dilin çekirdek bir parçası olmalıdır.

Kısacası, sıfırdan başlayarak test edilebilirlik göz önünde bulundurularak tasarlanmış bir dile ihtiyacımız var .

ygulamaları Katmanlara Ayırma; Veri Katmanı, İş Katmanı, UI Katmanı

Bundan hoşlanmamamın temel nedeni, bu yöntemi takip eden çoğu yerde, bunu yapmak için çok kırılgan çerçeveler kullanmasıdır. I.E. UI Katman iş katmanı nesneleri ile başa çıkmak için el kodlanmış, iş katmanı nesneleri iş kuralları ve veritabanı ile başa çıkmak için el kodlanmış, veritabanı SQL ve zaten oldukça kırılgan ve değişikliği sevmeyen "DBA" grubu tarafından yönetilir.

Bu neden kötü? En yaygın geliştirme isteği büyük olasılıkla "X ekranında Y olan bir alana ihtiyacım var." Bang! Her katmanı etkileyen yeni bir özelliğiniz var ve katmanları farklı programcılarla ayırırsanız, çok basit bir değişiklik için birden fazla kişi ve grubu içeren büyük bir sorun haline geldi.

Ayrıca, böyle bir şeye giden argümanlarda kaç kez olduğumu bilmiyorum. "Ad alanı maksimum 30 uzunlukla sınırlıdır, bu bir kullanıcı arayüzü katmanı veya iş katmanı veya veri katmanı sorunu mu?" Ve yüz argüman var ve doğru cevap yok. Cevap aynıdır, tüm katmanları etkiler, kullanıcı arayüzünü aptal hale getirmek istemezsiniz ve tüm katmanlardan geçmek zorunda kalırsınız ve veritabanında başarısız olursunuz, böylece kullanıcı girişinin çok uzun olduğunu öğrenir. Değiştirirseniz, tüm katmanları vb. Etkiler.

"Katmanlar" da sızma eğilimindedir; Herhangi bir katman, işlem/makine sınırları (I.E. web kullanıcı arabirimi ve iş arka uç mantığı) ile fiziksel olarak ayrılırsa, her şeyin makul şekilde iyi çalışması için kurallar çoğaltılır. Yani bazı iş mantığı "iş kuralı" olmasına rağmen kullanıcı arayüzünde sona erer, çünkü kullanıcının duyarlı olması için kullanıcı arayüzüne ihtiyacı vardır.

Kullanılan çerçeve veya kullanılan mimari, küçük değişikliklere ve sızıntıya, yani meta verilere dayanıyorsa ve tüm katmanlarda dinamik olarak ayarlanmışsa, daha az acı verici olabilir. Ancak çoğu çerçeve, her küçük değişiklik için UI değişiklikleri, iş katmanı değişiklikleri ve veritabanı değişiklikleri gerektiren ve tekniğin üretmesi gerekenden daha fazla iş ve daha az yardım gerektiren bir kraliyet ağrısıdır.

Muhtemelen bunun için çarpacağım, ama işte :)

10
Jay

JavaBeans

Java'da JavaBeans kullanımı. Benim sorum Neden JavaBeans yerine değişmez POJOs kullanmıyorum? StackOverflow üzerinde.

9
Jonas

Kullanıcı Hikayeleri/Kullanım Örnekleri/Personas

Bilmediğiniz bir endüstri için programlama yaparken bunlara duyulan ihtiyacı anlıyorum, ancak tam güçle uygulandıklarında çok kurumsal hale geldiklerini ve zaman kaybına dönüştüklerini düşünüyorum.

7
riwalk

80 karakter/satır sınırı aptal

Bazı uzlaşmaların GUI tarafındaki en yavaş koşucunun hızıyla eşleşmesi gerektiğini anlıyorum (ekran çözünürlüğü sınırlamaları, vb.), Ancak bu kural neden kod biçimlendirmesi için geçerli?

Bakın ... Sanal ekran alanını en sağ piksel sınırı dışında yönetmek için oluşturulmuş yatay kaydırma çubuğu adı verilen bu küçük buluş vardı. Sözdizimi vurgulama ve otomatik tamamlama gibi üretkenliği artıran mükemmel araçlar oluşturmayı başaran geliştiriciler neden kullanmıyor?

Elbette, VT220 terminallerinin yorgun eski sınırlamalarını takip eden * nix dinozorlar tarafından dini olarak kullanılan CLI editörleri var, ancak geri kalanımız neden aynı standarda tutuluyor?

Diyorum ki, 80 karakter sınırını vidala. Dinozorlar tüm gün emacs/vim'i hackleyecek kadar destansıysa, neden CLI IDE'lerine otomatik olarak hatları saran veya yatay kaydırma yetenekleri veren bir uzantı oluşturamıyor?

1920x1080 piksel monitörler nihayetinde norm haline gelecek ve dünya çapındaki geliştiriciler, neden yaptıkları dışında hiçbir etkisi olmadan hala aynı sınırlamalar altında yaşıyorlar, bu, programlamaya yeni başladıkları zaman büyükleri tarafından yapmaları söylendi.

80 karakter limiti değil en iyi uygulama olmakla birlikte, çok az sayıda programcı için niş bir uygulamadır ve bu şekilde ele alınmalıdır.

Düzenleme:

Birçok geliştiricinin yatay kaydırma çubuğunu sevmediği anlaşılabilir, çünkü bir fare hareketi gerektirir ... Modern ekranlar kullananlarımız için neden sütun genişliği sınırını daha yüksek bir sayıya (80'den fazla) yükseltmeyelim.

800x600 bilgisayar monitörü çoğu kullanıcı için norm haline geldiğinde, web geliştiricileri web sitesi genişliklerini çoğunluğa uyacak şekilde artırdı ... Neden geliştiriciler de aynı şeyi yapamıyor?.

7
Evan Plaice

Ölçün, Ölçün, Ölçün

Çok iyi, ölçün, ama izole performans hataları, ölçüm çalışmaları ve art arda eleme. İşte kullandığım yöntem.

Ben tedbir-ölçü "bilgelik" kaynağını bulmaya çalışıyorum. Yeterince uzun bir sabun kutusuna sahip biri dedi ve şimdi seyahat ediyor.

5
Mike Dunlavey

Tek Ton Kullan

Bir şeyin sadece bir örneğine sahip olmanız gerektiğinde. Ben katılmıyorum daha fazla. Asla bir singleton kullanmayın ve sadece bir kez ayırın ve gerekirse işaretçiyi/nesneyi/referansı aktarın. Bunu yapmamak için kesinlikle hiçbir neden yok.

5
user2528

Öğretmenim tüm tanımlayıcılarımı (sabitler hariç) küçük harflerle başlatmamı istiyor, örn. myVariable.

Ben küçük bir şey gibi görünüyor biliyorum, ama birçok programlama dili gerektirir değişkenleri büyük harflerle başlamak için. Tutarlılığa değer veriyorum, bu yüzden her şeye büyük harflerle başlamak benim için bir alışkanlık.

5
Maxpm

İmzasız int'yi yineleyici olarak kullanma

İmzalı int kullanmanın çok daha güvenli ve daha az hataya açık olduğunu ne zaman öğrenecekler. Dizi indeksinin sadece pozitif sayı olabilmesi neden herkesin 4 - 5'in 4294967295 olduğu gerçeğini göz ardı etmekten mutluluk duyması neden önemlidir?

5
AareP

Yöntemler tek bir ekrandan daha uzun olmamalıdır

Tek sorumluluk ilkesine tamamen katılıyorum ama neden insanlar bunu "bir fonksiyonun/yöntemin en iyi mantıksal ayrıntı düzeyinde tek bir sorumluluktan daha fazla olamaz" anlamına geldiğini düşünüyorlar?

Fikir basit. Bir işlev/yöntem bir görevi yerine getirmelidir. Bu işlevin/yöntemin bir kısmı başka bir yerde kullanılabiliyorsa, kendi işlevine/yöntemine kesin. Projenin başka bir yerinde kullanılabiliyorsa, kendi sınıfına veya yardımcı sınıfına taşıyın ve dahili olarak erişilebilir hale getirin.

Kodda yalnızca bir kez çağrılan 27 yardımcı yöntem içeren bir sınıfa sahip olmak aptal, alan kaybı, karmaşıklıkta gereksiz bir artış ve büyük bir zaman alıcıdır. Daha çok yeniden düzenleme koduyla meşgul görünmek isteyen, ancak fazla üretmeyen insanlar için iyi bir kural gibi geliyor.

İşte kuralım ...

Bir şeyi başarmak için işlevleri/yöntemleri yazın

Kendinizi bir kodu kopyalamak/yapıştırmak üzere bulursanız, kendinize bu kod için bir işlev/yöntem oluşturmanın daha iyi olup olmayacağını sorun. Bir işlev/yöntem başka bir işlevde/yöntemde yalnızca bir kez çağrılırsa, gerçekten ilk sırada olmasının bir anlamı var mıdır (gelecekte daha sık çağrılır mı). Hata ayıklama sırasında işlevlere/yöntemlere daha fazla atlama eklemek değerli mi (yani, eklenen atlama hata ayıklamayı kolaylaştırıyor veya zorlaştırıyor)?

200 çizgiden büyük fonksiyonların/yöntemlerin incelenmesi gerektiğine tamamen katılıyorum, ancak bazı fonksiyonlar sadece bir görevi çok sayıda satırda gerçekleştiriyor ve projenin geri kalanında soyutlanabilecek/kullanılabilecek hiçbir yararlı parça içermiyor.

API geliştirme perspektifinden bakıyorum ... Yeni bir kullanıcı kodunuzun sınıf şemasına bakacak olsaydı, bu şemanın kaç kısmı projenin daha büyük bir bölümünde mantıklı olurdu ve kaç tanesi sadece proje içindeki diğer kısımlara yardımcı olur.

İki programcı arasında seçim yapacak olsaydım: birincisi çok fazla yapmaya çalışan fonksiyonlar/yöntemler yazma eğilimindedir; ikincisi, her fonksiyonun/yöntemin her bir parçasını en ince ayrıntı düzeyine böler; İlk elleri aşağı seçerdim. Birincisi daha fazlasını başaracaktı (yani, uygulamanın daha fazla etini yazacak), kodunun hata ayıklaması daha kolay olurdu (hata ayıklama sırasında işlevlere/yöntemlere daha az atlama nedeniyle) ve meşgul işi mükemmelleştirmek için daha az zaman harcayacaktı. Kod, kodun nasıl çalıştığını mükemmelleştirmek vs.

Gereksiz soyutlamaları sınırlayın ve otomatik tamamlamayı kirletmeyin.

4
Evan Plaice

Mutlakçı, katı, kapsülleme

Çoğunlukla kapsüllemeye katılıyorum, ancak bazı kuralsal kodu OOP Array to Object refactoring kullanarak dönüştürmek için bu kuralı geçici olarak kırmak gerçek bir kurtarıcıydı. Biraz gevşetmek için biraz Push gerekiyordu. Teşekkürler, Martin Fowler)

  • Dizi

    ->

  • public özelliği olarak dizi içeren yeni sınıf

    ->

  • müşteri kodundan geç/erişimci ekle

    ->

  • only then kapsülleyin ve özel/korumalı yapın

2
JW01

Aşırı genelleme.

Kare blok daire deliğine sığmaz!

1
PMV

Aklıma gelen sadece biri Java if ifadeleri şöyle:

if (condition) ...

onun yerine

if(condition) ...

Çoğunlukla, en iyi olmak için en iyi uygulamaları buldum ve onlarla yaptığım ilk rezervasyonlar yanlış yerleştirilme veya daha önemli endişelerle geçersiz kılma eğilimindedir.

1
Armand

"Eğer kırılmazsa, tamir etme". Kod her zaman bozuk. Kimsenin orijinal geliştiriciye söylememesinin nedeni,

  1. onların kendi hatası olduğunu düşünüyorum,
  2. kiminle iletişime geçeceğini bilmiyorum,
  3. "teknisyen" ile konuşmak için destek alamıyor,
  4. rahatsız edilemez veya
  5. sorunu yeterince ayrıntılı olarak nasıl açıklayacağımı bilmiyorum.
1
l0b0

Kısaltılmış form üzerinde her zaman uzun, açık, değişken ve rutin adları tercih edin

örn. Kimlik Doğrulama AuthN üzerinden

Bu bit beni , MS dosya yolları o kadar uzun olduğunda Subversion çalışma kopyası bilgisayarıma yüklenemedi.

Bakınız: https://stackoverflow.com/questions/3282303/my-choice-of-class-names-is-hampered-by-windows-xp-max-path-length-issues-with-sv

1
JW01

Dosyaları taşımak için gerekli bir ayrıştırıcı yazmak gibi nispeten küçük, tek seferlik bir proje yaparken neredeyse tüm en iyi uygulamaları görmezden gelme eğilimindeyim. Tüm ihtiyacım olan sonuç olduğunda, bir kez, readablitiy, ölçeklenebilirlik, sürdürülebilirlik vb.

1
user281377

Diş açma, tüm performans sorunlarının cevabıdır

Birçok nedenden dolayı buna katılmıyorum.

  • Genelde indeksleme ve zamansal önbellekleme, performansta çok daha fazla artış sağlar. Tabii ki aslında "kirli bayrakları" kullanmanız gerekebilir .. Tasarımınızı dağınık ve malzeme yapmak ..

  • Çok iş parçacıklı fazla kilodan kaynaklanan sorunlar, zaman ve para açısından akıllıca fayda sağlar.

  • Çok çekirdekli teknolojinin bize gerçekte getirdiği şey daha iyi çoklu görevdir (birkaç uygulamayı aynı hızda çalıştırmak). Ustaca yazılmış çok iş parçacıklı programların kullanılması sadece bir yan etkidir.

0
AareP

DEVAM BİLDİRİMİ IS KÖTÜ

Joint Strike Fighter Air Vehicle C++ Coding Standards'ı burada referans göstereceğim:

AV Kural 190 (MISRA Kural 57) devam ifadesi kullanılmayacak kullanılmalıdır.

ve bir profesörüm:

"DEVAM BEYANI IS KÖTÜ"

Onların mantığı, kontrol akışını bozması ve kodu daha az okunabilir hale getirmesidir. Nested if ifadeleri kullanmak daha temiz bir yaklaşımdır.

Yine de, bunu daha okunabilir buluyorum:

 
for(int i = 0; i < CONST_FOO; ++i) {
    if(aTwo[i] == NULL) continue;
    aTwo[i]->DoBar();
    //...do other stuff with aTwo[i]
    //...do other stuff with aTwo[i]
    //...do other stuff with aTwo[i]
    //...do other stuff with aTwo[i]
    //...do other stuff with aTwo[i]
    //...do other stuff with aTwo[i]
    //...do other stuff with aTwo[i]
    //...do other stuff with aTwo[i]
}
 

Bundan daha:

 
for(int i = 0; i < CONST_FOO; ++i) {
    if(aTwo[i] != NULL) {
        aTwo[i]->DoBar();
        //...do other stuff with aTwo[i]
        //...do other stuff with aTwo[i]
        //...do other stuff with aTwo[i]
        //...do other stuff with aTwo[i]
        //...do other stuff with aTwo[i]
        //...do other stuff with aTwo[i]
        //...do other stuff with aTwo[i]
        //...do other stuff with aTwo[i]
        //...do other stuff with aTwo[i]
        //...do other stuff with aTwo[i]
        //...do other stuff with aTwo[i]
    }
}
 

Bu çok basit bir örnektir, (iç içe geçmiş olanların birden fazla seviyeye gittiğini hayal edin) ama saçma “işlev en iyi” uygulaması başına sadece bir dönüş ifadesine benzer. Hata ayıklayıcının etrafa sıçramasını önler (muhtemelen birkaç sayfa uzakta), daha az girinti genellikle kolayca okunabilir kod vb.

0
Casey

JavaScript'te birçok kişi, diğer C dalı dillerinde ihtiyaç duydukları tüm noktalı virgülleri yazmanın en iyi yöntem olduğunu düşünmektedir (ve birçoğu, daha fazla noktalı virgül içerebilecek kodu gördüğünde "hatayı" belirtmekten korkmaz). Onlara hiç ihtiyaç duymadım, görsel işaretleyici rolleri zaten çizgi kaymalarıyla doludur.

Bir yan notta, noktalı virgül gerektiren bir derleyici görmek biraz eğlencelidir, ancak yine de güvenle "Eksik noktalı virgül" hatasını atmak mümkündür. "İkimiz de ne yazmak istediğinizi biliyoruz, ancak başvurunuzu reddetmeliyim çünkü resmen boşluklar ve satır kaymaları arasında ayrım yapmama izin verilmiyor."

Bir dizi diğer JavaScript/C stili en iyi uygulamalar dolaşıyor, ancak hiçbiri nitelikli argümanlar olmadan hype açısından yaklaşmıyor.

Düzenleme: Kodu noktalı virgül kullanmadan simge durumuna küçültmek mükemmeldir Closure Compiler bunları gerektiği gibi ekleyecektir.

0
aaaaaaaaaaaa

Kısayol düğmelerimden biri performans analizi . İnsanlar diyor ki

Erken optimizasyon tüm kötülüklerin köküdür.

Ve sonra tam teklifin şöyle olduğunu söylüyorlar:

Zamanın yaklaşık% 97'si gibi küçük verimlilikleri unutmalıyız: erken optimizasyon tüm kötülüklerin köküdür. Yine de bu kritik% 3'teki fırsatlarımızı kaçırmamalıyız.

Bu "algoritmaları" tartışırken mükemmel bir mantıklı - programın% 3'ünün iki kod satırı olabileceği akıllı akademik şeyler.

10 ^ 6 satır uygulamalarında, 10 ^ 4 sınıfında 10 ^ 5 yöntemiyle, bir düzine programcı ve test uzmanı tarafından yıllar boyunca çalıştım, bu teklifin hiçbir ilgisi olmayan çok sayıda revizyon ve sürümden geçtim. Tipik olarak zaman drenajları "fırsatlar" olabilecek tek bir kod satırıdır, ancak hiç kimse nerede olduklarını tahmin edemezdi.

OTOH, insanlar "profil" der ya da "ölçü ölçüsü" derler. Güzel. Bunu söylüyorlar ama sık sık yapmıyorlar. Olabilir, yapmamalarının nedeni çok iyi çalışmıyor .

Bu cevap bunun hakkında daha fazla şey söylüyor ve neyin işe yaradığına dikkat çekiyor .

0
Mike Dunlavey

Bağlanma verileri

Ondan nefret ediyorum ve seviyorum. (Projenin karmaşıklığına bağlıdır)

0
Amir Rezaei