Szczerze mówiąc, wolisz kodowanie Cowboy? [Zamknięte]

66

Większość programistów broniących poprawnych politycznie metodologii, takich jak Agile, Waterfall, RUP itp. Niektórzy z nich stosują metodologię, ale nie wszyscy. Szczerze mówiąc, jeśli możesz wybrać metodologię, z pewnością poszedłbyś do głównego nurtu „poprawnych” metodologii, czy wolałbyś metody „łatwiejsze”, takie jak programowanie kowbojskie? Dlaczego?

Wiem, że to zależy. Wyjaśnij, kiedy chcesz użyć jednego lub drugiego. Powiedz, jakie korzyści widzisz w kodowaniu Cowboy.

Zobacz o kodowaniu Cowboy na Wikipedii

Maniero
źródło
13
Eksperyment przeprowadzono raz z dwiema grupami ludzi, których poproszono o zrobienie glinianych garnków w ustalonych ramach czasowych. Grupie 1 powiedziano, aby zrobili najwyższej jakości doniczkę, jaką mogli, grupie 2 powiedziano, że będą mierzone na podstawie wagi wszystkich wyprodukowanych doniczek. Jakość puli końcowej grupy 2 była wyższa niż puli grupy 1. Niestety nie udało mi się znaleźć oryginalnego źródła tego eksperymentu, ale nadrzędnym punktem jest „im większa liczba iteracji, tym lepsza jakość”. Czy byli kowboje z grupy 2? Prawdopodobnie.
czosnek Adolf
3
„Kowbojskie kodowanie” to straszny wybór słów, jeśli nic więcej. Kiedy odnosi się do ludzi w zespole, „kowboj” często oznacza coś w stylu „osoby, która po prostu robi swoje i nie dba o to, co to oznacza dla reszty zespołu”. Ale pytanie o wartość „mniej struktury” jest dobre.
MIA,
4
Myślę, że powinieneś umieścić swoją definicję programowania kowbojów (bezpośrednio) w swoim pytaniu, ponieważ zarówno strona wikipedia, jak i osoby udzielające odpowiedzi wydają się mieszane z tym, co tak naprawdę jest kodowaniem kowbojskim. Masz na myśli po prostu nie używać żadnej metodologii? Ponieważ wiele osób wydaje się myśleć, że kowbojskie kodowanie wcale nie robi projektu. Przynajmniej dla mnie oznaczało to po prostu brak formalnego procesu - nie to, że od razu przeskakujesz do kodowania. Myślę, że skoro to ty zadajesz pytanie, powinieneś je zdefiniować zgodnie z tym, co chciałeś wiedzieć.
n1ckp,
@ n1ck: Dzięki. Niektórzy ludzie po prostu wskakują w odpowiedzi, nie rozumiejąc pytania. Jest już za późno, zmiana spowoduje unieważnienie niektórych odpowiedzi. Niestety niektórzy użytkownicy nie dostali pytania. Masz to.
Maniero,
Czy ta osoba nie używa żadnego systemu kontroli źródła, czy po prostu odmawia korzystania z firmy?
Thomas

Odpowiedzi:

201

Myślę, że prawie każdy doświadczony programista przeszedł przez trzy etapy, a niektóre przechodzą przez cztery:

  1. Kowbojscy koderzy lub samorodki wiedzą niewiele o projektowaniu i postrzegają go jako niepotrzebną formalność. W przypadku małych projektów dla nietechnicznych interesariuszy takie podejście może im służyć przez chwilę; robi rzeczy zrobione, robi wrażenie na szefie, sprawia, że ​​programiści czują się dobrze i potwierdzają pomysł, że wie, co robi (chociaż tego nie robi).

  2. Architektura Astronauci byli świadkami niepowodzenia swoich pierwszych projektów z przędzą kulkową, aby dostosować się do zmieniających się okoliczności. Wszystko musi zostać przepisane i aby uniknąć potrzeby kolejnego przepisywania w przyszłości, tworzą one wewnętrzne platformy i spędzają 4 godziny dziennie na wsparciu, ponieważ nikt inny nie rozumie, jak z nich właściwie korzystać.

  3. Quasi-inżynierowie często mylą się z rzeczywistymi , przeszkolonymi inżynierami, ponieważ są naprawdę kompetentni i rozumieją niektóre zasady inżynierii. Są świadomi podstawowych koncepcji inżynieryjnych i biznesowych: ryzyka, ROI, UX, wydajności, łatwości konserwacji i tak dalej. Ci ludzie postrzegają projekt i dokumentację jako kontinuum i zwykle są w stanie dostosować poziom architektury / projektu do wymagań projektu.

    W tym momencie wielu zakochuje się w metodologiach, bez względu na to, czy są zwinni, wodospad, RUP itp. Zaczynają wierzyć w absolutną nieomylność, a nawet konieczność stosowania tych metod, nie zdając sobie sprawy, że w rzeczywistej dziedzinie inżynierii oprogramowania są jedynie narzędziami , nie religie. I niestety uniemożliwia im to przejście do końcowego etapu, którym jest:

  4. Programiści taśmą klejącą AKA guru lub wysoko opłacani konsultanci wiedzą, co architektura i design idą do wykorzystania w ciągu pięciu minut po wysłuchaniu wymagań projektowych. Wszystkie prace związane z architekturą i projektowaniem wciąż trwają, ale dzieje się to na poziomie intuicyjnym i dzieje się tak szybko, że niedoświadczony obserwator pomyliłby to z kodowaniem kowbojskim - i wiele osób tak robi .

    Generalnie ci ludzie są o stworzenie produktu, który jest „wystarczająco dobre”, a więc ich prace mogą być trochę pod inżynierii, ale są mile od kodu spaghetti produkowanego przez kowbojskich koderów. Bryłki nie potrafią nawet zidentyfikować tych ludzi, kiedy im się o nich mówi , ponieważ dla nich wszystko, co dzieje się w tle, po prostu nie istnieje.

Niektórzy z was zapewne będą w tym momencie myśleć, że nie odpowiedziałem na pytanie. To dlatego, że samo pytanie jest wadliwe. Kodowanie kowbojskie nie jest wyborem , to poziom umiejętności i nie możesz wybrać kodera kowbojskiego bardziej niż możesz być analfabetą.

