Tasarım desenleri kaşlarını çattı mı?


135

20 yıldır bu işte çalışan üst düzey geliştiricilerimizden biriyle bir tartışma yaptım. Ontario’da yazdığı bir blog için oldukça iyi tanınıyor.

Garip olan şey bana söylediği şeydi: Çalışmak için bir kabus olan bir kod parçası olduğunu söyledi çünkü bir ders kitabından yazılmış ve gerçek dünyayı hesaba katmıyor. Kullanıcı Arayüzüne / veri tabanına / Veri katmanına yeni bir alan eklemek 2-3 saat sürüyor, oysa kodunda 30 dakika sürüyor.

Diğer bir şey de tasarım modellerinden kaçınmasıdır çünkü çoğu programcı onları anlamamaktadır ve bakım açısından iyi değildir.

Ayrıca, Kanada’daki çoğu web geliştiricisinin, veri modellerini izole tutmak yerine Veri Katmanı sınıflarından miras almayı tercih ettiği fikri de var. “Modelin veri katmanından ayrılması endüstri standardı değil mi?” Diye sordum. Bazen dedi, ama buradaki çoğu insan bunu yapmamayı tercih ediyor çünkü çok fazla iş var.

En iyi uygulamaları kullanarak kodlama yapmama gerekçesinin bir bakım kabusu olması, çalışanlarımızın azının (kendim dışında) anlaması gibi geliyor ve birkaç gün içinde yeni özellikler veya alanlar ortaya çıkarmanız gerekiyorsa, çalışmak yavaş. saati.

Stack Overflow'un çoğunlukla insanları endüstri standartlarını takip etmeye teşvik ettiği düşünülürse, böyle bir görüşü duymak çok garip. Birkaç gün içinde sürekli olarak yeni alanlar ve özellikler ortaya çıkarmak zorunda kalmamız, yeterince esnek olan sağlam bir örüntü ortaya çıkarmak mümkün olmuyor mu? Bundan anladığım şeyin özü bu gibi görünüyor.

Bu ifadelerden ne anlıyorsunuz?



67
Şahsen ben "en iyi uygulama" olarak adlandırılan herhangi bir şeye gerginim (gerekçesiz) çünkü genellikle "Bunun neden iyi bir fikir olduğunu bilmiyorum ama yine de yapmanı istiyorum; tartışmaların sonu" anlamına geliyor
Richard Tingle

34
endüstri standardı, tasarım deseni ve en iyi uygulamalar sadece "Birisinin kendi bağlamında daha iyi çalıştığını söylediği şeylerdir, bu yüzden sizin için de geçerli. Muhtemelen. Belki" ®. kıdemli arkadaşın haklı.
CptEric

86
Bunun Çevik ile ilgisi yok.
Orbit'teki Hafiflik Yarışları,

68
"üst düzey mvc geliştirici" "tasarım desenleri kötü" bilişsel uyumsuzluk
Dan Pantry

Yanıtlar:


239

Bunlar başarıya ulaşan ve anlamadığı desen jargonunda ne yapması gerektiğini söylemeye çalışan insanları görmezden gelen birinin sözleri.

Tasarım desenleri ve en iyi uygulamalar aynı şey değil. Bazı insanlar kendileri olduğunu düşünüyor ve ne yaptıklarını bilen insanları tahrik ediyor. Yaptıkları şeyin doğru adını bilmiyor olsalar bile.

Tasarım desenleri isimleri olmadan önce vardı. Onlarla konuşmayı kolaylaştırmak için isimler verdik. Bir adı olan bir desen onu iyi bir şey yapmaz. Bu tanınabilir bir şey yapar .

Bu adam muhtemelen hiçbirinizin duymadığı modelleri kullanıyor. Sorun değil, onunla bir şeyin nasıl yapılacağı hakkında konuşmanız gerekene kadar. Ya seninle nasıl konuşulacağını öğrenmek zorunda kalacak ya da onunla nasıl konuşacağını öğrenmek zorunda kalacaksın. "Doğru" olanla hiçbir ilgisi yok.


12
Günümüzde çoğu insan "tasarım desenleri" terimini kullandığında, genellikle Dörtlü Çeteye atıfta bulunduğunu belirten anlaşmaya varıldı .
Robert Harvey,

35
Doğru ve ben İngilizceyi kullanmayı seviyorum, bu benim için anlamlı. Fransız halkının neden bu kadar uzun süredir evlat edindiğini anlamıyorum. Onlar gelene kadar sürekli duyduğum bu metrik sistem hakkında bir şeyler öğreneceğim.
candied_orange

6
Anlayamıyor olabilir, aynı zamanda anlayabilmiş olabilir ama her şeyin her durumda geçerli olmadığını biliyor.
whatsisname,

