Czy to zły znak, że często przeprojektowuję podczas opracowywania projektu?

Kiedy po raz pierwszy zacząłem programować, założyłem, że pewnego dnia dojdę do momentu, w którym rozpocznę projekt, siadając i szkicując schemat UML dla wszystkich klas, a następnie trzymaj się tego. Programuję teraz od kilku lat i tak nie jest. Kiedy przechodzę przez projekt, często mówię

• „Hej, potrzebuję zajęć do zrobienia _ _. Nie myślałem o tym wcześniej.”
• „Zaczekaj, ta funkcja powinna naprawdę znajdować się w tej klasie zamiast tej. Przestawię ją.”
• „To powinny być dwie klasy zamiast jednej. Podzielę to.”
• „Powinienem uczynić te trzy samodzielne klasy odziedziczonymi po jednej klasie abstrakcyjnej”.
• Etcetera itp.

Czy to zły znak, że często zmieniam projekt w ten sposób? Czy to oznacza, że ​​jestem słabym programistą, czy to normalne?

To normalna część rozwoju. Dwa podstawowe założenia Continuous Design to:

1. Nie jesteś wszechwiedzący, nie możesz poznać całego systemu od początku do końca, zanim zaczniesz.
2. Projekt nie jest statyczny. Jest to bardziej powszechne, gdy projekt był używany od dłuższego czasu, a problemy, które teraz rozwiązuje, nie są problemami, które rozwiązał, gdy był napisany po raz pierwszy.

Moim osobistym poglądem w tej sprawie jest to, że powinieneś mieć dobry pomysł na projekt makro , ale pozwolić na rozwój mikroprojektów . Innym sposobem na wyrażenie tego jest to, że projekt wysokiego poziomu (który jest tak daleko, jak to możliwe z narzędziami UML / do modelowania) najprawdopodobniej pozostanie dość statyczny przez cały czas trwania projektu. Szczegółowy projekt, które metody robią, a hierarchia klas musi być dowolna, aby była plastyczna.

Kiedy naprawdę nie wiesz zbyt dużo o rozwiązywanym przez ciebie problemie, będziesz popełniał znacznie więcej początkowych błędów. Jednak po tym, jak pracujesz nad tym wystarczająco długo, ogólny projekt zacznie się ustalać, a refaktoryzacje, o których mówisz, są wszystkim, co będzie potrzebne, aby utrzymać porządek w kodzie.

To, co robisz, jest powszechnie nazywane „refaktoryzacją”. Jeśli kiedykolwiek przestaniesz to robić, będziesz miał kłopoty.

Faktem jest, że większość kodu jest złożona, a ludzie, nawet całkiem sprytni, nie potrafią tego rozgryźć od razu.

Nie, wydaje się, że śledzisz YAGNI i dokonujesz refaktoryzacji na podstawie podanych przykładów. Czy nie uważasz, że lepiej jest mieć to lepsze rozwiązanie i móc to zrobić, niż po prostu nigdy więcej o tym nie myśleć?

Zwinne tworzenie oprogramowania zwykle stosuje praktyki, które są w stanie to zrobić zupełnie inaczej niż w modelu kaskadowym.

To jest całkowicie w porządku (chyba że te przeprojektowania są zawsze poważnymi remontami lub odbudowują od zera). Nie martw się Dobrze jest zacząć od schematu UML na początku projektu, ale nie rzeźb go w kamieniu, ponieważ prawie zawsze odkryjesz, że rzeczy się zmieniają podczas pracy. Możesz nauczyć się nowych technik, których na początku nie znałeś, możesz ulepszyć niektóre funkcje w sposób, o którym nie pomyślałeś podczas wstępnego projektowania, zmieniają się wymagania biznesowe, czasem podczas wstępnego projektowania są nieznane, które mogą tylko być rozliczone później itp.

Co jest ważne, aby iść i aktualizacji tych dokumentów wstępnych UML tak, że odzwierciedlają one żadnych znaczących zmian w projekcie, bo inaczej przyszłych programistów (w tym siebie) może skończyć się bardzo mylić. Może to być trudne i często wymaga dobrej planówki (i czasu).

Bardzo bardzo bardzo rzadko zaczyna się od projektu i przestrzega go w 100% do momentu wdrożenia. Osobiście nigdy nie widziałem czegoś takiego, z wyjątkiem bardzo małych i trywialnych programów.

To, co robisz, jest całkowicie normalne (pod warunkiem, że za każdym razem nie zaczynasz od zera). Byłem w tym od ponad dwudziestu lat i wciąż jest to proces iteracyjny.

Jedyny raz będziesz w stanie zaprojektować wszystko z góry i trzymać się tego, jeśli rozwiążesz dokładnie ten sam problem, który rozwiązałeś ostatnim razem, a nawet wtedy prawdopodobnie będziesz w stanie znaleźć miejsce na poprawę.

W żadnym wypadku nie jestem bardzo doświadczonym programistą, ale robię to również. W ciągu ostatnich kilku lat znacznie poprawiła się moja zdolność mentalnego konstruowania niezbędnej architektury. Jednak gdy piszę oprogramowanie, bez względu na to, ile planuję, zawsze są miejsca, które wymagają nieco przeprojektowania. Miejsca, których nie zdawałem sobie sprawy, że powtarzam się, dopóki kod nie zostanie napisany.

Moim celem tego postu jest stwierdzenie, że robię wszystko na twojej liście i nie uważam, że te rzeczy są koniecznie złe, chyba że ciągle się zdarzają i mają realny negatywny wpływ na twoją produktywność.

To się nazywa proces iteracyjny i jest to podstawowa koncepcja we wszystkich nowoczesnych technikach tworzenia oprogramowania.