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

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

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.

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.

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ć.

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.

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.

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ż.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Tylko przy prototypowaniu bardzo prostych funkcji.

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

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.

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ś.

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.

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.

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.

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.

Programowanie kowbojskie jest raczej pewnym sposobem na stworzenie dużej kuli błota . Co, choć jest to nieprzyjemne, wydaje się ...

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ć.

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 ...