148
“İsmi olan bir model onu iyi bir şey yapmaz. Onu tanınabilir bir şey yapar.” Aman Tanrım, bu şimdiye kadar duyduğum sorunun en iyi özeti: D
Orbit'teki Hafiflik Yarışları,

7
@JanDoggen Bunlara (anti-) kalıplar denir, çünkü bunlar yazılım geliştirmedeki ortak kalıplardır (bazıları tasarımla ilgili kalıplardır).
JAB,

95

Sizin ve arkadaşınızın tanımladığı türden birçok tasarım deseni, programlama dillerindeki eksiklikler için gerçekten geçici çözümlerdir . Daha etkileyici bir programlama dili kullanın ve bu tasarım desenlerine duyulan ihtiyacın çoğu kayboluyor.

İyi tasarım desenlerinin birçok olası kullanım senaryosuna uyması gerektiğinden, aşırı mühendislik olma eğilimindedirler. Aşırı tasarlanan kodun bir maliyeti vardır: okumalısınız, ne yaptığını anlamalısınız ve tüm yazılım sistemi kapsamında nasıl çalıştığını anlamalısınız. Sonuç olarak, diğer yazılım geliştirme tekniklerinde olduğu gibi, tekniği tekniği kullanma maliyetine göre değerlendirmeniz ve faydaların maliyeti aşıp aşmadığına karar vermeniz gerekir.

Diğer tüm şeyler eşit olmakta, daha az kod her zaman daha iyidir. Gerçekten ilginç bir kod bulmak , yani aslında ek yükü eklemekten başka bir şey yapan kodu bulmak için birden fazla projede üç ila altı atlama yapmak zorunda olduğunuz katmanlı mimarilerde bulundum .

İyi bilinen yazılım kalıplarının, size tasarım stratejilerini aktarabileceğiniz ortak bir kelime vermesi beklenir. Ne yazık ki, pek çok yazılım geliştiricisi, yazılım paternlerini kelime problemlerine uygun şekilde uygulayabilecek kadar iyi anlamıyor. Deneyimsiz geliştiriciler bu kalıpları uzmanlık alanı içinde görür; uzman olarak görülmek istiyorlar ve bu yüzden hazır olmadan önce kalıpları çok erken öğrenip uygulamaya çalışıyorlar. Bunun yerine, yapmaları gereken şey, önce programlamanın temellerini öğrenmeye odaklanmak ve ardından her bir örüntüün kendi çözeceği sorunu çözmeye çalışmaktır. Bunu yaparlarsa, kalıpları doğru anlamak ve uygulamak için çok daha iyi bir konumda olacaklar.


19
Bu, sorunuzda tarif ettiğinizden farklı bir problem. Şu anda çalıştığım dükkan, çevik olabileceğinizin ve bakımı kolay, çok temiz, yalın bir kodun olabileceğinin canlı kanıtıdır, ancak çoğu zaman Java mağazalarında gördüğünüz normal işletme, çok katmanlı şeyler değildir ve oldukça adildir. yaklaşımında "standart dışı". Uygulamaları "kurumsal" bir şekilde oluşturmak için bir yılımız yok.
Robert Harvey,

34
@ Igneous01: Asla herhangi bir gerçek dünya deneyimi yaşamamış bir profesörün “iyi” olarak nitelendirdiği bir şeyin para kazanmaya çalışan bir şirketin “iyi” olarak düşündüğünden çok farklı olabileceğini unutmayın.
Robert Harvey,

8
“Ne yazık ki, birçok yazılım geliştiricisi, yazılım paternlerini kelime problemlerini programlama problemlerine uygun şekilde uygulayacak kadar iyi anlamıyor.” Bu benim kısaca benim. =) Ben isimlerini gördük kaç, ben bir var son derece zor bir zaman onları gerçek uygulanmasını lekelenme. Muhtemelen yazdığım kodları uygulama kalıpları olarak sınıflandırmış olabilirim, ama kesinlikle hangilerini söyleyemedim. Kalıpların kodun gerçekten deşifre edilebilir olmasından çok daha az önemli olduğunu ve gerekliliklerin sadece birkaç kod yerini etkileyen değişiklikleri düşündüğünü düşünüyorum.
jpmc26

35
Ben ukalalıkla ile sorunu alacağım iken ben benzediğini koduna yol açar biliyorum çünkü "daha az kod her zaman daha iyidir" brainfuck , ben enthusiasicly "desen vacabulary" noktası ile kabul edecektir. Kodumun saçmalık olduğundan şikayet etmeyin, çünkü onu ders kitabınızda bulamazsınız. Kodumu zaptetmek için pek çok mükemmel sebep var, ama bu onlardan biri değil.
candied_orange

