Jaki jest / Czy istnieje właściwy sposób poinformowania kierownictwa, że ​​nasz kod jest do bani?


70

Nasz kod jest zły. Nie zawsze było to uważane za złe, ale jest złe i idzie tylko w dół. Zacząłem świeżo po studiach mniej niż rok temu, a wiele rzeczy w naszym kodzie łamie mi głowę nie do uwierzenia. Na początku pomyślałem, że jako nowy facet powinienem trzymać gębę na kłódkę, dopóki nie dowiem się trochę więcej o naszej bazie kodu, ale widziałem wiele, aby wiedzieć, że to źle.

Niektóre z najważniejszych wydarzeń:

  • Nadal używamy ramek (spróbuj uzyskać coś z quistystring, prawie niemożliwe)
  • VBScript
  • Źródło Bezpieczne
  • „Używamy” .NET - mam na myśli to, że mamy opakowania .NET, które wywołują biblioteki DLL COM, co sprawia, że ​​prawie niemożliwe jest łatwe debugowanie
  • Wszystko jest w zasadzie jedną gigantyczną funkcją
  • Kod nie jest możliwy do utrzymania. Każda strona ma wiele plików, które są tworzone za każdym razem, gdy tworzona jest nowa strona. Strona główna w zasadzie robi Response.Write () kilka razy, aby renderować HTML (runat = "server"? Nie ma mowy). Po tym może być dużo logiki po stronie klienta (VBScript), a na koniec strona sama się poddaje (często przechowuje wiele rzeczy w ukrytych polach), gdzie następnie publikuje na stronie przetwarzania, która może np. Zapisać dane do bazy danych.
  • Otrzymane specyfikacje są śmieszne. Często wzywają do takich rzeczy, jak „automatyczne wypełnianie pola X polem Y lub Z” bez wskazania, kiedy wybrać pole Y lub pole Z.

Jestem pewien, że część tego wynika z braku zatrudnienia w firmie programistycznej, ale wydaje mi się, że ludzie piszący oprogramowanie powinni przynajmniej dbać o jakość swojego kodu. Nie mogę sobie nawet wyobrazić, że gdybym coś wymyślił, wszystko by się wkrótce stało, ponieważ zbliża się długi termin, ale nadal piszemy zły kod i stosujemy złe praktyki.

Co mogę zrobić? Jak w ogóle poruszyć te problemy? 75% mojego zespołu zgadza się ze mną i poruszało te problemy w przeszłości, ale nic się nie zmienia.


27
przyzwyczaić się do tego. 90% pisania kodu to czytanie kodu.

7
nic się nie zmienia z tego samego powodu, że jest to zły kod. Dawno temu przestali płacić booku $$$$ za to, że ktoś dał im pohukiwanie.

11
To jest nie na temat. Ale krótka odpowiedź brzmi: ekonomia. Ile miesięcy programistów będzie kosztowało uporządkowanie bazy kodów, a ile miesięcy programistów uratuje uporządkowaną bazę kodów?
Oliver Charlesworth

89
najlepszym sposobem jest rozmowa kwalifikacyjna.
kylben

32
Nie ma znaczenia, jak mówisz niewidomym o kolorze. Oni cię nie zrozumieją.
ThomasX

Odpowiedzi:


68

Upewnij się, że nie przesadzasz. Jesteś świeży, prawdopodobnie nie pracowałeś w wielu (żadnych?) Innych miejscach, a więc nie jesteś przygotowany na świat „prawdziwego kodu”. Kod z życia jest okropną rzeczą. To jest jak twój fajny szkolny kod i twój obsesyjnie ulepszony osobisty kod projektu uprawiał seks w piwnicy reaktora jądrowego, a dziecko dorastało w kanale toksycznych odpadów; to ohydny mutant.

Ale zakładając, że masz rację, a kod jest tak zły, jak mówisz (tj. Gorszy niż zwykły zły kod), masz rację. Porozmawiaj ze swoim zespołem i ustal, czy wszyscy inni są po stronie. Zajmie to pracę nad poprawą sytuacji - jeśli reszta zespołu rozpozna problem, ale nie przejmuj się, zmarnujesz swój czas.

