En tartışmalı programlama fikriniz nedir?

Bu kesinlikle sübjektiftir, ancak tartışmacı hale gelmesini önlemek istiyorum. İnsanların buna uygun davranması ilginç bir soru olabilir diye düşünüyorum.

Bu soru için fikri gelen açıklama iplik geldi cevabım için "favori dili hakkında nefret nelerdir beş şey?" soru . C # 'daki sınıfların varsayılan olarak mühürlenmesi gerektiğini iddia ettim - mantığımı soruya koymayacağım, ancak bu sorunun cevabı olarak daha kapsamlı bir açıklama yazabilirim. Yorumlarda tartışma sıcaklığına şaşırdım (şu anda 25 yorum).

Peki, hangi çekişmeli görüşlere sahipsiniz ? Ben nispeten az temeli (örneğin küme ayracı yerleştirme) ile oldukça dini olan bir şey kaçınmak istiyorum ama örnekler "birim test aslında çok yararlı değil" veya "kamu alanları gerçekten iyi" gibi şeyler içerebilir. Önemli olan (benim için, her neyse), görüşlerinizin arkasında nedenleriniz olması.

Lütfen fikrinizi ve muhakemenizi sunun - İnsanları, kendileriyle hemfikir olsanız da olmasanız da, iyi tartışılmış ve ilginç fikirlere oy vermeye teşvik ediyorum.

Boş zamanlarında eğlenmek için kodlama yapmayan programcılar asla bu kadar iyi olmayacaktır.

Bence en zeki ve en yetenekli insanlar bile bir işten öte bir şey olmadıkça asla gerçekten iyi bir programcı olmayacaklar. Yani yanlarında küçük projeler yapıyorlar ya da boş zamanlarında birçok farklı dil ve fikirle uğraşıyorlar.

(Not: İyi programcıların programlamadan başka bir şey yapmadığını söylemiyorum, ancak 9'dan 5'e kadar programdan daha fazlasını yapıyorlar)

Her zaman kullanmanız gereken tek "en iyi uygulama" "Beyninizi Kullanın" dır.

Çok fazla insan çok fazla bandwago atlıyor ve yöntemleri, desenleri, çerçeveleri vb. Bir şeyin yeni olması ya da saygı duyulan birinin bir görüşü olması, hepsine uyduğu anlamına gelmez :)

DÜZENLEME: Sadece açıklığa kavuşturmak için - insanların en iyi uygulamaları, değerli fikirleri vb. yapıyorum ve ne gibi faydaları / dezavantajları var?

"Googling" sorun değil!

Evet, bazı insanları yıllarca süren yoğun ezberleme ve / veya şanlı programlama kitap yığınlarının, saniyeler içinde herkesin erişebileceği bir kaynağa yol açmaya başladığını biliyorum, ancak bunu insanlara karşı tutmamalısınız. kullanın.

Sık sık eleştirinin sonucu olan sorunlara googling yanıtları duyarım ve gerçekten anlamsızdır. Her şeyden önce, herkesin referans olması için materyallere ihtiyacı olduğu kabul edilmelidir. Her şeyi bilmiyorsunuz ve bir şeylere bakmanız gerekecek. Bunu kabul ederek, bilgiyi nereden aldığınız gerçekten önemli mi? Bir kitaba bakmanız, Google'da bakmanız veya halüsinasyon yaptığınız konuşan bir kurbağadan duymanız önemli midir? Hayır. Doğru cevap doğru cevaptır.

Önemli olan, materyali anlamanız, başarılı bir programlama çözümünün sonu olarak kullanmanız ve müşteri / işvereninizin sonuçlardan memnun olmasıdır.

(halüsinasyon yapan kurbağalardan cevap alıyorsanız, muhtemelen aynı şekilde yardım almalısınız)

Koddaki yorumların çoğu aslında kod çoğaltmanın zararlı bir şeklidir.

Zamanımızın çoğunu başkaları (veya kendimiz) tarafından yazılan kodu korumak için harcıyoruz ve kötü, yanlış, modası geçmiş, yanıltıcı yorumlar koddaki en can sıkıcı eserler listesinin en üstünde olmalıdır.

Sonunda birçok insan onları boşalttı, özellikle de o çiçek kutusu canavarlıklarını.

Kodu okunabilir hale getirmeye, gerektiğinde yeniden düzenlemeye ve deyimleri ve tuhaflığı en aza indirmeye odaklanmak çok daha iyi.