23
"Genel gider eklemek dışında başka bir şey yapan kod" - Kurumsal yazılımın amacının, aslında hiçbir şeyi gerçekleştiren bir kod olmaması gerektiğini düşündüm . Yazılımın sahip olabileceği herhangi bir gerçek davranış, katmanlı tasarımın yeni ortaya çıkmış bir özelliği olmalı ya da kodun veri olarak gördüğü iş kurallarına göre yönlendirilmelidir. Sadece% 50 şaka yapıyorum.
Steve Jessop,

86

Stackoverflow.SE ve Programcılar.SE çoğunlukla insanları , endüstri standartları yerine SOLID gibi en iyi uygulamaları takip etmeye teşvik eder . Ve ister inan ister inanma, fiili endüstri standardı genellikle "büyük çamur topu" mimarisidir - ciddi olarak.

Ancak sorunuzu doğrudan cevaplamak için: tasarım desenleriyle ilgili problem, kalıtımsal olana benzer bir durumdur - birçok vasat geliştirici, onları aşındırarak kodlama zor, aşılması zor bir riski vardır. Ancak, bunun cevabı kesinlikle tasarım modellerinin (veya mirasın) tamamen kullanılmasını önlemek veya yasaklamak değildir, cevap bu araçları anlam ifade ettikleri durumlarda ve sadece orada kullanmayı öğrenmektir. Ve bu "çevik" çalışmaktan tamamen bağımsızdır.


"Tasarım kalıpları ile ilgili problemin kalıtımsal olanlarla aynı - çok fazla vasat geliştiricinin kullandığı" ifadesinin özgüllüğü, kodlamanın tüm yönleriyle, gereksiz bir şeyin uygun kullanımı konusunda eğitimli olmayan bir geliştiricinin gereksiz olduğunu düşünüyorum. ve çoğunlukla onu kötüye kullanacak ve alt optimal kod yazacaktır. Bu, genel olarak bir gelişme aksiyomu olarak düşünülebilir.
Jeremy Holovacs

1
@ JeremyHolovacs: tam olarak değil. Gördüğüm sorun, eğitimli geliştiricilerin bile onları aşırı kullanması. Tecrübeli dev'lerin bir problemi “bir şekilde” uydurabilen, ama iyi olmayan bir şekle sokmaya çalıştıkları çözümleri çok sık gördüm.
Doktor Brown

45
  1. Tasarım desenleri sadece fikirleri iletmek için kullanılan isimlerdir. Sık sık kendimi daha sonra bir ismi olan bulduğum şeyler yaparken buldum. Bu nedenle, "tasarım dışı desen yolunun" aksine "tasarım deseni yolu" yoktur.

  2. Tasarım kalıpları kurallardır. Her şey olarak, her birinin avantajları ve dezavantajları vardır. Kilit nokta, deseni öğrenmek ve uygun olan yere uygulamak değil, kalıp fikrini, sahip olduğu avantaj ve dezavantajları anlamak ve problemin çözümü için ilham almak için kullanmaktır.

  3. Yeterince iyi bir neden varsa, her iyi uygulama ve rehber dikkate alınmayabilir. Geçerli nedenler arasında geliştirme süresi ve uygulamadan beklentiler vardır. Örneğin, sabit kod değerlerinin kötü olduğunu biliyorum (aptal örnek) ancak kavramın kanıtı için, avantajların maliyetlerden ağır basabileceğini (bu durumda, çoğunlukla geliştirme süresi). Bununla birlikte, böyle bir karar verilirse, geri tepebilir ve bir noktada yeniden düzenleme gerekebilir.


5
RE: 1 numara, evet, orada bulundum - şablon şablonunu icat ettim. İlk önce ben yapmadım. Ya da ilk gibi bir şey.
Grimm The Opiner,

29

Çorbaya başka bir metafor eklemek için, tasarım desenleri Clippy Microsoft Office'in yardımcısıdır. “Aynı şeyi bir sürü şeyle yapıyor gibi görünüyorsun. Size tekrarlayıcı veya Ziyaretçiyi önererek size yardımcı olabilir miyim?”

Bu kalıpların iyi bir şekilde yazılması, daha önce birçok kez yapıldığı gibi bir şeyi yapmanın ne zaman yararlı olacağını, ilk denemede hangi hataları yapacağınızı ve bu hataları önlemek için ne gibi ortak yolların bulunduğunu gösterecektir. . Böylece tasarım desenini okuyorsunuz (veya bellekten inceliyorsunuz) ve sonra işinize devam ediyorsunuz. Yapamadığın şey, sadece Clippy ve sihirbazları kullanarak elde etmek .

