sugerowanie dużych zmian / przepisanie jako stażysta [zamknięte]

Kontekst:

• to wewnętrzny projekt (nie sądzę, że wiele osób korzysta)
• to jest stare
• aktualizujemy to

Problemy:

1. narusza strukturę mvc (bez użycia modeli, logiki biznesowej w widokach itp.)
2. to, o co jesteśmy proszeni, jest niewielkie, ale z powodu niskiej spójności mamy dwie opcje:
   1. nadal beczkować
   2. przesuń duże fragmenty kodu lub przepisz to

Rozwiązania (widzę):

1. kontynuuj pracę z nim, zignoruj ​​najlepsze praktyki, aby zrobić to wkrótce i nie wprowadzać nowych błędów przez refaktoryzację / przepisywanie
2. refaktoryzuj / przepisz

Wydaje mi się, że moje pytanie brzmi naprawdę: jeśli chcę dokonać dużych zmian w tym projekcie, jak mam to zaproponować, nie obrażając nikogo? Czy może lepiej byłoby po prostu iść z prądem, nawet jeśli czasami oznacza to (metaforyczną) taśmę klejącą?

OK Proszę.

Myślisz, że aplikacja jest źle skonstruowana i źle napisana.

Klient uważa, że ​​spełnia swoje zadanie.

Chcesz przepisać go bez żadnego innego powodu niż poprawić jego „piękno wewnętrzne”.

Dlatego prosisz klienta, aby wydał pieniądze na to, aby aplikacja zrobiła dokładnie to, co robi teraz - tylko te części, których użytkownik nie widzi lub nie rozumie, będą w jakiś sposób „lepsze”.

Głównym zarzutem do źle napisanego źle ustrukturyzowanego kodu jest to, że trudno go zrozumieć.

Kod jest trudny do zrozumienia i ma funkcjonalność oraz funkcje, które można łatwo zaimplementować tylko w źle zorganizowanej aplikacji. Więc jeśli nie jesteś w tym bardzo dobry, nowa aplikacja nie zrobi dokładnie tego, co robi bieżąca aplikacja, a ponieważ nie do końca rozumiesz, co robił oryginalny kod, prawdopodobnie zrobi to źle.

Twój klient wydał teraz dużo pieniędzy, aby uzyskać aplikację znacznie gorszą niż oryginalna. Nie będziesz popularny!

Na szczęście twoje bardziej doświadczone uczelnie są gotowe cię wyśmiewać (prawdopodobnie dlatego, że popełniły ten sam błąd, kiedy zaczynali, a może nawet niefortunnie było uzyskać zgodę kierownictwa na tak niefortunny projekt).

Tak więc radzę, aby zachować starą bazę kodu i zachować spokój. Klient chce tylko systemu, który działa, nie obchodzi go to, jeśli uważasz, że kod jest brzydki.

Zaproponuj zmiany. Dla każdego z nich wyjaśnij jasno : dlaczego proponowana zmiana pomoże systemowi jako całości? Jeśli nie, spodziewaj się odepchnięcia. Po co wydawać pieniądze na naprawę czegoś, co się nie zepsuło? Powody, takie jak uczynienie systemu bardziej rozszerzalnym i rozdzielenie obaw mogą być ważne (w zależności od tego, z kim rozmawiasz), ale 99% czasu, po prostu powiedzenie „nie jest poprawnie wdrożone”, nie doprowadzi cię do niczego. Upewnij się, że dodajesz wartość do projektu, a nie tylko proponujesz wykonanie pracy (nawet jeśli spowoduje to wyczyszczenie kodu).

Niestety, w świecie zawodowym, tylko dlatego, że coś zostało źle zaimplementowane, nie oznacza, że ​​jest zepsute, a zatem nie wymaga naprawy. Ponadto, naprawiając go, możesz wprowadzić nieprzewidziane problemy, które mogą mieć wpływ na inne obszary projektu.

Czytając twoje pytanie, jestem sceptyczny, że przepisanie aplikacji jest tego warte. Może nie zadałeś sobie trudu, aby w pełni odpowiedzieć na twoje pytanie. Ale jak prawdopodobne jest, że korzyść z przepisywania jest warta kosztu, jeśli jest to stara, rzadko używana aplikacja wewnętrzna? Koszt przepisania prawdopodobnie będzie większy niż suma wszystkich aktualizacji i poprawek, jakie kiedykolwiek będzie miał.