Jeśli jesteś kowbojskim programistą, nie znasz innej drogi.

Jeśli zostałeś astronautą architektury, jesteś fizycznie i psychicznie niezdolny do tworzenia oprogramowania bez projektu.

Jeśli jesteś quasi-inżynierem (lub profesjonalnym inżynierem), to ukończenie projektu przy niewielkim nakładzie pracy projektowej lub bez niego to świadomy wybór (zwykle z powodu absurdalnych terminów), który należy porównać z oczywistym ryzykiem i podjąć dopiero po wyrażeniu zgody przez zainteresowane strony (zwykle na piśmie).

A jeśli jesteś programistą taśm klejących, to nigdy nie ma powodu, by „kodować kowboja”, ponieważ równie szybko możesz zbudować produkt wysokiej jakości .

Nikt nie „preferuje” kodowania kowbojów nad innymi metodologiami, ponieważ nie jest to metodologia. Jest to odpowiednik programistyczny przycisków zacierania w grze wideo. Jest OK dla początkujących poziomów, ale każdy, kto przejdzie przez ten etap, po prostu tego nie zrobi. Mogą zrobić coś, co wygląda podobnie, ale to nie będzie to samo.

Aaronaught
źródło
27
Pięknie artykułowane.
Brandon,
4
+1 za dobry wkład pomimo sprzeczności. Powiedziałeś, że quasi-inżynier dokonuje świadomego wyboru, kiedy jest potrzebny. Wiele razy doświadczeni programiści z wiedzą muszą wybierać łamanie zasad, które zna i w których wierzy ze względu na pewne ograniczenia. Oczywiście, jeśli programista jest cholernie dobry i szybki w swojej pracy, nie musi wybierać, ale niewielu specjalistów ma taką jakość. W każdym razie pytanie jest prowokujące.
Maniero,
14
Problem polega na tym, że zbyt wielu ludzi chce być programistami taśm klejących, nie będąc najpierw astronautami architektury, a następnie quasi inżynierami, co oznacza, że ​​są wiecznymi kowbojami. Myślę więc, że mogę wskazać tę listę i powiedzieć „wygląda to na rozwój kariery” ... szkoda, że ​​kierownictwo uważa, że ​​AA są szczytem.
MIA,
19
Nie wiem nawet, gdzie jestem na tej liście: S Czasami słyszę o projekcie i od razu wiem, jak go zbuduję 4, a potem cierpię poważny paraliż analizy i zastanawiam się nad architekturą, na przykład 2, wtedy rozważam YAGNI i myślę o wartości biznesowej, staram się być pragmatyczny i czuję się jak 3, a potem skończę robić bałagan jak 1.
Carson Myers,
14
Powinienem dać ci -1 za sugerowanie, że wysoko płatny konsultant jest na poziomie umiejętności programisty taśm klejących (wskazówka: większość z nich nie jest, nawet nie jest blisko). Ale i tak dałem ci +1.
Falcon
47

Tak.

Wolę też zostawić skarpetki na podłodze, gdzie je zdjąłem, biurko pokryte wydrukami i stare opakowania po przekąskach, zlew pełen brudnych naczyń i łóżko nie posłane.

Nie uważam wakacji zaplanowanych z góry za odpowiednie wakacje, posiłek spożywany z myślą o odżywianiu się odpowiednim jedzeniem, czy pobyt na znanych szlakach o właściwej wędrówce.

Lubię się dobrze bawić, być zaskoczonym, uczyć się nowych rzeczy, popełniać błędy i nigdy nie być całkiem pewnym, czy wrócę. Czasami takie podejście jest dokładnie tym , czego potrzeba, aby rozpocząć projekt od podstaw ...

... ale przez większość czasu jest to po prostu nieodpowiedzialne. Kiedy taniec się skończy, dudziarz otrzyma zapłatę ... Zapomnij o tym na własne ryzyko.

Shog9
źródło
Mam problem +1 dla „starych opakowań na przekąski, mojego zlewu pełnego brudnych naczyń i [co najważniejsze] mojego łóżka nie posłanego”. Co do cholery, +1, ponieważ dreszczyk kodowania kowbojów i dyskomfort wynikający z niewiedzy, czy uda się go przywrócić, jest zbyt mocny, aby tracić czas z głupim UML, projektem i specyfikacjami. Piszą swoje specyfikacje z mojej implementacji, NIGDY na odwrót. :: sarkazm
Chris
31

Masz dokładnie rację. Takie podejście do „programowania kowbojów” może szybciej wydobyć pierwszą wersję kodu, ale oszczędność czasu będzie więcej niż stracona dzięki:

  • Dodatkowe błędy
  • I tak potrzebny jest dodatkowy czas na znalezienie błędów, które byś miał
  • Konieczność inżynierii wstecznej kodu, aby pamiętać, co zrobiłeś, gdy musisz wprowadzić zmiany w ciągu sześciu miesięcy
  • Dodatkowy czas poświęcony na szkolenie dodatkowych programistów, którzy muszą popracować nad Twoim kodem
  • Brak dziennika poprawek, do którego można się cofnąć, gdy dokonujesz zmiany, która coś psuje
  • Nie mając modułów, możesz je łatwo wykorzystać w późniejszych projektach
  • I tak dalej i dalej i dalej

Jak wspomniał Neil Butterworth w swojej odpowiedzi, czasami musisz zrobić to, co musisz. Jednak, ogólnie rzecz biorąc, nie, upowszechnianie kodu tak szybko, jak to możliwe, bez poświęcania czasu na kontrolę kodu źródłowego, wzorców, dokumentacji itp. Jest bardzo złym nawykiem.

To dobrze, gdy analizujesz współpracowników i zastanawiasz się, czy ich nawyki są korzystne, czy szkodliwe, zamiast ślepo postępować.