Będąc juniorem, prawdopodobnie nie jesteś w stanie prowadzić. Jeśli sam pójdziesz do zarządzania, jako nowy pracownik, który jest również młodszy, Twoja opinia prawdopodobnie zostanie zignorowana. Zaangażuj swojego głównego programistę lub jednego z najbardziej zaangażowanych pracowników. Ponownie, jeśli żadna z osób starszych nie jest zainteresowana, tracisz czas.

Zakładając, że możesz zainteresować kilka starszych osób technicznych, pracuję nad identyfikacją obszarów problemowych i możliwych rozwiązań. Na przykład, jeśli „wszystko jest w zasadzie jedną gigantyczną funkcją”, następnym razem, gdy będziesz pracować w tej „gigantycznej funkcji”, może powinieneś trochę przebudować. Ponownie musisz zachęcić wszystkich do działania. Jeśli odłupiesz małe fragmenty swojego problemu i poprawisz kawałek po kawałku, ostatecznie staną się znacznie mniejszym problemem. Za każdym razem, gdy dotkniesz fragmentu kodu, zastanów się, czy można go ulepszyć.

Nie zamierzasz siadać z zarządem i mówić „wszystko jest złe i trzeba je przepisać”. To nie ma dla nich sensu - kosztuje dużo i jest potencjalnie bardzo ryzykowne. Zamiast tego należy uświadomić im, że występują problemy i że planuje się powoli poprawiać wraz z wprowadzaniem zmian. Powinny być edukowane na temat korzyści z utrzymywalnego kodu. Powinno to pochodzić od osoby starszej, której ufa technicznie i zawodowo - a nie od ciebie.

Kompletne przepisanie? Prawie zawsze zły pomysł.

Ostatecznie niewiele możesz zrobić, ponieważ jesteś nowy. Jeśli nikt nie chce poprawiać rzeczy, zbierasz swoje doświadczenia i przenosisz się do następnego miejsca.


10
+1 za samą ostatnią linię. Ludzie zazwyczaj nie chcą słuchać nowicjusza, nawet jeśli nowicjusz zapewnia własne doświadczenie i inną perspektywę, którą wszyscy inni są zbyt głęboko zanurzeni w kulturze korporacyjnej, aby to zobaczyć. Ludzie są również ślepi, aby usłyszeć prawdę (tzn. „Wszystko jest złe, ponieważ ludzie, którzy ją założyli, byli idiotami, którzy nie wiedzieli, że robią WTF”) i wolą zejść ze statku, niż przyznać, że rzeczy są złe i trzeba byc naprawionym. Zadziwiające jest czasami, że właściciele firm ryzykują utratę wszystkiego, zamiast zajmować się naprawą złych rzeczy.
Wayne Molina

2
Kontynuując ten ostatni punkt, widziałem wiele miejsc, w których kierownictwo wolałoby ryzykować, że przestanie działać, gdy tandetny system się załamie, niż w rzeczywistości poradzić sobie z problemami i rozwiązać je, nawet jeśli te problemy oznaczają wstrzymanie się w sprawie nowych funkcji.
Wayne Molina

5
Niestety, zastosowanie pewnego rodzaju podejścia „wojny partyzanckiej” do przefakturowania może czasami prowadzić do strzelania sobie w stopę. O ile system nie ma dobrego zestawu testów jednostkowych / integracyjnych napisanych przeciwko niemu (co jeśli jest złe, najprawdopodobniej nie będzie) nieuchronnie doprowadzi do wprowadzenia błędów, które będą wymagały przejścia całego testu systemu przez kontrolę jakości.
aceinthehole

1
@aceinthehole: dokładnie w porządku. Jeśli testowanie jest drogie, zarząd nie będzie chciał ryzykować żadnych „niepotrzebnych” zmian, nawet jeśli bez nich system stanie się niemożliwy do utrzymania w dającej się przewidzieć przyszłości.
kevin cline

2
@WayneM, a ci idioci, którzy nie znali WTF, co robili na początku projektu, są teraz wyższymi menedżerami. Nigdy nie zapomnij tej części!
HLGEM,

58

Przeczytaj Joel On Software - rzeczy, których nigdy nie powinieneś robić. Zapoznaj się z jego uzasadnieniem, a następnie przeczytaj kilka innych artykułów na temat złego oprogramowania i sposobów jego naprawy, napisanych przez menedżerów, a nie programistów. Uzbrojeni w te informacje będziesz w stanie przedstawić sprawę do ich naprawy, w sposób zrozumiały dla menedżerów. Wskazówka: dobrzy menedżerowie nie spędzają czasu i pieniędzy wyłącznie na podstawie opinii i odczuć programistów na temat tego, co należy zrobić.