Deneyimsiz kişilerin yanlış gittiği ve gerçeği hesaba katmadığı bir kod yazabildiği yerlerde, tasarım kalıpları listesinin yazılımdaki sorunları çözmek için tüm olası yaklaşımların tam bir listesi olduğunu ve tasarımları birbirine bağlayarak kodu tasarlamaya çalıştıklarını düşünüyorlar. bitene kadar desenler. Vahşi doğada gözlenen bir başka kötü taktik, bir tasarım modelini, "tasarımın en iyi uygulama" olduğu temeline dayanarak, gerçekten uygun olmayan bir duruma atmaktır. Hayır, gerçekte çözdüğü problem sınıfı için en iyi yöntem olabilir veya olmayabilir , ancak kesinlikle çözemediği problemler veya sadece daha basit bir çözüm olduğunda gereksiz yere karmaşıklık getirerek çözdüğü problemler için kesinlikle en iyi yöntem değildir. .

Elbette birisinin YAGNI temelli bir kalıptan kaçınması, daha sonra ihtiyaç duyduklarını fark etmesi ve normal çözüme doğru ilerlemesi de mümkündür. Bu genellikle (ancak her zaman değil) gereksinimi en baştan karşılamaktan daha kötüdür ve çevik gelişimde bile tamamen tahmin edilebilir gereksinimler erken keşfedilmediğinde sinir bozucu olmasının nedeni budur. Java'nın jenerik kapları gereksiz yere karmaşık olarak reddettiği ve daha sonra tekrar vidaladığı için çok eğlendirilmiş tek C ++ programcısı olamam.

Bu nedenle, tasarım modellerinden kaçınmayı tercih ettiğiniz için prensip olarak bir yineleyici yazmaktan kaçınmak neredeyse kesin bir hatadır .

Kullanıcı Arabirimine / veritabanına / Veri katmanına yeni bir alan eklemek, kodunda olduğu gibi 30 dakika sürdüğünde, 2-3 saat sürer.

Bununla gerçekten tartışamazsınız: Bu metrik ile tasarımı diğerinden çok daha iyidir. Bunun nedeni , tasarım modellerinden kaçındığı için sorgulanabilir olsa da, daha muhtemel olduğunu düşünüyorum çünkü tasarlarken doğru "gerçek dünya" meselelerini düşündüğü için ve deneyimin yararıyla işinde sadece bir ders kitabı ile silahlı bir kişiden daha iyidir. yüksek idealler.

Bu nedenle, bir alan eklemek için koddaki birçok farklı noktaya dokunmanızı gerektiren herhangi bir kalıbın, "alan eklemeyi kolaylaştırır" işi için kötü bir kalıp olduğunu ve bu kalıpları kullanmadığını kabul etti. Katmanlı mimariler gerçekten de bu bakımdan acı çekebilirler ve tasarım kalıplarını dezavantajlarından ödün vermeden kullanmak yanlıştır.

Buna karşı, tasarımında yeni bir UI yazmak ne kadar sürer ve katmanlı bir mimaride ne kadar sürer? Proje, sürekli olarak yeni alanlar eklemek yerine sabit bir veri modeli üzerinden sürekli olarak yeni UI'lar kurması ve dağıtması için çağrıda bulunsaydı, umarım bunun için tasarlardı. Veya aynı zamanda. Ancak tüm faydaları için, “çevik davranıyoruz” demek, ne yazık ki, başka bir takas yapmak zorunda kalmayacağınız anlamına gelmez!

Bir tasarım desenleri menüsünden seçim yapmak kesinlikle en önemli endişeleri düşünmenizi durdurabilir. Ancak bir Ziyaretçi yazarken ve okurların hızlı bir şekilde bulmasına yardımcı olmak için "Ziyaretçi" yi belgelemek veya isimlendirmek, hiçbir şeyin önüne geçmez. Doğru bir şekilde belgelemek yerine "bu bir Ziyaretçi" yazmak , yaşlı arkadaşınızın verdiği nedenden dolayı korkunç bir hatadır - programcılar bunu anlamaz. Bir Ziyaretçinin ne olduğunu bilen programcılar bile "Bu bir Ziyaretçi" den daha fazla bilgiye ihtiyaç duyuyor.


5
"tasarım kalıpları Clippy Microsoft Office'in yardımcısıdır" Bu gece kabuslar göreceğim.
MetalMikester

“Deneyimsiz insanların yanlış gidebileceği yerler, tasarım kalıplarını bitene kadar birbirine bağlayarak kodu tasarlamaya çalıştıkları zamandır.” Duy duy. Keşke vermek için birden fazla olsaydı. :)
Quuxplusone 4:16