Warren Pena
źródło
6
Zawsze są wyjątki. Niektórzy koderzy mogą być geniuszami, mają pamięć fotograficzną, ale mało cierpliwości. Inni nie są tacy szybcy, ale wytrwali; ocierają się o zadanie po jednym bajcie, aż stanie się ich suką. Istnieje wiele sposobów na bycie dobrym programistą. Może programowanie dla kowbojów działa dla niej. To może nie działać dla pytającego lub wielu innych. Jednak dlaczego upoważnić JAK ktoś powinien pracować, gdy ważna jest szybkość i jakość wyników. Po co uchwalać prawo zabraniające 12-cylindrowych silników, skoro można po prostu nagradzać wyższe mpg poprzez ulgę podatkową?
Job
@Job: Zgadzam się. Każdy ma inny proces; proces ten nie jest zwykle udany, ale może być. Z jednej strony jestem notorycznym użytkownikiem algorytmu Feynmana i wykonuję krok 3 tak szybko, jak to możliwe, gdy jestem jeszcze w strefie.
Jon Purdy
3
@Job - Czasami zdarzają się wyjątki. Procenty w końcu przejmą kontrolę. Mogą istnieć wyjątki, gdy są oceniane w oderwaniu od doskonałego kodu (bez błędów, bez problemów itp.), Ale w końcu nawyki kowbojskich programistów uderzą w jej firmę (i jej zespół i ją) w tyłek. Możesz wygrać w rosyjskiej ruletce pięć razy z rzędu, ale graj dalej, a moje pieniądze są na pierwszym miejscu.
Thomas
2
@Job: Tak, do pewnego stopnia zgadzam się. Ale odmowa rozważenia czegokolwiek innego (co = odmowa nauki) i odmowa użycia kontroli źródła to dwie duże czerwone flagi, które mówią mi: Może być szybki, ale naprawdę niebezpieczny boofhead.
Szybko_niedz
1
Postępowanie zgodnie z formalnym procesem nie jest jedynym sposobem na napisanie kodu jakości i nie gwarantuje i tak kodu jakości. Posiadanie formalnego procesu jest mniej ważne, jeśli praca osoby jest „luźno związana” z pracą innych ludzi. Kontrola wersji, jeśli w ogóle, staje się ważniejsza, ponieważ proces staje się bardziej nieformalny. O „odmowie uczenia się” - ile złych doświadczeń miała ta osoba ze złymi procesami i złymi systemami w przeszłości? Wnioskowanie jest niedoskonałe, ale jest to w zasadzie jedyny sposób, w jaki musimy zrozumieć wszystko poza naszymi głowami i przy odpowiednich (lub raczej złych) doświadczeniach ...
Steve314,
29

To naprawdę sprowadza się do pytania, czy można poprawnie wdrożyć rzeczy bez ścisłej struktury i dużej ilości czasu pochłoniętego przez planowanie.

Wyrzucę tutaj coś, co może być naprawdę niepopularne: klienci na ogół chcą rzeczy traktowane w kowbojski sposób .

Oznacza to, że chcą zażądać zrobienia czegoś i pozwolić, aby ktoś wskoczył na to, wykonał to i wyniósł. Brak zarządzania projektami, spotkań, połączeń konferencyjnych lub formularzy. Po prostu to zrób. Nigdy nie miałem klienta, który powiedziałby: „hej, zrobiono to trochę za szybko, jak na nasz gust, docenilibyśmy to, gdyby następnym razem postawiono tam mały wodospad lub coś w tym stylu”.

Metodologie i struktura zespołu zostały zaprojektowane tak, aby wyrównać szanse w projekcie i uzyskać różne poziomy programistów na tej samej stronie, pracujących na te same cele, w ten sam sposób.

Odnoszący sukcesy „kowboje”, z którymi współpracowałem, są w stanie:

  • Zidentyfikuj najprostszy sposób szybkiego wdrożenia czegoś
  • Wiedz, w którym momencie się zepsuje
  • Napisz czysty, czytelny i prosty kod
  • Przewiduj, w jaki sposób użytkownicy będą z niego korzystać, nadużywaj go i psuj
  • Wyskaluj / wyodrębnij to w odpowiednich miejscach, a nie astronauta architektury
  • Dowiedz się, gdzie i jak obsługiwać przypadki krawędziowe i wyjątki

Tacy ludzie dają naprawdę świetne wyniki przy niewielkim nakładzie zarządzania i strukturze, ale są rzadkie.

Brandon
źródło
9
Naprawdę nie nazwałbym twojej końcowej listy kodowaniem „kowbojskim”. To bardziej jak kwintesencja „programisty taśm klejących” uwielbionego przez Spolsky'ego. Różnica polega na tym, że kowbojski programista po prostu rozpoczyna tworzenie kodu razem, nie zwracając uwagi na ogólny projekt; „programator taśm klejących” wymyśla to w miarę postępów, ale wciąż ma plan; po prostu wykonuje większość prac projektowych na poziomie intuicyjnym (a czasem iteracyjnym).
Aaronaught
3
Klienci niekoniecznie chcą tego w stylu kowbojskim, chcą po prostu taniego i szybkiego. To od nas zależy.
@ user1249: To przypomina mi trójkąt zarządzania projektem: tani, szybki, dobry - wybierz dwa.
DanMan
Założenie, że klienci są profesjonalnym autorytetem, jest śmieszne. Oczywiście chcę, aby rzeczy były traktowane w stylu kowbojskim, dlatego chcę, aby mój samochód był zrobiony szybko i brudnie, mój dom został zbudowany przez przybyszów, którzy mogą po prostu przykleić cement w sposób podobny do ściany, a moje jedzenie powinno być przygotowane przez tych, którzy ignorują ryzyko dla zdrowia z korzyścią dla mnie, że wcześniej jem ...
Henry Aloni
13

EDYCJA: Na przyszłość, moja odpowiedź dotyczy innego pytania, które zostało połączone w jedno. Tu jest zupełnie nie na miejscu, ale to nie był mój telefon.


Jest po prostu leniwa, arogancka, ignorancka i wyjątkowo samolubna. To zachowanie jest lekkomyślne.

Chodzi mi o to, że nie chodzi o to, że używa niekonwencjonalnej, a może przestarzałej metodologii. Po prostu świadomie nie używa . Brak standardów Brak zapewnienia jakości. W ogóle nie. Skąd ona może oczekiwać jakości oprogramowania? Drzewa?
To zabawne, że tak naprawdę zaprzecza doświadczaniu osób, które zacytowałeś, kiedy wyraźnie jej brakuje. Przedstawienie weryfikowalnych i odpowiednich argumentów w celu zakwestionowania ich roszczeń jest prawidłowe. Ale próba zdyskredytowania ich poprzez zaprzeczenie ich doświadczeniu nie jest.

