it-swarm.dev

Açıkçası, Kovboy kodlamasını mı tercih edersiniz?

Metodolojileri savunan çoğu programcı Çevik, Şelale, RUP, vb.Gibi politik olarak doğrudur. Bazıları metodolojiyi takip eder, ancak hepsini değil. Açıkçası, eğer metodolojiyi seçebilirseniz, ana akım “doğru” metodolojilere gidersiniz ya da kovboy programlama gibi “daha ​​kolay” metodolojiyi mi tercih edersiniz? Neden?

Değiştiğini biliyorum. Lütfen, ne zaman birini ya da diğerini kullanacağınızı açıklayın. Lütfen, Kovboy kodlamasında ne gibi avantajlar gördüğünüzü söyleyin.

Wikipedia'da Kovboy kodlaması hakkında bilgi edinin

68
Maniero

Evet.

Ayrıca çoraplarımı çıkardığım yerde bırakmayı, masamın çıktıları ve eski atıştırmalık sargıları, kirli bulaşıklarla dolu lavabomu ve yatağımı dağınık bırakmayı tercih ederim.

Önceden planlanmış bir tatil, uygun bir tatil, doğru beslenmeye doğru bir zihinle yenen bir yemek ya da bilinen yürüyüş yollarında uygun yürüyüş olarak kalmayı düşünmüyorum.

Eğlenmeyi, şaşırmayı, yeni şeyler öğrenmeyi, hata yapmayı ve geri getirip getirmeyeceğimi asla tam olarak bilmiyorum. Ve bazen, bu tutum tam olarak bir projeyi yerden kaldırmak için gerekli olan şeydir ...

... ama çoğu zaman sorumsuz. Dans sona erdiğinde, piper ödenir ... Bunu senin tehlikesinde unut.

46
Shog9

Kesinlikle haklısın. Bu "kovboy programlama" yaklaşımı, kodun ilk revizyonunu daha hızlı çıkarabilir, ancak bu zaman tasarrufu sayesinde aşağıdakilerden daha fazla kaybolacaktır:

  • Ek hatalar
  • Yine de sahip olacağınız hataları bulmak için gereken ek süre
  • Altı ayda bir değişiklik yapmanız gerektiğinde ne yaptığınızı hatırlamak için kodunuzu tersine çevirmek zorundasınız
  • Kodunuz üzerinde çalışması gereken ek geliştiricileri eğitmek için ekstra zaman harcanması
  • Bir şeyi bozan bir değişiklik yaptığınızda geriye bakmak için revizyon günlüğüne sahip olmamak
  • Daha sonraki projelerde kolayca yeniden kullanabileceğiniz modüllere sahip olmamak
  • Ve tekrar tekrar

Neil Butterworth'un cevabında belirttiği gibi, bazen yapman gerekeni yapmalısın. Yine de genel bir uygulama olarak, hayır, kaynak kodu kontrolü, kalıpları, dokümantasyon vb. İçin harcanan zaman olmadan kodu olabildiğince hızlı çıkarmak çok kötü bir alışkanlıktır.

İş arkadaşlarınızı analiz etmek ve alışkanlıklarını, körü körüne yaptıkları gibi yapmak yerine yararlı mı yoksa zararlı mı olduğunu düşünmeniz için iyi bir seçimdir.

31
Warren Pena

Bu gerçekten, sıkı bir yapı olmadan ve planlamada çok fazla zaman tüketmeden işleri doğru bir şekilde uygulayıp uygulayamayacağınız sorusuna gelir.

Buraya gerçekten popüler olmayan bir şey fırlatacağım: müşteriler genellikle kovboy tarzında işlerin yapılmasını istiyorlar.

Yani, bir şeylerin yapılmasını talep etmek istiyorlar ve birisinin üzerine atlamasını, yürütmesini ve oraya götürmesini istiyorlar. Proje yönetimi, toplantılar, konferans görüşmeleri veya formlar yok. Sadece yap. Asla bir müşteri "hey, bu bizim zevkleri için biraz hızlı bir şekilde yapıldı, bir dahaki sefere orada küçük bir şelale ya da bir şey koyarsanız takdir ediyorum" demedim.

Takım metodolojileri ve yapısı, bir projenin oyun alanını düzleştirmek ve aynı sayfada farklı seviyelerde geliştiriciler elde etmek, aynı amaçlarla aynı şekilde çalışmak üzere tasarlanmıştır.