Ayrıca son paragraf için birden fazla oy almamı isterdim. Tasarım kalıpları, programlama kelimesidir : büyük bir kelime bilgisine sahipseniz daha iyi ve net bir yazar olacaksınız. Bir söyleyebilir Fabrikası bir gelen Builder Onları görmek, ama nasıl söyleyeceğimi öğrendim daha ben, tasarım desenleri üzerine kitaplar okuyarak bir daha o alamadım ucunu kayanın bir gelen blöf İngilizce sözlüğü okuyarak.
Quuxplusone

20

Meslektaşınız NIH sendromundan muzdarip görünüyor ("Burada İcat Edilmedi").

Kodunun yeni alanlar eklemeyi kolaylaştırması son derece kolaydır: Ayrıca kendi kodumu güncellemek için diğer kişilerin yazdığı koddan daha hızlıyım. Ancak bu kısa süreli hız, kodun sürdürülebilirliği ve taşınabilirliği hakkında hiçbir şey söylemez. Ona şüphe avantajını vereceğim: Var olan kod, kötü bir ders kitabı izlemişse veya yanlış bağlamda iyi bir tarif izlerse, gerçekten de kötü bir şekilde yapılandırılmış olabilir.

Tasarım modellerinden kaçınmak gerçekten şaşırtıcı. Kodlayıcılar ve kodlayıcıları yönetmemin son 30 yılında, tasarım kalıpları içgüdüsel olarak yapılan şeylere kelimeler koymaya yardımcı oldu, böylece amacı, avantajları, uygunsuzlukları, riski, fırsatları ve ilgili kalıpları daha çabuk anlamaya yardımcı oldular. Tasarım kalıpları, karmaşıklığın üstesinden gelmek için gerçek bir hızlandırıcıydı!

  • Belki meslektaşınız çoğumuzdan gerçekten çok daha zekidir ve fark edilebilir bir verimlilik azalması olmadan kalıpları yeniden icat etmenin yükünü karşılayabilir?

  • “Programcıların tasarım modellerini anlamadığı” argümanları “Ne yaptığımı gerçekten açıklayamıyorum” gibi geliyor. Veya "Kendi tasarımım hakkında tartışmak istemiyorum". Modellemenin genel anlayışı destekleyebileceğini ve daha az kıdemli meslektaşların değerli görüşlerini paylaşmalarına izin verebileceğini düşünüyorum. Belki de kıdemli meslektaşınız bundan kaçınmak ister.

Katmanlı yaklaşımların çoğu işletme uygulamasında diğer mimarilere göre daha üstün olduğu kanıtlanmıştır. Birinci sınıf lider paketleri bu fikir etrafında yapılandırılmış ve büyüklük sırasına göre zanaat mimarisinden daha iyi bir performans sergilemiştir. Martin Fowler bu yaklaşımı "Kurumsal mimarinin kalıpları" üzerine yaptığı mükemmel kitapta sunar . Ah! Tekrar özür dilerim: Kanıtlanmış kalıplarla ilgili; meslektaşınızın NIH görüşünde şans yok ;-)


NIH sendromu, ilginç, bunu daha önce duymamıştım. Açıkçası bu, çoğu Kuzey Amerika işvereninin çalışanlarını nasıl yönetecekleriyle karşı karşıya kaldığı meselesi!
ödeme yapın

@pay Bunun Kuzey Amerika ile sınırlı olduğundan emin değilim ;-) Her zaman geçmişte biraz başarılı bir şekilde kullandığımız çözümler için gitmek her zaman caziptir. Konfor bölgesi. Ancak zorlu meslektaşlarınızla daima yeni fikirlere ve yapıcı diyaloga açık kalmalısınız. Sonuçta, " Yalnız daha hızlı seyahat edersiniz, ancak birlikte daha uzağa gidersiniz. "
Christophe

16

Pek çok insanın özlediği önemli bir fikir, yazılım tasarımının bağlamsal olduğudur. İş hedeflerine ulaşmak için var ve farklı hedefler farklı yaklaşımlar gerektirebilir. Başka bir deyişle, her zaman en iyi tasarım olsa bile, her zaman en iyi olan tasarım yoktur.

Tasarım desenleri standart sorunlara standart çözümlerdir. Ancak, eğer probleminiz yoksa, bunu çözmek bir çaba kaybıdır.

Şelale ve çevik yazılım tasarımı arasındaki temel fark , tasarım kararlarının alındığı zamandır . Şelale'de, tüm gereksinimleri bir araya getiriyoruz, hangi tasarım desenlerine ihtiyacımız olduğunu belirliyoruz ve ancak daha sonra kodlamaya başlıyoruz. Çevik mimaride, mümkün olan en fazla seçimden haberdar olduğumuzda, tasarım kararlarını son sorumlu ana kadar ertelemek için YAGNI fiyatını takip ediyoruz.

