Açıkçası, Kovboy kodlamasını tercih ediyor musun? [kapalı]

Agile, Waterfall, RUP, vb. Gibi metodolojileri savunan programcıların çoğu, bazıları metodolojiyi izler ama hepsini değil. Açıkçası, eğer metodolojiyi seçebiliyorsanız, kesinlikle ana akım "doğru" metodolojilere gidersiniz veya kovboy programlaması gibi "kolay" metodolojiyi mi tercih edersiniz? Neden?

Buna bağlı olduğunu biliyorum. Lütfen birini ne zaman kullanacağınızı açıklayın. Lütfen, Kovboy kodlamasında hangi avantajları gördüğünüzü söyleyin.

Hakkında Bkz Kovboy kodlama Wikipedia'da

Neredeyse her deneyimli programcının üç aşamadan geçtiğini ve bazılarının dördüncü aşamaya gittiğini düşünüyorum:

1. Kovboy kodlayıcıları veya külçeleri tasarım hakkında hiçbir şey bilmez ve gereksiz bir formalite olarak görürler. Teknik olmayan paydaşlar için küçük projeler üzerinde çalışıyorsanız, bu tutum bir süre için onlara iyi hizmet edebilir; İşleri halleder, patronu etkiler, programcının kendisi hakkında iyi hissetmesini sağlar ve ne yaptığını bildiği fikrini doğrular (olmasa da).

2. Mimarlık Astronotları , ilk iplik yumağı projelerinin değişen koşullara uyum sağlamadaki başarısızlıklarına şahit oldular. Her şey yeniden yazılmalı ve ileride başka bir yeniden yazma ihtiyacını önlemek için iç platformlar oluşturmalı ve günde 4 saatini desteklemeye harcamalı çünkü başka hiç kimse onları nasıl doğru kullanacağını anlamıyor.

3. Yarı-mühendisler genellikle gerçek , eğitimli mühendisler için hata yaparlar çünkü gerçekten yetkindirler ve bazı mühendislik prensiplerini anlarlar. Altta yatan mühendislik ve iş kavramlarının farkındalar: Risk, YG, UX, performans, bakım kolaylığı, vb. Bu insanlar tasarım ve dokümantasyonu bir süreklilik olarak görürler ve genellikle mimari / tasarım seviyesini proje gereksinimlerine uyarlayabilirler.

   Bu noktada birçoğu Çevik, Şelalesi, RUP, vb. Metodolojilere aşık olurlar . Gerçek yazılım mühendisliği alanında gerçek anlamda bir araç olduğunun farkında olmadan, bu metodolojilerin mutlak yanılmazlığa ve hatta gerekliliğine inanmaya başlarlar. , dinler değil. Ve ne yazık ki, bu onların son aşamaya gelmelerini önler, ki bu:

4. Koli bandı programcıları AKA guruları veya yüksek ücretli danışmanlar , proje gereksinimlerini dinledikten sonra beş dakika içinde hangi mimariyi ve tasarımı kullanacaklarını bilir. Tüm mimari ve tasarım çalışmaları hala devam ediyor, ancak sezgisel bir seviyede ve o kadar hızlı gerçekleşiyor ki eğitimsiz bir gözlemci kovboy kodlaması için hata yapacak - ve çoğu kişi bunu yaptı .

   Genel olarak, bu insanlar “yeterince iyi” bir ürün yaratmakla ilgilidir ve bu yüzden çalışmaları biraz daha az mühendis olabilir, ancak kovboy kodlayıcıları tarafından üretilen spagetti kodundan mil uzaktalar. Nugget'lar bu insanlara onlar hakkında söylendiklerinde bile tanımlayamazlar , çünkü onlar için, arka planda gerçekleşen her şey mevcut değildir.

Bazılarınız soruyu cevaplamadığım bu noktada muhtemelen kendinize düşüneceksiniz. Çünkü sorunun kendisi hatalı. Kovboy kodlaması bir seçim değildir , bu bir beceri seviyesidir ve okuma yazma bilmeme seçeneğinden daha fazla bir kovboy kodlayıcısı olmayı seçemezsiniz.