„Ten kod jest badziewny i wymaga przepisania” z pewnością zostanie odrzucony, nawet jeśli masz techniczną rację.

„Możemy odjąć kilka miesięcy od bieżącego harmonogramu projektu, kosztując mniej i czyniąc go bardziej niezawodnym.” zwróci ich uwagę (zauważ brak wzmianki o tym, JAK zamierzasz to zrobić na jego etapie.

Cokolwiek powiesz, bądź pewien, że masz rację. Jeśli powiesz, że to źle, twoje przepisywanie musi być cholernie dobre. Jeśli powiesz, że zajmie to tydzień, lepiej upewnij się, że będzie to tydzień, i bądź dobry. Wszelkie wady w przerobionym kodzie będą cię osobiście, drogo kosztować, niezależnie od tego, co by się stało, gdybyś nie zrobił przeróbki. Jeśli ktoś był tu przed tobą i spieprzył lub sprzedał przepisywanie, zrezygnuj, menedżerowie nie lubią, gdy oszukują cię i nie pozwolą, by stało się to dwa razy. W tym momencie, nie spieprz tego dla facetów, którzy podążą za tobą, dostaniesz tylko jeden strzał w to ...

Znajdź sposoby na rozłożenie kosztów na okres lub liczbę projektów. Menedżerowie nienawidzą ryzyka, inwestycji spekulacyjnych i ujemnych przepływów pieniężnych - pracuj w granicach tolerancji dla nich. Zacznij od małej sugestii o niskim ryzyku i niskich kosztach. Gdy okaże się, że masz rację, możesz wybrać większą rybę.


2
zabawne ... zostałem odrzucony za sugerowanie strony Joela :-)
Robert French

6
@Robert French: Twój menedżer czyta twoje posty ...
Dave Markle

8
Bez żartów. Nie jest fajnie próbować argumentować za: „Czy mogę mieć 6 miesięcy czasu programisty na przepisanie wszystkiego? Końcowy wynik będzie dokładnie taki, jaki mamy dzisiaj, ale prawdopodobnie z kilkoma nowymi błędami. Och, i będziemy używać wielu ci sami programiści, którzy stworzyli aktualną kupę bzdur do ponownego napisania, ponieważ teraz wiedzą lepiej. ”
JohnFx

3
@ joshin4colours: <quote> Tak, wiem, to tylko prosta funkcja wyświetlania okna, ale wyrosło na niej trochę włosów i inne rzeczy i nikt nie wie dlaczego. Powiem ci dlaczego: to są poprawki błędów . ... Każdy z tych błędów wymagał tygodni użytkowania w świecie rzeczywistym, zanim został znaleziony. ... Kiedy wyrzucasz kod i zaczynasz od zera, wyrzucasz całą tę wiedzę. </quote>
Martin York

4
Przepraszam, ale roczne doświadczenie nie gwarantuje wiarygodności w zakresie zgłaszania jakichkolwiek roszczeń do jego kierownictwa.
Jeremy

14

Po pierwsze, głupie, starsze rzeczy znajdziesz wszędzie, gdzie pracujesz jako programista, chyba że pracujesz na starcie i to ty tworzysz oryginalny, głupi, starszy kod. Jeśli planujesz karierę programistyczną, musisz być w stanie rzucić się na te ciosy.

Po drugie, często trzeba brać pod uwagę koszty ulepszenia starych systemów. Na przykład widziałem więcej niż jedną firmę, w której wciąż działało 10-letnie VB6 i klasyczne aplikacje ASP. W niektórych przypadkach było to spowodowane tym, że duży projekt przeniesienia platformy .NET nie powiódł się. W innych powodem było „jeśli się nie zepsuło, nie naprawiaj go”. Ale w innych koszt przeniesienia jest uzasadniony, ponieważ problemy spowodowane przez starszy system są zbyt duże, aby je zignorować.

W sytuacjach, w których w przeszłości doszło do dużej awarii, zmiana jest prawie niemożliwa. W takim przypadku dopracuj swoje CV i zacznij szukać nowej pracy. Jeśli nie zostanie zepsuty, prawdopodobnie nie będziesz miał powodów do narzekań na sam kod, ale nie byłeś na satysfakcjonującej i rozwijającej się ścieżce kariery. Jeśli jest zepsuty i wygląda na to, że tak jest w twoim przypadku, wtedy masz szansę na zmianę.