Diğer bir deyişle, şelale içerisinde, ihtiyaç duyulursa çevik olarak ihtiyaç duyulduğunda öngörülürse tasarım desenleri uygulanır . Sonuç olarak, çevik projeler, öngörülen tüm ihtiyaçlar gerçek olmadığından tasarım desenlerini daha az uygulama eğilimindedir.


1
İçin +1 Design patterns are standard solutions to standard problems. Ben biraz daha yanıtlanmış cevaplarda görmedim biraz disapointed değilim. Bu nedenle, önce sorununuzu standart bir sorunla eşleştirip çözmediğinizi belirlemeniz gerekir ve gerçekten sık sık anlarlar.
Walfrat

8

Tasarım kalıpları aslında tasarım kalıpları olarak adlandırılmaz, çünkü ne yapacaklarını belirtirler. Tasarım kalıpları tasarım kalıplarıdır, çünkü daha önce neler yapıldığını açıklarlar . Bazı geliştirici veya geliştiriciler, belirli bir görevi iyi yerine getiren ve benzer sonuçlarla benzer durumlara uygulayabilen bir yöntem tasarladı. Hepsi bu kadar. Bir çok model, içsel güçlü ve zayıf yönlere sahiptir ve uygulanacak uygun bir model belirlemek için teknolojik ve iş gereksinimlerini değerlendirmek üzere eğitimli geliştiriciye kalmıştır.

Bu bağlamda,% 100 bir defaya mahsus kod yazmayı gerçekten taahhüt etmediğiniz sürece, hiçbir kullanım veya bir kullanım durumundan diğerine hiçbir kavram veya uygulama kullanılamıyorsa, neredeyse kesinlikle en azından bazı tasarım modellerini kullanıyorsunuzdur. "Depo" veya "İş Birimi" veya "MVC" gibi gösterişli, ortak isimler olmayabilir, ancak bu onları "tasarım deseni değil" yapmaz.


6

Genellikle GPS kullanarak - "navigasyon" gibi düşünmeyi severim. 'En iyi uygulamaları' ve 'tasarım desenlerini' öğrenirken - GPS navigasyon rotasını kullanmayı öğrenirsiniz. Ancak bölgeyi tanıdığınızda, sık sık yan yoldan aşağı sürüşün sizi sorunlu alanlara yönlendireceğini, oraya daha hızlı ve / veya daha iyi bir şekilde ulaşacağınızı öğreneceksiniz. Bunlar söz konusu olduğunda da aynıdır - deneyim, alet çantanızı yapmanıza ve kestirme yollara gitmenize olanak tanır.

Tasarım kalıplarını öğrenmek ve "en iyi uygulamaları" öğrenmek, belirli bir durumda seçim yapabilmeniz için arkasındaki fikir hakkında bir anlayış kazanmanız anlamına gelir. Çünkü gerçek hayattaki durumlar genellikle teorik durumlara göre daha karmaşıktır - genellikle ders kitaplarında bulunmayan kısıtlamalar ve konular olacaktır. Müşteriler / Müşteriler ürünlerinin hızlı ve genellikle ucuz olmasını ister; Eski kodla çalışmanız gerekir; Kara kutu ve etkisiz olabilen üçüncü parti araçlarla etkileşime geçmeniz gerekiyor; ve her türlü şey. Durumunuz özeldir - en iyi uygulamalar ve modeller daha geneldir.

SE gibi sitelerde bulunan birçok insanın size 'en iyi uygulama' cevaplarını ve 'tasarım deseni' cevaplarını vermesinin önemli sebeplerinden biri, genel ve soyutlanmış çözümlere cevap vermeleridir ve bu sayede bir tür çözümü çözmek için ortak bir dil sunmasına yardımcı olmaktadır. sorunları. Ve öğrenmeni sağlamak için.

Yani - hayır - tasarım kalıpları Çevik geliştirme ortamlarında kaşlarını çatmaz; Bununla birlikte, gelişme nadiren geneldir ve bir kalıba mükemmel bir şekilde uyması için yeterince soyuttur ve (deneyimli) geliştirici bunu bilir.


5

Kullanıcı Arabirimine / veritabanına / Veri katmanına yeni bir alan eklemek, kodunda olduğu gibi 30 dakika sürdüğünde, 2-3 saat sürer.

Bir tasarımı "optimize etmek" istiyorsanız, neyi optimize etmeye çalıştığınızı söylemeniz gerekir.