Öte yandan, birçok ders yorumların kodun kendisinden çok daha önemli olduğunu öğretir, bu sonraki satıra yol açmak faturaya bir yorum stili ekler .

XML çok abartılıyor

Bence beyinlerini kullanmadan önce XML bandwagonuna çok fazla zıplama ... Web için XML harika, bunun için tasarlanmış. Aksi takdirde, bazı problem tanımlarının ve tasarım düşüncelerinin, onu kullanma kararını önceden alması gerektiğini düşünüyorum.

5 sentim

Tüm programcılar eşit yaratılmaz

Çoğu zaman yöneticiler DeveloperA == DeveloperB'nin sadece aynı seviyede deneyime sahip olmaları ve benzeri şeyler olduğunu düşünürler. Gerçekte, bir geliştiricinin performansı bir diğerinin performansının 10 katı, hatta 100 katı olabilir.

Bu konuda konuşmak siyaseten riskli, ancak birkaç takım üyeleri olsa bile bazen, o işaret gibi hissediyorum görünür her zaman böyle değil, eşit beceri olmak. Baş geliştiricilerin ümitin ötesinde olduğu ve genç geliştiricilerin tüm gerçek işleri yaptıkları vakaları bile gördüm - krediyi aldıklarından emin oldum. :)

İnsanların neden Java'nın üniversitelerde öğretilecek en iyi "ilk" programlama dili olduğunu düşündüklerini anlamıyorum.

Birincisi, ilk programlama dilinin nesneler ve sözdizimi değil kontrol akışını ve değişkenleri öğrenme ihtiyacını vurgulayacak şekilde olması gerektiğine inanıyorum.

Bir diğeri için, C / C ++ 'da bellek sızıntılarını ayıklama konusunda deneyim sahibi olmayan kişilerin Java'nın tabloya getirdiklerini tam olarak anlayamayacağına inanıyorum.

Ayrıca doğal ilerleme, "bunu nasıl yapabilirim" den "bunu yapan kütüphaneyi nasıl bulabilirim" den, tam tersi şekilde olmamalıdır.

Sadece bir dil biliyorsanız, ne kadar iyi bilirseniz öğrenin, harika bir programcı değilsiniz.

C # veya Java'da gerçekten iyi olduğunuzda ya da öğrenmeye başladığınız diğer herhangi bir dilin o zaman ihtiyacınız olan tek şey olduğunu söyleyen bir tutum var gibi görünüyor. Buna inanmıyorum - öğrendiğim her dil bana programlama hakkında yeni bir şey öğretti ve diğerleriyle birlikte çalışmalarıma geri getirebildim. Bence kendilerini tek bir dile kısıtlayan herkes asla olabilecek kadar iyi olmayacak.

Aynı zamanda bana gerçekten iyi bir programcıda bulmayı umduğum niteliklerle uyuşmayan belirli bir sorgulama ve deneyime isteksizlik olduğunu da gösteriyor.

Performans yapar olsun.

Yazdırma ifadeleri, kod hatalarını ayıklamanın geçerli bir yoludur

Kodunuzu System.out.println(veya diliniz için ne olursa olsun yazdır deyimini) çalıştırarak kodunuzu hata ayıklamak için gayet iyi olduğuna inanıyorum . Genellikle, bu hata ayıklamadan daha hızlı olabilir ve basılı çıktıları uygulamanın diğer çalışmalarıyla karşılaştırabilirsiniz.

Üretime gittiğinizde yazdırma deyimlerini kaldırdığınızdan emin olun (veya daha iyisi, bunları günlük bildirimlerine dönüştürün)

İşiniz kendinizi işten çıkarmaktır.

İşvereniniz için yazılım yazarken, oluşturduğunuz herhangi bir yazılım, herhangi bir geliştirici tarafından alınabilecek ve minimum çaba ile anlaşılabilecek şekilde yazılmalıdır. İyi tasarlanmış, açık ve tutarlı bir şekilde yazılmıştır, temiz bir şekilde biçimlendirilmiştir, olması gerektiği yerde belgelenmiştir, beklendiği gibi günlük olarak inşa edilir, depoya kontrol edilir ve uygun şekilde biçimlendirilir.

Bir otobüse çarpar, işten çıkartılır, işten çıkarılır veya işten çıkarsanız, işvereniniz sizi bir an önce değiştirebilir ve bir sonraki adam rolünüze adım atabilir, kodunuzu alıp kalkabilir ve bir hafta içinde çalışan üstleri. Eğer bunu yapamazsa, sefil bir şekilde başarısız oldunuz.

