Jakie są przeszkody w stosowaniu najlepszych praktyk? Jak można je pokonać? [Zamknięte]

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?

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

Dla porównania, opisane powyżej fazy zostały pierwotnie zdefiniowane w Modelu Zmiany Satir (nazwanym na cześć Virginii Satir ).

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

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.

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

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.

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.

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

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.

To kwestia edukacji :)

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

@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! ”

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