Jeśli uważasz, że to nieprawda, będziesz musiał uzasadnić to bardziej niż tutaj.

Jeśli chodzi o ulepszanie aplikacji, możesz mieć szansę na trochę refaktoryzacji, co dzieje się naturalnie w trakcie aktualizacji.

Jesteś stażystą. Przypuszczalnie jesteś nowy. Prawdopodobnie podejrzewają cię za idiotę.

Więc kiedy zaczniesz sugerować, stąpaj lekko . Bądź pokorny i skromny. Pozwól, aby Twoje pomysły płynęły w rozmowach, gdy pozwalasz innym członkom dyskutować również o swoich pomysłach na temat bazy kodu i presji, jaką mogą wywierać (może być bardzo dobry powód, dla którego nie podjęto wysiłku, aby to uporządkować).

Chcesz zdobyć ich zaufanie. Robisz to, pisząc dobry kod dla powierzonych zadań. Pisz to czysto, korzystaj z najlepszych praktyk, które chciałbyś, aby zostały wdrożone, ale tylko zgodnie z tym, do czego jesteś przydzielony. Prawdopodobnie będą to drobne rzeczy, które zdaniem reszty zespołu prawdopodobnie są nieistotne. Rób te rzeczy dobrze. Rozjaśnij kąt, w którym się znajdujesz, a gdy zespół przyjrzy się pozytywnie swojemu kodowi, Twoje pomysły z kolei również wzrosną.

W końcu , gdy wykażesz się kompetencjami i wiedzą, być może uda Ci się wyciągnąć jedną lub dwie sugestie.

Zrobiłbym tę sugestię całkowicie, ale tylko dla innych programistów . Nie poruszyłbym tego z zarządzaniem, ponieważ wyobrażam sobie, że zarządzanie postrzegałoby to jako pewien rodzaj przekroczenia granic.

Po przedstawieniu sugestii programistom, z którymi współpracujesz, prawdopodobnie będą mieli dobre powody, dla których jest to podstawa kodu. Przyczyny mogą być różne: od „nie, właściwie kod jest w porządku, po prostu nie rozumiesz MVC (i dlatego jesteś stażystą)” po „to świetny pomysł, zróbmy razem nową aplikację!”

Należy pamiętać, że odpowiedź na refaktoryzację tego wniosku będzie bardziej niż prawdopodobnie nie; Nigdy nie chciałbym, aby stażysta przejmował przepisywanie aplikacji wewnętrznej (co się stanie, gdy staż zostanie zakończony, a przepisanie jest w połowie ukończone?) Ponadto, prawdopodobnie jest coś ważniejszego, nad czym mógłbyś popracować niż przeszukiwanie wewnętrznej aplikacji .

Ale nigdy nie boli pytać rówieśników, a jeśli to zrobisz, nauczysz się czegoś. I na tym właśnie polega 7983879342.

Cokolwiek się stanie, mam nadzieję, że zabierzesz następującą wiadomość. Jak niektóre z powyższych odpowiedzi wskazywały czasem na przepisywanie kodu, ze względów technicznych czasami jest to niemożliwe z przyczyn biznesowych / kosztowych. Zbyt wielu programistów żyje w rozwiązaniu technicznym i nie bierze pod uwagę, że ich osobiste dążenie do technicznej elegancji / czytelności / najlepszych praktyk powinno być zrównoważone potrzebami firmy do wykonania zadań. Z mojego osobistego doświadczenia, facet, który nie osiąga tej równowagi (z obu kierunków) jest często postrzegany jako odpowiedzialność w zespole.

Nie przestawaj jednak zadawać pytań, nawet jeśli dostaniesz odrzuty, to sposób, w jaki się uczymy i rozwijamy.

Inne odpowiedzi wiele mówiły o polityce twojej sytuacji i raczej się zgadzam. O ile nie możesz przedstawić przekonującego uzasadnienia biznesowego, przepisywania prawdopodobnie nie ma na kartach.

Nie oznacza to jednak, że powinieneś zapomnieć o Zwiadowcach :

Zawsze zostawiaj kemping czystszy, niż go znalazłeś.