İlginç bir şekilde, bu hedefe sahip olmanın beni işverenlerim için daha değerli hale getirdiğini fark ettim. Ne kadar tek kullanımlık olmaya çalışırsam onlara o kadar değerli olurum.

1) İş Uygulamaları ücretleri :

Bence tüm "Kurumsal" çerçeveler duman ve aynalar. J2EE, .NET, Apache çerçevelerinin çoğunluğu ve bu tür şeyleri yönetmek için çoğu soyutlama çözdüklerinden çok daha karmaşıktır.

Sıkıcı, basit görevleri çözmek için "sihir" yapan herhangi bir düzenli Java veya .NET ORM veya sözde modern MVC çerçevesini alın. Sonunda hızlı bir şekilde doğrulanması ve yazılması zor olan çok sayıda çirkin XML demirbaş yazısı yazıyorsunuz. Bunların yarısının diğer API'lerin çalışmalarını, geri dönüştürülmesi imkansız olan arayüzleri ve yalnızca Java ve C # esnekliğini aşmak için gerekli soyut sınıfları entegre etmek için devasa API'larınız var. Bunun çoğuna ihtiyacımız yok.

Kendi darned tanımlayıcı sözdizimi, aşırı karmaşık veritabanı ve grup yazılımı ürünleri ile tüm farklı uygulama sunucularına ne dersiniz?

Bunun amacı karmaşıklık == kötü değil, gereksiz karmaşıklık == kötü. Bazılarının gerekli olduğu büyük kurumsal kurulumlarda çalıştım, ancak çoğu durumda bile evde kullanılan birkaç komut dosyası ve basit bir web ön ucu çoğu kullanım durumunu çözmek için gerekli.

Tüm bu kurumsal uygulamaları basit web çerçeveleri, açık kaynak kodlu DB'ler ve önemsiz programlama yapılarıyla değiştirmeye çalışırdım.

2) Gerekli n yıllık deneyim:

Bir uygulama, API veya çerçeve ile ilgili belirli bir sorunu ele almak için bir danışmana veya teknisyene ihtiyacınız olmadığı sürece, o uygulamada 5 yıllık deneyime sahip birine gerçekten ihtiyacınız yoktur. İhtiyacınız olan şey, belgeleri okuyabilen, ne yaparsanız yapın alan bilgisi olan ve hızlı bir şekilde öğrenebilen bir geliştirici / yöneticidir. Bir çeşit dilde geliştirmeniz gerekiyorsa, iyi bir geliştirici bunu 2 aydan daha kısa sürede alacaktır. X web sunucusu için bir yöneticiye ihtiyacınız varsa, iki gün içinde man sayfalarını ve haber gruplarını okumalı ve hız kazanmalıdır. Daha az bir şey ve o kişi kendisine ödenen paraya değmez.

3) Ortak "bilgisayar bilimi" derecesi müfredatı:

Bilgisayar bilimi ve yazılım mühendisliği derecelerinin çoğu boğadır. İlk programlama diliniz Java veya C # ise, yanlış bir şey yapıyorsunuz demektir. Cebir ve matematikle dolu birkaç ders almazsanız, yanlıştır. Fonksiyonel programlamayı araştırmazsanız, bu tamamlanmamıştır. Döngü değişmezlerini döngü için önemsiz olanlara uygulayamazsanız, varsayılan bir bilgisayar bilimcisi olarak tuzunuza değmezsiniz. Eğer x ve y dillerinde deneyim ve nesne yönelimi ile karşılaşırsanız, bu s *** ile doludur. Gerçek bir bilgisayar bilimcisi, kullandığı kavramlar ve sözdizimleri açısından bir dil görür ve programlama metodolojilerini birçokları arasında görür ve her ikisinin de yeni dilleri, tasarım yöntemlerini veya spesifikasyon dillerini seçmenin temel felsefelerini iyi bilmektedir. önemsiz olmak.

Mektuplar ve Ayarlayıcılar Aşırı Kullanıldı

Kamusal alanların kötü olduğunu iddia eden milyonlarca insan gördüm, bu yüzden onları özel yapıyorlar ve hepsi için alıcılar ve pasifler sağlıyorlar. Bunun, alanları genel hale getirmekle neredeyse aynı olduğuna inanıyorum, belki iş parçacıkları kullanıyorsanız (ancak genellikle durum böyle değil) veya erişimcilerinizin iş / sunum mantığı (en azından 'garip') varsa biraz farklı olabilir.

