Refaktoryzuj lub skoncentruj się na uzupełnianiu aplikacji

Czy przebudujesz swoją aplikację na bieżąco, czy skupisz się na jej ukończeniu? Refaktoryzacja oznacza spowolnienie postępu aplikacji.

Ukończenie aplikacji sprawi, że później będzie Ci bardzo trudno utrzymać aplikację?

Aplikacja jest osobistym projektem. Naprawdę nie wiem, jak odpowiedzieć na pytanie „Co napędza funkcjonalność i wygląd”, ale myślę, że ma to na celu rozwiązanie nieefektywności obecnego oprogramowania. Lubię też minimalne, łatwe w obsłudze oprogramowanie. Usuwam więc niektóre funkcje i dodaję te, które moim zdaniem pomogą.

Niech to zadziała. Więc zrób to szybko. Na koniec spraw, aby było piękne.

Jeśli masz dobry rozdział między kodem (warstwą prezentacji, biznesową i warstwą danych) za pomocą interfejsów i nie jest to projekt monolityczny, wówczas refaktoryzacja nie powinna być trudna.

Jeśli masz tak duże trudności z refaktoryzacją, prawdopodobnie jest to zapach kodu - proponuję spojrzeć na Solid Principles

Myślę, że zasadniczą kwestią jest utrzymanie interfejsów w czystości . Zawsze możesz zawsze przeredagować, a nawet przepisać moduł / klasę / dowolne implementacje, o ile warstwy komunikacyjne między nimi są zdrowe. Poświęć trochę czasu na zastanawianie się, co później łatwo zmienić, a co nie. Zrób to drugie.

Jest to zgodne z duchem TDD. Aby pisać dobre testy, potrzebujesz dobrego interfejsu do testowania. To, jak chaotycznie jest za kulisami, nie jest w tym momencie tak ważne, ponieważ możesz to poprawić później.

Zawsze refaktoryzuję na bieżąco, szczególnie używając TDD.

1. Napisz testy

2. Sprawdź testy

3. Refaktor

Pomoże to w zmniejszeniu liczby błędów i poprawieniu kodu gotowego produktu. Pozwoli ci to również mieć mniej kodu do utrzymania po zakończeniu.

Refaktoryzuj wcześnie i często! Czas, który „oszczędzasz” na nie robieniu tego, jest poświęcony wiele razy na próbę włamania się do kolejnej funkcji i poszukiwanie błędów w zbyt złożonym lub chaotycznym kodzie.

Refaktoryzacja jest jak odbiór pokoju.

Jeśli utrzymujesz porządek, masz liniowy narzut, proporcjonalny do ilości produktywnej pracy, którą wykonujesz na kodzie, O (n) w kategoriach algorytmologa. Zakładając, że spędzisz 10% czasu na refaktoryzacji (lub utrzymaniu porządku w pokoju), że 10% jest podaną i pozostanie niezmienna w czasie.

Jeśli jednak rzucisz swoje brudne ubrania w kąt i będziesz to robił dalej, ilość czasu, który będziesz spędzać na podnoszeniu pokoju, rośnie, gdy bałagan staje się bardziej złożony. Zakładając, że każda pojedyncza część brudnego prania przyczynia się wykładniczo do wymaganego czasu czyszczenia, jesteś teraz w O (e ⁿ ) sytuacji.

Każdy, kto kiedykolwiek zagłębił się w koncepcję złożoności algorytmicznej, zauważy, że istnieje gdzieś próg rentowności, czyli optymalna ilość brudnego prania do gromadzenia; ile to zależy od stałych czynników, które są odrzucane w notacji big-O. Kolejnym czynnikiem jest wartość twojej pracy w czasie: jeśli twoja praca jest teraz dużo warta, ale tania w przyszłym tygodniu (tj. W piątek jest termin na ten projekt i jeszcze trzy, ale potem będziesz w większości bezczynny ), równanie może okazać się na korzyść braku refaktoryzacji.