Örneğin, bir yarış bisikleti en iyi duruma getirilmiş bir araç ... ve bir Boeing 747 de en iyi duruma getirilmiş bir araç ... ama farklı ihtiyaçlar için optimize edildiler.

Örneğin, "MVC" deseni fikri, aşağıdakiler için en iyi duruma getirir:

  • Aynı modelin farklı görünümleri (görünüm modelden bağımsızdır)
  • Her katman ayrı olarak (örneğin farklı ekipler tarafından) geliştirilebilir ve entegrasyondan önce ayrı olarak test edilebilir (birim testleri)
  • vb.

Oysaki kodu başka bir şey için optimize ediyor olabilir, örneğin:

  • Minimal kod satırları
  • Bir kişinin tüm katmanları etkileyen bir değişiklik yapması kolaydır (gerçekten de farklı katmanlara sahip olmadan)
  • vb.

Model tanımları, modelin çözmesi amaçlanan problemin bir açıklaması ile başlar. Belirli bir kalıp kullanmamanın "en iyi uygulama" olduğunu düşünüyorsa, o zaman (aptal bir kalıp olmadığını varsayarsak, bazen yararlı olan bir kalıp olduğunu varsayarsak). çözmek için ve / veya bunun için optimize etmeye çalıştığı farklı (daha büyük veya daha acil, rekabet eden) bir sorunu var.


"hiç bir şekilde gerçekten farklı katmanlara sahip olmamakla" - veya dürüst olmak gerekirse, katmanlar arasında ilerleyen kabul edilebilir "varsayılan davranışa" sahip olarak. Örneğin, web tabanlı SQL yönetici uygulamaları, veritabanı katmanı değiştiğinde kendini otomatik olarak güncelleyen bir sunum katmanıdır. Sadece, sınırlı kullanımlar dışında, verilerinizi kullanıcılara sunmalarını istediğiniz şekilde sunmazlar :-) Yarım saatte yeni bir alan eklemek inanılmaz derecede hızlı görünüyor, bu da tasarım için önemli bir kullanıcı arayüzü olmadığını gösteriyor. yeni alanla bağlantı, katmanlı veya başka türlü.
Steve Jessop

4

Tasarım kalıpları araçlardır. Araçlar gibi, bunları kullanmanın iki yolu vardır: doğru yol ve yanlış yol. Örneğin, size bir tornavida ve bir çivi verirseniz ve sizden iki odun parçasını birleştirmenizi isterseniz , benden bir çekiç istemeniz gerekir . Çiviler için çekiçler, vidalar için tornavidalar kullanılır.

Çok sık olarak, bir tasarım deseni, yalnızca belirli sorunlar ortaya çıktığında doğru olan Tek Doğru Yol olarak tanıtılır. Küçük geliştiriciler, oynamak için yeni bir şeyler buldukları zaman genellikle çocuklar gibidir; bu tasarım desenini her şeye uygulamak istiyorlar . Ve sonunda A Deseninin B Problemine uygulanacağını öğrendikleri ve sonunda C Desen D Problemine uygulanacağını öğrendikleri sürece, yanlış olan hiçbir şey yoktur. sadece var olduğu için desen; Deseni kullanırsınız çünkü bu iş için en iyi (bilinen) araçtır.

Desenlerin çevirme tarafı, desenlerdir. Zaman ve tekrar kötü olduğu kanıtlanmış şeyler, genellikle yürütme zamanı veya hafıza açısından. Bununla birlikte, hem kalıplar hem de anti-kalıplar geliştiriciye, neden var olduklarını anlamayan bir yarar sağlamaz . Geliştiriciler yaptıklarının yeni ve yaratıcı olduğunu düşünmekten hoşlanırlar, ancak çoğu zaman değildir. Muhtemelen daha önce düşünülmüş. Onlardan önceki insanlar deneyimler yüzünden kalıpları yarattılar.

Tabii ki, küçük geliştiriciler genellikle eski şeyleri yapmanın yeni yollarını bulurlar ve bazen bu yollar daha iyidir. Ancak, çok sık sık Dunning-Kruger etkisinin bir örneği olarak sona erer; geliştirici, işlevsel bir program oluşturmak için yeterince bilgilidir, ancak kendi sınırlamalarını anlamamaktadır. Bunu aşmanın tek yolu hem olumlu hem de olumsuz deneyimlerden geçiyor. Modelleri görmezden geliyorlar çünkü kendilerinin üstün olduklarına inanıyorlar, ama gerçekte 10.000 geliştiricinin zaten belirli bir tasarım kullandığını ve sonra gerçekten kötü olduğu için attığını bilmiyorlar.