Najważniejsze jest jednak: ile czasu zajmuje kontrola wersji?
Jeśli nie da się jej przekonać do inwestowania 5 sekund co jakiś czas, powinieneś zabrać ją do jej szefa. Kontrola wersji nie jest opcjonalna. Kropka.

A kiedy już będziesz używać jej kontroli wersji, możesz łatwo śledzić, które błędy wprowadziła. I pozwól jej je naprawić. To jej bałagan, dlaczego miałbyś to posprzątać? Jeśli uważa, że ​​jej podejście jest lepsze, pozwól jej to zrobić - do końca .
Zakładając, że faktycznie może to zrobić (w rozsądnym czasie), nadal masz problem: praca z nią w zespole jest prawie niemożliwa. I musisz to rozwiązać, przekonując ją (co wydaje się mało prawdopodobne), zmuszając ją do odejścia (ze względu na twoje towarzystwo) lub odejścia (ze względu na twoje zdrowie psychiczne).
Ale jej porażka jest o wiele bardziej prawdopodobna i zdecydowanie powinna udowodnić twoją rację. A potem zacznie stosować się do najlepszych praktyk, tak jak robi to wiele osób z dużym doświadczeniem.

back2dos
źródło
2
Czasami prawda boli prosto i prosto ...
ChaosPandion,
+1 za powiedzenie, że praca zespołowa z tak samolubnymi ludźmi jest niemożliwa. Nawet jeśli są genitami, kowboje nie są graczami zespołowymi; są głównym show, a my jesteśmy grupą wspierającą
Mawg
11

Zależy to całkowicie od tego, czy pracuję solo, czy w zespole.

Jeśli pracuję w zespole, niektóre są wymagane konwencje i umowy - każdy w zespole musi podążać jakąś powszechnie przyjętą normę, aby działać na rzecz wspólnego celu, tak, że ich wysiłki są kompatybilne.

Ale jeśli pracuję sam, to oczywiście chcę być kowbojem. Wszystkie wielkie dzieła na świecie zostały wymyślone przez jeden umysł lub co najwyżej dwa pracujące w stylu kowbojskim. Żeby wymienić tylko kilka:

  • Mechanika klasyczna? Cowboy Isaac Newton, później dodatki z Leibniz, Lagrange, Hamilton.
  • Samolot? Cowboys Wright.
  • Teoria względności? Cowboy Albert Einstein.
  • Podstawowa nauka o komputerach? Kowboj Alan Turing.
  • Tranzystor? Cowboys Walter Brattain i John Bardeen.

Zespoły są dobre w wprowadzaniu stopniowych ulepszeń i tworzeniu nowych systemów opartych na sprawdzonych przepisach dość szybko (pod warunkiem, że są dobrze prowadzone), ale rzadko słyszy się o prawdziwym wynalazku stworzonym przez zespół. Praca zespołowa i wymagane przez nią metody mają swoje zalety, ale kodowanie kowbojów również.

Joonas Pulakka
źródło
Zauważyłem, że wspomniałeś o niektórych sławnych sukcesach kowbojów, pomijając znacznie więcej niepowodzeń kowbojów.
Mawg
7

Zależy od problemu. Dobry starszy programista napisze bardzo kompaktowy, prosty i solidny kod, który jest bardzo stabilny i wykorzystuje wszystkie najlepsze praktyki bez przeglądania stron dokumentacji i mnóstwa różnych wzorców i paradygmatów. Ale będzie również wiedział, kiedy będzie mógł sobie pozwolić na robienie takich rzeczy.

Byłbym zszokowany, gdyby wziął nowy problem i zaczął projektować aplikację, która od zera wymaga wielu miesięcy roboczych. Ale jeśli jest to wtyczka, proste narzędzie, które można napisać w ciągu 2 godzin, funkcja, która dokonuje pewnej konwersji i nie jest przeznaczona do ponownego użycia, projekt i wzory są w rzeczywistości dobre tylko do marnowania czasu.

Wydaje mi się też, że duża część projektu została już przetworzona w wątku tła gdzieś wewnątrz głowy starszych programistów.

Musisz zacząć się martwić, kiedy starszy programista zacznie odrabiać klasy złożonego systemu lub nowe aplikacje od zera i bez etapu planowania.

Koder
źródło
9
twoja odpowiedź całkowicie pomija najbardziej wymowną część pytania „Mam programistę, który szybko koduje poprzez zwolnienie kontroli wersji ...” każdy, kto odrzuca kontrolę wersji i promuje tę opinię wśród młodszych pracowników, jest przestępcą.
1
@Jarrod: czy nie. Nie ma sensu popełniać niekompletnego / dysfunkcyjnego kodu.
Denis de Bernardy,
1
@Denis - właśnie do tego służy gałąź. Historia decyzji, zmian, błędów, ślepych zaułków itp. Podczas opracowywania niekompletnego / niefunkcjonalnego kodu jest IMO częścią dokumentacji tego kodu i jest bardzo ważna podczas konserwacji. Łatwiejsze rozgałęzianie i łączenie jest dobrym powodem do zastąpienia subversion rozproszonym VCS.
Steve314,
@steve: Zakładałoby to, że przeglądasz dzienniki przed edycją linii kodu. Szczerze mówiąc, znam bardzo niewielu programistów, którzy tak naprawdę robią ... I nawet wtedy (tak jak ja ...), są o wiele mniej zainteresowani tym, dlaczego to / to zostało popełnione, niż tym, dlaczego zostało zmienione z oryginalnego kodu.
Denis de Bernardy,
@steve: W przypadku prostych funkcji łatwiej jest użyć pojedynczego zatwierdzenia z komentarzem „Dodano funkcję, która oblicza parametry przyspieszenia”, niż mieć koomity: „Szkielet PaternX”, „Dodano pierwszy wiersz kodu”, „Naprawiono błąd”, „Naprawiono inny pluskwa". Łatwiej jest śledzić globalne zmiany projektu, jeśli liczba zatwierdzonych „szumów” jest mniejsza. Istnieją półki, których można użyć do niekompletnego kodu, aby uniknąć utraty danych.
Coder
6

