Od czasu do czasu zastanawiam się nad tym pytaniem. Chcę robić rzeczy we właściwy sposób: pisać czysty, zrozumiały i poprawny kod, który jest łatwy w utrzymaniu. W końcu jednak piszę łatkę na łatce; tylko dlatego, że nie ma czasu, klienci czekają, błąd należy naprawić z dnia na dzień, firma traci pieniądze na ten problem, kierownik mocno naciska itp. itp.
Wiem doskonale, że na dłuższą metę tracę więcej czasu na te plastry, ale ponieważ ten czas obejmuje miesiące pracy, nikogo to nie obchodzi. Ponadto, jak mawiał jeden z moich menedżerów: „nie wiemy, czy będzie to długoterminowe, jeśli nie naprawimy go teraz”.
Jestem pewien, że nie jestem jedynym uwięzionym w tych nieskończonych cyklach wyboru rzeczywistego / idealnego. Jak więc sobie radzicie, moi koledzy, programiści?
AKTUALIZACJA: Dziękuję wszystkim za tę interesującą dyskusję. To smutne, że tak wiele osób musi codziennie wybierać między ilością a jakością swojego kodu. Mimo to, zaskakująco wiele osób uważa, że można wygrać tę bitwę, więc dziękuję wszystkim za tę zachętę.
Odpowiedzi:
W rzeczywistości jest to bardzo trudne pytanie, ponieważ nie ma absolutnie właściwej odpowiedzi. W naszej organizacji wprowadziliśmy lepsze procesy w celu uzyskania lepszego kodu. Zaktualizowaliśmy nasze standardy kodowania, aby odzwierciedlić, w jaki sposób, jako grupa, piszemy kod, i ustanowiliśmy bardzo silną pętlę testowania / refaktoryzacji / projektowania / kodu. Dostarczamy w sposób ciągły lub przynajmniej staramy się. Przynajmniej mamy coś do pokazania interesariuszom co dwa tygodnie. Uważamy, że jesteśmy rzemieślnikami oprogramowania, a morale jest wysokie. Ale pomimo tych wszystkich kontroli i równowagi mamy ten sam problem, co ty.
Pod koniec dnia dostarczamy produkt płatnemu klientowi. Ten klient ma potrzeby i oczekiwania, realistyczne lub nie. Często zespół sprzedaży wpędza nas w kłopoty tylko po to, aby otrzymać prowizję. Czasami klient ma rzeczywiste oczekiwania, które są nierealne lub wymagają zmiany, nawet jeśli mamy podpisaną umowę. Czasy się zdarzają. Może się zdarzyć WOM i stracone dni podczas sprintu. Kulminacją wszelkiego rodzaju drobiazgów jest sytuacja, w której musimy wpaść w zagadkę „zrób to dobrze” lub „zrób to jak najszybciej”. Prawie zawsze jesteśmy zmuszeni „zrobić to jak najszybciej”.
Jako rzemieślnicy oprogramowania, programiści, programiści, ludzie kodujący pracę - naszą naturalną skłonnością jest „robić to dobrze”. „Zrób to jak najszybciej” to, co dzieje się, gdy pracujemy, aby przetrwać, jak większość z nas. Bilans jest trudny.
Zawsze zaczynam od podejścia do zarządzania (jestem dyrektorem ds. Rozwoju oprogramowania i aktywnym programistą w tej grupie), aby bronić harmonogramu, zespołu i wykonywanej pracy. Zwykle w tym momencie mówi mi się, że klient musi to mieć teraz i musi działać. Kiedy wiem, że nie ma miejsca na negocjacje ani dawanie, wracam i współpracuję z zespołem, aby zobaczyć, jakie rogi można skrócić. Nie poświęcę jakości w funkcji, która napędza potrzebę klienta, aby jak najszybciej, ale coś pójdzie i zostanie zepchnięty do kolejnego sprintu. To prawie zawsze jest OK.
Jeśli nie możesz dostarczyć, ponieważ jest tak wiele błędów, jakość kodu jest zła i pogarsza się, a terminy są coraz krótsze, wtedy znajdujesz się w innej sytuacji niż to, co opisuję. W takim przypadku obecne lub wcześniejsze niewłaściwe zarządzanie, złe praktyki programistyczne, które doprowadziły do złej jakości kodu lub inne czynniki mogą zabrać cię na marsz śmierci.
Uważam, że staram się bronić dobrego kodu i najlepszych praktyk, aby zacząć wyciągać firmę z rowów. Jeśli nie ma ani jednego kolegi chętnego do wysłuchania grupy lub pójścia na nią wbrew kierownictwu, być może nadszedł czas, aby zacząć szukać nowej pracy.
W końcu prawdziwe życie przebija wszystko. Jeśli pracujesz dla firmy, która musi sprzedawać to, co rozwijasz, codziennie spotkasz się z tym kompromisem. Tylko starając się wcześnie osiągnąć dobre zasady programowania, udało mi się wyprzedzić krzywą jakości kodu.
Push i pull między deweloperami a sprzedawcami przypomina mi żart. „Jaka jest różnica między sprzedawcą używanych samochodów a sprzedawcą oprogramowania? Przynajmniej sprzedawca używanych samochodów wie, że kłamie”. Utrzymuj podbródek i staraj się „postępować właściwie”.
źródło
W mojej karierze zdałem sobie sprawę, że zawsze jest czas, aby zrobić to dobrze. Tak, twój menedżer może naciskać. Klient może być wkurzony. Ale nie wiedzą, jak długo to trwa. Jeśli ty (twój zespół deweloperów) tego nie zrobisz, nie da się tego zrobić; utrzymujesz całą dźwignię.
Ponieważ wiesz, co tak naprawdę spowoduje, że Twój menedżer zmusi Ciebie lub Twojego klienta do wkurzenia? Niska jakość .
źródło
Sprowadza się to do tego, co zacząłem myśleć o „Wiecznym konflikcie” (między biznesem a inżynierią). Nie mam rozwiązania, ponieważ jest to problem, który nigdy nie ustępuje, ale możesz robić rzeczy, które pomogą złagodzić.
Ludzie często nie zdają sobie sprawy, że jako inżynierowie zakładamy, że problem „udanego biznesu” jest zawsze podany. Chcemy, aby nasz kod był ładny, schludny i łatwy w utrzymaniu, abyśmy mogli szybko dodawać nowe funkcje i poprawiać istniejące, przy minimalnej liczbie klientów wykonujących dla nas kontrolę jakości, odkrywając dziwaczne przypadki, które zostałyby udaremnione przez lepszy kod. Utrzymywanie klientów i utrzymywanie przewagi konkurencyjnej dzięki funkcjom i finezji, których nikt inny nie jest w stanie wyprodukować wystarczająco szybko, to zarówno wygrane biznesowe, do których dobry kod bezpośrednio przyczynia się i informuje wiele z powodów, dla których chcemy przede wszystkim lepszego kodu.
Więc przeliteruj to. „Chcemy wykonać X w naszej bazie kodu, ponieważ jeśli tego nie zrobimy, wpłynie to negatywnie na biznes z powodu Y” lub „… ponieważ zwiększy naszą zdolność do pozostania konkurencyjnym poprzez poprawę naszej zdolności do szybszego wprowadzania nowych ulepszeń i funkcji . ”
I staraj się uzyskać namacalne dowody na to, że udoskonalenia działają. Jeśli ulepszenie jakiegoś podzbioru aplikacji spowodowało szybsze działanie / ulepszenie, sprawdź, jakie narzędzie zaległości, którego możesz użyć, jest tego dowodem i wskaż je na odpowiednich spotkaniach.
Ego są często problemem. Jedną rzeczą, której zespoły inżynierskie bardzo potrzebują, jest ustalenie wartości uzgodnionego spójnego podejścia do rozwiązywania określonych rodzajów problemów w stosunku do każdego, kto robi swój własny puchar Kool Aid d'jour, ponieważ wiedzą lepiej. Można wierzyć, że preferencje drugiego faceta są gorsze niż twoje, ale cenisz sobie konsekwencję w stosunku do bycia bardziej właściwym, jeśli jego podejście jest wykonalne i jest to argument, którego nie możesz wygrać. Kompromis ze względu na spójność jest kluczem. Kiedy rzeczy są spójne, trudniej jest je zrobić źle, ponieważ konsekwentnie ustalony sposób będzie zwykle najszybszy.
Istnieją dwie szkoły frameworków / zestawów narzędzi / bibliotek / cokolwiek innego. „Ustaw dla mnie 99%, więc muszę wiedzieć / robić bardzo mało” vs. stosować raczej na zasadzie marchewki niż na patyczku. ” Sprzyjaj drugiemu. Elastyczności i szczegółowej kontroli nigdy nie należy poświęcać przy ołtarzu szybkiego zwrotu, ponieważ dziwne: „nie możemy tego zrobić, ponieważ nasze własne narzędzia nam na to nie pozwolą”, nigdy nie jest akceptowalną odpowiedzią, a pytanie zawsze będzie wymyślić trywialna / jednorazowa inżynieria produktu. Z mojego doświadczenia wynika, że nieelastyczne narzędzia prawie zawsze są rozwalane na oścież lub pracują nieelegancko i robią wielkiego giganta, którego nie da się utrzymać. Częściej niż nie elastyczne / łatwiejsze do modyfikacji rozwiązania są tak samo lub bardzo szybkie w krótkim okresie, niezależnie od tego. Szybkie, elastyczne i łatwe w utrzymaniu są możliwe dzięki odpowiednim narzędziom.
Wydaje mi się, że jest to pytanie z perspektywy programisty, ale byłem w zbyt wielu sytuacjach, w których decyzje technologiczne były podejmowane przy zerowym wkładzie inżyniera. Co to do diabła jest? Tak, ktoś ostatecznie musi zadzwonić, ale uzyskać kwalifikowane opinie, jeśli jesteś nietechnicznym menedżerem, a nie to, co mówi sprzedawca lub strona demonstracyjna na temat własnych produktów. Wszystko, co obiecuje zaoszczędzić ci pieniądze, ponieważ ludzie nie muszą być tak mądrzy lub dlatego, że chroni programistów przed sobą, jest brudnym, brudnym kłamstwem. Zatrudnij talent, któremu możesz zaufać. Powiedz im, co chcesz ze stosu lub innego rozwiązania technologicznego, i poważnie podejmij ich uwagi, zanim zdecydujesz, na który modowy pas technologiczny wskoczyć.
Narzędzia są do wdrożenia i jako takie mogą ci pomóc, ale priorytetem musi być architektura bez względu na zestaw zabawek, które masz do budowania tej architektury. Pod koniec dnia KISS i DRY oraz wszystkie doskonałe filozofie, które wywodzą się z tych kwestii, są ważniejsze niż to, czy jest to .NET czy Java, a może coś, co jest zarówno wolne, jak i nie jest do bani.
Kiedy strona dziwna nalega, abyś zrobił to źle, zapisz ten e-mail, szczególnie w tej części, w której powiedziałeś, dlaczego to cię kosztuje. Kiedy wszystkie twoje prognozy się sprawdzą i pojawią się poważne, szkodliwe dla biznesu problemy, wtedy masz mnóstwo argumentów za poważniejszym traktowaniem problemów inżynierów. Ale czas ostrożnie. W środku płonącego piekła jest zły czas na „tak ci powiedziałem” na temat przestrzegania kodu ogniowego. Wygaś ogień i przenieś swoją listę wcześniej ignorowanych obaw na retrospektywne spotkanie / rozmowę i staraj się skupiać na problemach technicznych wyrażonych i zignorowanych oraz rozumowaniu, które rozumiesz, dlaczego były ignorowane, a nie imiona i nazwiska rzeczywistych ludzi podejmowanie decyzji o zignorowaniu. Jesteś inżynierem Trzymaj się problemów, nie ludzi. „ Wyraziliśmy zaniepokojenie z powodu X, ponieważ baliśmy się, że doprowadzi to do problemów z Y. Powiedziano nam Z i żebyśmy się tym nie zajmowali. ”
źródło
Jest tylko jedno rozwiązanie. Zarezerwuj około 10-20% czasu projektu / pracy na refaktoryzację. Jeśli trudno jest przekonać kierownictwo, że jest to uzasadnione zadanie, daj im jedyny prawdziwy argument: bez refaktoryzacji koszty utrzymania kodu będą rosły wykładniczo z czasem. Dobrze jest mieć kilka wskaźników / artykułów / wyników badań na poparcie tej tezy podczas spotkania z kierownikiem :)
Edycja: istnieje kilka dobrych zasobów na temat „refaktoryzacji kontra rosnące koszty utrzymania” wspomnianych w niniejszym oficjalnym dokumencie: http://www.omnext.net/downloads/Whitepaper_Omnext.pdf
źródło
Ilekroć masz czas na zrobienie czegoś dobrze, użyj go - napisz najlepszy kod, jaki możesz, i stale go ulepszaj. Nie rób trudniejszej pracy, pozostając niechlujnym i wprowadzając dług techniczny, gdy nie ma takiej potrzeby.
Telefony alarmowe w celu naprawienia poważnego błędu nie są rzeczami, którymi sam możesz kontrolować, kiedy wystąpią, musisz zareagować jak najszybciej, to jest życie. Oczywiście, jeśli masz wrażenie, że cała twoja praca składa się z połączeń alarmowych i nigdy nie masz wystarczająco dużo czasu, aby zrobić dobrze, to jesteś na drodze do wypalenia i powinieneś porozmawiać z szefem.
Jeśli to nie pomoże, nadal istnieje „strategia Scotty'ego”, aby uzyskać wystarczająco dużo czasu na właściwe działania: pomnóż wszystkie swoje szacunki przez współczynnik 4:
http://blogs.popart.com/2007/07/what-scotty-from-star-trek-can-teach-us-about-managing-expectations/
źródło
Widzę moją pracę jako dostarczanie oprogramowania najlepszej jakości, które jest możliwe w ramach ograniczeń czasowych dozwolonych dla projektu. Jeśli obawiam się, że poziom jakości będzie niski, zaangażuję właściciela projektu. Opisuję swoje obawy i omawiam potencjalne ryzyko związane z wdrażaniem oprogramowania w tym stanie. W tym momencie wydarzy się jedna z 3 rzeczy:
Właściciel projektu nie będzie chciał zaakceptować ryzyka i cofnie harmonogram, abyśmy mogli poświęcić więcej czasu na jakość oprogramowania.
Właściciel projektu nie będzie chciał zaakceptować ryzyka, ale nie może cofnąć harmonogramu. Jeśli tak się stanie, musimy negocjować, które funkcje / funkcje należy usunąć z zakresu projektu, aby spędzić więcej czasu na jakości oprogramowania dla głównych części aplikacji.
Właściciel projektu zaakceptuje ryzyko, a oprogramowanie niskiej jakości wyjdzie na czas. Czasami ryzyko biznesowe braku wdrożenia (lub wdrożenia późnego) jest znacznie większe niż ryzyko biznesowe związane z wdrożeniem oprogramowania niskiej jakości i tylko właściciel projektu może podjąć taką decyzję.
Oprogramowanie do pisania przypomina malowanie portretu. Nie można powiedzieć, że portret wykonano „dobrze” lub „perfekcyjnie”. Idealny jest wrogiem zrobionych. Możesz dosłownie spędzić 1 miesiąc pracując nad jedną metodą, a niektórzy nadal nie uważają jej za „idealną”. Moim zadaniem jest namalowanie portretu, z którego klient jest zadowolony.
źródło
To nie zadziała w każdym przypadku, ale miałem trochę szczęścia w stosowaniu tej strategii, jeśli problemem jest zepsuty problem z produkcją, który należy pilnie rozwiązać. Oszacuj czas na szybką poprawkę, aby uruchomić produkcję i czas na poprawkę jakości na przyszłość. Przedstaw swoje prognozy swojemu szefowi / klientowi i uzyskaj czas zatwierdzony dla obu. Następnie wykonujesz szybką poprawkę, aby uruchomić produkcję, a długoterminową naprawę natychmiast po zakończeniu pilnej presji czasu. Uważam, że jeśli przedstawię to, ponieważ potrzebuję tego czasu, aby dobrze wykonać pracę, ale mogę wprowadzić tymczasową poprawkę, dopóki nie będę mógł tego zrobić, że moim klientom podobają się takie podejścia. Ponownie uruchamia prod i zaspokaja długoterminową potrzebę.
źródło
Optymalną równowagą może być poświęcenie tyle dodatkowego czasu, aby zrobić to dobrze, ile zmarnowałbyś naprawianie błędów, które eliminujesz, robiąc to dobrze. Unikaj pozłacania roztworu. W większości przypadków dobrze wykonane rozwiązanie Volkswagena jest tak dobre, jak rozwiązanie Cadillac. Zwykle możesz dokonać aktualizacji później, gdy okaże się, że potrzebujesz Cadillaca.
Naprawianie kodu, który nie przestrzegał najlepszych praktyk, często trwa znacznie dłużej. Próba znalezienia skąd pochodzi wartość null, gdy wywołanie wygląda jak abcde (), może zająć dużo czasu.
Zastosowanie DRY i ponowne użycie istniejącego kodu jest zwykle znacznie szybsze niż kodowanie i testowanie jeszcze innego rozwiązania. Ułatwia także wprowadzanie zmian, gdy się pojawią. Musisz tylko zmienić i przetestować jeden zestaw kodu, a nie dwa, trzy lub dwadzieścia.
Cel dla solidnego kodu podstawowego. Wiele czasu można zmarnować, próbując uczynić go idealnym. Istnieją najlepsze praktyki, które prowadzą do szybkiego kodu, ale niekoniecznie najszybszego. Poza tym, próba przewidywania wąskich gardeł i optymalizacji kodu podczas jego tworzenia może być zmarnowanym czasem. Co gorsza, optymalizacja może spowolnić kod.
Jeśli to możliwe, zapewnij minimalne działające rozwiązanie. Widziałem tygodnie zmarnowanych rozwiązań w zakresie złocenia. Zachowaj szczególną ostrożność co do zakresu.
Spędziłem trochę czasu pracując nad projektem, który powinien zająć sześć miesięcy. Kiedy dołączyłem, trwało to półtora roku. Kierownik projektu zadał kierownikowi projektu jedno pytanie na początku: „Chcesz, żebym zrobił to dobrze, czy reagował?” W ciągu tygodnia funkcja została zaimplementowana w poniedziałek, środę i piątek; We wtorek i czwartek funkcja została usunięta.
EDYCJA: Gdy kod zostanie wykonany na zadowalającym poziomie, pozostaw go. Nie wracaj, aby to naprawić, jeśli znajdziesz lepszy sposób. Jeśli musisz zrobić notatkę. Jeśli wymagane są zmiany, przejrzyj swój pomysł i zastosuj go, jeśli nadal ma sens.
Jeśli są miejsca, w których chcesz zaimplementować rozszerzenia dla nadchodzących funkcji, nie implementuj ich. Możesz zostawić komentarz znacznika, aby przypomnieć, gdzie wprowadzić zmiany.
źródło
Spraw, by działało, a następnie dopracuj
Mogę narysować trochę luzu - ale jeśli liczy się czas, Twoim głównym priorytetem powinno być sprawienie, by było to proste. Komentuj obszernie o niedociągnięciach w kodzie i zanotuj to, co zrobiłeś w dowolnym oprogramowaniu do zarządzania projektami / czasem, którego używasz.
Mamy nadzieję, że da ci to więcej czasu na powrót do tych problemów i uczynienie ich idealnymi.
Oczywiście nie ma absolutnie poprawnej odpowiedzi na to pytanie, ale jest to odpowiedź, której staram się trzymać. Jednak może nie być odpowiedni dla twojego obecnego stylu pracy. Co prowadzi mnie do alternatywy ...
Po prostu znajdź metodę, która Ci odpowiada ; i trzymaj się tego. Każdy ma swój własny sposób radzenia sobie z projektami i nie ma podejścia „jeden rozmiar dla wszystkich”. Znajdź podejście i wybierz je dla siebie.
źródło
„Właściwe postępowanie” oznacza dokonanie właściwych kompromisów w konkretnej sytuacji. Niektórzy z nich są:
Oczywiście, jeśli fragment kodu zostanie użyty raz i wyrzucony, # 2 można poświęcić dla dowolnego z pozostałych. (Ale uwaga: możesz myśleć, że zamierzasz go wyrzucić, a potem odkryć, że musisz nadal go używać i utrzymywać, w którym to momencie trudniej będzie przekonać ludzi, aby dać ci czas na ulepszenie czegoś, co „działa”).
Jeśli ty i / lub twój zespół będziecie nadal używać i aktualizować jakiś kod, stosowanie skrótów oznacza teraz spowolnienie później.
Jeśli obecnie dostarczasz błędny kod (słaby na 4) i zajmuje ci to dużo czasu (słaby na 1), a to dlatego, że próbujesz zaktualizować kod, który był słaby na 2, cóż, masz otrzymali solidny, pragmatyczny argument za zmianą praktyk.
źródło
Jeśli to błąd, zrób to jak najszybciej, jeśli to nowa funkcja, nie spiesz się.
A jeśli pracujesz dla firmy, która nie szanuje pracy programistów, możesz nie mieć wyboru, musisz zrobić to szybko i poświęcić się jakości.
Pracowałem dla wielu firm, które przechodziły od projektu do projektu i robiły wszystko szybko. Ostatecznie odniosły niewielki sukces w każdym projekcie, ponieważ wdrożenie (nie tylko programowanie) zostało przyspieszone.
Najlepsze firmy wiedzą, że dobre oprogramowanie wymaga czasu i kunsztu.
źródło
W sytuacji awaryjnej stwórz rozwiązanie do łatania. Stwórz nowy błąd w śledzeniu błędów, wspominając o tym. Zrób to dobrze, ilekroć masz odpowiedni czas.
źródło
Myślę, że robię to, co robią wszyscy, którzy utknęli w pracy w tej branży. Robię to tak szybko, jak to możliwe, a jeśli muszę pominąć niektóre miłe rzeczy, które mogłyby pomóc w zapobieganiu problemom w przyszłości lub ułatwić rozwiązywanie problemów w przyszłości, robię to. Nie jest to sytuacja optymalna, ale kiedy utkniesz w terminach opartych na szacunkach opartych na szacunkach, opartych na wielu nieznanych zmiennych, jest to najlepsze, co możesz zrobić.
źródło
Oto dobry plan:
źródło
Robię większość rzeczy rutynowo, pierwszy sposób, jaki przychodzi mi na myśl. To szybkie i lubię myśleć, że jestem przyzwoitym programistą i robię większość rzeczy w miarę dobrze za pierwszym razem.
Od czasu do czasu (chciałbym powiedzieć dwa razy dziennie, ale dwa razy w tygodniu jest bardziej realistyczny), szczególnie gdy znajduję coś wyjątkowo nudnego w rutynowy sposób, myślę „jaki byłby NIESAMOWITY sposób na zrobienie tego ? i spędzam dodatkowy czas, aby znaleźć lub wymyślić lepszy sposób na zrobienie tego.
Myślę, że jeśli będę to robił wystarczająco często, moje rutynowe kodowanie będzie nadal się poprawiać.
źródło
Oprogramowanie jest dziwne, a proces tworzenia oprogramowania jest dziwniejszy.
W przeciwieństwie do większości rzeczy w prawdziwym życiu, ale jak większość rzeczy związanych z komputerami
Szybszy jest bardziej niezawodny
Jest to sprzeczne z każdą intuicją, której nauczyło Cię dotychczasowe życie, dobrze dostrojone samochody psują się częściej niż standardowe, szybko budowane domy rozpadają się szybciej, zadania domowe wykonane z tyłu autobusu szkolnego nie otrzymują wysokich not.
Ale powolne procedury metodyczne nie dają lepszego oprogramowania. Faceci, którzy spędzają tygodnie na opracowywaniu dokumentów wymagań i dni na diagramach klas przed napisaniem kodu, nie produkują lepszego oprogramowania. Facet, który spełnia podstawowe wymagania, wyjaśnia kilka problemów, zapisuje schemat klasowy na tablicy i otrzymuje kodowanie swojego zespołu, prawie zawsze będzie produkować bardziej niezawodne i lepsze oprogramowanie, i zrobi to za kilka dni, a nie miesięcy.
źródło
Ta praca nie jest dla ciebie odpowiednia.
Napisany kod niskiej jakości „ponieważ nie ma czasu, klienci czekają, błąd powinien zostać naprawiony z dnia na dzień, firma traci pieniądze na ten problem, menedżer mocno naciska” jest objawem źle zarządzanej firmy.
Jeśli chcesz być dumny ze swojej pracy i pisać wysokiej jakości kod, najlepiej jest znaleźć pracodawcę, który to zrozumie i zapłaci ci za to.
źródło