A potem jest masa krytyczna złożoności. W pewnym momencie bałagan („krytyczny bałagan”, jeśli wolisz) staje się tak zły, że łatwiej jest po prostu spalić cały pokój i kupić nowe ubrania. W rzeczywistości zwykle tak nie jest, ale wydaje się, że tak jest, a efekty psychologiczne sprawią, że dziesięć razy trudniej poradzisz sobie z tym problemem.

I oczywiście, jeśli wejdziesz już w projekt, który jest gigantycznym, wielokrotnie redundantnym bałaganem, masz ograniczony wybór.

TL; DR: W razie wątpliwości dokonaj refaktoryzacji. Powinieneś mieć naprawdę dobry dowód, zanim zdecydujesz się tego nie robić.

Jeśli masz możliwość dodania funkcji lub zmiażdżenia błędów, aby uzyskać satysfakcję ze sprzedaży / klienta tam, gdzie uważasz, że powinna być, zrób to. Gdy pojawi się mniej nowych wymagań, możesz zrównoważyć z refaktoryzacją. W pewnym momencie musisz się upewnić, że piszesz kod, który ludzie chcą. Wszystkie rzeczy są równe, wolę wyrzucić 100 godzin kodu niż 1000. To właśnie zrobisz, jeśli nikt tego nie chce.

Naprawdę zależy od tego, gdzie jesteś!

Inne rzeczy do przemyślenia:

Czy jesteś pewien, czy naprawdę masz funkcjonalny design? Czy możesz ponownie zaprojektować po otrzymaniu opinii od użytkowników?

Wolę wypuścić niż przepisać. Zoptymalizuj po upewnieniu się, że masz funkcjonalny design.

Dopóki masz pewność, że dotrzymasz terminu, upewnij się, że możesz refaktoryzować wszystko, co chcesz. Jednak nawet jeśli istnieje niepewność, lepiej trzymać się rozwoju i może być refaktorem tylko w niewielkim stopniu.

Jeśli zły projekt, który chcesz przerobić, naprawdę cię boli, lepiej go teraz napraw, niż stwórz więcej zależnego od niego kodu. Refaktoryzacja później byłaby trudniejsza i droższa; są szanse, że nie będziesz już w stanie tego zrobić.

Z drugiej strony, jeśli twoim jedynym problemem jest brzydota, możesz najpierw ukończyć swoje oprogramowanie, ponieważ prawie nic nie jest w stanie zrobić .

Refaktoryzacja będzie bardzo ważna podczas pracy nad wypełnieniem wniosku.

+ VES

1. Clear Flow: Refaktoryzacja zapewni przejrzystość kodu, ponieważ czasami, jeśli kod jest mało nieustrukturyzowany, zrozum przepływ kodu po pewnym czasie stanie się trudny, a refaktoryzacja kodu może stać się trudnym zadaniem i mogą zostać wprowadzone błędy.

2. Poprawa wydajności: Odpowiednie refaktoryzowanie aplikacji z pewnością pomoże poprawić wydajność aplikacji.

3. Konserwacja: Wreszcie, na dłuższą metę łatwiej byłoby ją utrzymać.

-VE

1. Czasochłonne: Byłoby o wiele bardziej czasochłonne na każdym etapie swojego rozwoju. Może więc wystąpić opóźnienie w zakończeniu.

Dolna linia

W zależności od typu projektu można ustalić priorytety dotyczące jakości lub zakończenia kodu, zależnie od tego, co jest wymagane w obecnej sytuacji.

W oparciu o moje osobiste doświadczenia zwykle najpierw kończyłem aplikacje, pod warunkiem, że jest to termin ostateczny. po zakończeniu możesz go refaktoryzować.

Zakończ i przebuduj. Ale jeśli nie ma terminu na pośpiech lub ramy czasowe, sugeruję, aby refaktoryzacja byłaby dobra.