Jeśli podczas implementowania czegoś w tej bazie kodu możesz znaleźć sposób na oczyszczenie jakiegoś aspektu projektu lub implementacji, to powinieneś to rozważyć. Prawdopodobnie nie trzeba ponownie pisać całej aplikacji, aby lepiej wykorzystać model MVC, a jeśli wdrażasz nową logikę biznesową dla konkretnego widoku, możesz rozważyć przeniesienie logiki ze starego widoku do modelu i dodając do tego nową logikę.

Jak powiedzieli inni, poproś innego programistę (znającego się na tej aplikacji), aby zrobił krótki przewodnik, abyś mógł zrozumieć, w jaki sposób / dlaczego wdrożenie. Wyjaśnij, że chociaż rozumiesz aspekty technologiczne, ale chcesz być w stanie połączyć kropki z wymaganiami biznesowymi (wymagania biznesowe przebijają wszystkie).

Po uzyskaniu tych informacji możesz dokonać oceny. Jeśli osobiście uważasz, że należy go przepisać, ale nie uważasz, że inni uznają to za dobre wykorzystanie czasu, weź go jako osobisty projekt. Nawet jeśli masz godzinę tu / tam, kiedy masz przestój, wykonaj implementację „poprawnie”. Kiedy skończysz, przedstaw go innym programistom jako „hej, czułem, że przydałoby się to posprzątanie, więc zrobiłem trochę pracy bocznej podczas mojego przestoju. Jak myślisz?” Nie naciskaj na nich zmiany - po prostu zaoferuj im to jako „hej, chłopaki to lubią?” i stamtąd

Większość zmian odbywa się stopniowo, co do zasady.

Kilka rzeczy, o których należy pamiętać;

• Jaka jest historia aplikacji?
• Dlaczego dzisiaj jest brzydka?
• Jaka jest korzyść ze zmian architektonicznych?

Dobrą strategią jest praca nad małymi rzeczami i zadawanie mnóstwa pytań na temat rzeczy (pytań, których nie można nauczyć się od Google lub źródła, nie marnuj czasu ludzi). Kiedy poczujesz się dobrze z bazą kodu i programistami, powinieneś dobrze wiedzieć, dlaczego kod jest taki, jaki jest. Czasami jest po prostu: „Tak, musieliśmy razem coś zhakować i wyrzucić za drzwi”. Jeśli możesz zaproponować łagodne zmiany w małych częściach systemu, które pojawiają się podczas normalnej pracy, uzyskasz większą przyczepność niż radykalne przepisywanie.

Sugerowanie przepisania tekstu nie jest niczym złym, jeśli ładnie poprosisz i zrobisz logiczny przypadek (nie tylko przeczucie lub to lepszy sposób na zrobienie tego). Istnieje duża szansa, że ​​przepisanie aplikacji mało używanej zostanie zestrzelone, i istnieje duża szansa, że ​​ktokolwiek pierwotnie napisał system, wciąż jest w pobliżu (i znajduje się wyżej w hierarchii niż ty) i może nie przyjąć krytyki.

Nie mów więc: „Musimy przepisać ten okropnie zaprojektowany system, który narusza podstawowe zasady MVC”, zadaj go jako otwarte pytanie odpowiednim wyższym osobom (osobom bezpośrednio nad tobą). Coś w rodzaju „Zastanawiam się, czy przepisanie systemu w modelu MVC może na dłuższą metę zaoszczędzić dużo czasu. Jak myślisz? Założę się, że możemy skrócić czas konserwacji o połowę dzięki znacznej przeróbce (powiedzmy 2 tygodnie), że zawiera model MVC, TDD itp. zostało zrobione i że po dwóch miesiącach rutynowej konserwacji osiągniemy próg rentowności ”. Odpowiedź może być taka, że ​​nie, nie uważamy, że jest to konieczne - nie zgadzam się z twoimi szacunkami czasu i prawdopodobieństwem, że nowy system będzie odpowiednim zamiennikiem. Lub odpowiedź może być, dobrze, ale pamiętaj, jeśli twój nowy system nie t działa tak dobrze / lepiej niż nowy system w proponowanych ramach czasowych, że ludzie będą cię winić. I nawet jeśli system jest mało używany; przestanie być aktualizowana z drobnymi poprawkami podczas okresu przepisywania.