To zależy od okoliczności. Na przykład po katastrofalnych skandalach handlowych kilka elektronicznych giełd nalegało, aby do wszystkich transakcji dodano flagi automatycznego handlu. I musiało to dotyczyć całego oprogramowania handlowego w ciągu tygodnia. Mam na myśli, że trzeba było to zrobić - jeśli nie było flagi, nie można było handlować. W takich okolicznościach wszystkie dobre praktyki są przestrzegane przez zarząd - wystarczy (jak mawialiśmy) „hacky, hacky, hacky”. W tych okolicznościach szybkie i dokładne pisanie kodu jest kluczowe. Zwłaszcza, że ​​nie było dostępnych systemów testowych.

Neil Butterworth
źródło
Jak korzystać ze SWINE? Jaki jest język opisu okien dialogowych?
Job
@ Job To nie jest jeszcze gotowe.
Neil Butterworth,
twoja odpowiedź całkowicie pomija najbardziej wymowną część pytania „Mam programistę, który szybko koduje, odrzucając kontrolę wersji ...” Jestem prawie pewien, że twój przykład nie odrzucił kontroli wersji ani zarządzania wydaniami itp.
@Jarrod Kontrola wersji. Cóż, mieliśmy RCS. Zarządzanie wydaniami? To był bank inwestycyjny! Wypychasz rzeczy za drzwi tak szybko, jak je piszesz.
Neil Butterworth,
Witamy spowrotem.
P Shved
5

Z mojego doświadczenia, kodowanie krowa chłopca Z kontrolą źródła jest najlepszym i najbardziej wolnym od błędów sposobem na tworzenie dużych systemów oprogramowania.

jojo
źródło
2
Kosztem stworzenia dużej kuli błota (moja własna odpowiedź ;-))
Denis de Bernardy
4

Myślę, że jeden z komentatorów miał rację - wszystko zależy od wyników.

Jeśli dana osoba jest w stanie wyprodukować dobry produkt - coś, co robi to, co ma robić, a także jest łatwe do utrzymania i niezawodne - to co ma znaczenie, jeśli przestrzegane są formalne metodologie lub procesy? Procesy są świetne, aby zapewnić jakość podłogi, ale jeśli ktoś już pracuje nad tą podłogą, wówczas procesy nie dodają nic do równania. Obecnie zbyt wielu programistów, imo, uważa, że celem programowania jest przestrzeganie procesów, a nie wytwarzanie dobrego produktu.

Grandmaster B.
źródło
4

Ten rodzaj osoby nazywa się hakerem i zwykle nie jest to termin komplementarny od bardziej profesjonalnego wśród nas.

Jak zauważyłeś, czas poświęcony na projektowanie, organizację i kontrolę jest tracony podczas debugowania. I często przy ustalaniu, która wersja kodu została faktycznie wysłana. Jeśli w ogóle możesz to znaleźć!

Uważam, że taka osoba jest zbyt pochłonięta sobą, myślę, że są zbyt dobrzy, aby pracować z „ograniczeniami”, które inni muszą cierpieć, więc nie zawracaj sobie nimi głowy, a to traci jeszcze więcej czasu, jak reszta zespół musi po nich posprzątać. Nie są też zbyt zaangażowani w proces naprawiania błędów (to zadanie programisty konserwacji, znacznie poniżej umiejętności i talentu programisty).

Może to być wspólne podejście gdzie indziej, ale u mnie (i jestem starszym programistą, który ma tendencje do takiego podejścia, hm), nie cierpimy z tego powodu. Nie chodzi o to, że wymagamy mnóstwa procesów i procedur, ale nalegamy na minimalną ilość organizacji, kontrolę kodu źródłowego (szczerze mówiąc, to cholerny wschód i cholernie przydatne!)

Kent Beck i in. Są profesjonalistami, którzy widzieli, że stare, obciążone procesem sposoby były same w sobie złe, dlatego stworzyli nowe metodologie organizowania kodowania, jednocześnie utrzymując go bardziej zorientowany na rzemiosło, a następnie powiedzieli o tym wszystkim innym - publikując książki ( jak inaczej to zrobiłeś przed Internetem?)

Brzmisz tak, jakbyś miał rację - nie akceptuj złej praktyki tylko dlatego, że ktoś inny nie może jej zhakować. Twój lider zespołu lub menadżer powinien ciężko spotykać się z tą „gwiazdą rocka”, ale jeśli nie są… cóż, to nadal nie przeszkadza ci w robieniu właściwych rzeczy. Po prostu nie akceptuj od niej tandetnej praktyki, jeśli spieprzy (a zrobi to!), Pozwól jej to posprzątać. Trzymasz się dobrych praktyk (i wiesz, czym one są), nie pozwalając im przejąć kontroli ze szkodą dla wydajności kodowania, i będziesz dobry na przyszłość.

Oto esej od naprawdę wnikliwego pisarza. Nie rozwiązuje problemu, ale daje kilka informacji na temat tego, jak to jest, i może kilka wskazówek, jak sobie z tym poradzić profesjonalnie.

gbjbaanb
źródło
+1 To niefortunne, że „haker” zmienił się w ten sposób. Krótka historia hackerów
Gyan alias Gary Buyn
4
Powiedziałbym „hack” zamiast „hacker”.
Mike Sherrill „Cat Recall”
2
Są kowbojem, tak jak stwierdził PO, nie mylą tego, czym jest haker. Pozostaw to mediom.
ocodo
może to być programista „rockstar”… zbyt pełen ego i talentu, aby martwić się o „małe rzeczy”. Gdzie moja wanna jest pełna niebieskich m & ms ?! Chcę tego teraz!
gbjbaanb
3

Jedynym ważnym faktem są długoterminowe wyniki zespołu.

Twierdzi się, że zespół obejmujący jednego świetnego programistę (lub więcej) da lepsze wyniki niż zespół z jeszcze większą liczbą średnich programistów kodujących ze średnią szybkością.

Jeśli kowboj produkuje rzeczy, których nie robią zwykli programiści (na dany termin lub specyfikację), a zespół z kowbojem musi nawet poświęcić kilka tygodni / miesięcy na sprzątanie bałaganu kowboja, może nadal skończyć z lepszy wynik wcześniej.

