Це загальна проблема в будь-якому проекті розробки програмного забезпечення imho, і як такий ви можете отримати користь від використання будь-якого з таких понять, як Rapid Prototyping, DSDM. Поєднується з будь-яким стилем, наприклад, гнучким (екстремальне програмування або Feature Driven Design (мій улюблений)). Дотримуйтесь загальних принципів, які ви вирішили на початку, стикаючись з ними, і дотримуйтесь їх (KISS, YAGNI).
Тож для мене це: - спочатку побудуйте базовий функціональний «прототип», що охоплює один функціональний блок попиту. Обмежте себе від занурення у «це може бути приємно» / «мені може знадобитися повторне використання цього пізніше», якщо вони не є ОБОВ'ЯЗКІ. Скажіть собі, вам це не потрібно! (ЯГНІ). - Запишіть рішення, які ви приймаєте, як «умову кодування», і дотримуйтесь їх, наприклад, теги PHP: Я використовую короткі, тому що для мого сценарію аргумент .. застосовується і ... не. - додайте базовий стиль, але знову обмежтеся.
Потім розширюйте свій код, поки не досягнете прототипу вищого рівня, який охоплює більш функціональні блоки. Відповідно до цього, змусьте вашу модель css рости. Як тільки ви зіткнетеся з рішеннями, які впливають на все, що ви вже зробили (ви хочете), прочитайте його, прийміть рішення і запишіть у свої умови кодування, чому ви пішли ліворуч або праворуч.
"Обведіть" свій шлях до більш зрілого та кінцевого продукту.
Не бійтеся великих рішень, з якими ви можете зіткнутися, тому що турбота про них може коштувати вам більше часу, ніж виправляти її в дорозі. Крім того, не турбуйтеся про те, що інтернет-спільнота нахмуриться через плече, врешті-решт, коли у вас є продукт, який працює, ви багато чого навчилися, а творчий суддя поганого вихідного коду буде радувати більше наступне, що ви будуєте (помічайте ітерацію тут).
Тільки мої 50cts