Birlikte çalıştığım başarılı "kovboylar":

  • Bir şeyi hızlı bir şekilde uygulamanın en basit yolunu belirleyin
  • Hangi noktada kırılacağını bilin
  • Temiz, okunabilir ve anlaşılır kod yazın
  • Kullanıcıların nasıl kullanacağını tahmin et, kötüye kullan ve kır
  • Ölçekleyin/doğru yerlere soyutlayın ve üzerine mimari astronot gitmeyin
  • Edge davalarının ve istisnalarının nerede ve nasıl ele alınacağını bilin

Bunun gibi insanlar, çok az yönetim ve yapı yükü ile gerçekten harika sonuçlar verir, ancak nadirdir.

29
Brandon

DÜZENLEME: Gelecekte başvurmak için cevabım başka sorusu, bununla birleştirildi. Burada oldukça yer yok, ama bu benim çağrım değildi.


O sadece tembel, kibirli, cahil ve son derece bencil. Bu davranış pervasızdır.

Demek istediğim, alışılmadık veya belki de modası geçmiş bir metodoloji kullanmıyor. Sadece bilinçli olarak yok kullanıyor. Standart yok. Kalite güvencesi yok. Hayır. Yazılım kalitesinin nereden gelmesini bekliyor? Ağaçlar?
Oldukça açık bir şekilde eksik olduğu zaman, alıntı yaptığınız insanların deneyimlerini reddetmesi çok komik. İddialarını sorgulamak için doğrulanabilir ve ilgili argümanlar sağlamak geçerlidir. Ancak deneyimlerini reddederek onları itibarsızlaştırmaya çalışmak değil.

Ancak asıl nokta şudur: Sürüm kontrolü ne kadar zaman alır?
Eğer ara sıra 5 saniye yatırım yapmaya ikna edilemezse, patronuna götürmelisin. Sürüm kontrolü isteğe bağlı değildir. Tam durak.

Ve sürüm kontrolünü kullandıktan sonra, hangi hataları tanıttığını kolayca izleyebilirsiniz. Ve onu onları düzeltsin. Bu onun karışıklığı, neden temizlemelisin? Yaklaşımının daha iyi olduğunu düşünüyorsa, yapmasına izin verin - sonuna kadar.
Gerçekten yapabildiğini varsayarsak (makul bir süre içinde) hala bir sorunun var: onunla takım çalışması imkansız. Ve bu onu ikna ederek (ki bu pek olası görünmüyor), onu terk ederek (şirketiniz uğruna) ya da terk ederek (akıl sağlığınız için) çözmeniz gereken bir şeydir.
Ama ilk etapta başarısızlığı çok daha muhtemeldir ve kesinlikle kanıtlaman gerekir. Ve sonra çok fazla deneyime sahip birçok insanın yaptığı gibi en iyi uygulamalara bağlı kalmaya başlayacak.

13
back2dos

Bu tamamen yalnız mı, yoksa ekip içinde mi çalıştığımla ilgili.

Eğer bir takımda çalışırsam, bazı sözleşmeler ve anlaşmalar gereklidir - takımdaki herkes bazı bazı çabalarının uyumlu olması için ortak hedefe yönelik çalışma konusunda ortak bir mutabakata varılan standart.

Ama eğer yalnız çalışırsam, o zaman elbette bir kovboy olmak istiyorum. Dünyadaki tüm büyük kreasyonlar, tek bir zihin veya en fazla iki çalışan kovboy tarzı tarafından icat edilmiştir. Sadece birkaç isim:

  • Klasik mekanik? Kovboy Isaac Newton, daha sonra Leibniz, Lagrange, Hamilton'dan eklemeler.
  • Uçak? Kovboylar Wright.
  • Görecelilik teorisi? Kovboy Albert Einstein.
  • Bilgisayarların temel bilimi? Kovboy Alan Turing.
  • Transistör? Walter Brattain ve John Bardeen tarafından yapılan kovboylar.

Takımlar, artımlı iyileştirmeler yapma ve kanıtlanmış tariflere dayanan yeni sistemleri oldukça hızlı bir şekilde bir araya getirme konusunda iyidir (iyi yönlendirilmeleri koşuluyla), ancak bir ekip tarafından yapılan gerçek bir icattan haberdar olmak nadirdir. Takım çalışması ve gerektirdiği yöntemler erdemlere sahiptir, ancak kovboy kodlaması da vardır.

