Niedawno zostałem przydzielony do nowego projektu. Właściwie stary projekt napisany w klasycznej ASP. Teraz nowa wersja aplikacji jest pisana w najnowszej wersji ASP.NET, ale nie należy się spodziewać, że będzie to RTM za jakiś czas (przewidywana data premiery to styczeń 2017 r.), Więc muszę przeprowadzić konserwację starej aplikacji, dopóki nie będzie można odrzucone.
Mam też wrażenie, że nie wszyscy klienci natychmiast przestawią się na nowy program, więc ta wersja prawdopodobnie będzie dostępna przez jakiś czas.
Problem polega na tym, że jest pełen błędów. Niektóre z nich pochodzą z ubiegłego wieku, kiedy nie było żadnych standardów sieciowych, a tak naprawdę nie mam nic przeciwko trybowi dziwactwa widthi heightatrybutom zamiast CSS, tabel używanych do układu, zestawów ramek itp., Ale och, wszystkie te błędy! width="20px"wszędzie onchange="javascript:..."i wszędzie tam, gdzie używają css style="width:20"i style="width=20px"są powszechne. Nie wspominając o wielu liniach, w których istnieją sprzeczności widthi styleatrybuty. Itd itp.
W rezultacie aplikacja internetowa działa tylko w IE i tylko w trybie zgodności. Oczywiste jest, że programiści nigdy nie patrzyli na poprawność kodu, tylko jeśli to, co wyszło, wyglądało tak, jak mieli na myśli, powinno to wyglądać.
I nie wiem jak sobie z tym poradzić. Nie mogę zamknąć oczu na te błędy podczas wyszukiwania w kodzie innych błędów.
Mogę oczywiście dokonać globalnego wyszukiwania i zamiany, aby usunąć większość problemów, ale to oznaczałoby, że moje pierwsze zatwierdzenie składałoby się z tysięcy zmienionych plików .asp. Czy mogę to zrobić?
źródło
Odpowiedzi:
Brzmi, jakbyś mylił kilka rzeczy z terminem „błędy”
W starszej aplikacji, która zostanie zastąpiona, tylko jeden z tych rodzajów błędów powinien Cię dotyczyć. Ostatni.
Chciałbym powiedzieć, że nie powinieneś nawet refaktoryzować innych rzeczy w funkcji, którą naprawiasz, głównie z powodu:
Możesz zobaczyć z kodu, jak to mogło działać, ale nigdy tak nie było, ale wszyscy użytkownicy dogadywali się z nieokreślonym rozszerzeniem elementu przez ostatnie 10 lat i nie będą ci wdzięczni za naprawę.
Na plus, jeśli włożysz cyniczny interfejs JFDI, będziesz w stanie nagrać błędy bardzo szybko, a zespół nowej wersji nie będzie w stanie nadążyć za funkcjami starych wersji.
To da ci krzykliwy uśmiech ironicznej radości, gdy polecasz klientom chromowaną wtyczkę, tj. Emulator 6, aby mogli nadal korzystać z „funkcji” markizy, którą kochają
źródło
... JFDI ...To, co zadajesz, nie jest pytaniem technicznym i nikt tutaj nie może na nie odpowiedzieć.
Pracujesz nad oprogramowaniem w trybie konserwacji i obserwujesz przestarzałą technologię oraz dużą liczbę niedoskonałości i niespójności. Pytasz co robić. Czy należy na przykład zwiększyć wysiłki, aby uczynić go kompatybilnym z różnymi przeglądarkami? Czy powinieneś dostosować go do nowoczesnych standardów? Czy należy naprawić niespójności składniowe w aplikacji? Chodzi o to, że są to decyzje biznesowe . Powinieneś zapytać swojego menedżera lub właściciela produktu, jakie problemy chcesz rozwiązać i jakie są ich priorytety. Ponieważ już trwa projekt przepisywania aplikacji, kierownictwo najprawdopodobniej już zdaje sobie sprawę z problemów, które zaobserwujesz.
Jeśli aplikacja zostanie w pełni zastąpiona w ciągu kilku miesięcy, prawdopodobnie chcą tylko, abyś naprawił określone problemy krytyczne i zostawił resztę bałaganu w spokoju. Ale nie wiemy.
Pytasz, czy możesz wykonać obszerną operację wyszukiwania i zamiany w bazie danych, zmieniając tysiące plików. Oczywiście, że możesz. Pytanie brzmi, czy powinieneś . Takie zamiany prawdopodobnie będą wymagały obszernych testów, aby upewnić się, że nic się nie zepsuło. Ponownie decyzja biznesowa jest ważniejsza, jeśli korzyści przewyższają koszty w czasie i ryzyko.
źródło
Gdy wniosek zostanie zastąpiony w ciągu 18 do 24 tygodni (dodając spodziewane opóźnienia do przedstawionego powyżej szacowanego okresu od 6 do 8 tygodni), naprawdę musisz zadać sobie pytanie, jaką wartość dodasz do firmy, wciąż inwestując znaczną ilość pracy w stara wersja.
Pewnie, jeśli utkniesz ze wsparciem aplikacji przez kilka lat, to pozbycie się długu technicznego może być tego warte na dłuższą metę. Ale skoro i tak wszystko zostanie zrzucone, to po co zawracać sobie głowę? Wystarczy dodać kolejną poprawkę hackish na wierzchu wszystkich innych hackish poprawek, aby naprawić każdy problem, po prostu nie mogę się doczekać wydania nowej wersji i nazwać to dzień.
Można również zadać sobie pytanie, co można zrobić dla aplikacji w małym życiu jeszcze opuścił. Kiedy jesteś naprawdę nudzi już teraz i po prostu nie mają nic lepszego do roboty ze swoim czasie mogła dać mu wielki remont i usunąć wszystkie problemy styl pan wspomniał, ale jest bardzo prawdopodobne, że będzie to na pierwszej przerwie więcej rzeczy niż to naprawić . Być może będziesz w stanie pozbyć się tych nowych problemów, mając w końcu wystarczająco dużo czasu, ale nie masz tego czasu.
źródło
s/weeks/years/Powody, dla których NIE należy wprowadzać dużych zmian:
Po pierwsze: kod zniknie za kilka miesięcy. Czy naprawdę warto poświęcić firmie 5 miesięcy na naprawę systemu, który zostanie wyrzucony 1 miesiąc później? Zastrzeżenie: systemy rzadko znikają, gdy są zaplanowane na odejście. System wymiany prawie zawsze się spóźnia, są użytkownicy, którzy nie mogą dokonać aktualizacji z jakiegokolwiek powodu itp. Ale to złożony problem.
Po drugie: jeśli wprowadzisz wiele zmian, zwłaszcza masowe wyszukiwanie i zamiany, wprowadzisz błędy. Nie możesz wprowadzać błędów: będziesz. Załóżmy, że zrobiłeś S&R i zmieniłeś „width = 200” na „width: 200px”. Czy na stronach ASP jest kod C # lub VB? Ponieważ jeśli miałeś zmienną o nazwie „szerokość”, którą ustawiłeś na 200, po prostu ją złamałeś. (A jeśli chodzi o to, czy pomyślałeś o ograniczeniu S&R do stron ASP?) Lub jeśli zmieniłeś „width: 200” na „width: 200px”, co się stanie, jeśli w kodzie będzie jedno miejsce z napisem „szerokość: 200 mm „? Teraz mówi „szerokość: 200pxmm”. Okej, załóżmy, że o tym pomyślałeś. Co jeśli jest miejsce, które ma niepoprawną specyfikację szerokości, co oczywiście jest ignorowane, a teraz układa się całkiem nieźle. Naprawiasz" szerokość i teraz określa się na 200px ... a wyświetlacz jest zepsuty, ponieważ 200px to w rzeczywistości niewłaściwa szerokość do podania i działało tylko dlatego, że ta wartość została zignorowana? Mass S & R są bardzo niebezpieczne, ponieważ prawie na pewno nie studiujesz każdego miejsca, które zmienisz. Prawdopodobnie nie jesteś nawet pewien, co przetestować.
Po trzecie: kod, który jest „oczywiście” zły, może być tym, czego chce użytkownik. Widziałem wiele specyfikacji wymagań, które nawołują do zachowania, które jest oczywiście złe i szalone ... a potem wracam do użytkowników i pytam, czego NAPRAWDĘ chcą, i okazuje się, że naprawdę chcą tego szalonego zachowania, ponieważ to jak działają ich firmy lub wymagają tego przepisy rządowe lub cokolwiek innego.
Nawet jeśli zachowanie jest naprawdę złe, być może użytkownicy zaczęli się tego spodziewać i rutynowo obejdą go, a naprawiając go, złamiesz ich obejścia. Przykład: Pracuję w systemie, w którym mamy miejsce, w którym podajesz daty od i do momentu, kiedy wyprzedaż jest dostępna publicznie. Obie daty były tak naprawdę północą, która rozpoczęła się tego dnia, więc jeśli powiesz „do 30 lipca”, oznacza to, że zakończyło się ono z końcem dnia 29 lipca, tj. Minutę przed 12:01 30 lipca, a nie do końca 30 lipca W pewnym momencie to naprawiłem, ale mogłem to zrobić tylko dlatego, że było mniej niż pół tuzina osób uprawnionych do korzystania z tego ekranu i mogłem po prostu powiedzieć im wszystko, co naprawiłem. Gdyby były setki użytkowników i wszyscy do tej pory zorientowali się, że naprawdę musisz podać dzień po ostatecznej dacie, to moje „naprawienie”
źródło
Nie rozumiem dlaczego nie. Zatwierdzenie powinno być koncepcyjnie jedną rzeczą, ale nie widzę powodu, dla którego globalne znajdowanie i zamiana z
style="width=20"nastyle="width: 20px"nie byłoby liczone jako „jedna rzecz”, mówiąc koncepcyjnie. A jeśli to pomoże ci lepiej spać, nie rozpraszaj się, gdy naprawiasz inne rzeczy i niczego nie psujesz , dlaczego nie?źródło
Twoim problemem jest ustalenie priorytetów : Które z problemów to showstoppers (w produkcji)? Które tykają szkielety czasu? A które można pozostawić za chwilę (bo to działa i działa od lat, a nawet w pewnym sensie)?
W twojej sytuacji zrobiłbym listy klas problemów , na które chciałbym spojrzeć. Na przykład, zastępując
style="width=(\d+)"zstyle="width: \1px"(które prawdopodobnie mogą być usunięte z globalnym Znajdź / Zamień przy użyciu regexp - Przepraszam, jeśli moje nie jest w 100%) będzie jedną klasę, a jeśli nie jest po prostu jednym przypadku, to niech tak będzie. Dla każdej kategorii wymień priorytet (jak pilne jest to zrobić) i szacunek pracy (ile czasu zajmie wykonanie tej kategorii).Twoje zadania konserwacyjne również znajdą się na tej liście. Teraz zaczynasz stosować pewne zarządzanie, nawet jeśli tylko do siebie, i masz narzędzie, z którego możesz skorzystać, gdy masz czas i nie masz nic do roboty, lub gdy musisz negocjować z menedżerem o pracy do wykonania (lub poprosić czas przeznaczony na coś, czego może nie być świadomy). (Ten rodzaj proaktywności może pomóc ci zostać zauważonym w przypadku promocji, jeśli zostanie to zrobione prawidłowo).
Myślę, że lubisz programować, ponieważ masz do pewnego stopnia perfekcyjną osobowość. ALE w środowisku komercyjnym musisz zacząć zdawać sobie sprawę, że doskonały jest wrogiem dobra (a dobro przynosi pieniądze, doskonały niekoniecznie może przynieść zauważalnie więcej za dużo więcej pracy). Najpierw zrób to, co jest potrzebne, a następnie zrób to, co jest miłe. Tak, to może iść wbrew twojemu zbożu bez końca. Po prostu się uśmiechnij i znieść, a może zdobędziesz hobby, aby ćwiczyć swój perfekcjonizm i zachować zdrowie psychiczne ;-)
źródło