Jeśli zespół z kowbojem nie jest w stanie posprzątać (dokumentować, debugować, integrować, utrzymywać) bałaganu nawet po wielu osobach / miesiącach, wtedy jakiekolwiek postępy, jakie stworzył kowboj, nie dawały drużynie przewagi na dłuższą metę.

Zdecyduj, który z nich, i zoptymalizuj skład drużyny.

Nie każdy programista działa (lub powinien działać) w ten sam sposób, o ile wynik końcowy jest dobry.

hotpaw2
źródło
4
Twierdzi się, że zespół, w tym jeden wielki programista (lub więcej), da lepsze wyniki niż zespół z jeszcze większą liczbą przeciętnych programistów kodujących ze średnią szybkością - to znaczy, dopóki wielki programista nie odejdzie i nie weźmie siodła, konia i twój kod z nimi. Jak dobrze zatem wyglądają te wyniki?
Thomas
Założenie niekoniecznie jest prawidłowe. Bardzo ważne może być także dotrzymanie terminu konferencji lub kolejnego pokazu Twojego produktu.
1
@Thomas: Czynniki ryzyka zmniejszają się w obie strony. Facet, który finansuje wszystkie wypłaty, może wyjść z kolejnej rundy finansowania, gdy nawet zhakowany dowód koncepcji nie pojawi się wkrótce. Jak dobrze wyglądają teraz twoje wolne konie? Wszystkie możliwości inżynieryjne są hazardem. Umieść swoje żetony.
hotpaw2
@ hotpaw2 - Ryzyko polega na tym, czy (potencjalnie terminalne) koszty związane z kodowaniem kowbojskim uderzą, zanim będziesz mógł uzyskać fundusze. Ogólnie rzecz biorąc, mój zakład jest przeciwko kodowaniu kowbojskiemu (i że potrwa to dłużej). Och, możesz mnie pokonać 1/10 razy, a nawet 1/5. Ale biorąc pod uwagę, z roku na rok, gdy szanse się zwiększają, kowbojscy koderzy będą cię kosztować więcej niż zyskujesz.
Thomas
1
@ Thorbjørn Ravn Andersen, @ hotpaw2 - W grze jest jeszcze jedna dynamika. Koder, który chętnie stosuje ryzykowne techniki, o ile nie są one aktywne, nawet jeśli nie są one potrzebne, na ogół dokona bardziej ryzykownych wyborów w innym miejscu. Tj. Ich wybór przeciwko kontroli źródła wskazuje na bardziej ryzykowny wzór zachowania, który ostatecznie ugryzie ich i ich firmę. Nawet w grach hazardowych czasami możesz pokonać dom, ale w końcu procent cię pokonał.
Thomas
3

Możesz znaleźć pewien wgląd w mojej odpowiedzi na Szczerze, czy wolisz kodowanie kowbojskie? Problem polega na tym, że „kodowanie kowboja” oznacza różne rzeczy dla różnych ludzi i nie jest od razu oczywiste dla niewprawnego oka, którą wersję widzisz.

Gdy ktoś może spojrzeć na problem i natychmiast rozpocząć usuwanie kodu, szybko i dokładnie, może to być znak inżyniera, który widział go już tysiące razy i już zna najlepszy sposób rozwiązania problemu.

Lub może to być znak rangi amatora.

Powiem wam jedno: odmowa użycia kontroli wersji lub pisania testów, ponieważ są one zbyt „akademickie”, zdecydowanie nie jest podejściem „wyższym” ani nawet zdalnie profesjonalnym. Nigdy nie zobaczysz tego rodzaju rzeczy w dużych sklepach z oprogramowaniem, takich jak Microsoft czy Google, i prawdopodobnie nie zobaczysz tego w większości start-upów ani w dość dojrzałych zespołach przedsiębiorstw.

Ryzyko jest po prostu zbyt duże. Co się stanie, jeśli Twój komputer umrze w ciągu nocy? Do widzenia 3 lata wydajności. Okej, więc rób kopie zapasowe; a co się stanie, gdy dokonasz poważnej zmiany, zdasz sobie sprawę, że to całkowicie nie tak i musisz ją cofnąć? Dzieje się tak nawet w przypadku najbardziej doświadczonych i utalentowanych programistów, ponieważ wymagania są błędne. Jeśli nie korzystasz z żadnej kontroli wersji, po prostu kręcisz kołami w błocie. Byłem tam raz i nigdy nie wrócę.

Po prostu nie ma wymówki - skonfigurowanie repozytorium zajmuje 10 minut, a zatwierdzenie zajmuje 10 sekund. Stanowi to może 1% całkowitego czasu rozwoju. Testy, jeśli się spieszysz, można łatwo zmniejszyć do 20-30 minut dziennie i nadal są dość przydatne.

Nie jestem fanem metodologii Agile (zwróć uwagę na wielką literę A), ale czasami naprawdę musisz po prostu zakasać rękawy i zacząć pisać cholerny kod. Widziałem ludzi i zespoły z „paraliżem analizy”, a produktywność naprawdę widocznie uderza. Ale odrzucenie podstawowych narzędzi naszej branży, takich jak kontrola wersji i testy, jest dla mnie naprawdę klinicystą; ta osoba nie należy na wyższe stanowisko.

Aaronaught
źródło
2

Tak, ale musisz rozpoznać, kiedy NIE możesz tego zrobić.

W każdym małym przypadku prawdopodobnie masz się dobrze, ale jeśli masz coś złożonego, niebezpiecznego, ograniczonego itp., Musisz być w stanie rozpoznać, kiedy odpowiedni projekt jest wart dodatkowego czasu.

Myślę też, że zdecydowanie powinieneś przemyśleć odpowiedź Aaronaught. Kowboj oznacza różne rzeczy dla różnych ludzi.

Rachunek
źródło
2

Kiedy myślę o „tradycyjnych” metodach, myślę, że „zarządzanie nie wie, jak rozumieć programistów, więc zamiast wchodzić do świata programistów i wystarczająco rozumieć, aby wiedzieć, co się dzieje, sprawiają, że programiści przychodzą do swojego świata”.

Zasadniczo, kiedy myślę o „Agile”, myślę „robisz to, co musisz zrobić, aby zminimalizować nieefektywność wprowadzoną przez wiele osób pracujących razem”. Jestem więc mocno w obozie, że „nie ma czegoś takiego jak THE Agile Methodology , tylko zestaw wartości i zasad”.