11
Joonas Pulakka

Soruna bağlıdır. İyi bir üst düzey geliştirici, çok kararlı, basit ve sağlam bir kod yazacak ve dokümantasyon sayfaları ve tonlarca farklı desen ve paradigma çalkalamadan tüm en iyi uygulamaları kullanacaktır. Ancak bu tür şeyleri ne zaman yapabileceğini de bilecek.

Yeni bir sorun çıkarır ve sıfırdan insan ayları gerektiren bir uygulama tasarlamaya başlarsa şok olurdum. Ama eğer 2 saat içinde yazabileceğiniz bir eklenti, basit bir araçsa, biraz dönüşüm yapan ve yeniden kullanım için tasarlanmamış bir işlev, tasarım ve desenler aslında sadece zaman kaybetmek için iyidir.

Ayrıca, tasarımın büyük bir kısmının zaten üst düzey geliştiriciler kafasının içinde bir arka plan iş parçacığında işlendiğini tahmin ediyorum.

Üst düzey geliştirici karmaşık bir sistemin sınıflarını veya yeni uygulamaları sıfırdan ve planlama aşaması olmadan çalkalamaya başladığında endişelenmeye başlamalısınız.

7
Coder

Koşullara bağlıdır. Örneğin, bazı felaket ticaret skandallarından sonra, birkaç elektronik borsa, tüm işlemlere otomatik ticaret bayraklarının eklendiğinde ısrar etti. Ve bu bir hafta içinde tüm ticaret yazılımları için olmalı. Yani yapılması gerekiyordu - bayrak orada olmasaydı ticaret yapamazdınız. Bu gibi durumlarda, tüm iyi uygulamalar yönetim kurulu tarafından yürütülür. Ve bu durumlarda, kodu hızlı ve doğru bir şekilde yazmak çok önemlidir. Özellikle hiçbir test sistemi bulunmadığından.

6
Neil Butterworth

Deneyimlerime göre, kaynak kontrolü İLE kodlama inek çocuk büyük yazılım sistemleri geliştirmek için en iyi ve en hatasız yoludur.

5
jojo

Bu tür bir kişiye hacker denir ve genellikle aramızdaki daha profesyonel bir terim değildir.

Fark ettiğiniz gibi, hata ayıklamada tasarım, organizasyon ve kontrolde tasarruf edilen zaman kaybedilir. Ve genellikle hangi kod sürümünün gerçekten gönderilen kod olduğunu bulmak için. Eğer hiç bulabilirsen!