Eğer bir kovboy kodlayıcısıysanız, başka yol bilmiyorsunuz demektir.

Bir mimari astronot olduysanız, fiziksel ve psikolojik olarak tasarımsız bir yazılım üretemezsiniz .

Eğer yarı-mühendis (veya profesyonel bir mühendis) iseniz, o zaman çok az veya hiç hazırlıksız tasarım çabasına sahip bir projeyi tamamlamak (genellikle saçma süreleri nedeniyle) bariz risklere karşı tartılması ve üstlenilmesi gereken bilinçli bir seçimdir. sadece paydaşların kabul etmesinden sonra (genellikle yazılı olarak).

Eğer bir koli bandı programcısıysanız, o zaman "kovboy kodunu" uygulamak için hiçbir neden yoktur, çünkü kaliteli bir ürün kadar çabuk üretebilirsiniz .

Hiç kimse kovboyun diğer metodolojileri kodlamasını "tercih etmiyor" çünkü bir metodoloji değil. Bir video oyunda mashing düğmelerinin yazılım geliştirme eşdeğeri. Yeni başlayanlar için sorun yok, ancak o aşamadan geçen herkes bunu yapmaz. Benzer görünen bir şey yapabilirler ama aynı şey olmayacak.

Evet.

Çoraplarımı çektiğim yerde bırakmayı, masamın çıktılarını ve eski atıştırmalık paketleyicileri, kirli bulaşıklarla dolu lavabomu ve yatağımı yapmamayı tercih ediyorum.

Önceden planlanmış bir tatilin uygun bir tatil olduğunu, uygun beslenmeye yönelik doğru gıdaya dikkat edilerek yenen bir öğeyi veya bilinen yürüyüş parkurlarında uygun yürüyüş yapmayı düşünmüyorum.

Eğlenmeyi, şaşırtmayı, yeni şeyler öğrenmeyi, hatalar yapmayı ve geri dönüp başaramayacağımı asla bilemiyorum. Ve bazen, bu tutum tam olarak yerden bir proje almak için gerekli olan şeydir ...

... ama çoğu zaman, sadece sorumsuzluk olur. Dans sona erdiğinde, pipere ödeme yapılır ... Bunu tehlikeye atarsın.

Tamamen haklısın. Bu "kovboy programlaması" yaklaşımı, kodun ilk revizyonunu daha hızlı yapabilir, ancak aşağıdakiler sayesinde zamandan tasarrufun kaybedilmesi daha fazla olacaktır:

• Ek hatalar
• Zaten böcek olurdu bulmak için gerekli ek süre
• Altı ay içinde değişiklik yapmanız gerektiğinde ne yaptığınızı hatırlamak için kodunuzu tersine çevirmek zorunda
• Kodunuz üzerinde çalışması gereken ek geliştiricileri eğitmek için ekstra zaman harcandı
• Bir şeyleri kıran bir değişiklik yaptığınızda geriye dönecek bir revizyon günlüğüne sahip olmamak
• Modül kullanmamak, sonraki projelerde kolayca yeniden kullanabilirsiniz
• Ve açık ve açık ve açık

Neil Butterworth'un cevabında bahsettiği gibi, bazen yapman gerekeni yapmalısın. Genel bir uygulama olarak, hayır, kaynak kodu kontrolü, kalıpları, dokümantasyonu vb.

İş arkadaşlarınızı analiz etmek ve alışkanlıklarını yaptıkları gibi yapmak yerine kör ya da zararlı olup olmadıklarını düşündüğünüz için iyi.

Bu gerçekten, sıkı bir yapıya sahip olmadan ve planlamada tüketilen çok zaman olmadan işleri doğru bir şekilde uygulayıp uygulayamayacağınız sorusuyla ilgilidir.

Buraya gerçekten sevilmeyen bir şey fırlatacağım: müşteriler genellikle kovboy tarzında işlenen şeyleri isterler .

Yani, bir şeyin yapılmasını istemek ve birisinin üzerine atlatmasını, yürütmesini ve oraya çıkarmasını istiyorlar. Proje yönetimi, toplantılar, konferans görüşmeleri veya formlar yoktur. Sadece yap. "Hey, bu bizim zevklerimiz için çok hızlı bir şekilde yapıldıysa, bir dahaki sefere biraz şelale ya da başka bir şey koyarsanız memnun oluruz" derim.