Najlepsze podejście, jakie widziałem, to nie gryźć zbyt wiele, ale zacząć od zmian przyrostowych, które będą miały najbardziej pozytywny wpływ. Na podstawie Twojego opisu lepiej zacząć od zarządzania wnioskami o zmianę. Gdy będzie to pod kontrolą, możesz zacząć szukać struktury usług lub innych przyrostowych ulepszeń projektu / kodu.

Najgorsze podejście, jakie widziałem, to zrobić wielki skok bezpośrednio ze starszego systemu do najnowszego i największego, na przykład, skacząc z działającego, ale niezgrabnego systemu VB6 / Classic ASP / COM + do systemu MVC / Entity Framework.


3
„Po pierwsze, głupie, starsze rzeczy znajdziesz wszędzie, gdzie pracujesz jako programista, chyba że pracujesz na starcie i to ty tworzysz oryginalny, głupi, starszy kod”. Byłem pierwszym programistą na starcie. Osiem ostatnich często powtarzam: „kto napisał ten głupi kod?”, Tylko po to, by sprawdzić i odkryć, że jestem winny.
Jim In Texas

Szybkość iteracji przewyższa jakość iteracji. Innymi słowy, często wprowadzaj wiele drobnych zmian, a ostatecznie dotrzesz tam, gdzie chcesz.
jasonk

11

„Hej, szefie, po Big Project ja i zespół chcieliby trochę czasu, najlepiej X miesięcy, na uporządkowanie naszego kodu. Rzeczy, które powinny być możliwe do wykonania w ciągu kilku minut, wymagają godzin, ponieważ wszystko jest bardzo zdezorganizowane. Jeśli nie jest to możliwe zaraz po Big Project chcielibyśmy zaplanować realistyczny harmonogram ”.

(częściowo sparafrazowany z komentarza Azkara do pytania)


10
Teoretycznie byłoby świetnie. W praktyce odpowiedzią byłoby coś w stylu „Nie, CEO chce Another Big Projectzrobić za X miesięcy”. lub „Mamy nowe funkcje, które należy wykonać od razu, nie mamy czasu, aby naprawić to, co już działa”
Wayne Molina,

2
To rzadko (jeśli w ogóle) działa. Zwłaszcza jeśli masz menedżera, który jest tu od dłuższego czasu, ponieważ on / ona usłyszy tę linię, zanim zobaczy, jak się wysadza.
taylonr

1
To po prostu mnie śmieje. Nigdy nie dostaniesz pełnego przepisywania w harmonogramie. To, co potencjalnie możesz zrobić, to mieć mniejsze zadanie w każdym nadchodzącym projekcie, aby ulepszyć jakiś podsystem, aby ostatecznie (w ciągu kilku lat) został on sprecyzowany.
Martin York,

Z mojego doświadczenia wynika, że ​​takie podejście często jest odrzucane. Alternatywnym podejściem jest wielokrotne oszacowanie Big Project o 1,5 i poświęcenie 1/3 czasu na czyszczenie kodu po drodze.
JBRWilkinson

2
Bardzo częstą odpowiedzią jest: „Kto to sfinansuje, otrzymując wypłatę?” Jeśli nie masz bezpośredniego sponsora zadania, musisz zlecić firmie długoterminową inwestycję. A może będziesz pracować za darmo?

7

Zacznij czytać Joel on Software (Joel Spolsky / Założyciel Stack Exchange) ...

PIERWSZĄ rzeczą, którą bym zrobił, to wykonanie testu Joela .

Pozwoli ci to przedstawić to jako „Gdy szukałem sposobów na ulepszenie jako programista ... Natknąłem się na ten 12 pytań testowych na temat środowisk programistycznych, więc dla zabawy odpowiedziałem im, gdzie pracuję”. ... To z kolei sprawia, że ​​strona trzecia objaśnia, co jest nie tak z twoim kodem, a nie ty osobiście.

Gdy przeczytasz więcej o Pragmatic Practices , będziesz się doskonalić i wdrażać takie rzeczy, jak czerwony / zielony / refaktor, a to z kolei pozwoli ci wyczyścić bazę kodu, aby stała się łatwa do utrzymania. (z biegiem czasu)