Bu tür bir insanın kendi içinde çok fazla sarıldığını düşünüyorum, başkalarının acı çekmesi gereken 'sınırlamalarla' çalışmak için çok iyi olduklarını düşünüyorum ve bu yüzden onlarla uğraşmayın ve bu, ekibin peşinden temizlenmesi gerekiyor. Ayrıca hata düzeltme sürecine çok fazla dahil değiller ('l33t kodlayıcısının becerilerinin ve yeteneklerinin altında bir bakım geliştiricisinin görevi).

Yani, başka bir yerde ortak bir yaklaşım olabilir, ama benim yerimde (ve bu yaklaşıma eğilimi olan kıdemli bir kodlayıcıyım ahem) buna maruz kalmıyoruz. Bir ton süreç ve prosedür talep etmiyoruz, ancak minimum miktarda organizasyon, kaynak kodu kontrolü konusunda ısrar ediyoruz (dürüst olmak gerekirse kanlı doğu ve lanet olası!)

Kent Beck et al, eski süreç yüklü yolların kendi başlarına kötü olduğunu gören profesyoneller, bu yüzden kodlamayı organize etmek için hala daha zanaat odaklı tutup yeni herkese anlattılar ve sonra herkese söylediler bu konuda - kitap yayınlayarak (bunu İnternet'ten önce nasıl yaptınız?)

Kulağa doğru sahipmişsiniz gibi geliyor - sadece başkaları hackleyemediği için kötü uygulamayı kabul etmeyin. Takım lideriniz veya menajeriniz bu 'rockstar'da zorlanmalı, ama eğer değillerse .. iyi, bu hala doğru şeyi yapmanıza engel olmaz. Sadece ondan kalitesiz uygulamayı kabul etmeyin, eğer vidalanırsa (ve yapacak!) Sonra temizlemesine izin verin. Kodlama verimliliğinizin zarar görmesine izin vermeden iyi uygulamalara bağlı kalırsınız (ve ne olduklarını bilirsiniz) ve gelecek için iyi olursunuz.

İşte bir deneme gerçekten anlayışlı bir yazardan. Sorununuzu çözmez, ancak bunun neden böyle olduğuna dair birkaç fikir verir ve profesyonel olarak bununla başa çıkmak için birkaç ipucu verir.

4
gbjbaanb

Bence yorumculardan biri haklıydı - hepsi sonuçlarla ilgili.

Kişi iyi bir ürün üretebiliyorsa - yapması gereken şeyi yapan ve sürdürülebilir ve güvenilir - resmi metodolojiler veya süreçler takip edilirse ne önemi var? ? Süreçler kaliteyi sağlamak için harikadır, ancak birisi zaten o katın üzerinde çalışıyorsa, işlemler denkleme hiçbir şey eklemez. Bu günlerde çok fazla geliştirici, imo, programlamanın nokta sürecinin, üretim iyi bir ürün yerine süreçlere bağlı olduğunu düşünüyor.

4
GrandmasterB

Cevabımda biraz içgörü bulabilirsiniz Açıkçası, kovboy kodlamayı tercih ediyor musunuz? Sorun şu ki, "kovboy kodlama" farklı insanlar için farklı şeyler ifade ediyor ve eğitimsiz göz için hemen belli değil, hangi sürümü görüyorsunuz.

Birisi bir soruna bakıp hemen kodu hızlı ve doğru bir şekilde bantlamaya başlayabildiğinde, bu mayıs bunu daha önce bin kez görmüş ve zaten en iyisini bilen bir usta mühendisin işareti olabilir. sorunu çözmek için bir yol.

Ya da, sıradan bir amatörün işareti olabilir.

Size bir şey söyleyeceğim: Çok "akademik" oldukları için sürüm kontrolü kullanmayı veya test yazmayı reddetmek kesinlikle değil "kıdemli" veya hatta uzaktan profesyonel bir yaklaşımdır. Bu tür şeylerin Microsoft veya Google gibi büyük bir yazılım mağazasında yapıldığını asla görmeyeceksiniz ve muhtemelen çoğu girişimde veya makul ölçüde olgun kurumsal ekiplerde görmeyeceksiniz.

Riskler çok büyük. Bilgisayarınız bir gecede ölürse ne olur? Güle güle 3 yıllık verimlilik. Tamam, böylece yedeklemeler yaparsınız; büyük bir değişiklik yaptığınızda, bunun tamamen yanlış olduğunu fark ettiğinizde ve geri döndürmeniz gerektiğinde ne olur? Bu, en deneyimli ve yetenekli geliştiricilerin bile başına gelir çünkü gereksinimler yanlıştır. Herhangi bir sürüm kontrolü kullanmıyorsanız, sadece tekerleklerinizi çamurda döndüreceksiniz. Ben orada, bir kez oldum ve asla geri gitmek istiyorum.

Sadece bir mazeret yok - bir depo kurmak 10 dakika ve taahhütte bulunmak 10 saniye sürüyor. Toplam geliştirme sürenizin% 1'ini oluşturur. Aceleniz varsa, testler günde 20-30 dakikaya kadar kolayca atılabilir ve yine de oldukça yararlı olabilir.

Ben Agile (başkent A'ya dikkat) metodolojilerinin hayranı değilim ama bazen sadece kollarınızı toplamanız ve lanet kodunuzu yazmaya başlamanız gerekir. "Analiz felci" olan insanları ve ekipleri gördüm ve üretkenlik gerçekten gözle görülür bir darbe alıyor. Ancak revizyon kontrolü ve testler gibi ticaretimizin temel araçlarının işten çıkarılması benim için gerçekten katılıyor; bu kişi kıdemli bir konuma ait değildir.

3
Aaronaught

Tek önemli gerçek, ekibin uzun vadeli ürün sonuçlarıdır.

Harika bir programcı (veya daha fazla) içeren bir takımın, ortalama bir oranda kodlayan daha fazla sayıda ortalama programcıya sahip bir takımdan daha iyi sonuçlar üreteceği iddiası vardır.

Kovboy, düzenli programcıların yapmadığı şeyler üretiyorsa (belirli bir süre veya spesifikasyon için) ve kovboylu ekibin kovboyun dağınıklığını temizlemek için birkaç adam hafta/ay harcamak zorunda kalması durumunda, yine de daha iyi sonuç daha erken.

Kovboylu takım, birçok ay/yıl sonra bile karışıklığı temizleyemezse (belge, hata ayıklama, entegre etme, bakımını yapamazsa), kovboyun yarattığı ilerlemeler takıma uzun vadede avantaj sağlamaz.

Hangisine karar verin ve ekibin kadrosunu optimize edin.

Sonuç iyi olduğu sürece her programcı aynı şekilde çalışmaz (ya da çalışmalıdır).

3
hotpaw2

"Geleneksel" metodolojileri düşündüğümde, "yönetimin geliştiricileri nasıl anlayacağını bilmediğini düşünüyorum, bu yüzden geliştiriciler dünyasına gelip neler olup bittiğini bilecek kadar anlamak yerine geliştiricilerin dünyalarına gelmelerini sağlıyor".

Temel olarak, "Çevik" diye düşündüğümde, "birlikte çalışan birden çok kişinin getirdiği verimsizlikleri en aza indirmek için yapmanız gerekeni yapıyorsunuz" diye düşünüyorum. Bu yüzden sıkıca kamptayım " Çevik Metodoloji , sadece bir dizi değer ve prensip ".

Başka bir deyişle, çok büyük bir projede yapmanız gereken şeyler vardır ve küçük projelerde yapmanız gereken şeyler vardır ve her ikisinde de yapmanız gereken şeyler vardır.

Örneğin, kendim üzerinde çalıştığım bir proje için en basit biriktirme birikiminden daha fazlasına sahip olmazdım ... Sadece yapılacaklar listesi olurdu. Eğer ikimiz varsa, muhtemelen bu listeyi paylaşırdım, ama çok basit bir formatta (muhtemelen sadece kod depomuzda saklanan bir not). Bir kez 3 veya 4 var, ben bir tür iş öğesi sistemi arıyorum.

2
MIA

Evet, ancak ne zaman YAPILMAMASI gerektiğini bilmelisiniz.

Küçük bir şey üzerinde muhtemelen iyi, ama karmaşık, tehlikeli, kısıtlı, vb. Bir şey varsa, uygun bir tasarım ekstra zaman değerinde olduğunu bilmek gerekir.

Ayrıca Aaronaught'un cevabı aracılığıyla kesinlikle düşünmeniz gerektiğini düşünüyorum. Kovboy farklı insanlar için farklı şeyler ifade eder.

2
Bill

Onun tarzı için hoşgörüsüzlüğün onu biraz yanlış tanıttığına inanıyorum. Kovboy yaklaşımı hata ayıklamada ödenir - zaten olan bu mu yoksa nasıl oynayacağına dair varsayımınız mı?

Adil açıklama - Ben kendim kıdemli bir geliştiriciyim ve genellikle tasarım ve deneyim için resmi bir süreçten vazgeçiyorum. Sorun alanında çok deneyimli biri için resmi bir sürece sahip olmamak oldukça yaygındır. Düzinelerce kez bir problemi çözdüyseniz, benzer bir çözümü tekrar formüle etmek için resmi bir sürece ihtiyacınız yoktur.

Resmi bir süreç kod tasarımı ile ilgilenir - resmi bir süreç eksik olduğu için neden daha fazla hata getirilmesi gerektiğini anlamıyorum. Hesabınızda okuduğum tek büyük sorun, revizyon kontrolünün kullanılmaması - ki bu sadece bencil değil, geliştirici adına düpedüz pervasız. Aslında hiç taahhüt etmiyor mu, yoksa sadece beğeninize göre bir desende değil mi?

Tasarımda resmi bir yaklaşıma sahip olmam, kitabımda 'kovboy kodlaması' değil (revizyon kontrolü kullanmamak olsa da). Deneyim tam olarak bunun için kullanılmalıdır - 'yeterince iyi' bir çözüm bulmak için gereken zamanı azaltmak için. Unutmayın, şu anda sahip olduğunuz sorunları çözmeniz ve kodun kolayca değiştirilmesini sağlamalısınız, asla gerçekleşmeyecek gelecek senaryoları için tasarlamalısınız. Deneyim ile bunu nasıl çok hızlı yapabileceğiniz hakkında iyi bir fikir edinirsiniz.

1
Eran Galperin

İki kamp var gibi görünüyor - sonuçları tercih edenler ve ilkeleri tercih edenler. Ben ikincisine düşüyorum.

Ben vasat ama tartışmasız vicdani bir programcı - kodlama benim ana endişe, ötesinde işi halletmek, ben onların işimi yapmak için kodumu kullanan kim yardımcı olduğunu. Bunu her zaman başardığımı söyleyemem - ama bunu yapmayı hedefliyorum.

Elbette, mayıs takımınızda bir hotrodunuz var - ancak birkaç hafta izin aldıklarında ve işlerinizde hata ayıklamanız veya bir şeyler eklemeniz istendiğinde ne olur? Sonuçta, kovboy programcıları takım oyuncusu değildir. Harika kodlar yapabilirler, ancak takım onlara bağlıysa - o zaman tehlikelidir.

1
sunwukung

Sadece çok basit özelliklerin prototipini oluştururken.

Sonra bir kez yapılır ve doğru şekilde kabul, kodu hendek ve ciddi olsun.

1
Klaim

Bir kez gerçek bir projede yaptım (Samurai Programlama olarak adlandırdığımız zaman, Saturday Night Live'daki Samurai Tailor serisi çizimlerinden sonra) ve hayretlerime göre çok işe yaradı. Tabii ki, başladığım çöp oldu, bu yüzden daha da kötüleşme riski azdı.

Ancak, kalbimdeki "temiz" biriyim ve kalçadan çıkma gelişim tarzından hoşlanmıyorum.

Öte yandan, ağır süreç yüklü modus operandi de benim zevkime göre değil. Ben harekete geçmeden önce plan yapmayı seviyorum.

Sonuçta, uygun resmi işlem miktarının büyük ölçüde projenin büyüklüğüne (kodun boyutu, proje süresi, geliştirici sayısı, gereksinim türleri, vb.) Bağlı olduğunu hissediyorum. Aviyonik veya biyomedikal ekipman için yazılımı geliştiren kişilere titizlik ve katı kriterler verilmesini istiyorum, ör. Oyunlar için, örneğin, herhangi bir başarısızlığın çok daha az tarafı vardır, bu nedenle titiz ve metodik geliştirme uygulamalarının maliyeti ve yükü gerçekten haklı değildir.

1
Randall Schulz

Projenin büyüklüğüne (büyük ölçüde) bağlıdır. Bir yandan, iyi bir sonuç almak için bir tasarıma sahip olmanız gerekir. Öte yandan, proje, tasarımın tamamını yazmadan, diyagram çizmeden, vb. Olmadan kavramsallaştırabileceğiniz kadar küçükse, muhtemelen ekstra bir iş yapmadan da iyi durumdasınız demektir. yaptığınız her şeyi belgelemek.

Neredeyse herkes ne yaptığınız ve işlerin nereye gittiğine dair net bir fikir olmadan atlamaya çalışmanın bir felaket tarifi olduğunu anlayacak kadar korku hikayesi duymuştur. Daha nadiren vurgulanan şey, bunun tersinin aynı derecede felaket olabileceğidir. Örneğin, çoğumuz programlama sürecinde rutin olarak küçük araçlar yazıyoruz. Eksiksiz bir şartname, test, dokümantasyon yazmak genellikle faydalı değildir. Aşağıda, ürünleştirmenin değerli olmadığı bir eşik var - insanlar tekerleği yeniden icat etmekten hoşlanmazlar, ancak bazı durumlarda yeniden icat etmekten daha kolaydır.

Bu gibi durumlarda, genellikle değerinde olan, bunun gibi görevleri kolaylaştırmak için bir kitaplık üretmektir. Bununla birlikte, ön uç kodu genellikle o kadar önemsiz hale gelir ki, istediğiniz şeyi yapmak için kod yazmak (veya değiştirmek), istediğiniz şeyi yapmak için tam bir programın nasıl elde edileceğini sıralamaktan daha kolay hale gelir. Örnek olarak, gnu, birçoğu çeşitli ince yollarla etkileşime giren 50'den fazla farklı bayrağıyla girintiyi düşünün, bu yüzden sadece makul seçenekler hakkında 1) hiç kullanmayın veya 2) size verdikleri şeyi beğenmeye karar verin aslında istediğini elde etmeye çalışmak yerine.

1
Jerry Coffin

Kovboy kodlamanın üst düzey bir yaklaşım olduğunu düşünmüyorum.

Diğerlerinin söylediği gibi, sürüm kontrolünü atmada gerçek bir tehlike var. Belgeleri ve analizi atlamak, kullanıcının istemediği bir şeyin teslim edilmesinin de riskli olduğu anlamına gelebilir. Sadece benim düşüncem, ama tek yaptığınız kovboy kodu ise "kodlayıcıdan geliştiriciye" gittiğinizi sanmıyorum.

Ancak evet, Neil Butterworth'un bahsettiği istisnalar var. Ve bu durumlarda, kovboy kodlaması yapmak zorunda olan deneyimli bir üst düzey geliştiriciye sahip olmayı tercih ederim.

0
Bernard Dy

Gönderinizi ilginç buluyorum. Sık sık konunuzla görüşlerini paylaştım ve onun hissi, aşırı resmileştirilmiş yöntemlerin boğucu olduğudur. Başka birinin belirttiği gibi, eğer bir dahiyse ve aynı anda çok sayıda zihinsel notu unutmadan veya karışmadan izleyebiliyorsa, monolitik kıvrımlı kod yığınını korumak ve tamamen belirsiz değişikliklerle inanılmaz şeyler yapmasını sağlamak oldukça mümkündür. . İnsanların beynine gelen, bunu yapabilen belirli bir zihinsel mutluluk var - bu, zihninizde küçük bir evrenin tanrısı olmak gibi.

Bununla birlikte, akıllı işverenler, orijinal yazardan başka hiç kimsenin bu kod için değerli bir şey yapamayacağını öğrendi. Programcı devam ederse, tek seçeneğin yeniden yazmak olduğunu anlayarak çok para harcıyorlar (bunun toplam kayıp anlamına geldiğini düşünürdüm, ama bu günlerin içsel sonucunu yok etmediğini anlıyorum. dış işlevsellik düzeyinde yinelemeli geliştirme).

Şahsen, ekipte böyle birine sahip olmayı umursamıyorum, çünkü bir çatırtıda kimsenin düşünmediği bir şey yapabilirler.

Öte yandan, kendi kişiniz olun ve sorunuzun cevabının ne olduğuna kendiniz karar verin, çünkü kesin olan tek şey hiç kimse yazılım geliştirme söz konusu olduğunda bunu çözmüş olmasıdır. Onu ilginç bir alan yapan şeylerden biri ...

0
Aaron Anodide

Kovboy programlama bir büyük çamur top oluşturmak için oldukça emin bir yoldur. Bu, göründüğü kadar nahoş, teslim etme eğilimi ...

0

Yeni programcılar, bir projenin/kapsamların çok fazla deneyime sahip olamayacaklarını veya bir patronun baskısı nedeniyle "sadece işleri halletmeye" çalıştıklarında bazı kovboy kodlama şeyleri yapma eğiliminde olduğunu düşünüyorum Kesinlikle birkaç kez bu yoldan gittiğimi biliyorum, çünkü kullanmak için uygun kalıp bilgisine sahip değildim ve sadece "yolumdan hacklendim".

Ben ve şikayet ettiğiniz kişi arasındaki fark, genellikle daha kısa bir süre sonra daha iyi yapabileceğimi ve daha sürdürülebilir hale getirebileceğimin farkına vardığım ve genellikle daha fazla bilgi edinmem ve becerilerimi geliştirmem için beni teşvik ediyor. bağlıdır). Bu saldırıya uğramış çözümlerin bazılarını hata ayıklamaya geri döndüğümde genellikle bir acı olduğunu görüyorum ve bunu "doğru yol" ile nasıl yapacağımı öğrenmek istememe daha fazla katkıda bulunuyor. Sanırım tanımladığınız bu kişi temelde çocuksu bir kendini yansıtma seviyesinde sıkışmış ve kendi egolarının bir yazılım geliştiricisi olarak becerilerini geliştirme yoluna girmesine izin vermek, çalışmak istediğim biri gibi görünmüyor.

0
programmx10

Hayır asla.

Her zaman ihtiyaç analizi yaparım, mimariyi düşünürüm, ayrıntıları tasarlarım ve sonra kodlarım. Kişisel bir proje için evde yalnız çalışsam bile.

Ve eğer bir kovboy tarzında çalışıyorsa ekibimde bir geliştiriciyi hemen kovardım. Biz mühendisiz ve müşteri ve kullanıcılarla ilgili bir sorumluluğumuz var.

0
CesarGon