Być surowym czy pragmatycznym?

Zaczynam zdawać sobie sprawę, że tworzenie oprogramowania to (między innymi) proces ciągłego zadawania sobie pytań. Pytania dotyczące jakości kodu, separacji problemów, minimalizacji zależności, ...

Ale główne pytanie brzmi: jak daleko można się posunąć bez wylądowania w szpitalu psychiatrycznym?

Ubiegam się o nową pracę. Wczoraj byłem z potencjalnym przyszłym pracodawcą, który chciał przetestować moje możliwości programistyczne. Jednym z ćwiczeń było: wyjaśnienie, co robi ten kod. Przeszedłem przez pewien kod aplikacji (winforms w vb.net), którą opracowują (jest to aplikacja administracyjna dla szpitala). To dało mi okazję zobaczyć, jak do tego podchodzą, i było to raczej rozczarowujące.

Kilka przykładów:

• Gdzieś widziałem: Zadzwoń [wpisz tutaj nazwę podprogramu] -> Uderzyło mnie: czy to nie jest coś z VB6?
• Mają osobną warstwę danych, wykorzystującą ado.net, ale jedna metoda, którą musiałem zbadać, zwraca zestaw danych do warstwy wywołującej. Niezależnie od tego, czy jest to osobna warstwa danych, czy nie, aplikacja jest powiązana z ado.net (co również nigdy nie może stanowić problemu, jeśli nigdy nie przełączy się na inne podejście do dostępu do danych).
• Ten zestaw danych jest odczytywany „tak, jak jest”, więc nadal jest to podejście skoncentrowane na danych (oczywiście można spierać się o to, ile logiki / zachowania można umieścić w klasach takich jak „Pacjent” lub „LabAnalysisRequest”.
• Uważam również, że widziałem konstruowanie zapytania SQL przez konkatenację łańcuchów.
• Używają procedur przechowywanych (co dla mnie oznacza: rozproszenie logiki)
• bez wzmianki o widokach / kontrolerach: wszystko zależy od formy
• Najbardziej brzydką rzeczą, jaką zobaczyłem, było:

      Jeśli TestEnvironment.IsTesting to
         someVar = [jakaś zakodowana wartość]
      jeszcze
         someVar = [jakaś wartość pobierana dynamicznie]
      koniec jeśli
      [pozostała część funkcji tutaj]
  

To wszystko tak różni się od tego, czego nauczyłem się w szkole: warstwa domeny (agnostyczna trwałość), warstwa trwałości, warstwa prezentacji, testy jednostkowe, ...

Przeformułowuję więc moje pytanie: jak fundamentalny lub dogmatyczny powinien być? W jakim stopniu programista powinien trzymać się swoich zasad lub po prostu napisać kod, który wykona zadanie?

Wiem, że to nie odpowiada bezpośrednio na twoje pytanie, ale nadal uważam, że jest to warte więcej niż komentarz:

Kiedy przeprowadzasz rozmowę o pracę, przeprowadzasz z nimi wywiad tak samo, jak oni rozmawiają z tobą . Przełam nawyk oglądania wywiadu jako czegoś, na co czołgasz się na brzuchu, błagając, by coś ci zaoferowali. Sprawdzają cię, ale ty również je kasujesz . Jeśli cię nie lubią, nie zatrudnią cię. Jeśli ich nie lubisz, nie idź tam pracować.

Tak, w branży, z dziesięcioletnią bazą kodu, która została zhakowana z czasem przez trzy tuziny programistów o różnym pochodzeniu, umiejętnościach i pasji, kierowanych napiętym terminem, brakiem zasobów i ograniczeniami finansowymi, kod nigdy wyglądaj tak, jak powinieneś (powinnaś) się tego nauczyć. Będziesz musiał zrobić pewne ustępstwa. Ale ile i gdzie wytyczysz granicę, zależy to wyłącznie od Ciebie.
Oczywiście trudniej jest znaleźć pracę przy mniejszych koncesjach. Ale mogą być bardziej przyjemne.

FWIW, do tej pory (> 10 lat w branży) nigdy nie pracowałem w dużej firmie z wieloma programistami (ok. 30 programistów było najbardziej, kilkanaście normą), ponieważ jest o wiele bardziej prawdopodobne, że zmienisz coś w małym firma. Tak długo, jak zarabiam wystarczająco dużo pieniędzy, aby nie zagłodzić dzieci, nie chciałbym być małym kołem zębatym w dużej firmie, w której wszystko, co muszę zrobić, to zsynchronizować się z resztą biegów.
Odrzuciłem oferty pracy po obejrzeniu testów, które chciałem, bym zdał. Jestem programistą C ++, a jest wiele testów C ++, które są tak złe, że twoje paznokcie uginają się z obrzydzeniem, i nie chcę spędzać czasu na walce z wiatrakami, ponieważ zatrudniali kretynów, którzy nie potrafią napisać czystego kodu.
Po kilku miesiącach zrezygnowałem z pracy, ponieważ ich filozofia programowania (cele krótkoterminowe, nie wspominając o przyszłym roku) nie pasowała do moich umiejętności (długoterminowa stabilność kodu), mimo że w wywiadzie mówili inaczej.

Nigdy nie pisz kodu, który po prostu działa. Jednak bądź równie chętny do zbadania swojej doktryny. To, że nauczyłeś się tego w szkole, nie oznacza, że ​​jest to myślenie aktualne, a nawet prawidłowe. Cykl życia oprogramowania staje się przestarzały, ponieważ programowanie musi być bardziej reaktywne w świecie biznesu. Czasami niezręcznie połączone rozwiązania oprogramowania są niezręcznie połączone, ponieważ części zostały wymienione w miarę upływu czasu.

Oto lista opracowanych przeze mnie zagadnień, które określą, jak dobrze wpasowujesz się w kodeksowy styl życia firmy.

1. Jak bardzo cenią sobie czas poświęcony na refaktoryzację i aktualizację bazy kodu. To, jak postrzegają aktualizację bazy kodu, będzie głównym czynnikiem decydującym o tym, jak dobrze się dopasowujesz.
2. Jak często kupują firmy zewnętrzne zamiast kodować wewnętrznie.
3. Co myślą o oprogramowaniu typu open source. Czy zdają sobie sprawę, że mają elastyczność w modyfikowaniu kodu? Czy widzą to tak samo, jak kupowanie stron trzecich.
4. Będziesz pracował na pewnej warstwie abstrakcji. Czy zespół, z którym się kontaktujesz, określa Twój interfejs dla Ciebie? Która warstwa / zespół / strona interfejsu ma większą moc w podejmowaniu decyzji.
5. Jak bardzo słuchacze nadzorują słuchaczy programistów podczas podejmowania decyzji. Gdy programista rzuca czerwoną flagę, organ nadzoru zatrzymuje się i weryfikuje swoją decyzję.
6. Czy uważasz, że doświadczeni programiści zarządzania? Jak oceniają swoje doświadczenia? Czy ich doświadczenie jest ważne? Czy pozwalają, aby nieaktualne doświadczenia wpływały na podejmowanie decyzji?
7. Jak lepka jest baza kodu?
8. Jak często aktualizują swoje narzędzia programistyczne (IDE itp.)

Odpowiedzi na te pytania lepiej pasują do tego, jak cenisz ich programistyczny styl życia, niż sprawdzanie, czy pasują do twojego dogmatu.

Dogmat nieuchronnie zostanie złamany (po prostu nie mamy czasu na aktualizację X). Jednak priorytety określą, jak bardzo kolidujesz z ich stylem i podejmowaniem decyzji.

Myślę, że musisz rozważyć to jako część całości. Pamiętam, że jednym z moich pierwszych zadań było stanowisko w grupie, która powiedziała mi, że zajmują się obiektowym C ++ - co właśnie zrobiłem kilka lat w szkole.

Ich samoocena była błędna - robili nieco masywną C. Wciąż był bardzo funkcjonalnie zaprojektowany w naturze i musiałem zdobyć książkę C, aby nauczyć się printf i getf oraz innych mechanizmów C, których nigdy nie nauczyłem się. Fakt, że nikt w zespole nawet nie zdawał sobie sprawy z tego, jak C podobał się ich kodowi, wskazuje na to, jak bardzo upadł ten „projekt C ++”. Moim celem w tym czasie było rozwijanie OO, więc było to trochę odrażające.

Ale cieszę się, że ostatecznie utknąłem w zespole. Byli dynamiczną grupą bardzo inteligentnych ludzi i zmoczyłem stopy z wieloma trudnymi problemami, musiałem pracować przez cały cykl życia, a rzeczy, których dowiedziałem się o problematycznej dziedzinie (PKI), od tego czasu napędzały moją karierę. Praca, którą zespół wykonał w przestrzeni funkcjonalnej była niesamowita i nadal bardzo czule myślę o tym produkcie i doświadczeniu zawodowym. Jeszcze lepiej - nadal współpracuję z niektórymi z tych osób (kilka firm później), wciąż są inspiracją i nadal wykonujemy dobrą pracę.

Nie sądzę, że idealne wdrożenie najlepszych praktyk języka kodowania jest zrobieniem lub przerwaniem dobrego doświadczenia zawodowego lub dobrego zespołu - praca, która napędza karierę, to znacznie więcej, a jeśli produkt ma przyzwoitą jakość jakość, zespół ma przyzwoite warunki pracy (takie jak test Joela), a zespół jest pełen ludzi, którzy są inteligentni i wykonują zadania, a następnie doskonałość wdrożenia jest drugorzędna. Zabierz czynniki, takie jak dobra praca, dobrzy ludzie, dobre warunki pracy - i nie warto się tu trzymać - niezależnie od tego, czy kod jest dziwnie złożony.

jak fundamentalny czy dogmatyczny powinien być? W jakim stopniu programista powinien trzymać się swoich zasad lub po prostu napisać kod, który wykona zadanie?

Najważniejszą rzeczą do zapamiętania tutaj jest jaki jest twój cel ?

W większości firm Twoim celem w życiu nie jest pisanie doskonałego kodu. Twoim celem jest dostarczenie wartości dla użytkownika. Pisanie dobrego kodu jest zwykle najlepszym sposobem na dostarczenie dobrego produktu, który jest również łatwy w utrzymaniu, rozwiązywaniu problemów i rozwijaniu.

Dobry kod to narzędzie, które należy zastosować tam, gdzie daje dobry zwrot z inwestycji.

Kilka przykładów:

1. Spędziłbym dużo czasu na projektowaniu i kodowaniu moich interfejsów API, zwłaszcza API warstwy biznesowej. Wielu innych programistów zamierza z nich korzystać, a jeśli są odpowiednio zaprojektowane, zaoszczędzi wiele czasu i problemów
2. Rozluźnię reguły trochę w mojej warstwie prezentacji. Będę bardziej skłonny poświęcić „doskonałość” kodu na rzecz dodania kolejnych funkcji

Podsumowując, musisz mieć zasady, ale powinieneś także być wystarczająco elastyczny, aby złamać te zasady, gdy przynoszą więcej szkody niż wartości.

Przez kilka lat pracowałem w sklepie internetowym. Kiedy tam zacząłem, kod dla ich wewnętrznych aplikacji został napisany w VB dla MS Access i co najmniej było okropne. Miałem zespół 3 programistów i przez kilka następnych lat zastąpiliśmy to odpowiednimi aplikacjami VB.Net.

Ale ponieważ mój budżet na zatrudnienie był bardzo ograniczony, mogłem sobie pozwolić tylko na młodszych programistów. I oczywiście kod, który stworzyli, nie był wcale taki świetny. Ale zadziałało i firma wykorzystywała te aplikacje każdego dnia do zarabiania pieniędzy.

A potem zacząłem pracować z moimi chłopakami. Trochę szkolenia w zakresie OOD, projektowania bazy danych, w MVC i C #. Z biegiem lat sytuacja uległa poprawie. Kiedy wyszedłem po 4 latach, baza kodów wciąż nie była świetna, ale była 100 razy lepsza niż na początku.

Sytuacja taka jak ta, którą opisujesz, jest często konsekwencją zaspokojenia dostępnych zasobów. Nie żyjemy w idealnym świecie. Jednocześnie jest to świetna okazja, aby naprawdę coś zmienić.

BTW: niektóre z tych aplikacji są nadal w użyciu, praktycznie niezmienione od około 3 lat temu, i nadal zarabiają.

Myślę, że przestrzeganie twoich zasad jest bardzo ważne. Zawsze powinieneś dążyć do stworzenia najlepszego możliwego kodu w ramach podanych ograniczeń. Jeśli jednak dodasz do listy zasad „nigdy nie musisz czytać ani zmieniać złego kodu”, będziesz mieć trudności ze znalezieniem pracy. Pamiętaj, że 50% programistów ukończyło dolną połowę swojej klasy. Nawet w zespole jednoosobowym „dziś ty” jest lepiej wykwalifikowany do rozwiązania problemu niż „ty w zeszłym miesiącu”. Możliwość pracy z niezbyt idealnym kodem to tylko część pracy.

Wielu pracodawców zdaje sobie z tego sprawę, więc kod, który dają ci do przeczytania, może reprezentować najgorszy kod w swojej bazie kodu, a nie ich najlepszy. Jeśli nie wynika to z kontekstu, powinieneś zapytać. Jeden kolega, z którym czasami przeprowadzam wywiad, ma stronę kodu, którą celowo źle napisał, aby użyć go jako pytania do rozmowy kwalifikacyjnej.

W 99% przypadków powinieneś trzymać się «dogmatu», jak go nazywasz. Dogmaty są tworzone przez doświadczone osoby przez lata praktyki, a to, co w pewnym momencie wydaje się pragmatyczne, naprawdę nie jest. Jest to zwykle ważniejsze niż fakt, że nie jesteś wystarczająco dobry, aby właściwie poradzić sobie z tym problemem.

Nie przestrzegajcie jednak dogmatu na ślepo. Pamiętajcie, jakie wnioski prowadzą ludzi do przestrzegania tego dogmatu. Ponieważ znajdziesz niewielką część przypadków, których nie należy śledzić. W każdym razie przypadki te będą bardzo rzadkie i przed podjęciem takiej decyzji należy zawsze omówić z innymi doświadczonymi programistami.

Bądź ostrożny, gdy ma to znaczenie. Styl nawiasu klamrowego (lub inne konwencje kodowania)? To nie ma znaczenia Użyj tego, którego używa sklep. Zerwanie enkapsulacji (lub innych podstawowych zasad programowania) bez ważnego powodu? Nie takie trywialne.

Stack Exchange używa tabel do układania (podobnie jak wiele innych głównych stron internetowych, które zarabiają pieniądze ). Czy to sprawia, że ​​z uszu purystów wydobywa się dym? Jasne, że tak. Ale pragmatyzm zawsze wygrywa z czystością. Produkt wysyłany wygrywa z uzyskaniem idealnego za każdym razem.

Cała warstwa domeny, warstwa trwałości, warstwa prezentacji, testowanie jednostkowe jest wciąż stosunkowo nowe, z historycznego punktu widzenia. Istnieje mnóstwo programów, które nadal używają modelu klient / serwer i nie zostaną zmienione na najnowszy styl architektoniczny tylko dlatego, że jest „lepszy”.