Jakie są przeszkody w stosowaniu najlepszych praktyk? Jak można je pokonać? [Zamknięte]
22
Wszyscy widzieliśmy (i większość z nas napisała) dużo źle napisanego kodu. Czemu? Co sprawia, że stosujemy złe praktyki zamiast dobrych?
Najbardziej oczywistą odpowiedzią (dla mnie) jest „ignorancja”, ale jestem pewien, że to nie jedyny powód. Jacy są inni Co możemy zrobić, aby pokonać pokusę napisania złego kodu?
Jaki jest powód, dla którego możesz dziś powiedzieć, że kod jest źle napisany, a nie dlaczego?
@ Thorbjørn: Przepraszam, nie rozumiem pytania?
Kramii Przywróć Monikę
@Kramil, czy rozpoznałeś, kiedy napisałeś źle napisany kod, że został źle napisany, a jeśli tak, to dlaczego napisałeś go w ten sposób? Jeśli nie, to co się stało, ponieważ można to teraz rozpoznać, w przeciwieństwie do wcześniejszych.
4
@ Kramii, żadna „najlepsza praktyka” nigdy nie może zastąpić racjonalnej, krytycznej myśli. Wszystkie „najlepsze praktyki” są jedynie narzędziami, a używanie ich na ślepo byłoby po prostu szkodliwe. Głupio jest podążać za czymś tylko dlatego, że jest to uważane za „najlepszą praktykę”, bez zrozumienia uzasadnienia tego. Ale przy takim zrozumieniu nie będziesz musiał przestrzegać „najlepszych praktyk”. Dlatego samo pojęcie „najlepszych praktyk” jest głęboko wadliwe i z natury szkodliwe.
SK-logic
Odpowiedzi:
29
Odporność na zmiany.
To główny czynnik powodujący ignorancję, złe zarządzanie itp.
Rozdział 30 Peopleware 2nd Edition poświęcony jest temu tematowi. I cytuje z książki innego dość znanego konsultanta, napisanego nieco wcześniej:
I należy wziąć pod uwagę, że nic nie jest trudniejsze do opanowania, bardziej wątpliwe w sukces, ani bardziej niebezpieczne w zarządzaniu, niż postawienie się na czele wprowadzania nowych zamówień. Ponieważ wprowadzający ma wszystkich tych, którzy czerpią korzyści ze starych rozkazów jako wrogów, i ma letnich obrońców we wszystkich, którzy mogliby skorzystać z nowych rozkazów.
Niccolo Machiavelli: The Prince (1513)
DeMarco i Lister nadal powtarzają mantrę, aby pamiętać o tym, zanim poprosą ludzi o zmianę:
Podstawowa reakcja na zmianę nie jest logiczna, ale emocjonalna.
Proces zmian rzadko jest prostym i płynnym przejściem z obecnych nieoptymalnych warunków do nowego, ulepszonego świata. W przypadku każdej nietrywialnej zmiany zawsze pojawia się okres zamieszania i chaosu przed przybyciem do nowego status quo . Uczenie się nowych narzędzi, procesów i sposobów myślenia jest trudne i wymaga czasu. Podczas tego okresu przejściowego spada produktywność, cierpi morale, ludzie mogą narzekać i żałować, że tylko można wrócić do starych dobrych sposobów robienia rzeczy. Bardzo często to robią, nawet przy wszystkich problemach, ponieważ uważają, że dobre znane dobre problemy są lepsze niż nowe, nieznane, frustrujące i kłopotliwe problemy. Jest to opór, który trzeba taktownie i delikatnie, ale zdecydowanie pokonać, aby odnieść sukces.
Z cierpliwością i wytrwałością ostatecznie zespół przechodzi z Chaosu do następnego etapu, Ćwiczenia i Integracja. Ludzie, choć nie do końca czują się dobrze z nowymi narzędziami / procesami, zaczynają je rozumieć. Mogą wystąpić pozytywne doświadczenia „Aha”. I stopniowo zespół osiąga nowy status quo.
Naprawdę ważne jest, aby zdać sobie sprawę, że chaos jest integralną, nieuniknioną częścią procesu zmian . Bez tej wiedzy - i przygotowania do niej - można wpadać w panikę po wejściu w fazę Chaosu i pomylić ją z nowym status quo. Następnie proces zmiany zostaje porzucony, a zespół wraca do wcześniejszego nieszczęśliwego stanu, ale z jeszcze mniejszą nadzieją na kiedykolwiek coś poprawić ...
Myślę, że jest to prawdą w przypadku bardziej uznanych programistów, ale myślę, że stanowią one bardzo mały odsetek tych, którzy nie kodują zgodnie z najlepszymi praktykami. Cały kod, który widziałem, a który nie przestrzega najlepszych praktyk, pochodzi z dwóch innych odpowiedzi - braku czasu i naiwności.
AndrewKS
1
@AndrewKS, dotyczy to nie tylko programistów, ale także menedżerów i klientów. W dobrym zespole i procesie programistycznym terminy są realistyczne, a programistom nie przypisuje się zadań przekraczających ich obecne możliwości - a przynajmniej nie bez odpowiedniego mentoringu i weryfikacji. Niepowodzenie w nich prawie zawsze oznacza, że kierownictwo nie chce stosować najlepszych praktyk.
Péter Török
Naprawdę dobra uwaga - do tej pory nie myślałem o programistach w tej sytuacji.
AndrewKS
Niechęć często skutkuje pewnym lenistwem, które ostatecznie rodzi ignorancję.
S.Robins
23
Péter Török ma rację, ale pominął jeden ważny i optymistyczny punkt:
ludzie mogą lubić zmiany, w które są zaangażowani, ale prawie nigdy nie lubią zmian, które po prostu „im się przytrafiają”
więc zaangażujcie ich, pozwólcie im wnieść pomysły, pozwólcie im stworzyć stawkę, a to nie będzie tak bolesne
Uwaga: dotyczy to programowania, ponieważ wiele udanych technicznie projektów oprogramowania kończy się niepowodzeniem, ponieważ użytkownicy je odrzucają .
Musisz uważać na zjazdy rowerowe ! Nie pozwól im się w to zaangażować!
shapr
18
Czas wydaje się być duży, w którym pracuję.
np. Po co stosować testowanie jednostkowe, gdy trzeba napisać więcej kodu, a więc uzyskanie produktu, który można wydać, zajmuje więcej czasu? Klient x chce tego teraz! Koduj szybciej!
(To oczywiście nie kończy się dobrze)
Jest to również wynikiem złego zarządzania i ekonomii, niewystarczającego obciążenia klientów, aby pozwolić sobie na poświęcenie czasu na robienie tego dobrze.
Czas też jest tu ogromny. Mój szef powiedział nam na spotkaniu pracowników: „Firma nie płaci za świetną pracę”.
Joshua Smith
@Joshua Smith: wtf !? Poważnie? Nie zdziwiłbym się, gdyby dostali dokładnie to, za co płacą.
Steven Evers,
2
Często widziałem podejście, na które nie możemy sobie pozwolić, aby zrobić to dobrze. Ale możemy sobie pozwolić na spędzenie nieskończonego czasu na naprawie bałaganu. Które podejście jest najlepsze dla firm konsultingowych rozliczających się według godziny?
BillThor
1
@jwenting: Aby umieścić mój wcześniejszy komentarz w kontekście, zalecałem testy jednostkowe na spotkaniu personelu. Obecnie tylko dwóch z nas pisze testy jednostkowe (i musimy to zrobić po cichu). Osobiście nie uważam testów jednostkowych za złote ozdoby i diamentowe ozdoby.
Joshua Smith
1
@shapr: To cholernie przerażająca rzecz, którą można usłyszeć od firmy, która buduje ROCKETS I MISSILES. >: P
Mr. JavaScript
11
Pomimo ogromnych dowodów przeciwnych, ludzie są zwykle bardzo racjonalnymi stworzeniami. Powodem, dla którego ludzie nie stosują najlepszych praktyk, na przykład TDD, jest to, że nie uważają, że będzie warto. Albo uważają, że praktyki nie są w rzeczywistości najlepsze; i że faktycznie będzie ich to kosztować więcej, niż je uratuje. Lub uważają, że korzyść jest tak marginalna, że koszt zmiany przeważy nad niewielką korzyścią. Najważniejsze jest to, że problem najlepszych praktyk jest problemem dolnej linii.
Jeśli chcesz być agentem zmian, Twoim zadaniem jest wykazanie, że ich postrzeganie dolnej linii jest błędne. Musisz pokazać, że najlepsza praktyka naprawdę jest najlepsza. Że korzyści są natychmiastowe i znaczące . Musisz pokazać, że krzywa uczenia się jest wystarczająco mała, aby znieść, i że przynajmniej niektóre korzyści zaczynają się natychmiast.
Jak to pokazujesz? Przyjmując najlepszą praktykę samodzielnie! Nic nie przekonuje innych lepiej niż twoje własne zachowanie. Jeżeli Państwo śledzić najlepszych praktyk i są vocal o nim inni zobaczą, że ty zrobił analizę ekonomiczną i podjął decyzję przeciwną. To sprawi, że ponownie rozważą swoją decyzję. Zrobią to prywatnie i nigdy się do tego nie przyznają. Ale każdy, kto zobaczy cię przy użyciu tej najlepszej praktyki, ponownie zbada swoją pozycję.
To najlepsze, na co możesz liczyć. Jeśli najlepsza praktyka jest najlepszą praktyką, reszta nastąpi automatycznie. Och, to nie będzie szybkie i będzie wiele przeszkód. Przejście będzie powolne i nierówne; i doświadczysz wielu rozczarowań. Ale przejście będzie również nieuniknione i nieuniknione. Może minąć pokolenie, ale najlepsza praktyka będzie wygrać.
Na dowód tego zadaj sobie pytanie, kiedy ostatnio widziałeś, jak ktoś używa goto.
Jest to wynik niewiedzy lub myślenia, że ktoś zna idealną metodę. Ludzie nie wybierają złego pisania kodu; jest to raczej przypadek niewiedzy. Lepszym słowem byłoby „ naiwność ” w przeciwieństwie do „ ignorancji ”.
Najprostszym sposobem na dostosowanie się do dobrej praktyki jest potwierdzenie (najprawdopodobniej) lepszego sposobu napisania właśnie napisanego kodu, a następnie dążenie do nauczenia się, co to jest „lepszy sposób”.
+1 i nie wszyscy programiści otrzymują lub poświęcają wystarczająco dużo czasu na naukę lub odkrywanie lepszych sposobów. dla wielu (kierowników i programistów) jest on odraczany, dopóki nie stanie się przeszkodą, której nie można zignorować. tymczasem rezolucje nie są dość heurystycznie często - wiele osób często przyjmuje zamiast tego istniejące rozwiązanie lub zalecenie. ta praktyka wiąże się z szansą, przybliżeniem i omija większą część procesu uczenia się, który jest niezbędny do zrozumienia. z kolei niezrozumienie (negatywnie) wpływa na zdolność dokonywania lepszych wyborów.
justin
6
Dwie przyczyny
Ignorancja.
Arogancja.
Jak można je pokonać?
Zachęty.
Dopóki menedżerowie (ludzie kupujący umiejętności programisty) nie będą wymagać najlepszych praktyk w ramach dostarczania oprogramowania, nic się nie zmieni. Wiele organizacji jest wyraźnie schizofrenicznych: kształcą programistów w różnych technologiach, a następnie żądają nieprzetestowanego oprogramowania lub niestabilnego projektu. Albo gorzej.
Prawda, że: szczególnie śmiertelna ignorancja + arogancka kombinacja.
Sklivvz,
6
Najlepsza praktyka to dla mnie oprogramowanie napisane przez zespół 8 osób. Nie mieliśmy pisemnych wymagań, recenzji kodu, testów jednostkowych, dokumentów wydania formatu. Bez testowania przez użytkownika końcowego, z tego, co według wszystkich książek wynika, że powinniśmy byli zrobić. Kod został spieszony, błędny i po prostu niemożliwy do utrzymania. Zostało odrzucone 3 lata po wydaniu, było tak źle. Co było w tym takiego wspaniałego. Dwa lata po pierwszym wydaniu właściciel firmy (który sfinansował rozwój hipoteką we własnym domu) odszedł z tylną kieszenią w wysokości 30–40 milionów dolarów.
Często tracimy z oczu fakt, że jesteśmy (częściej niż nie) tutaj, aby tworzyć oprogramowanie, które zarabia pieniądze dla firmy. Firmy nie istnieją, aby zapewnić nam możliwość tworzenia oprogramowania przy użyciu „najlepszych praktyk”, istnieją po to, aby zarabiać pieniądze.
Większość praktyk „najlepszych praktyk” nie poprawia zysków. Te, które robią, powinny i są powszechnie przyjęte. Dlatego „najlepsza praktyka” nie jest praktykowana.
Czy nigdy nie ryzykowałeś i nie grałeś w coś? Nastąpił kryzys czasowy, więc możesz go uruchomić z zamiarem jego refaktoryzacji później (w przeciwieństwie do refaktoryzacji wcześniej). Dla niektórych jest to uważane za dobrą praktykę.
W końcu zostajesz spalony wystarczająco często i zmieniasz swoje sposoby. Pomyśl o wszystkich „najlepszych praktykach”, które istnieją. Czy potrafisz śledzić je wszystkie przez cały czas? Czy ktoś zaprzecza sobie nawzajem? Nie chcesz tracić czasu na obsługę każdej wartości odstającej.
Jeśli napiszę zły kod, który działa i nikt już go nie obejrzy, czy nadal jest uważany za zły? (Proszę nie rujnować filozoficznej debaty, spierając się o to, co to jest „zły kod”).
+1 za to, że otrzymaliśmy kod za pierwsze wyprodukowanie kodu. Mamy dodatkową odpowiedzialność (subiektywnie) uczynienia go utrzymywalnym, po drugie. W końcu - nie płacę ogrodnikowi za utrzymanie kosiarki - to do niego należy. Jeśli wykona dobrą robotę, a jego sprzęt się zatrzyma, zaproszę go z powrotem i oddam mu mój interes.
Pan JavaScript
4
IME to połączenie tego, co powiedzieli inni. Ignorancja („Zawsze korzystałem tylko z DataSets, po co zawracać sobie głowę tymi sprawami LINQ?”, Brak czasu („Szef chce, żeby to zrobiono jak najszybciej, nie możemy poświęcać na to dużo czasu”), brak zrozumienia („Co jest złego w pisaniu całego mojego kodu za kodem?”).
Ironią, którą widzę, jest to, że kiedy zaczynasz tą ścieżką, po prostu zanurzasz się głębiej. Jeśli teraz skrócisz rogi i podrzucisz cały kod aplikacji w plikach ASPX, nigdy nie będziesz w stanie tego naprawić później; nowe rzeczy będą na ciebie rzucane, co oznacza, że musisz to zrobić szybko, co oznacza, że musisz po prostu rzucić cały kod w pliku ASPX (przysięgając, że to kiedyś naprawisz) itp. itd. to nigdy - spirala końcowa, ponieważ nie można już zatrzymać rozwoju i powiedzieć, że najpierw trzeba naprawić.
Często deweloperom po prostu nie pokazano lepszej praktyki lub, co ważniejsze, korzyści płynących ze stosowania lepszej praktyki (zaczynam przestać używać terminu „najlepsze praktyki” z różnych powodów).
Istnieje teoria, że programiści są „celowo leniwi”. Innymi słowy, będą mieli tendencję do wybierania ścieżki najmniejszego oporu.
Gdy szybko pokażesz im zalety lepszej praktyki (takiej jak TDD lub, powiedzmy, przestrzeganie zasad SOLID) i że faktycznie pozwala im to być lepszym (ale nadal „leniwym”) programistą, to zwykle masz wrażenie, że opór topnieje z dala.
Nauczyłem się programowania w krótkiej sesji (2 do 3 godzin). (Właściwie kilka sesji w różnych językach.) Podczas sesji pokazano bardzo dobry kod i wyjaśniono powód pisania kodu w takiej formie, w jakiej był. Żaden z moich „oficjalnych” kursów językowych nigdy nie był bliski wprowadzenia dobrego kodu.
BillThor
„najmniejszy opór” jest dość opisowy. Doświadczeni programiści po prostu lepiej rozumieją, co oznacza „najmniejszy opór” przez cały okres użytkowania aplikacji.
4
(Brak) Wiedzy i umiejętności + Czas na inwestowanie
Dziwi mnie, że nikt inny tego nie wydał, ale może to dla mnie oczywiste, ponieważ tak wiele z mojej pracy było jako programista singletonów, do którego nikt (oprócz stosu) nie mógł się udać, gdy coś mi się podoba. Znam „lepsze” techniki - takie jak TDD - ale często nie rozumiem ich wystarczająco dobrze, aby z nich korzystać i trudno mi znaleźć dobre informacje, które pomogą mi zacząć z nich korzystać. Ponownie, używając TDD jako przykładu, rozumiem jego podstawowe znaczenie - budowanie testów, które potwierdzają, że Twój kod generuje określony wynik - ale czy rzeczywiście go wdrażasz?
Poza tym, że XCode ma teraz wbudowane testy jednostkowe, nie mam pojęcia, od czego zacząć. Czy twierdzę, że widok zawiera przyciski X po uruchomieniu procedury, aby je wykonać? Co powiesz na stwierdzenie, że moje UIViews zostały odpowiednio uporządkowane po wywołaniu tagu obrotu?
Cholera, jak napisać test jednostkowy w XCode? To coś, co muszę poświęcić na naukę.
Tak, zgadzam się, że czasem czas i budżet to pewne ograniczenia, które nie pozwalają na wprowadzenie do programu każdej znanej zasady „lepszego programowania”.
Wiesz, że bieżące zadanie można wykonać w znacznie bardziej niezawodny sposób, gdybyś miał trochę więcej czasu. Ale bardzo niewielu klientów (zwłaszcza jeśli robią pierwszą aplikację na iPhone'a lub swoje pierwsze niestandardowe oprogramowanie do analizy biznesowej) rozumie, kiedy mówisz, że ponownie wdrażasz coś już zrobionego, ponieważ znalazłeś lepszy sposób.
To samo dotyczy testów jednostkowych. Niestety mam jeszcze spotkać klienta, który jest gotów przeznaczyć na nie budżet. Typowa odpowiedź brzmi: „Automatyczne testy regresji OK. Rozumiem, ale testy jednostkowe? Nie mamy na to czasu! Musimy szybko dotrzeć na rynek! ”
Nigdy nie proszę klientów o przeznaczenie czasu na testy jednostkowe, ale uważam to za część zadania. Nakłanianie klientów do przeprowadzania testów jednostkowych tylko zachęca klientów do mikro zarządzania pracą. Po naprawie samochodu mechanicy nie pytają cię, jakich narzędzi powinien użyć, aby wykonać zadanie !! to samo dotyczy testów jednostkowych, musisz ocenić odpowiednią równowagę testów, które Twoim zdaniem są konieczne do prawidłowego wykonania zadania.
Newtopian
Niestety, lepsze techniki programowania mogą być szybsze niż techniki, na których ulepszenie nie możesz sobie pozwolić.
BillThor
2
Dwie części w większości moich doświadczeń:
czas
zachęcenie wystarczającej liczby osób do uzgodnienia, jakie praktyki są najlepsze w obecnej sytuacji
„Najlepsze praktyki” są BARDZO subiektywne w wielu rzeczywistych sytuacjach. Jeśli jedna połowa zespołu próbuje zrobić kilka SOLID & TDD, podczas gdy druga połowa pracuje 60 godzin tygodniowo, aby zaoszczędzić kilka sekund czasu trwania tu i tam za pomocą wszelkich niezbędnych środków, ponieważ minęło już miejsce, w którym jest za późno, aby przeprojektuj coś, co nie będzie działać na czas na następne wydanie, nie zajdziesz daleko.
Nawet jeśli nie doświadczasz zbyt dużego rozbieżności w zespole, dużo wysiłku wymaga formalne porozumienie, dokumentacja i szkolenie w zakresie polityki, którą zdecydujesz się zastosować. Jest to duży blok nieproduktywnego czasu z biznesowego punktu widzenia, który trzeba będzie dokładnie uzasadnić.
Czasami przekonasz się, że nawyk w znacznym stopniu przyczynia się do pisania okropnego kodu.
Możesz być bardzo doświadczonym programistą i możesz wiedzieć wszystko o obecnych najlepszych praktykach branżowych. Do diabła, mógł być nawet ekspert o takich rzeczach. Doświadczenie mówi mi, że tacy ludzie często nie piszą okropnego kodu, a jednak łatwo jest wrócić do starych nawyków i zrobić coś, o czym wiesz, że złamie zasady, po prostu dlatego, że jest to bezpieczne i wygodne. W takich przypadkach ignorancja i arogancja oraz wszystkie inne przymiotniki wskazujące na palce, które możesz wymyślić, nie mają tak naprawdę znaczenia. Niekoniecznie tacy programiści są szczególnie źli w tym, co robią (chociaż częściej tak się dzieje), a nawet, że chcą stworzyć okropny bałagan.
To niefortunne, że osobiście byłem świadkiem tego, że dzieje się to więcej razy, niż chciałbym policzyć, w którym niektórzy prawdziwie utalentowani ludzie wyrzucali zwykłe śmieci, ponieważ ich palce i mózgi działały na auto przez kilka miesięcy. Najczęściej w tym miejscu widać oznaki wypalenia zawodowego, żalu i stresu. Czasami tak naprawdę jest to po prostu ślepy nawyk noszenia ich przez codzienne ruchy. Nauczyłem się uważnie obserwować, aby niepotrzebnie nie ryzykować oznaczania osób wymagających szczególnego traktowania.
Tylko trochę do przemyślenia dla tych z nas, którym łatwiej jest po prostu przeskoczyć do negatywnych wniosków ... mimo że niestety masz rację częściej niż nie.
Nikt nie wykazuje odsetek do zapłacenia za projekt o nazwie coś przy refaktoryzacji. Musi zawierać kilka słów, które odwołują się do interesów „biznesowych”. Słowa takie jak odnawianie, odświeżanie, remake, aktualizacja cyklu życia itp. Działają w moim miejscu pracy. Prawie wszystkie mają refaktoryzację jako główną część projektu.
Niestety, dzięki ekonomicznemu zabójcy praca odbywa się tylko wtedy, gdy jest wynagrodzenie. Nawet jeśli praca ma na celu tylko ocalenie fortuny biznesowej na dłuższą metę.
Odpowiedzi:
Odporność na zmiany.
To główny czynnik powodujący ignorancję, złe zarządzanie itp.
Rozdział 30 Peopleware 2nd Edition poświęcony jest temu tematowi. I cytuje z książki innego dość znanego konsultanta, napisanego nieco wcześniej:
DeMarco i Lister nadal powtarzają mantrę, aby pamiętać o tym, zanim poprosą ludzi o zmianę:
Proces zmian rzadko jest prostym i płynnym przejściem z obecnych nieoptymalnych warunków do nowego, ulepszonego świata. W przypadku każdej nietrywialnej zmiany zawsze pojawia się okres zamieszania i chaosu przed przybyciem do nowego status quo . Uczenie się nowych narzędzi, procesów i sposobów myślenia jest trudne i wymaga czasu. Podczas tego okresu przejściowego spada produktywność, cierpi morale, ludzie mogą narzekać i żałować, że tylko można wrócić do starych dobrych sposobów robienia rzeczy. Bardzo często to robią, nawet przy wszystkich problemach, ponieważ uważają, że dobre znane dobre problemy są lepsze niż nowe, nieznane, frustrujące i kłopotliwe problemy. Jest to opór, który trzeba taktownie i delikatnie, ale zdecydowanie pokonać, aby odnieść sukces.
Z cierpliwością i wytrwałością ostatecznie zespół przechodzi z Chaosu do następnego etapu, Ćwiczenia i Integracja. Ludzie, choć nie do końca czują się dobrze z nowymi narzędziami / procesami, zaczynają je rozumieć. Mogą wystąpić pozytywne doświadczenia „Aha”. I stopniowo zespół osiąga nowy status quo.
Naprawdę ważne jest, aby zdać sobie sprawę, że chaos jest integralną, nieuniknioną częścią procesu zmian . Bez tej wiedzy - i przygotowania do niej - można wpadać w panikę po wejściu w fazę Chaosu i pomylić ją z nowym status quo. Następnie proces zmiany zostaje porzucony, a zespół wraca do wcześniejszego nieszczęśliwego stanu, ale z jeszcze mniejszą nadzieją na kiedykolwiek coś poprawić ...
Dla porównania, opisane powyżej fazy zostały pierwotnie zdefiniowane w Modelu Zmiany Satir (nazwanym na cześć Virginii Satir ).
źródło
Péter Török ma rację, ale pominął jeden ważny i optymistyczny punkt:
więc zaangażujcie ich, pozwólcie im wnieść pomysły, pozwólcie im stworzyć stawkę, a to nie będzie tak bolesne
Uwaga: dotyczy to programowania, ponieważ wiele udanych technicznie projektów oprogramowania kończy się niepowodzeniem, ponieważ użytkownicy je odrzucają .
źródło
Czas wydaje się być duży, w którym pracuję.
np. Po co stosować testowanie jednostkowe, gdy trzeba napisać więcej kodu, a więc uzyskanie produktu, który można wydać, zajmuje więcej czasu? Klient x chce tego teraz! Koduj szybciej!
(To oczywiście nie kończy się dobrze)
Jest to również wynikiem złego zarządzania i ekonomii, niewystarczającego obciążenia klientów, aby pozwolić sobie na poświęcenie czasu na robienie tego dobrze.
źródło
Pomimo ogromnych dowodów przeciwnych, ludzie są zwykle bardzo racjonalnymi stworzeniami. Powodem, dla którego ludzie nie stosują najlepszych praktyk, na przykład TDD, jest to, że nie uważają, że będzie warto. Albo uważają, że praktyki nie są w rzeczywistości najlepsze; i że faktycznie będzie ich to kosztować więcej, niż je uratuje. Lub uważają, że korzyść jest tak marginalna, że koszt zmiany przeważy nad niewielką korzyścią. Najważniejsze jest to, że problem najlepszych praktyk jest problemem dolnej linii.
Jeśli chcesz być agentem zmian, Twoim zadaniem jest wykazanie, że ich postrzeganie dolnej linii jest błędne. Musisz pokazać, że najlepsza praktyka naprawdę jest najlepsza. Że korzyści są natychmiastowe i znaczące . Musisz pokazać, że krzywa uczenia się jest wystarczająco mała, aby znieść, i że przynajmniej niektóre korzyści zaczynają się natychmiast.
Jak to pokazujesz? Przyjmując najlepszą praktykę samodzielnie! Nic nie przekonuje innych lepiej niż twoje własne zachowanie. Jeżeli Państwo śledzić najlepszych praktyk i są vocal o nim inni zobaczą, że ty zrobił analizę ekonomiczną i podjął decyzję przeciwną. To sprawi, że ponownie rozważą swoją decyzję. Zrobią to prywatnie i nigdy się do tego nie przyznają. Ale każdy, kto zobaczy cię przy użyciu tej najlepszej praktyki, ponownie zbada swoją pozycję.
To najlepsze, na co możesz liczyć. Jeśli najlepsza praktyka jest najlepszą praktyką, reszta nastąpi automatycznie. Och, to nie będzie szybkie i będzie wiele przeszkód. Przejście będzie powolne i nierówne; i doświadczysz wielu rozczarowań. Ale przejście będzie również nieuniknione i nieuniknione. Może minąć pokolenie, ale najlepsza praktyka będzie wygrać.
Na dowód tego zadaj sobie pytanie, kiedy ostatnio widziałeś, jak ktoś używa goto.
źródło
Jest to wynik niewiedzy lub myślenia, że ktoś zna idealną metodę. Ludzie nie wybierają złego pisania kodu; jest to raczej przypadek niewiedzy. Lepszym słowem byłoby „ naiwność ” w przeciwieństwie do „ ignorancji ”.
Najprostszym sposobem na dostosowanie się do dobrej praktyki jest potwierdzenie (najprawdopodobniej) lepszego sposobu napisania właśnie napisanego kodu, a następnie dążenie do nauczenia się, co to jest „lepszy sposób”.
źródło
Dwie przyczyny
Ignorancja.
Arogancja.
Jak można je pokonać?
Dopóki menedżerowie (ludzie kupujący umiejętności programisty) nie będą wymagać najlepszych praktyk w ramach dostarczania oprogramowania, nic się nie zmieni. Wiele organizacji jest wyraźnie schizofrenicznych: kształcą programistów w różnych technologiach, a następnie żądają nieprzetestowanego oprogramowania lub niestabilnego projektu. Albo gorzej.
źródło
Najlepsza praktyka to dla mnie oprogramowanie napisane przez zespół 8 osób. Nie mieliśmy pisemnych wymagań, recenzji kodu, testów jednostkowych, dokumentów wydania formatu. Bez testowania przez użytkownika końcowego, z tego, co według wszystkich książek wynika, że powinniśmy byli zrobić. Kod został spieszony, błędny i po prostu niemożliwy do utrzymania. Zostało odrzucone 3 lata po wydaniu, było tak źle. Co było w tym takiego wspaniałego. Dwa lata po pierwszym wydaniu właściciel firmy (który sfinansował rozwój hipoteką we własnym domu) odszedł z tylną kieszenią w wysokości 30–40 milionów dolarów.
Często tracimy z oczu fakt, że jesteśmy (częściej niż nie) tutaj, aby tworzyć oprogramowanie, które zarabia pieniądze dla firmy. Firmy nie istnieją, aby zapewnić nam możliwość tworzenia oprogramowania przy użyciu „najlepszych praktyk”, istnieją po to, aby zarabiać pieniądze.
Większość praktyk „najlepszych praktyk” nie poprawia zysków. Te, które robią, powinny i są powszechnie przyjęte. Dlatego „najlepsza praktyka” nie jest praktykowana.
źródło
Dopuszczalne ryzyko
Czy nigdy nie ryzykowałeś i nie grałeś w coś? Nastąpił kryzys czasowy, więc możesz go uruchomić z zamiarem jego refaktoryzacji później (w przeciwieństwie do refaktoryzacji wcześniej). Dla niektórych jest to uważane za dobrą praktykę.
W końcu zostajesz spalony wystarczająco często i zmieniasz swoje sposoby. Pomyśl o wszystkich „najlepszych praktykach”, które istnieją. Czy potrafisz śledzić je wszystkie przez cały czas? Czy ktoś zaprzecza sobie nawzajem? Nie chcesz tracić czasu na obsługę każdej wartości odstającej.
Jeśli napiszę zły kod, który działa i nikt już go nie obejrzy, czy nadal jest uważany za zły? (Proszę nie rujnować filozoficznej debaty, spierając się o to, co to jest „zły kod”).
źródło
IME to połączenie tego, co powiedzieli inni. Ignorancja („Zawsze korzystałem tylko z DataSets, po co zawracać sobie głowę tymi sprawami LINQ?”, Brak czasu („Szef chce, żeby to zrobiono jak najszybciej, nie możemy poświęcać na to dużo czasu”), brak zrozumienia („Co jest złego w pisaniu całego mojego kodu za kodem?”).
Ironią, którą widzę, jest to, że kiedy zaczynasz tą ścieżką, po prostu zanurzasz się głębiej. Jeśli teraz skrócisz rogi i podrzucisz cały kod aplikacji w plikach ASPX, nigdy nie będziesz w stanie tego naprawić później; nowe rzeczy będą na ciebie rzucane, co oznacza, że musisz to zrobić szybko, co oznacza, że musisz po prostu rzucić cały kod w pliku ASPX (przysięgając, że to kiedyś naprawisz) itp. itd. to nigdy - spirala końcowa, ponieważ nie można już zatrzymać rozwoju i powiedzieć, że najpierw trzeba naprawić.
źródło
Często deweloperom po prostu nie pokazano lepszej praktyki lub, co ważniejsze, korzyści płynących ze stosowania lepszej praktyki (zaczynam przestać używać terminu „najlepsze praktyki” z różnych powodów).
Istnieje teoria, że programiści są „celowo leniwi”. Innymi słowy, będą mieli tendencję do wybierania ścieżki najmniejszego oporu.
Gdy szybko pokażesz im zalety lepszej praktyki (takiej jak TDD lub, powiedzmy, przestrzeganie zasad SOLID) i że faktycznie pozwala im to być lepszym (ale nadal „leniwym”) programistą, to zwykle masz wrażenie, że opór topnieje z dala.
To kwestia edukacji :)
źródło
(Brak) Wiedzy i umiejętności + Czas na inwestowanie
Dziwi mnie, że nikt inny tego nie wydał, ale może to dla mnie oczywiste, ponieważ tak wiele z mojej pracy było jako programista singletonów, do którego nikt (oprócz stosu) nie mógł się udać, gdy coś mi się podoba. Znam „lepsze” techniki - takie jak TDD - ale często nie rozumiem ich wystarczająco dobrze, aby z nich korzystać i trudno mi znaleźć dobre informacje, które pomogą mi zacząć z nich korzystać. Ponownie, używając TDD jako przykładu, rozumiem jego podstawowe znaczenie - budowanie testów, które potwierdzają, że Twój kod generuje określony wynik - ale czy rzeczywiście go wdrażasz?
Poza tym, że XCode ma teraz wbudowane testy jednostkowe, nie mam pojęcia, od czego zacząć. Czy twierdzę, że widok zawiera przyciski X po uruchomieniu procedury, aby je wykonać? Co powiesz na stwierdzenie, że moje UIViews zostały odpowiednio uporządkowane po wywołaniu tagu obrotu?
Cholera, jak napisać test jednostkowy w XCode? To coś, co muszę poświęcić na naukę.
źródło
@Zues i @Joshua Smith
Tak, zgadzam się, że czasem czas i budżet to pewne ograniczenia, które nie pozwalają na wprowadzenie do programu każdej znanej zasady „lepszego programowania”.
Wiesz, że bieżące zadanie można wykonać w znacznie bardziej niezawodny sposób, gdybyś miał trochę więcej czasu. Ale bardzo niewielu klientów (zwłaszcza jeśli robią pierwszą aplikację na iPhone'a lub swoje pierwsze niestandardowe oprogramowanie do analizy biznesowej) rozumie, kiedy mówisz, że ponownie wdrażasz coś już zrobionego, ponieważ znalazłeś lepszy sposób.
To samo dotyczy testów jednostkowych. Niestety mam jeszcze spotkać klienta, który jest gotów przeznaczyć na nie budżet. Typowa odpowiedź brzmi: „Automatyczne testy regresji OK. Rozumiem, ale testy jednostkowe? Nie mamy na to czasu! Musimy szybko dotrzeć na rynek! ”
źródło
Dwie części w większości moich doświadczeń:
„Najlepsze praktyki” są BARDZO subiektywne w wielu rzeczywistych sytuacjach. Jeśli jedna połowa zespołu próbuje zrobić kilka SOLID & TDD, podczas gdy druga połowa pracuje 60 godzin tygodniowo, aby zaoszczędzić kilka sekund czasu trwania tu i tam za pomocą wszelkich niezbędnych środków, ponieważ minęło już miejsce, w którym jest za późno, aby przeprojektuj coś, co nie będzie działać na czas na następne wydanie, nie zajdziesz daleko.
Nawet jeśli nie doświadczasz zbyt dużego rozbieżności w zespole, dużo wysiłku wymaga formalne porozumienie, dokumentacja i szkolenie w zakresie polityki, którą zdecydujesz się zastosować. Jest to duży blok nieproduktywnego czasu z biznesowego punktu widzenia, który trzeba będzie dokładnie uzasadnić.
źródło
Czasami przekonasz się, że nawyk w znacznym stopniu przyczynia się do pisania okropnego kodu.
Możesz być bardzo doświadczonym programistą i możesz wiedzieć wszystko o obecnych najlepszych praktykach branżowych. Do diabła, mógł być nawet ekspert o takich rzeczach. Doświadczenie mówi mi, że tacy ludzie często nie piszą okropnego kodu, a jednak łatwo jest wrócić do starych nawyków i zrobić coś, o czym wiesz, że złamie zasady, po prostu dlatego, że jest to bezpieczne i wygodne. W takich przypadkach ignorancja i arogancja oraz wszystkie inne przymiotniki wskazujące na palce, które możesz wymyślić, nie mają tak naprawdę znaczenia. Niekoniecznie tacy programiści są szczególnie źli w tym, co robią (chociaż częściej tak się dzieje), a nawet, że chcą stworzyć okropny bałagan.
To niefortunne, że osobiście byłem świadkiem tego, że dzieje się to więcej razy, niż chciałbym policzyć, w którym niektórzy prawdziwie utalentowani ludzie wyrzucali zwykłe śmieci, ponieważ ich palce i mózgi działały na auto przez kilka miesięcy. Najczęściej w tym miejscu widać oznaki wypalenia zawodowego, żalu i stresu. Czasami tak naprawdę jest to po prostu ślepy nawyk noszenia ich przez codzienne ruchy. Nauczyłem się uważnie obserwować, aby niepotrzebnie nie ryzykować oznaczania osób wymagających szczególnego traktowania.
Tylko trochę do przemyślenia dla tych z nas, którym łatwiej jest po prostu przeskoczyć do negatywnych wniosków ... mimo że niestety masz rację częściej niż nie.
źródło
Nikt nie wykazuje odsetek do zapłacenia za projekt o nazwie coś przy refaktoryzacji. Musi zawierać kilka słów, które odwołują się do interesów „biznesowych”. Słowa takie jak odnawianie, odświeżanie, remake, aktualizacja cyklu życia itp. Działają w moim miejscu pracy. Prawie wszystkie mają refaktoryzację jako główną część projektu.
Niestety, dzięki ekonomicznemu zabójcy praca odbywa się tylko wtedy, gdy jest wynagrodzenie. Nawet jeśli praca ma na celu tylko ocalenie fortuny biznesowej na dłuższą metę.
źródło