Innymi słowy, są rzeczy, które musisz zrobić w bardzo dużym projekcie, i są rzeczy, które musisz zrobić w małych projektach, i są rzeczy, które robisz w obu przypadkach.

Na przykład nie miałbym więcej niż najprostsze zaległości w projekcie, nad którym pracuję ... To byłaby tylko lista rzeczy do zrobienia. Jeśli jest nas dwóch, zapewne udostępniam tę listę, ale w bardzo prostym formacie (prawdopodobnie tylko notatkę zapisaną w naszym repozytorium kodów). Kiedy mam 3 lub 4, szukam jakiegoś systemu elementów pracy.

MIA
źródło
1

Tylko przy prototypowaniu bardzo prostych funkcji.

Potem, kiedy już to zrobię i zastanowię się, jak to zrobić, porzucam kod i mówię poważnie.

Klaim
źródło
1

Zrobiłem to raz w prawdziwym projekcie (w tym czasie nazywaliśmy to Programowaniem samurajskim, po serii szkiców Samurai Tailor w Saturday Night Live) i ku mojemu zdziwieniu, zadziałało dobrze. Oczywiście zacząłem od śmieci, więc ryzyko pogorszenia było niewielkie.

Jestem jednak „schludny” w sercu i nie lubię strzelania z hip-hopu.

Z drugiej strony, modus operandi mocno obciążony procesem również nie jest w moim guście. Po prostu lubię planować, zanim zacznę działać.

Podsumowując, uważam, że ilość odpowiedniego procesu formalnego zależy w dużej mierze od wielkości (rozmiaru kodu, czasu trwania projektu, liczby programistów, rodzajów wymagań itp.) Projektu. Chcę, aby osoby, które opracowują oprogramowanie dla awioniki lub sprzętu biomedycznego, nałożyły rygorystyczne i surowe kryteria, np. W przypadku gier, np., Jest dużo mniej wad związanych z awariami, więc koszt i ciężar rygorystycznych i metodycznych praktyk programistycznych nie jest tak naprawdę usprawiedliwiony.

Randall Schulz
źródło
2
Często musisz rozwiązać problem, aby dowiedzieć się, jak go rozwiązać ...
1

Zależy (w dużym stopniu) od wielkości projektu. Z jednej strony, aby uzyskać przyzwoity wynik, musisz mieć projekt. Z drugiej strony, jeśli projekt jest wystarczająco mały, aby można było konceptualizować cały projekt (i tak jest ich większość) bez zapisywania go, rysowania schematów itp., To prawdopodobnie równie dobrze byłoby bez dodatkowej pracy dokumentowanie wszystkiego, co robisz.

Prawie wszyscy słyszeli wystarczająco dużo horrorów, aby zdać sobie sprawę, że próba wskoczenia bez jasnego pojęcia o tym, co robisz i dokąd zmierzają, to przepis na katastrofę. O wiele rzadziej wskazywane jest to, że przeciwieństwo może być równie katastrofalne. Na przykład większość z nas rutynowo pisze małe narzędzia w trakcie programowania. Pisanie pełnej specyfikacji, testów, dokumentacji często po prostu nie jest tego warte. Istnieje próg, poniżej którego produkcja nie jest opłacalna - ludzie często nie lubią wymyślać koła, ale w niektórych przypadkach łatwiej jest je odkryć na nowo niż go uniknąć.

W takich przypadkach, co często jest opłacalne jest productizing bibliotekę, aby zadania, takie jak to łatwe. Dzięki temu kod frontonu często staje się tak trywialny, że pisanie (lub modyfikowanie) kodu do robienia tego, co chcesz, staje się łatwiejsze niż ustalenie, jak uzyskać kompletny program do robienia tego, co chcesz. Rozważmy, na przykład, wcięcie gnu z ponad 50 różnymi flagami, z których wiele oddziałuje na różne subtelne sposoby, więc jedynymi rozsądnymi wyborami są 1) wcale go nie używaj lub 2) zdecyduj, czy ci się podoba zamiast próbować zdobyć to, czego pierwotnie chciałeś.

Jerry Coffin
źródło
1

Wydaje się, że istnieją dwa obozy - ci, którzy faworyzują wyniki i ci, którzy faworyzują zasady. Wpadłem w to drugie.

Jestem miernym, ale prawdopodobnie sumiennym programistą - moim głównym zmartwieniem podczas kodowania, poza wykonaniem zadania, jest to, że pomagam każdemu, kto używa mojego kodu do wykonania ICH zadania. Nie mogę powiedzieć, że zawsze to osiągałem - ale to właśnie zamierzam zrobić.

Jasne, może mieć hotrod na swój zespół - ale co się stanie, gdy wziąć kilka tygodni urlopu i jesteś proszony debugować swoją pracę, lub dodać rzeczy do niego? Ostatecznie kowboje-programiści nie są graczami zespołowymi. Mogą tworzyć świetny kod, ale jeśli zespół zależy od nich - to jest niebezpieczne.

sunwukung
źródło
Tak, i jest możliwe (prawdopodobnie?), Że niektórzy kowbojscy koderzy dostarczają niezbyt świetny kod.
Bernard Dy
1

Mam wrażenie, że niechęć do jej stylu powoduje, że lekko go wprowadzacie w błąd. Mówisz, że podejście do kowboja jest opłacalne podczas debugowania - czy to już się dzieje, czy też twoje przypuszczenie, jak to się potoczy?

Uczciwe ujawnianie informacji - sam jestem starszym programistą i często rezygnuję z formalnego procesu projektowania i zdobywania doświadczenia. Brak formalnego procesu dla kogoś, kto ma duże doświadczenie w dziedzinie problemowej, jest dość powszechny. Jeśli dziesiątki razy rozwiązałeś problem, nie potrzebujesz formalnego procesu, aby ponownie sformułować podobne rozwiązanie.

Proces formalny zajmuje się projektowaniem kodu - nie rozumiem, dlaczego należy wprowadzać więcej błędów, ponieważ brakuje formalnego procesu. Jedyny duży problem, który przeczytałem na twoim koncie, to to, że kontrola wersji nie jest używana - co jest nie tylko samolubne, ale wręcz lekkomyślne w imieniu dewelopera. Czy ona w ogóle się nie angażuje, czy po prostu nie postępuje według wzoru, który ci się podoba?