Ben kamu alanları lehine değilim, ama herkes için bir alıcı / ayarlayıcı (veya Mülkiyet) yapmak karşı ve sonra bunu yapmak kapsülleme veya bilgi gizleme olduğunu iddia ... ha!

GÜNCELLEME:

Bu cevap yorumlarında bazı tartışmalara neden oldu, bu yüzden biraz açıklığa kavuşmaya çalışacağım (orijinalin dokunulmadan bırakacağım, çünkü birçok insanın oyuna cevap vermediği).

Her şeyden önce: ortak alanları kullanan herkes hapishaneyi hak ediyor

Şimdi, özel alanlar oluşturmayı ve sonra IDE kullanarak bunlardan her biri için otomatik olarak Alıcılar ve ayarlayıcılar oluşturmak olduğunu bad neredeyse kamu alanlarını kullanarak olarak.

Pek çok insan düşünür:

private fields + public accessors == encapsulation

Diyorum ki (otomatik ya da değil) alanlarınız için alıcı / ayarlayıcı çifti etkili bir şekilde elde etmeye çalıştığınız kapsülleme karşı gider.

Son olarak, bu konuda Bob Amca'yı alıntılamama izin verin ("Temiz Kod" bölüm 6'dan alınmıştır):

Değişkenlerimizi gizli tutmamızın bir nedeni var. Başka kimsenin onlara güvenmesini istemiyoruz. Bir heves ya da dürtü üzerinde türlerini ya da uygulamalarını değiştirme özgürlüğünü istiyoruz. Öyleyse neden bu kadar çok programcı nesnelerine otomatik olarak alıcı ve ayarlayıcı ekliyor, özel alanlarını herkese açıkmış gibi gösteriyor?

UML diyagramları çok abartılıyor

Elbette faydalı diyagramlar vardır, örneğin Kompozit Model için sınıf diyagramı , ancak birçok UML diyagramının kesinlikle değeri yoktur.

Görüş: SQL koddur. Bu şekilde davran

Yani, tıpkı C #, Java veya diğer favori nesne / prosedür diliniz gibi, okunabilir ve bakımı kolay bir biçimlendirme stili geliştirin.

Özensiz serbest biçimlendirilmiş SQL kodu gördüğümde nefret ediyorum. Bir sayfada her iki kıvırcık ayraç stilini gördüğünüzde çığlık atıyorsanız, neden veya neden JOIN koşulunu gizleyen veya gizleyen serbest biçimlendirilmiş SQL veya SQL gördüğünüzde çığlık atmıyorsunuz?

Okunabilirlik kodunuzun en önemli özelliğidir.

Doğruluktan bile daha fazlası. Okunabilirse, düzeltmesi kolaydır. Ayrıca optimizasyonu kolay, değiştirilmesi kolay, anlaşılması kolay. Ve umarım diğer geliştiriciler de ondan bir şeyler öğrenebilirler.

Bir geliştiriciyseniz, kod yazabilmeniz gerekir

Geçen yıl biraz röportaj yaptım ve röportajın bir parçası için insanların nasıl düşündüklerini ve beyaz tahtada basit-orta dereceli algoritmaları nasıl uyguladıklarını test etmem gerekiyordu. Başlangıçta aşağıdaki gibi sorularla başladım:

Pi'nin daha fazla doğruluk sağlayan 4 * (1 - 1/3 + 1/5 - 1/7 + ...) işlevi kullanılarak tahmin edilebileceği göz önüne alındığında, Pi'yi 5 ondalık basamak doğruluğuna hesaplayan bir işlev yazın .