Mam nadzieję, że to pomaga! Witamy w Programowaniu (wczorajszy kod zwykle jest do bani) ;-)


4
Nie sądzę, żeby odnosiło się to do tego, jak powinien podejść do zarządzania.
Pubby

3
Wygląda na to, że Azbar zna problem i wie, jak go naprawić, ale nie wie, jak sprawić, by piłka się toczyła, aby można ją było naprawić.
Pubby

1
Tak ... Sugerowałem użycie punktu widzenia innej firmy podczas prezentacji. Nie sądziłem, że pytał konkretnie, jak rozmawiać z szefem.
Robert French

4
Ta odpowiedź nie zasługuje na tak wiele głosów negatywnych. Pierwsze zdanie zasługuje na +10. Problem z podejściem do zarządzania polega na zrozumieniu, co jest dla nich ważne, Joel, a ta odpowiedź rozwiązuje tego rodzaju problem, analizując powody, dla których, a dlaczego nie, z perspektywy biznesowej, kod powinien zostać przepisany.
mattnz

1
@Robert French +1 za dobrą odpowiedź. Ważne jest, aby Azkar zrozumiał biznes i technologię. Sugerowanie, by sformułował własną opinię na podstawie obserwacji wysoko wykwalifikowanej trzeciej osoby, pomoże w rozwoju Azkar jako programisty, a nie tylko programisty. Poza tym historia PB&J jest zabawna.
bakoyaro

7

Szybka wskazówka: jeśli zaproponujesz zarządzanie z listą powodów, dla których powinieneś kodować inaczej, dołącz jako argument „Poprawione morale / warunki pracy dla programistów”.

Wyjaśnij, że zespół technologiczny będzie pisał więcej treści i utrzymywał czysty kod niż obecny bałagan, a to z pewnością poprawi twoje podejście do pracy. Może to być przydatny argument.


zdecydowanie dobry pomysł, a także bardzo prawdziwy
sdm350

5
  • Czy kierownictwo faktycznie dyktuje projekt? Jeśli masz za sobą większość zespołu, co Cię powstrzymuje? Bądź proaktywny i decyduj jako grupa. Wymyśl plan, aby wprowadzić go stopniowo . Więc zrób to.
  • Czy kierownictwo dyktuje narzędzia programistyczne, których używasz? O ile zamiana zarządzania narzędziami nie jest czasochłonna, zwykle to nie obchodzi. Bądź proaktywny i wspólnie decyduj, jakich narzędzi programistycznych chcesz użyć. Jeśli potrzebujesz wykupić od zarządu, pokaż im plan migracji i analizę kosztów i korzyści. Więc zrób to.
  • Czy kierownictwo narzuca języki, których używasz? Bądź proaktywny i zdecyduj jako grupa, czego użyć zamiast VBScript. Wymyśl plan jego stopniowego wdrożenia i zrób to. Jeśli potrzebujesz wykupienia zarządzania, pokaż im plan. Więc zrób to.
  • Nie mam nic dla specyfikacji. Jest to zazwyczaj bardzo zależne od ludzi i procesów w twojej pracy. Określenie, co jest zepsute i minimalne zmiany wymagane do naprawienia procesu, wymaga czasu, analizy i zrozumienia tego, jak obecnie działają rzeczy i jak powinny one działać. Jeśli wiesz, że możesz wymyślić plan i spróbować przekonać kierownictwo.

Dostajesz więcej zmian i szacunku, jeśli zaproponujesz sposoby zmiany, które nie wymagają dużej ilości poświęconego czasu bez żadnej (lub miękkiej) wartości biznesowej do pokazania za to.


