Pracuję nad dość dużą i wadliwą aplikacją - a ze względu na sposób, w jaki jest napisany (oszczędzę ci szczegółów, ale narusza zasady w większości obszarów, o których możesz myśleć), jest prawie niemożliwe, aby rozwijać ją bez poważnego refaktoryzacji.
Znacząca część aplikacji została stworzona przez stażystów, n00bs itp .; ale był też programista w randze Master Developer i z całą pokorą kod, który pozostawił, jest również wątpliwy, może w inny sposób, ale nadal.
To prawda, że jego kod zazwyczaj wykonuje zadanie - przez większość czasu - ale zwykle jest tajemniczy, wymyśla koło (np. Duża niestandardowa metoda polegająca na wykonywaniu raczej zwykłej kopii zapasowej bazy danych SQL) itp. Zasadniczo niepotrzebne zamieszanie plus dużo nadinżynierii
I pomyślałem, że bycie wysoko wykwalifikowanym programistą (celowo nie używam słowa „programista”, zakładając, że oznacza to szerszy zestaw umiejętności), jeśli nie towarzyszą mu inne cechy, może faktycznie być trujące.
Zakładając, że to prawda, niektóre z powodów, o których mogłem pomyśleć, są:
- jeśli kodujesz z łatwością, wydaje się (lub w rzeczywistości jest to w krótkim okresie) szybsze znalezienie własnych rozwiązań na miejscu, bez potrzeby sięgania do bibliotek, istniejącej funkcjonalności itp.
- jeśli ktoś ma wystarczające doświadczenie, aby z łatwością zachować mentalny obraz złożonego programu, jest mniej skłonny do dzielenia go na moduły, warstwy itp.
Chodzi mi więc o to, że jeśli biegły programista jest złym programistą, jego płynność nie tylko nie kompensuje tego drugiego, ale w rzeczywistości wyrządza jeszcze więcej szkody.
Co o tym myślisz? Czy to prawda (w jakim stopniu, jeśli tak)?
źródło
I.ThinkOf(this).KindOfThing()Odpowiedzi:
Tak. Byłem tym facetem. I nauczyłem się, że to okropne.
Wszystko jest dla ciebie bardzo dobre, nie musisz uczyć się czegoś nowego.
Ale co z resztą twojego zespołu? Stają się bardzo od ciebie zależni. Nie mogą wyszukiwać w „Clive's Quicky ORM”, aby uzyskać pomoc na temat mapującego relację obiektową, który napisałeś.
A potem przychodzi dzień, kiedy muszą zatrudnić kogoś nowego i nie mogą szukać ludzi z doświadczeniem w Quicky ORM Clive'a.
I wreszcie nadszedł dzień, w którym wychodzisz i ktoś zauważy błąd w Twojej ORM. I tak będzie, ponieważ nie masz całej społeczności osób testujących i naprawiających Twój produkt.
Tak, nauka Hibernacji mogła zająć więcej czasu niż napisanie czegoś lekkiego. Ale korzyść z tego jest zdecydowanie zbyt duża, aby ją zignorować, IMHO.
źródło
Umiejętność w języku, ale nie w narzędziach. To naprawdę nie jest nawet silny programista. Po prostu szlifuje jedną umiejętność (znajomość języka) i pozwala zardzewieć innej (znajomość biblioteki). Odwrotna sytuacja jest równie zła, ale łatwiejsza do wykrycia.
To tylko lenistwo zamaskowane jako umiejętność. Nie trzeba wiele wysiłku, aby zachować w głowie to, nad czym aktywnie pracujesz. Potrzeba umiejętności, aby znaleźć odpowiednie szwy i podzielić kod wzdłuż nich. Koderzy, którzy twierdzą, że pozostawienie wszystkiego w jednym miejscu było szybsze lub lepsze, często nie widzą, które przedmioty należy podzielić.
źródło
Tylko upewnij się, że to nie dlatego, że pracował w środowisku „Jeśli klawiatura nie klika, nie pracujesz”. Wszyscy patrzymy wstecz na kod i zastanawiamy się, co myśleliśmy. Ponadto, czy ten sklep stosuje refaktoryzację swojego kodu? To mógł być luksus, którego nie otrzymał.
Musimy jednak oderwać się od naszego pierwszego pomysłu (tego, który można po prostu usiąść i młotkować) i zrobić trochę więcej planowania, badań, myślenia. Pokusa, aby usunąć każdy mały problem z drogi, jest kusząca i cały projekt jest zaśmiecony tą praktyką. Nikt nie chce płacić ludziom za naprawę rzeczy, które „nie są zepsute”, więc po co refaktoryzować.
Edycja: Upewnijmy się, że nie będziemy karać tych, którzy znają odpowiedzi. Są tacy, którzy biegle i szybko piszą dobry kod. Kluczem jest nie podejście do każdego problemu w ten sposób.
źródło
100%
Cyniczny sposób patrzenia na to polega na tym, że tego rodzaju kodery faktycznie utrzymują większość programistów w pracy, naprawiając błędy, które są tak fundamentalne, że można w nich zatopić tysiące godzin programistów, nie przechodząc w połowie do stabilnego, elastycznego i bezpiecznego , modułowy lub [twoja ulubiona właściwość oprogramowania]. Systemy te mają tak wiele osobliwości, że sama myśl o migracji do czegoś innego, nawet z 95% już istniejących funkcji i aktywną społecznością, uważa się za coś śmiesznego i uzasadnionego zwolnieniem.
Krótko mówiąc, biegli koderzy mogą wyrządzić więcej szkód niż horda konkurencji, ale cena jest zwykle płacona przez wiele lat. I zwykle po prostu wykonywali swoją pracę (zdefiniowaną przez kogoś innego).
Jak stwierdzić, czy jesteś programistą czy programistą? Myślę, że to niemożliwe, ale za każdym razem, gdy znajdziesz sposób na uproszczenie kodu bez obniżania jakości, robisz kolejny krok w kierunku oświecenia.
źródło
Problem, który opisałeś, był w zasadzie NIH („nie wymyślono tutaj”) - czy są jeszcze inne objawy?
Czasami NIH, szczególnie jeśli jest izolowany dla jednej lub dwóch osób, można poradzić sobie w dyskusji grupowej („Joe ma pewne doświadczenie w tworzeniu kopii zapasowych SQL przy użyciu standardowych bibliotek - co sądzisz, Joe?”). To może być mniej konfrontacyjne niż tylko bezpośrednie przejście do osoby i powiedzenie „Hej! Użyj standardowej biblioteki, manekinie!” :)
źródło
Będąc zarówno w twojej sytuacji, jak i powodując podobne sytuacje, rozumiem twoją frustrację, ale myślę, że odpowiedź na twoje pytanie jest jednoznaczna „nie”. Płynność nie gwarantuje, że programista wytworzy kod, który można utrzymać. Często organizacje zmuszają programistów do dostarczania źle zaprojektowanego i wdrożonego oprogramowania z powodu absurdalnych ograniczeń budżetowych i czasowych. Możliwe, że biegły programista robi postępy, tylko programiści chcą dostarczać coś, na czym zależy klientom. Oczywiście nie jest to dobre w praktyce, ale niestety rzeczywistość, z którą każdy programista musi sobie poradzić w pewnym momencie swojej kariery. Istnieje również szansa, że biegły programista jest po prostu leniwy lub zadowolony. Mówię doskonale po angielsku, ale łatwiej i przyjemniej jest używać slangu.
Jeśli chodzi o używanie kodu innej osoby lub generowanie własnego argumentu, myślę, że naprawdę sprowadza się to do tego, co najlepiej wykonuje zadanie. Czasami „najlepszy” nie bierze pod uwagę takich rzeczy jak styl i łatwość konserwacji, jeśli „najlepszy” oznacza dostarczenie projektu trwającego sześć tygodni w ciągu dwóch tygodni. Dlatego dokonujemy refaktoryzacji i udoskonalamy. Ponadto programista musi wiedzieć, co jest dostępne w zakresie kodu strony trzeciej, musi wiedzieć, jak go używać i mieć pewność, że będzie działał oraz że będzie odpowiednio obsługiwany / obsługiwany. Biorąc pod uwagę, że istnieją tysiące opcjonalnych frameworków, bibliotek i interfejsów API dla każdego popularnego paradygmatu programistycznego używającego takich rzeczy, może to ostatecznie kosztować więcej czasu, energii i stresu niż tylko rozwijanie własnych. Ponadto znajduję przypadki, w których kod innej firmy po prostu nie robi dokładnie tego, co jest mi potrzebne - czyli wtedy, gdy „
źródło
Jestem w tej łodzi (stary, płynnie napisany kod) i sam przez pewien czas byłem biegły.
Największą przeszkodą dla „szybkich i brudnych” rozwiązań jest zawsze konieczność późniejszego dodania kolejnych. Gdy potrzebujesz więcej funkcji. Jest tylko tyle rzeczy, które możesz zrobić bez struktury. Potem się psuje i jego zmiana jest kosztowna (ale satysfakcjonująca, ale niezbyt doceniana).
Zasadniczo musisz chronić się przed JAKIMKOLWIEK HAKIEM, który potencjalnie może stać się „praktycznym rozwiązaniem”, gotowym do sprzedaży przez chętnego sprzedawcę. To stare „Nie jest gotowe! - Ale działa, nie?” zagadka.
źródło