Ekip metodolojileri ve yapısı, bir projenin oyun alanını aynı seviyeye getirmek ve aynı şekilde aynı amaçlarla çalışan aynı sayfada farklı seviyelerde geliştiriciler elde etmek için tasarlanmıştır.

Çalıştığım başarılı “kovboylar” şunları yapabilir:

• Hızlı bir şekilde uygulamak için en basit yolu tanımlayın
• Hangi noktada kırılacağını bilmek
• Temiz, okunabilir ve anlaşılır kodlar yazın
• Kullanıcıların onu nasıl kullanacağını, kötüye kullanacağını ve kırdığını tahmin edin
• Ölçekle / doğru yerlerde soyutla ve mimarlık astronotuna gitme
• Son vakaları ve istisnaları nerede ve nasıl ele alacağınızı bilin

Bu gibi insanlar çok az yönetim ve ek yükü ile gerçekten harika sonuçlar üretir, ancak nadirdir.

EDIT: Gelecekte referans olması için cevabım, bununla birleştirilen başka bir soru için . Burada oldukça eski, ama bu benim çağrım değildi.

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

Yani, alışılmadık ya da belki eski bir metodoloji kullanmıyor. Sadece bilinçli olarak hiçbirini kullanmıyor . Standart yok. Kalite güvencesi yok. Hiçbir şekilde. Yazılım kalitesinin nereden gelmesini bekliyor? Ağaçlar?
Gerçekten de, açıkça açıkça görmezden geldiğinde, teklif ettiğiniz kişilerin deneyimini reddetmesi komik. Taleplerini sorgulamak için doğrulanabilir ve ilgili argümanlar sunmak geçerlidir. Ancak sadece deneyimlerini inkar ederek onları itibarsızlaştırmaya çalışmak değildir.

Ancak asıl konu şudur: Sürüm kontrolü ne kadar zaman alır?
Her seferinde 5 saniyeyi yatırmaya ikna edemiyorsa, patronuna götürmelisin. Sürüm kontrolü isteğe bağlı değil. Tam dur.

Ve sürüm kontrolünü kullanmasını sağladıktan sonra, hangi hataların ortaya çıktığını kolayca takip edebilirsiniz. Ve izin onu bunları düzeltmek. Bu onun pisliği, neden temizlemelisin? Eğer yaklaşımının daha iyi olduğunu düşünüyorsa, bırakalım - tamamen .
Aslında (makul bir süre içinde) yapabileceğini varsayarsak, hala bir problemin var: onunla takım çalışması imkansız. Ve bu, onu ikna etmek (olası görünmeyen), ayrılmak (şirketinizin uğruna) veya terk etmek (aklınız uğruna) için çözmeniz gereken bir şeydir.
Ancak ilk etapta başarısızlığı çok daha muhtemeldir ve kesinlikle amacınızı kanıtlamalıdır. Daha sonra, birçok deneyimi olan birçok insanın yaptığı gibi, en iyi uygulamalara bağlı kalmaya başlayacaktır.

Tamamen solo çalışmakta mı yoksa takımda mı çalışmam gerektiğine bağlı.

Bir ekip çalışıyorsanız, bazı sözleşmeler ve anlaşmalar gereklidir - takımda herkesin izlemesi gereken bazı çabalarının uyumlu olacak şekilde ortak bir hedefe doğru çalışması için yaygın olarak kabul edilen bir standart.

Ama eğer yalnız çalışırsam, elbette bir kovboy olmak istiyorum. Dünyadaki tüm harika kreasyonlar, tek bir zihinle veya en fazla iki çalışan kovboy tarzında 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? Kovboylar Walter Brattain ve John Bardeen.

Ekipler, artımlı iyileştirmeler yapmada ve kanıtlanmış tariflere dayalı olarak yeni sistemleri bir araya getirme konusunda (hızlı bir şekilde yönlendirilmeleri şartıyla) oldukça iyi, ancak bir ekip tarafından yapılan gerçek bir icadı duymak nadirdir. Takım çalışması ve gerektirdiği yöntemlerin erdemleri vardır, ancak kovboy kodlaması da yapar.

