Как правильно спланировать работу моего сайта до написания кода?
Я создаю веб-хостинг для игровых сообществ (по аналогии с GuildLaunch или GuildPortal). У меня возникли проблемы с опережением себя и такими вещами, как:
- Придумать лучшие способы сделать это позже, после того, как оригинальная идея уже реализована
- Реализация функции не будет работать (но закодирована на 90%) по неясной причине, которая была упущена
- так далее
Я знаю, что должен планировать лучше, но я не знаю, как это сделать правильно. Какова наилучшая практика для планирования сайта такого размера? В идеале, я хотел бы иметь документ, в котором изложены все аспекты веб-сайта, со всеми проработанными моментами.
Благодарю.
3 ответа
Может быть, вам стоит попробовать BDD (Behavior Driven Development). Огурец например.
Вы уже на полпути, осознав это!
Вы создаете что-то для кого-то другого, убедитесь, что вы точно знаете, что является основой сайта. Какие функции являются основой сайта?
Запиши все это
Напишите блок-схемы! это поможет вам кодировать ваши вещи!
не будь как: реализация его истории: создание страницы, создание макета, создание других вещей, получение оценок в переменных, ....! Я не могу передать переменные, потому что они не могут быть связаны с SQL из-за источника игры...
быть похожим на: реализацию hiscores: записать то, что нужно сделать: получение переменных, передачу переменных, список переменных, показать их на веб-странице. Затем подумайте, как вы собираетесь это сделать, прежде чем даже коснуться своей IDE!
Вы всегда будете думать, что вы могли бы что-то проще, это большая часть обучения!
Мне нравится думать о разных вещах, которые строго критичны для моего сайта. Сначала подумайте о том, как пользователь будет взаимодействовать с сайтом, какую информацию он захочет хранить или получить, и как он ожидает, что она будет выглядеть и работать. Напишите список всех этих функций, предоставьте как можно больше подробностей.
Возьмите этот список и отсортируйте его по степени сложности любой функции, ее влиянию на остальную часть сайта и важности этой функции.
Хорошая работа, вы только что написали спецификацию. Теперь вы можете написать любой код, который вы хотите, в соответствии с любой методологией, которую вы хотите (TDD или что-то подобное), но со спецификацией в руке он будет держать вас сосредоточенным на важных вещах. Если вы обнаружите, что работаете над чем-то, чего нет в спецификации, сначала спросите себя, действительно ли это должно быть в спецификации. Если это так, идите и добавьте это, но если нет, бросьте его на пол.
Избежать неприятностей, избежать получения 90% чего-либо только для того, чтобы обнаружить, что вы гонялись за красной сельдью, может быть сложно. Первый способ избежать этого - подумать о решении "шип", самом простом, глупом, возможно, сломанном решении, которое в основном может сделать то, о чем вы говорите. Решение с шипами обычно составляет менее 6 строк кода, иногда это всего лишь одна. Идея состоит в том, чтобы заставить его работать как можно быстрее, чтобы вы знали, что на самом деле работает. Затем вы можете улучшить решение по пику, чтобы оно стало полноценным, добавив поддержку для всех ключевых случаев, о которых вам нужно беспокоиться.
Другая вещь, которую вы можете сделать, - сосредоточиться на строгом автоматическом тестировании, как на модульном, так и на функциональном тестировании. Сделайте так, чтобы ваши тесты запускались как можно быстрее, чтобы вы могли их запустить и посмотреть, не сломали ли вы что-нибудь. Вы можете что-то сломать, потому что вы только что узнали, что то, что вы делали, неправильно, и вам нужно переписать это. Если у вас есть хорошие тесты, вы можете беспощадно рефакторировать свой код, и все же вы будете знать все, что вам нужно исправить, и точный момент, когда вы закончите, потому что ваши тесты сообщают вам, что все еще не работает, и что такое.