Sizi düşündürecek bir sorun, ancak deneyimli bir geliştiriciye ulaşılamamalı (yaklaşık 10 satır C # ile cevaplanabilir). Bununla birlikte, (ajans tarafından önceden taranan) adaylarımızın birçoğu cevap vermeye bile başlayamadı ve hatta cevap vermeye nasıl gidebileceklerini açıklayamadı. Bir süre sonra şöyle basit sorular sormaya başladım:

Bir dairenin alanı yarıçapın Pi çarpı ile verildiği göz önüne alındığında, bir dairenin alanını hesaplamak için bir işlev yazın.

Şaşırtıcı bir şekilde, adayların yarısından fazlası bu işlevi herhangi bir dilde yazamadı (en popüler dilleri okuyabilirim, böylece sahte kod da dahil olmak üzere seçtikleri herhangi bir dili kullanmalarına izin verdim). Biz bu işlevi C # yazamadı "C # geliştiricileri" vardı.

Buna şaşırdım. Her zaman geliştiricilerin kod yazabilmesi gerektiğini düşünmüştüm. Görünüşe göre, günümüzde bu tartışmalı bir görüş. Kesinlikle röportaj adayları arasında!

Düzenle:

İlk sorunun iyi ya da kötü olup olmadığı ve bir röportajda bu kadar karmaşık sorular sorup sormamanız gerektiği konusunda yorumlarda çok fazla tartışma var. Burada büyük ölçüde gönderinin noktasını kaçırdığınızı söylemek dışında (bu tamamen yeni bir soru) bu konuya girmeyeceğim .

Evet, insanların bununla ilerleme kaydedemediklerini söyledim, ancak ikinci soru önemsiz ve birçok insan da bununla ilerleme kaydedemedi! Kendilerini geliştirici olarak adlandıran herkes , ikincisine cevap bile düşünmeden birkaç saniye içinde yazabilmelidir. Ve birçoğu yapamaz.

Macarca gösterimin kullanımı ölümle cezalandırılmalıdır.

Bu yeterince tartışmalı olmalı;)

Tasarım kalıpları iyi tasarıma yardım ettiklerinden daha fazla zarar veriyor.

IMO yazılım tasarımı, özellikle iyi yazılım tasarımı, özellikle insanların gerçekten hatırlayabileceği az sayıda desende, desenlerde anlamlı bir şekilde yakalanamayacak kadar çeşitlidir ve insanların bir avuçtan daha fazlasını hatırlayamayacak kadar soyuttur. Yani fazla yardım etmiyorlar.

Öte yandan, çok fazla insan bu konsepte aşık olur ve her yerde desen uygulamaya çalışır - genellikle, sonuçta ortaya çıkan kodda (tamamen anlamsız) Singletons ve Soyut Fabrikalar arasındaki gerçek tasarımı bulamazsınız.

Daha az kod daha çok daha iyidir!

Kullanıcılar "bu kadar mı?" Derse ve işiniz görünmez kalırsa, doğru yapılır. Zafer başka bir yerde bulunabilir.

PHP berbat ;-)

Kanıt, puding içerisindedir.

Birim Testi, iyi kod yazmanıza yardımcı olmaz

Birim testlerinin tek nedeni, zaten çalışan kodun bozulmadığından emin olmaktır. Önce test yazmak veya testlere kod yazmak çok saçma. Testlere koddan önce yazarsanız, uç durumların ne olduğunu bile bilemezsiniz. Testleri geçen ancak öngörülemeyen durumlarda yine de başarısız olan bir kodunuz olabilir.

Dahası, iyi geliştiriciler uyumu düşük tutacak ve bu da yeni kod eklemenin mevcut şeylerle ilgili sorunlara neden olma olasılığını azaltacaktır.

Aslında, bunu daha da genelleştireceğim,

Yazılım Mühendisliğindeki çoğu "En İyi Uygulamalar" kötü programcıların çok fazla zarar görmesini engellemek için vardır .

Kötü geliştiricileri el altında tutmak ve onların dambıl hataları yapmalarını engellemek için oradalar. Tabii ki, çoğu geliştirici kötü olduğundan, bu iyi bir şeydir, ancak iyi geliştiriciler bir geçiş almalıdır.

Küçük yöntemler yazın. Programcılar, çok farklı şeyler yaptıkları yerlerde loooong yöntemleri yazmayı seviyor gibi görünüyor.

Bence her yerde bir yöntem oluşturulmalı.

Arada bir çöp kodu yazmak sorun değil

Bazen belirli bir görevi yerine getirmek için hızlı ve kirli bir çöp kodu parçası yeterlidir. Patterns, ORMs, SRP, whatever ... Bir Konsol veya Web Uygulaması atın, bazı satır içi sql (iyi hissettirir) yazın ve gereksinimi patlatın.

Kod == Tasarım

Ben gelişmiş UML diyagramları ve sonsuz kod belgelerinin hayranı değilim. Üst düzey bir dilde, kodunuz olduğu gibi okunabilir ve anlaşılabilir olmalıdır. Karmaşık belgeler ve diyagramlar artık daha kullanıcı dostu değildir.

İşte Tasarım Olarak Kod konulu bir makale .

Yazılım geliştirme sadece bir iştir