Soruna bağlı. İyi bir üst düzey geliştirici, çok istikrarlı olan ve en iyi uygulamaları, dokümantasyon sayfalarında ve tonlarca farklı desen ve paradigmalarda dolaşmadan kullanan çok kompakt, basit ve sağlam bir kod yazacaktır. Ancak, bu tür şeyleri ne zaman yapabileceğini de bilir.

Yeni bir sorun çıkarsa ve erkek ayları sıfırdan başlayacak bir uygulama tasarlamaya başlarsa şok olurum. Ancak, 2 saat içinde yazabileceğiniz bir eklenti, basit bir araçsa, bir miktar dönüşüm yapan ve bir yeniden kullanım için tasarlanmayan bir işlev, tasarım ve desenler aslında zaman kaybetmek için iyidir.

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

Kıdemli geliştirici, karmaşık bir sistemin sınıflarını veya sıfırdan yeni uygulamalar planlamayı baştan sona erdirmeye başladığında endişelenmeye başlamalısınız.

Koşullara bağlı. Örneğin, bazı feci ticaret skandallarından sonra, bazı elektronik borsalar otomatik alım satım bayraklarının tüm işlemlere eklenmesinde ısrar etti. Ve bunun bir hafta içinde tüm ticari yazılımlar için olması gerekiyordu. Yani yapılması gerekiyordu - eğer bayrak orada değilse ticaret yapamazdın. Bu gibi durumlarda, tüm iyi uygulamalar yönetim kurulu tarafından gerçekleştirilir - gitmeniz gerekir (söylediğimiz gibi) "hack, hack, hack". Ve bu durumlarda hızlı ve doğru kod yazmak çok önemlidir. Özellikle mevcut test sistemleri olmadığı için.

Tecrübelerime göre, kaynak kontrolü ile kodlayan inek çocuk, büyük yazılım sistemleri geliştirmenin en iyi ve en hatasız yoludur.

Bence yorumculardan biri haklıydı - hepsi sonuçtan ibaretti.

Eğer kişi iyi bir ürün üretebilirse - yapması gerekeni yapan ve bakımı yapılabilir ve güvenilir olan bir şey - o zaman resmi metodolojiler veya süreçler izlenirse ne önemi olur? Bir zeminin kaliteli olmasını sağlamak için işlemler harikadır, ancak eğer birileri o zeminin üzerinde çalışıyorsa, o zaman işlemler denklemde hiçbir şey eklemez. Bugünlerde çok fazla geliştirici, imo, programlama noktasının iyi bir ürün üretmek yerine süreçlere bağlı kalmak olduğunu düşünüyor gibi görünüyor .

Bu tür bir insan korsan denir ve genellikle aramızdaki daha profesyonel gelen ücretsiz bir terim değildir.

Fark ettiğiniz gibi, tasarım, organizasyon ve kontrolde kaydedilen zaman hata ayıklamada kayboluyor. Ve sıklıkla hangi kodun serbest bırakıldığını gösteren kodun bulunmasında. Eğer onu bulabilirsen!