Nie / Tak / Tak. Wybór języka i narzędzi rzadko jest dokonywany ze względów technicznych. (patrz: parashift.com/c++-faq-lite/big-picture.html#faq-6.5 ) Są to narzędzia, którymi firma dysponowała od samego początku. Ponowne oprzyrządowanie firmy lub zespołu jest mało prawdopodobne z powodu spadku wydajności.
Martin York,

1
+1 za planowanie i wdrażanie przyrostowe. przepisywanie wszystkiego wymaga jedynie niepowodzenia. Małe wygrane z czasem budują pewność siebie. Jeśli chodzi o specyfikacje ... większość specyfikacji, które otrzymujesz jako programista, nie będzie w stanie dopracować ich. Od czasu do czasu rozpieszcza cię ktoś, kto pisze dobre specyfikacje. Zazwyczaj przenoszą się / awansują / znajdują lepszą pracę daleko, jeśli chodzi o programistę.
SoylentGray

@Loki Astari: W większości firm, w których byłem, przeszedłem przez zmiany - od systemu kontroli wersji, struktury, procesu rozwoju do nawet języka. Wszystko, czego potrzebujesz, to rozsądny plan niż nakreślenie kosztów i korzyści związanych ze zmianą. To, że jest to rzadko wykonywane, nie oznacza, że ​​nie można tego zrobić.
dietbuddha

4

Mówiąc z doświadczenia: to nie jest łatwe. To prawie niemożliwe. Kierownictwo nie dba o to, aby kod był do bani i bardziej niż prawdopodobne jest to, że są całkowicie nieświadomi i / lub nieświadomi problemów, z którymi się borykają, bo inaczej rozwiązaliby go dawno temu i nie utknąłbyś z nim dzisiaj. Najlepszą rzeczą, jaką możesz zrobić, jest sporządzenie listy powodów, dla których kod jest do bani, a następnie uzasadnienie, dlaczego jest do bani, aby wykazać rzeczywistą wartość biznesową podczas refaktoryzacji / przepisywania.

Przykładem może być „Kod nie do utrzymania”:

Obecny kod nie jest możliwy do utrzymania z powodu X , Y i Z (podaj powody, dla których nie można go utrzymać ). To sprawia, że ​​żądania zmian i nowe funkcje są bardzo trudne, ponieważ X , Y , Z (powody, dla których wprowadzanie zmian jest trudne). Ponieważ zmiany są trudne, zespół programistów nie może łatwo reagować na poprawki i ulepszenia błędów.

Jedyną nadzieją jest to, że szef i kierownictwo wyższego szczebla nie są zbyt głupi, aby zrozumieć, jakie są konsekwencje dla kodu, i są gotowi przestać wysyłać nowe prośby o nowe funkcje, aby rozwiązać problemy, w przeciwnym razie twoje wysiłki będą daremne . Mówiąc z wcześniejszych doświadczeń, jest bardzo prawdopodobne, że nie zobaczą nic złego w kodzie i / lub twoi współpracownicy są zbyt bezrozumni, aby wnieść swoje obawy do kierownictwa.

Powodzenia. Będziesz tego potrzebować.


2
Zgadzam się i „nie do utrzymania” działa również tylko do pewnego stopnia. Dla wielu menedżerów (zwłaszcza bez wiedzy technicznej) działający kod jest równoważny kodowi, który można utrzymać. Jeśli twierdzisz inaczej, możesz być nawet postrzegany jako niekompetentny w ich oczach.
MAR,

3

„Zacząłem świeżo po studiach” - powinienem odpowiedzieć na twoje pytanie.

Kierownictwo prawdopodobnie wie, że kod nie jest optymalny. Większość kodu jest, chyba że zatrudniłeś Raya Goslinga, Guido Van Rossuma lub kogoś naprawdę dobrego i drogiego do napisania.

Kierownictwo wie również, że działa, niezależnie od tego, która definicja „działa” dotyczy Twojej firmy (nie ulega awarii, sprzedaje, dostarcza raporty itp.).

Chcą, abyś utrzymał kod „działający” przy minimalnych kosztach. Nie chcą, aby propozycja drogiego projektu przepisała wszystko od nowa.


Twoja pierwsza linia jest całkowicie stronnicza w stosunku do juniorów. Po pierwsze, nie znasz JEGO doświadczenia, więc nie możesz udzielić odpowiedzi na jego pytanie. A uogólnienie jako takie jest wyjątkowo stronnicze w stosunku do juniorów! Pracuję nad tym od około 20 lat i mogę zagwarantować, że widziałem bardziej doświadczonych „początkujących” niż „starszych ignorantów”.
Jeach

Niezupełnie stronniczy w stosunku do juniorów, ale być może powinien on uznać doświadczenie i doskonałą wiedzę swoich kolegów, którzy pracują od jakiegoś czasu? Nie wszyscy mogą być niekompetentnymi starymi Wallies.
James Anderson

2

Taki przypadek biznesowy jest prawie niemożliwy do wykonania, ponieważ twój produkt to działające oprogramowanie (co już mają) nie elegancki kod.

Dodaj fakt, że w oprogramowaniu pojawienie się na rynku z pierwszymi funkcjami wiąże się z dużymi kosztami alternatywnymi. Jeśli naprawdę się nad tym zastanowisz, nie ma gwarancji długoterminowego zwrotu z inwestycji w czas.

To powiedziawszy, nadal dobrym pomysłem jest refaktoryzacja i naprawa drobnych rzeczy (takich jak uzyskanie dobrego VSS) po drodze w zarządzalnych kęsach. Ostatecznie jest to kwestia techniczna, a nie problem zarządzania. Po prostu rób to, co trzeba zrobić, jednocześnie spełniając obietnicę, a wszystko będzie dobrze. Kierownictwo prawdopodobnie nie będzie zainteresowane drobiazgowymi szczegółami jakości kodu, nawet jeśli zrobisz to solidnie.


2

Po prostu odejdź tak szybko, jak to możliwe (może nie odejdź zbyt wcześnie, ponieważ nie chcesz wyglądać na lejka). Fakt, że kodują, to bałagan, a ludzie tam przebywają, co oznacza, że ​​prawdopodobnie współpracujesz ze słabymi programistami. Każdy porządny programista, który dba o swoją pracę, nie będzie długo pracował nad takimi bzdurami.

Szansa, że ​​przepisanie nastąpi dość nisko, chyba że możesz bardzo wyraźnie wykazać, że warto zainwestować $$$.


Jest to w końcu jedyny prawdziwy sposób działania. Powiedziałem to wcześniej, powiem to jeszcze raz: Inteligentni programiści pracują dla inteligentnych firm, które rozumieją, dlaczego tak ważne jest ZAWSZE pisanie dobrego kodu i poświęcanie niezbędnego czasu na zapewnienie dobrego kodu. Kiepscy programiści pracują dla kiepskich firm, w których wszyscy są zbyt skoncentrowani na „wykonywaniu swoich zadań”, aby dbać o to, że po prostu dodają więcej błota na stosie, a nawet widzą kod refaktoryzacji, który nie jest bezpośrednio związany z twoim bieżącym zadaniem, aby „marnować” czas". Te miejsca nie są warte pracy, jeśli uważasz się za mądrego.
Wayne Molina,

1

Kierownictwo nie dba o kod. Dbają o to, żeby produkt mógł sprzedać.

Jeśli starszy system jest naprawdę, naprawdę zły i dodaje niedorzecznej kwoty narzutów dla większości zespołu (mówię większość, ponieważ zawsze jest facet, który albo koduje duże fragmenty, albo całość, i zna go jak tył jego dłoń), a następnie podejdź do nich i powiedz, że kosztuje to pieniądze biznesowe w czasie programowania, a to przyniesie satysfakcję klienta.

Ale po raz kolejny wciąż nie dbają o kod, dbają o produkt, więc chociaż ta odpowiedź może sprawić, że powiedzą „Tak, zróbmy to”, równie dobrze możesz uporządkować kod bez uzyskania zgody menedżera. Nie przesadzaj, upewnij się, że najpierw porozmawiasz z zespołem, nikt nie lubi przyjść i spróbuj użyć tej funkcji, której napisanie zajęło Ci 3 miesiące, a teraz wydaje się, że nie działa, ponieważ została zhackowana.


Jak sugerujesz ... Musi być coś, co może zrobić, aby poprawić kod. Jeśli to wszystko jedna gigantyczna funkcja, można coś z tym zrobić. Fakt, że narzeka nawet na Bezpieczne źródło, jest dość zabawny. Nie ma nic złego w Source Safe, był używany przez lata, może mieć kilka rzeczy, które nie mają sensu w dzisiejszym świecie, ale z perspektywy czasu.
Ramhound,

Myślę, że sam SourceSafe nie jest problemem, nadal korzysta z SourceSafe, gdy dostępne są lepsze darmowe narzędzia, po prostu krzyczy: „Jesteśmy nieświadomi wszystkiego po wyjęciu z pudełka” i „Przeciętność jest regułą dnia, ponieważ będziemy trzymać się gorszego produkt zamiast uczyć się go lepiej ”. Problemem jest postawa większości użytkowników SourceSafe.
Wayne Molina

„posprzątaj kod bez pozwolenia” - brzmi jak naprawianie czegoś, co nie jest zepsute.
James Anderson,

1
Mój salon nie stanowi zagrożenia dla zdrowia, ale nadal dbam o to, aby go regularnie czyścić. Nie tyle przypadek naprawienia czegoś, co nie jest zepsute, ale wykonanie potrzebnego zadania.
Nicholas Smith

0

Podejdź do zarządzania w taki sposób, aby pokazać, że rozumiesz wpływ na budżet wprowadzania dużych zmian w kodzie i wpływ na budżet NIE dokonywania zmian. Podobały mi się słowa Emilio.

Należy pamiętać, że „stary” kod zawsze będzie okropny. Rozumiem przez to, że wszyscy stale rozwijamy się jako programiści. Piszemy dobry kod, a następnie uczymy się pisać lepszy kod później, a poprzedni „dobry” kod wydaje się okropny. Zbyt wielu programistów przyłapuje się na ciągłym ulepszaniu i marnowaniu większej ilości pieniędzy na dłuższą metę. To równowaga. To powiedziawszy, zawsze świetnie jest, jeśli możesz ulepszyć go w drodze. Kiedy idziesz zmodyfikować tę gigantyczną funkcję, podziel ją! W końcu gdzieś się dostaniesz.


0

Nie rób tego

W każdym razie przepisywanie dużego projektu od podstaw jest dużym błędem.


Duży jest względny.
Luca

1
Moja definicja brzmi: jeśli nie możesz przepisać go samemu w ciągu 5 dni, to jest duży.
Cesar Canassa

-1

Nigdy nie sądziłem, że łatwo jest powiedzieć menedżerom, zwłaszcza kierownikom projektów, o złym kodzie i refaktoryzacji. Po pierwsze, muszą ci ufać, nawet jeśli jesteś starszym facetem, wciąż potrzebujesz czasu, aby zaufać. Po drugie, po prostu nie rozumieją, jak poważny jest problem. Jeśli dzisiaj jest ostatni dzień na wydanie nowej kompilacji, a kompilacja się nie powiedzie. Wiedzą, jak poważny jest, ale nigdy nie wiedzą, że kompilacja po prostu się nie powiodła, ponieważ wiele problemów, takich jak zły kod, nieodpowiednie testowanie itp.

Wykonałem zadania związane z konfiguracją i wdrażaniem w projekcie internetowym. Naprawianie nieoczekiwanych problemów za każdym razem, gdy wdrażam nową kompilację, zajmuje dużo czasu. Większość problemów dotyczyła bezpieczeństwa i integracji (między kilkoma aplikacjami WWW / Windows). Nasz kod jest do kitu, kod innych jest do kitu, to kompletny kod spaghetti.

Planowaliśmy nową wersję i zdecydowanie poprosiłem o pewne refaktoryzowanie, po prostu dodaj szczegółowy dziennik do kodu logowania / uwierzytelnienia, w którym często występowały błędy. Menedżerowie zgodzili się, ale potem została umieszczona na ładnej liście i nie wiem, czy to się stanie, ponieważ mieliśmy już dużą listę funkcji i napięte ramy czasowe.


-3

Istnieją dwa rodzaje menedżerów: ci, którzy udają, że rozumieją, co robisz, i ci, którzy tego nie robią. Ci, którzy udają, że rozumieją oprogramowanie, będą ci wrogo nastawieni. Te, które nie są po prostu zirytowane przez ciebie.

W każdym razie menedżerowie są kłamcami, więc mają silną skłonność do zakładania, że ​​wszyscy inni są.

Chodzi mi o to, że jeśli powiesz, że oprogramowanie jest nieaktualne, uznają to za wymówkę. Nie obchodzi ich to.


+1 na „wszyscy menedżerowie są kłamcami, więc mają silną skłonność do zakładania, że ​​wszyscy inni są”
ZJR

-1 na tym samym; zarówno nieprawdziwe, jak i nieprzydatne
Jaap

@Jaap istnieje wiele badań, które korelują siłę i klasę społeczną z nieuczciwością. Czy to oznacza, że ​​cofniesz swoje -1? Przykłady: msnbc.msn.com/id/35836844 blogs.discovermagazine.com/notrocketscience/2010/04/27/... news.sciencemag.org/sciencenow/2012/02/shame-on-the-rich.html
Joe

Drugie badanie szczególnie potwierdza mój dokładny punkt.
Joe

1
@Joe: twoje linki nie (zaczynają) dowodzić twojego twierdzenia, że ​​„wszyscy menedżerowie są kłamcami”.
Jaap
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.