Brak formalnego podejścia do projektowania nie jest w mojej książce „kodowaniem kowbojskim” (choć nie stosuję kontroli wersji). Do tego celu należy wykorzystać doświadczenie - aby skrócić czas potrzebny na znalezienie „wystarczająco dobrego” rozwiązania. Pamiętaj, że musisz rozwiązać obecne problemy i ułatwić zmianę kodu, a nie projektowanie przyszłych scenariuszy, które mogą się nigdy nie zdarzyć. Dzięki doświadczeniu masz dobre wyczucie, jak to zrobić bardzo szybko.

Eran Galperin
źródło
0

Nie, nigdy.

Zawsze wykonuję analizę wymagań, myślę o architekturze, projektuję szczegóły, a następnie koduję. Nawet jeśli pracuję solo w domu dla osobistego projektu.

I natychmiast zwolniłbym programistę z mojego zespołu, gdyby pracował w stylu kowbojskim. Jesteśmy inżynierami i ponosimy odpowiedzialność za klienta i użytkowników.

CesarGon
źródło
-1: Musisz także działać w najlepszym interesie tego, kto pisze wypłatę.
Jim G.
@ Jim: Piszę wypłatę. Dlatego mam uprawnienia do zwalniania członków zespołu. Może twoje zdanie było trochę pochopne. :-)
CesarGon
Jesteśmy inżynierami i ponosimy odpowiedzialność za klienta i użytkowników. - Czasami klient żąda szybkiej daty wysyłki. Nacisk: czasami szybka data wysyłki nie podlega negocjacji.
Jim G.
@Jim: Wiem to bardzo dobrze po założeniu trzech firm. Mimo to nigdy nie kodowałem kowboja, dziękuję bardzo. Jak powiedziałem, ponosimy odpowiedzialność za klienta i użytkowników, i zawsze byłem w stanie dopasować to zobowiązanie do rzetelnych praktyk inżynieryjnych i nie mieć kowbojów.
CesarGon,
0

Nie sądzę, żeby kodowanie kowboja było podejściem seniorskim.

Jak powiedzieli inni, istnieje odrzucenie kontroli wersji. Pominięcie dokumentacji i analizy może również oznaczać ryzyko dostarczenia czegoś, czego użytkownik nie chce. Po prostu moja opinia, ale nie sądzę, że przechodzisz od „programisty do programisty”, jeśli wszystko, co robisz, to kod kowboja.

Jednak tak, istnieją wyjątki, takie jak wspomniane przez Neila Butterwortha. W takich sytuacjach wolałbym, aby doświadczony starszy programista był tym, który musiałby kodować kowboja.

Bernard Dy
źródło
0

Wydaje mi się, że nowi programiści robią pewne rzeczy, które kodują kowboje, biorąc pod uwagę aspekty projektu / zakresy, z którymi mogą nie mieć dużego doświadczenia lub gdy próbują „po prostu załatwić sprawę” z powodu presji ze strony szefa itp. Wiem, że zdecydowanie zszedłem tą ścieżką kilka razy, ponieważ brakowało mi wiedzy na temat prawidłowego wzoru i po prostu „zhakowałem go”.

Różnica między mną a osobą, na którą skarżysz się, polega na tym, że zwykle wkrótce potem zdaję sobie sprawę, że mogłem to zrobić lepiej i uczynić to łatwiejszym w utrzymaniu, i zwykle pobudza mnie do uczenia się i doskonalenia umiejętności (czytając książki / artykuły na Przedmiot). Kiedy wracam do debugowania niektórych zhackowanych rozwiązań, zwykle odczuwam ból i przyczynia się to bardziej do chęci nauczenia się, jak to zrobić „we właściwy sposób”. Myślę, że opisywana osoba w zasadzie utknęła w dziecięcym poziomie autorefleksji i pozwala jej własnemu ego przeszkadzać w faktycznym doskonaleniu umiejętności programisty, nie wydaje się kimś, z kim chciałbym pracować.

programmx10
źródło
0

Uważam twój post za interesujący. Często dzieliłem się poglądami z twoim tematem, a jej uczucie jest takie, że zbyt sformalizowane metody są duszne. Jak ktoś zauważył, jeśli jest geniuszem i potrafi jednocześnie śledzić wiele notatek, nie zapominając o tym ani nie myląc się, to całkiem możliwe jest utrzymanie monolitycznego kawałka skomplikowanego kodu i zrobienie niesamowitych rzeczy z całkowicie niejasnymi zmianami . Jest pewne szczęście mentalne, które przychodzi do mózgu ludzi, którzy mogą to zrobić - to tak, jakbyś był Bogiem małego wszechświata w twoim umyśle.

Jednak sprytni pracodawcy nauczyli się na własnej skórze, że nikt poza oryginalnym autorem nie może zrobić nic wartościowego dla tego kodu. Jeśli programista przejdzie dalej, marnuje mnóstwo pieniędzy, zastanawiając się, że jedyną opcją jest ponowne napisanie (myślałem, że oznacza to całkowitą stratę, ale zdaję sobie sprawę, że w dzisiejszych czasach nie niszczysz wewnętrznego wyniku iteracyjny rozwój na poziomie funkcjonalności zewnętrznej).

Osobiście nie mam nic przeciwko, aby mieć kogoś takiego w zespole, ponieważ w przypadku kryzysu mogą zrobić coś, o czym nikt inny nie pomyśli.

Z drugiej strony, bądź swoją osobą i sam zdecyduj, jaka jest odpowiedź na twoje pytanie, ponieważ jedyną rzeczą, która jest pewna, jest to, że nikt nie zorientował się, jeśli chodzi o tworzenie oprogramowania. To jedna z rzeczy, które sprawiają, że jest to interesujące pole ...

Aaron Anodide
źródło
Zgadzam się, chyba że jest to rozwiązanie ad-hoc, którego już nigdy nie trzeba dotykać, posiadanie jakiegoś wzorca jest ważne, ponieważ nie chodzi tylko o „sprawienie, by działało”, ktoś w końcu będzie musiał spojrzeć „pod maską” i mieć sens it
programmx10