Jest to powszechny problem w każdym projekcie programistycznym imho i jako taki możesz skorzystać z dowolnej z koncepcji, takich jak Rapid Prototyping, DSDM. Można go łączyć z dowolnym stylem, np. Zwinnym (programowanie ekstremalne lub projektowanie oparte na cechach (moje ulubione)). Trzymając się wspólnych zasad, o których decydujesz na początku, gdy się z nimi mierzysz, trzymaj się ich (KISS, YAGNI).
Więc dla mnie jest to: - najpierw zbuduj podstawowy funkcjonalny „prototyp”, obejmujący jeden funkcjonalny blok popytu Ogranicz się do nurkowania w „to może być miłe” / „być może będę musiał użyć tego później” rzeczy, chyba że są NIEWIDOCNE. Powiedz sobie, że nie będziesz go potrzebować! (YAGNI). - Zapisz decyzje, które podejmujesz jako „konwencję kodowania” i trzymaj się ich, np. Tagi php: używam krótkich, ponieważ w moim scenariuszu argument… ma zastosowanie i… nie. - dodaj podstawową stylizację, ale ogranicz się ponownie.
Następnie rozwijaj kod, aż uzyskasz prototyp wyższego poziomu, który obejmuje więcej bloków funkcjonalnych. Zgodnie z tym, twój model css rośnie. Jak tylko podejmiesz decyzje, które wpływają na wszystko, co już zrobiłeś (zrobisz), przeczytaj je, podejmij decyzję i zapisz w konwencjach kodowania, dlaczego poszedłeś w lewo lub w prawo.
„Okrąż” swoją drogę do bardziej dojrzałego i końcowego produktu.
Nie bój się wielkich decyzji, z którymi możesz się zmierzyć, ponieważ martwienie się o nie może kosztować więcej czasu niż ustalenie go na drodze. Nie martw się też, że społeczność internetowa spogląda z ukosa na zmarszczone brwi, w końcu, gdy masz produkt, który działa, nauczyłeś się wiele, a wyobraźni oceniający zły kod źródłowy będą bardziej zadowoleni z następna rzecz, którą zbudujesz (zwróć uwagę na iterację tutaj).
Tylko moje 50 centów