Çevik, gelişen müşteri gereksinimlerine hızlı bir şekilde uyum sağlaması bakımından "işleri hızlı bir şekilde yerine getirme" yönünden tercih eder. Tasarım desenlerini desteklemez ya da onları küçümsemez. Bir model en hızlı, en güvenilir yöntem ise, geliştirici onu kullanmalıdır. Belirli bir şablon basitçe "yapılmasını sağlamaktan" daha fazla zaman alırsa, bir model olmayan bir şey kullanmak büyük olasılıkla tamamdır (elbette, bu performansın ciddi şekilde düşmediği varsayılmaktadır). Bilinen bir kalıp bulunamazsa, müşteriye "hayır" demekten çok kendi tasarımlarını yapmak tercih edilir. Müşteriler, özellikle ödeme yapan müşteriler genellikle haklıdır.

Modellerin Yol olduğunu iddia eden veya modellerin Varoluşun Arması olduğunu iddia eden herkes yanlıştır. Desenler, belirli durumlara uygulanması amaçlanan ve koşullara bağlı olarak değişen derecelerde başarıya sahip araçlardır. Bu, MVC'yi seçip seçmemeye, Veri Aktarım Nesneleri'ni kullanıp kullanmamaya vb. Bağlı olmamasına bağlı olmayan bir Gerçeğidir. ve mantıklı hatalardan oldukça uzaktır.

Genellikle , kalıplar tutarlı bir tasarım şekline izin verir ve% 100 orijinal fikir yazmak yerine tüm kalıpları görmezden gelmekten daha iyi bir performans gösterir, ancak tüm kalıplardan kaçınamazsınız. Örneğin, eğer y = x + 5 ise, sadece x + 5 yazma biçiminden kaçınmak için y = x + (5 * 3 + 15/3) / 4 yazacak mısınız? Hayır değilsin. Y = x + 5 yazacak ve bir sonraki soruna geçeceksiniz.

İnsanlar her gün kalıp kullanıyor ve sorun değil . En önemli şey, mantıksal olarak işlevsel, nadiren çarpışan ve kullanıcı dostu kodlara sahip olmak. Bundan başka hiçbir şey önemli değil.


Bununla ilgili uyarı, sorunu ve etki alanını 'şu anki' anlayışınıza dayanarak, yeni bir sınıf oluşturabileceğiniz veya duruma uygun bir örüntü izleyebileceğiniz, ancak ertesi gün bir müşterinin sizin için istediği bir durum olduğunu düşünüyorum. diğer müşterilerin kendi sürümlerinde istemeyeceği bazı küçük yönlere göre özelleştirmeler yapın. 2 düzine müşterinin ihtiyacına cevap veren ve kopyalı makarnayı önleyen bir kod temeli oluşturmak, başarılması imkansız görünüyor. Ben sadece bugün eski bir posta birleştirme işlemi yeniden düzenlerken bu koştu.
Igneous01

2

Sisteminizin herhangi iki bölümünü aynı şekilde tasarlamaktan kaçınarak 'tavsiye etmiyorum' demediğinizden emin olamazsınız. Muhtemelen kastettiği 'tasarım desenine uyduğu için sadece bir tasarım kullanmaktan kaçınmaktır'. Yaptıklarınızı düşünmek kesinlikle 'en iyi uygulama' ve bir üniversiteyi öğretmek için var olması gereken ; ne yazık ki, bu görünmüyor.


2

Tasarım kalıpları çevik uygulamalara antitetik değildir. Çevik uygulamalara antitetik olan tasarım desenlerini kullanmak için tasarım kalıplarını, yeni mezunlar ve öğrenciler arasındaki ortak uygulamayı "bu sorunu bir fabrika kalıplarını kullanarak nasıl çözeceğiz?"

Çevik, iş için en iyi aracı seçmek, işi seçtiğiniz aracı sığdırmaya çalışmak DEĞİL anlamına gelir.
Ve tbh, TÜM sağduyu geliştirme uygulamalarının ortaya çıktığı şeydir (elbette ki, genellikle elbette ödün vermek zorundasınız, çünkü seçim yapabileceğiniz araçların seçimi genellikle şirket standartları, lisans kısıtlamaları (GPL ve bazen de diğer açık kaynak araçları gibi) tarafından kısıtlanır. özellikle yeniden satış için yazılım oluştururken kullanılamaz) ve bunun gibi şeyler.

Meslektaşınız / arkadaşınız muhtemelen kendi tasarım tasarımlarını kullandığından değil, başka bir tasarımın daha iyi olacağını düşündüğü zaman (genellikle sübjektif olsa da, Birçoğu benimle hiç kuşku yok) belirli bir tasarım modelinin zorla kullanılmasının çirkin, bakımı zor ve yüksek verimsiz kodlara yol açtığı pek çok örnek görmüştüm).

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.