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

39

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?

soczysta Lucy
źródło

Odpowiedzi:

41

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.

Berin Loritsch
źródło
3
+1, dlatego zawsze kulę się, gdy ludzie mówią o serializowaniu obiektów do bazy danych -> a co jeśli jutro twoja klasa zostanie rozbita na wiele części, w jaki sposób deserializujesz bez utrzymywania starego kodu? Zdecydowanie wolę alternatywę Protobuf (dedykowane klasy do przechowywania / wymiany wiadomości), w której twoje podstawowe klasy mogą swobodnie ewoluować, a ty po prostu musisz dostosować warstwę serializacji / deserializacji.
Matthieu M.,
@ Matthieu - piszesz migrację bazy danych. Pisanie i testowanie rzadko zajmuje więcej niż godzinę. Ruby on Rails ma bardzo ładne narzędzie do migracji baz danych.
kevin cline
1
@kevin: chyba nie mamy tych samych baz danych, moje zawierają kilkaset milionów linii. Migracja nie jest opcją.
Matthieu M.
+1 - bycie zbyt dumnym / upartym, aby przyznać się do błędu, nie jest dobrą rzeczą. Niektórzy uważają, że przyznawanie się do błędów jest oznaką tygodniowości, ale większość prawdopodobnie będzie cię za to szanować, a na pewno jeśli twoją strategią radzenia sobie z poważnym błędem jest zaprzeczenie, że jest to błąd, ten drugi błąd może być śmiertelny.
Steve314
12

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.

ElGringoGrande
źródło
5

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.

FrustratedWithFormsDesigner
źródło
6
Krok 1: Utwórz diagram UML. Krok 2: Napisz kod. Krok 3: Wyrzuć diagram UML, aby nikt go nie widział i nie był zdezorientowany, jak działa kod.
kubi
4

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ę.

John Bode
źródło
2

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ść.

Piper Merriam
źródło
0

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

vartec
źródło