Beni yanlış anlamayın, yazılım geliştirmeyi çok seviyorum. Konuyla ilgili son birkaç yıldır bir blog yazdım. Burada 5000'den fazla itibar puanına sahip olmak için yeterince zaman geçirdim. Ve bir başlangıçta, müteahhit olarak alabileceğimden çok daha az parayla 60 saat hafta boyunca çalışıyorum çünkü takım harika ve iş ilginç.

Ama şeylerin büyük planında, bu sadece bir iş.

Aile, kız arkadaşım, arkadaşlar, mutluluk vb. Birçok şeyin altında ve motosiklet sürmek, yelkenli yatlar veya snowboard yapmak gibi sınırsız bir nakit kaynağım olsaydı yapmayı tercih ettiğim diğer şeylerin altında önem taşıyor.

Bazen bir çok geliştirici, gelişmenin, başlı başına bir amaç olmaktan ziyade hayatta daha önemli şeylere sahip olmamızı (ve zevk aldığımız bir şey yaparak onlara sahip olmamızı) sağlayan bir şey olduğunu unutuyor.

Ben de kaynak kontrolünde ikili var yanlış bir şey olduğunu düşünüyorum .. bunun için iyi bir neden varsa. Eğer bir kaynağım varsa, kaynağım yok ve her devs makinesinde aynı yerde olmayabilir, o zaman genellikle bir "ikili" dizine yapıştıracağım ve göreceli bir yol kullanarak bir projeye başvuracağım .

Pek çok insan, aynı kaynakta "kaynak kontrolü" ve "ikili" den bahsettiğim için kazıkta yakılmam gerektiğini düşünüyor gibi görünüyor. Ekleyemeyeceğinizi söyleyen katı kuralları olan yerleri bile biliyorum.

Her geliştirici, modern bilgisayarların temel mimarisine aşina olmalıdır. Bu, sanal bir makineyi hedefleyen geliştiriciler için de geçerlidir (belki daha da fazlası, çünkü tekrar tekrar bellek yönetimi ile endişelenmeleri gerekmediği söylendi).

Yazılım Mimarları / Tasarımcıları Overrated

Bir geliştirici olarak Yazılım Mimarları fikrinden nefret ediyorum. Temelde artık tam zamanlı kodlamayan, dergi ve makaleleri okuyan ve size nasıl yazılım tasarlayacağınızı söyleyen kişilerdir. Sadece yaşamak için tam zamanlı yazılım yazan insanlar bunu yapmalıdır. 5 yıl önce Mimar olmadan önce dünyanın en iyi kodlayıcısı olmanız umrumda değil, düşünceleriniz benim için işe yaramaz.

Bu nasıl tartışmalı?

Düzenleme (açıklığa kavuşturmak için): Çoğu Yazılım Mimarının harika İş Analistleri (müşterilerle konuşma, yazma gereksinimleri, testler, vb.) Yaptığını düşünüyorum, sadece yazılım tasarımında, yüksek düzeyde veya başka bir yerde yerlerinin olmadığını düşünüyorum.

Gelişime "tek beden herkese uyar" yaklaşımı yoktur

Bunun tartışmalı bir görüş olduğuna şaşırdım, çünkü bana sağduyu gibi geliyor. Ancak, popüler bloglar geliştirme için "tek beden herkese uyar" yaklaşımını teşvik birçok girişler vardır, bu yüzden ben aslında azınlık olabilir düşünüyorum.

Şeyler ben olarak lanse ediliyor gördüğüm için doğru bir yaklaşım herhangi projede - herhangi bir bilgi bu konuda bilinmektedir önce - Test Driven Development (TDD) kullanımı gibi şeylerdir, Alan Tasarım (DDD) etkisiyle, Nesne-ilişkisel eşleme (ORM) , Agile (başkent A), Nesne Yönelimi (OO) vb. Metodolojilerden mimarilere ve bileşenlere kadar her şeyi kapsar. Tabii ki hepsi güzel pazarlanabilir kısaltmalar ile.

İnsanlar, bloglarında "Test Testiyle Sürüyorum" veya benzeri gibi rozet koymak gibi görünüyorlar, sanki proje projesinin ayrıntıları gerçekten iyi bir şeyse de tek bir yaklaşıma sıkı sıkıya bağlılarlar .

Öyle değil.

Doğru metodolojileri ve mimarileri ve bileşenleri vb. Seçmek, proje başına temel olarak yapılması gereken bir şeydir ve sadece üzerinde çalıştığınız projenin türüne ve benzersiz gereksinimlerine değil, aynı zamanda boyut ve yeteneğe de bağlıdır. çalıştığınız takımdan.