Bu tür bir insanın kendi içinde çok fazla sarılı olduğunu, başkalarının acı çekmesi gereken 'sınırlamalarla' çalışmak için iyi olduklarını ve bu yüzden onlarla uğraşmadıklarını ve diğerlerinin daha fazla zaman kaybettiğini düşünüyorum. Takım onlardan sonra temizlemek zorundadır. Ayrıca, hata düzeltme sürecine de dahil değiller (bu, 'l33t kodlayıcının yetenekleri ve yeteneklerinin de altında bulunan bir bakım geliştiricisinin görevi).

Yani, başka bir yerde ortak bir yaklaşım olabilir, ama benim yerimde (ve ben bu yaklaşıma eğilimi olan kıdemli bir kodlayıcıyım, ahem) buna maruz kalmıyoruz. Tonlarca işlem ve prosedür talep etmiyoruz, ancak asgari miktarda örgütlenme, kaynak kodu kontrolü konusunda ısrar ediyoruz (dürüst olmak gerekirse, kanlı doğu ve çok faydalı!)

Kent Beck ve ark., Eski süreç yüklü yöntemleri kendi içinde kötüyken gören tüm profesyonellerdir, bu yüzden hala zanaat odaklı tutarken kodlamayı organize etmek için yeni metodolojiler yarattılar ve daha sonra herkese anlattılar - kitaplar yayınlayarak ( İnternetten önce bunu başka nasıl yaptınız?)

Haklısın gibi ses çıkarıyorsunuz - kötü uygulamaları kabul etmeyin, çünkü başka biri hack edemez. Takım lideriniz veya menajeriniz bu 'rock yıldızı' üzerine sert bir şekilde aşağı iniyor olmalı, ama eğer yapmazlarsa ... peki, bu hala doğru olanı yapmanıza engel olmuyor. Sadece ondan ayakkabılı uygulama yapmayı kabul etmeyin, eğer batırırsa (ve yapacak!) O zaman temizlemesine izin verin. Kodlama verimliliğinizin zararına izin vermeden iyi uygulamalara (ve onların ne olduğunu bilirsiniz) bağlı kalıyorsunuz ve gelecek için iyi olacaksınız.

İşte gerçekten anlayışlı bir yazardan bir makale . Sorununuzu çözmez, ancak neden böyle olduğu hakkında birkaç fikir verir ve belki de profesyonel olarak ilgilenmeniz için birkaç ipucu verir.

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

Büyük bir programcı (veya daha fazla) içeren bir ekibin, ortalama oranda kodlayan daha fazla sayıda ortalama programcının bulunduğu bir ekipten daha iyi sonuçlar üreteceği iddiası vardır.

Kovboy normal programcıların yapmadığı şeyler üretirse (belirli bir son tarih veya şartname için) ve kovboyun bulunduğu takım bile kovboyun pisliğini temizlemek için birkaç hafta / ay harcamak zorunda kalırsa, daha iyi sonuç daha erken.

Kovboylu takım, bir kaç ay / yıl sonra bile pisliği temizleyemiyorsa (belgeleyin, hata ayıklayın, entegre edin, bakımını yapın), o zaman yaratılan kovboyun ilerleyişi ne olursa olsun takıma uzun vadede avantaj sağlamaz.

Hangisine karar verin ve takımın kadrosunu optimize edin.

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

Frankly’e verdiğim cevapta bazı bilgiler edinebilirsin, kovboy kodlamasını mı tercih edersin? Sorun şu ki, "kovboy kodlaması" farklı insanlar için farklı şeyler ifade eder ve eğitim görmemiş olan gözler için, hangi sürümü görüyorsanız, hemen belli değildir.

Birisi bir soruna bakıp hemen kodu hızlıca ve doğru bir şekilde kodlamaya başladığında, bu sorunu daha önce bin defa görmüş ve sorunu çözmenin en iyi yolunu zaten bilen bir usta mühendisinin işareti olabilir .

Veya, bir amatör rütbe işareti olabilir.

Size bir şey söyleyeceğim: sürüm kontrolü kullanmayı veya test yazmayı reddetmek, çünkü onlar da "akademik" oldukları için kesinlikle "kıdemli" değil , hatta uzaktan profesyonel bir yaklaşım. Asla, asla bu tür bir şeyi Microsoft veya Google gibi büyük bir yazılım mağazasında yapıldığını görmeyeceksiniz ve muhtemelen çoğu başlangıçta veya makul olarak olgun kurumsal ekiplerde görmeyeceksiniz.

Riskler çok fazla. Bilgisayarınız gece boyunca ölürse ne olur? Güle güle 3 yıl verimlilik. Tamam, böylece yedekleme yapıyorsunuz; Peki, büyük bir değişiklik yaptığınızda, tamamen yanlış olduğunu fark ettiğinizde ve geri döndürmeniz gerektiğinde ne olur? Gereksinimler yanlış olduğu için bu, geliştiricilerin en deneyimli ve yeteneklilerine bile olur . Herhangi bir sürüm kontrolü çalıştırmıyorsanız, tekerleklerinizi çamur içinde döndüreceksiniz. Bir zamanlar oradaydım ve asla geri dönmeyecektim.

Mazeret yok - bir havuz oluşturmak 10 dakika ve bir taahhütte bulunmak için 10 saniye sürüyor. Toplam gelişim sürenizin belki% 1'ini oluşturur. Testler, aceleniz varsa, günde 20-30 dakikaya kadar kolayca kısılabilir ve yine de oldukça faydalı olabilir.

Ben Agile (büyük harf A'ya not edin) metodolojilerinin hayranı değilim, ancak bazen gerçekten sadece kollarınızı açmanız ve lanet kodu yazmaya başlamanız gerekir. "Analiz felci" olan insanları ve ekipleri gördüm ve verimlilik gerçekten gözle görülür bir etki yaratıyor. Ancak revizyon kontrolü ve testler gibi ticaretimizin temel araçlarının işten çıkarılması gerçekten benim için gariptir; bu kişi kıdemli bir pozisyona sahip değil .

Evet, ancak ne zaman yapamayacağınızı bilmek zorundasınız.

Küçük bir şeyde muhtemelen iyisinizdir, ancak karmaşık, tehlikeli, kısıtlanmış bir şeyiniz varsa vb. Uygun bir tasarımın zamana değer olduğunu anlayabilmeniz gerekir.

Ayrıca Aaronaught'un cevabı ile kesinlikle düşünmeniz gerektiğini düşünüyorum. Kovboy, farklı insanlar için farklı anlamlara gelir.

"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 girip neler olup bittiğini bilecek kadar anlayışın yerine geliştiricilerin dünyalarına girmesini sağlıyorlar".

Temel olarak, "Çevik" diye düşündüğümde, "birlikte çalışan birden fazla insanın getirdiği verimsizlikleri en aza indirmek için yapmanız gerekenleri yapın." Bu yüzden "diye bir şey var ki kampta sıkıca olduğum Çevik Metodolojisi , değer ve ilkelerin sadece bir dizi".

Başka bir deyişle, çok büyük bir projede yapmanız gerekenler ve küçük projelerde yapmanız gerekenler 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 birikimden daha fazlasına sahip olamam ... Sadece yapılacaklar listesi olurdu. Eğer ikimiz varsa, muhtemelen o listeyi paylaşırdım, ama çok basit bir formatta (muhtemelen sadece kod depomuzda saklanan bir not). 3 veya 4'üm olduğunda, bir çeşit iş öğesi sistemi arıyorum.

Sadece çok basit özelliklerin prototiplemesi sırasında.

Sonra bir kez yapılır ve doğru şekilde değerlendirilirse, kodu alıp ciddileşirim.

Gerçek bir projede bir kez yaptım (Samurai Programlama adını verdiğimiz zaman, Saturday Night Live'daki Samurai Tailor serisinin ardından) ve şaşkınlıkla karşılaştım. Tabii ki, başladığım şey çöptü, bu yüzden daha kötü hale getirme riski çok azdı.

Bununla birlikte, kalbimdeki "temiz" bir kalitiyim ve en baştan beri süren gelişim tarzından hoşlanmadım.

Öte yandan, yoğun işlem yüklü modus operandi de benim zevkime göre değil. Harekete geçmeden önce plan yapmayı seviyorum.

Sonuçta, uygun olan resmi işlem miktarının, büyük ölçüde (kodun büyüklüğü, projenin süresi, geliştirici sayısı, gereksinim türleri vb.) Projeye bağlı olduğunu hissediyorum. Aviyonik veya biyomedikal teçhizat için yazılım geliştiren insanlara katı ve katı ölçütler uygulanmasını istiyorum, örneğin oyunlar için, örneğin, herhangi bir başarısızlığın çok daha az tarafı yoktur, bu nedenle titiz ve metodik geliştirme uygulamalarının maliyeti ve yükü gerçekten doğru, isabetli, uygun, haklı, mazur görülebilir.

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 ihtiyacınız var . Öte yandan, proje yeterince küçükse, bütün tasarımları (zaten birçoğudur) yazmadan, çizimleri vb. Çizmeden kavramsallaştırabileceksiniz. yaptığınız her şeyi belgelemek.

Neredeyse herkes, ne yaptığınız ve işlerin nereye gittiği hakkında net bir fikir olmadan atlamaya çalışmanın felaket için bir reçete olduğunu anlamaya yetecek kadar korku hikayesi duymuştur. Çok nadiren dikkat çeken, tam tersinin eşit derecede feci olabileceğidir. Örneğin, çoğumuz rutin olarak programlama sürecinde küçük araçlar yazarız. Tam bir şartname, testler, dökümantasyon yazmak çoğu zaman işe yaramaz. Aşağıda üretkenlik yapmanın değersiz olduğu bir eşik var - insanlar çoğu zaman tekerleği yeniden icat etmekten hoşlanmazlar, ancak bazı durumlarda yeniden icat etmekten kaçınmak daha kolaydır.

Bu gibi durumlarda ne sıklıkla var olan değerli bu kolay gibi görevleri yapmak için bir kütüphane ürünleştirerek edilir. Bununla, ön uç kod genellikle o kadar önemsiz hale gelir ki, istediğinizi yapmak için kod yazmanın (veya değiştirilmesinin), istediğinizi yapmak için tam bir programın nasıl alınacağını sıralamaktan daha kolay hale gelmesi daha kolay hale gelir. Örneğin, gnu, çoğu çeşitli ince şekillerde etkileşime giren 50'den fazla farklı bayrakla girintili olduğunu düşünün, bu nedenle yalnızca makul seçimler 1) hiç kullanmayın ya da 2) size ne vereceğini sevmeye karar verin aslında istediğini elde etmeye çalışmak yerine.

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

Ben vasat ama tartışmalı bir şekilde vicdanlı bir programcıyım - kodlama yaparken asıl endişem , işi bitirmenin ötesinde , THEIR işini yapmak için kodumu kullanan kişiye yardım ediyorum. Bunu her zaman başardığımı söyleyemem - ama yapmayı istediğim şey bu.

Tabii, ekibinizde bir ateşleme olabilir - ama birkaç hafta sonra ayrılırlarsa ve işlerinde hata ayıklamanız veya bir şeyler eklemeniz istendiğinde ne olur? Sonuçta, kovboy programcıları takım oyuncusu değildir. Büyük kodlar yapabilirler, ancak takım onlara bağlıysa - o zaman tehlikelidir.

Stili için hoşnutsuzluğunun, onu biraz yanlış tanıtmana yol açtığını hissediyorum. Kovboy yaklaşımının hata ayıklamada ödendiğini söylüyorsunuz - bu zaten olan şey mi, yoksa nasıl sonuçlanacağına dair varsayımınız mı?

Adil açıklama - Ben kendimi kıdemli bir geliştiriciyim ve genellikle tasarım ve deneyim için resmi bir süreçten ayrılıyorum. Sorun alanında çok deneyimli birileri için resmi bir sürece sahip olmamak oldukça yaygındır. Düzinelerce bir sorunu çö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ıyla ilgilidir - Neden resmi bir süreç eksik olduğundan 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 dikkatsizce değil. Aslında hiç bir şekilde taahhüt etmiyor mu, yoksa sadece sizin zevkinize uygun bir şekilde taahhüt etmiyor mu?

Tasarımda resmi bir yaklaşıma sahip olmamak kitabımda 'kovboy kodlaması' değildir (revizyon kontrolü kullanmamak da mümkündür). Tecrübe tam olarak bunun için kullanılmalıdır - 'yeterince iyi' bir çözüm bulmak için gereken süreyi azaltmak için. Unutmayın, şu anda sahip olduğunuz sorunları çözmeniz ve asla değişmeyecek gelecek senaryolar için tasarlamamanız, kodun değiştirilmesini kolaylaştırmanız gerekir. Tecrübe ile bunu çok hızlı nasıl yapacağınıza dair iyi bir fikir edinebilirsiniz.

Hayır asla.

Ben her zaman ihtiyaç analizi yapıyorum, mimariyi düşünüyorum, detayları tasarlarım ve sonra kodları yapıyorum. Kişisel bir proje için evde yalnız çalışsam bile.

Ve eğer bir kovboy tarzında çalışıyorsa ekibimdeki bir geliştiriciyi anında ateşlerdim. Biz mühendisiz ve müşteri ve kullanıcılarla sorumluluğumuz var.

Kovboy kodlamanın kıdemli bir yaklaşım olduğunu sanmıyorum.

Diğerlerinin dediği gibi, sürüm kontrolünü atma konusunda gerçek bir tehlike var. Belgeleri ve analizleri atlamak, kullanıcının istemediği bir şeyi riske atmak anlamına da gelebilir. Sadece benim düşüncem, ama tek yaptığınız kovboy koduysa "kodlayıcıdan geliştiriciye" gideceğinizi sanmıyorum.

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

Kovboy programlama, büyük bir çamur topu yaratmanın oldukça kesin bir yoludur . Bu, göründüğü kadar tatsız bir şekilde teslim olma eğiliminde ...

Yeni programcıların, bir patronun baskısı nedeniyle "sadece işleri bitirmeye" çalışırken ya da çok fazla deneyime sahip olamayacakları bir projeyi / kapsamları ele alırken bazı şeyleri kodlayan bazı kovboylar yapmaya meyilli olduğunu düşünüyorum. Kesinlikle birkaç kez bu yoldan geçtiğimi biliyorum çünkü kullanacağım uygun kalıp bilgisine sahip değildim ve sadece “içinden geçti.”

Şikayet ettiğiniz kişi ile benim aramdaki fark, genellikle daha sonra daha iyi yapabileceğimi ve daha iyi bir şekilde yapabileceğimin farkında olduğumdan ve genellikle daha fazla bilgi edinmem ve becerilerimi geliştirmem için beni teşvik ediyor. konu, özne). Bu hacklenmiş çözümlerden bazılarını ayıklamak için geri döndüğümde genellikle bunun bir acı olduğunu görüyorum ve bunun nasıl "doğru yolu" yapmayı öğrenmek istememe katkıda bulunuyor. Sanırım tanımladığınız bu kişi temel olarak bir çocuk yansıtma düzeyinde kendi kendine yansıma düzeyinde kalmış ve kendi egolarının bir yazılım geliştiricisi olarak becerilerini geliştirmeye çalışmasına izin veriyor, çalışmak istediğim biri gibi görünmüyor.

Görevinizi ilginç buluyorum. Sıklıkla konunuzla ilgili görüşlerimi paylaştım ve onun duygusu aşırı formalize yöntemlerin boğucu olduğu. Başka birinin belirttiği gibi, eğer bir dahi ise ve unutmadan veya kafanız karışmadan aynı anda çok sayıda zihinsel notayı izleyebiliyorsa, karmaşık bir kodun yekpare kodunu korumak ve tamamen belirsiz değişikliklerle şaşırtıcı şeyler yapmak oldukça mümkün. . Bunu yapabilen insanların beyinlerine gelen belirli bir zihinsel mutluluk var - bu zihninizde küçük bir evrenin tanrısı olmak gibi.

Ancak, akıllı işverenler, asıl yazardan başka hiç kimsenin bu koda değecek hiçbir şeyi yapamayacağını zor yoldan öğrendiler. Programcı devam ederse, tek seçeneğin yeniden yazmak olduğunu belirten çok para harcıyorlar (bunun toplam zarar anlamına geldiğini düşünürdüm, ama bu günlerin gerçek sonucunu mahvetmediğinizi fark ediyorum) dış işlevsellik düzeyinde yinelemeli gelişme).

Şahsen, takımda böyle birisinin olmasını umursamıyorum, çünkü bir sıkıntıda başka kimsenin düşünmediği bir şey yapabilirler.

Öte yandan, kendinize ait bir kişi olun ve sorunuzun cevabının ne olduğuna kendiniz karar verin, çünkü kesin olan tek şey, yazılım oluşturma konusunda kimsenin çözemediğidir. Onu ilginç bir alan yapan şeylerden biri ...